Beware of Buffer’s analytics

It took recent tweets via Buffer for me to realize that the analytics for click-thrus are not specific to my tweeted link: they are pulling from the aggregate of all shares using that same shortened link. For those of you that don’t know, the buff.ly links in Buffer are masking the bit.ly links. When you choose to use buff.ly link shortening in the Buffer App, it is really reaching out to bit.ly, creating a link—or in this case, using an existing one—and then masking it as a buff.ly link. (To prove this, type your buff.ly/xxxxxx link into your address bar, BUT be sure to add a + sign to the very end, as such: buff.ly/s8PGQR+ Hit return and you will see that it brings up a bit.ly analytics page using the same string of characters at the end. No harm there (though, in the discussion of link rot, that’s debatable.)

The issue I have is that the click-thrus displayed on my Buffer account are for all clicks on that link, even those that happened prior to you posting it. My recent post (seen below) uses a buff.ly link that 92 others have also used. Collectively, we referred 1850+ clicks to that page. When Buffer serves me my analytics, it is not parsing out just the clicks that happened via my post, but all posts with that shortened link on it.

Did you know about @twitterstories on @twitter? Curated, inspirational stories that started with a tweet: http://t.co/zmyMtQK0

— Tristan Denyer (@tristandenyer) September 14, 2012

You can see for yourself by visiting the shortened link with the + sign at the end: buff.ly/s8PGQR+

The problem

If you are using Buffer for your clients, and delivering them analytics straight from the interface, are you really serving them client-specific data? Or, are you delivering them data aggregated across multiple users?

If you set up your Buffer account to use the j.mp or buff.ly link shortening service in your posts, you are using shared shortened links. Link shortening service reuse shortened links, and do not create a new unique shortened link each time.

A couple of fixes

There are a couple of ways to do an endrun on this issue. The first is the more reliable, but will take a little time and management on your part to set up. The second is the quick-and-dirty hack.

OPTION 1: To track your links in your posts, you need to go to Settings > Link Shortening tab/section in your Buffer account and select “Connect Bitly” green button at the bottom. This will run the OAuth protocol to connect your bit.ly account with BufferApp.

You can also set up your own link shortening domain, and a good place to learn more about that is yourls.org.

OPTION 2: the easy work-around to forcing the link shorteners to create a new and unique short URL for you is to make the target URL unique. The website I was sending people to was stories.twitter.com/. And, as we saw above, 92+ other people were too. And anytime someone creates a short link via Buffer or Bitly they will use the same /s8PGQR URL for that Twitter Stories page. But, if we take the original URL, http://stories.twitter.com/, and add a query string to the end that is meaningless to the website, the link shorteners will see this as a new URL and serve up a new shortened link, unique to you.

To do this, add a query string and some characters to the end of the URL (after the /), like this: http://stories.twitter.com/?td (note the ? to start the query.) When I place this in Bitly, it serves me up a new, unique shortened URL that no one else has used: http://bit.ly/NunoBC

BUT! As with everything web, this will not always work for every website and server (depending on how they are set up to handle/block them.) And in other cases, you will be exchanging their query string for your own. Take the case of this article URL on CNN: http://www.cnn.com/2012/09/15/world/meast/embassy-attacks-main/index.html?hpt=hp_t1 Notice the ?hpt=hp_t1 they are using at the end. This particular string of characters happens to help their tracking/analytics. But, if you were to change their ?hpt=hp_t1 to something unique to you, like my ?td used above, you have a unique URL that you can use to get unique shortened links.

The best way to know if this will work on the website you are sending people to is to type out your unique query string (keep it short!) at the end of the URL in the address bar of your browser and hit return to try it out. If the page loads, you are in business and can use it in your Buffer/link-shortener.

In short

Let’s get serious: using Buffer analytics to tell your client that they got 3000 clicks to their page is not good reporting. Plus: How many were bots? How long did a human user stay? 3000 clicks and no re-tweets, is that what you were after? Is a click on a tweet real engagement? And on and on.

In today’s world, I do not count click-thrus to my pages via social media as engagement or a measurement of success. It’s akin to those old page view trackers we used to place at the bottom of our web pages in 1994. Success is based on how long they stayed on the page, how many other pages they viewed, and any follow-on actions such as comments, purchases or organic sharing via the page. And that is where Google Analytics and other in-page tracking comes in to play.

Buffer is a great and helpful tool, but I highly recommend you be wary of boasting your success as a marketer on the analytics it supplies alone.

UPDATE: Buffer just wrote a blog post “Brand new Buffer analytics for Twitter, Facebook and LinkedIn (Sep 18, 2012).” The notable fact is at the bottom, where they remind user” “One quick note to make your analytics even more accurate. If you want to have click data be 100% personalized for each link, make sure to connect your own bit.ly account under ‘settings’. The best part about this is that you can always also login to your bit.ly account and get more information from there.” So, while Buffer is updated and improved, the above post still applies: be cautious of what click-thrus were actually initiated by your post.