Stop using shortened URLs in tweets
August 31st, 2011 at 10:06 am by Dr. Drang
Twitter doesn’t want you to, and it’s changing to make you do what it wants.
I am, of course, talking about third-party shorteners like bit.ly and goo.gl, not Twitter’s own t.co service. Twitter really likes t.co. Not only does it use it to automatically shorten long URLs like http://www.leancrew.com/all-this/2011/08/twitters-shortened-links/, as of August 15 it’s been using t.co to reshorten small URLs like http://bit.ly/qhFLMk.
I wrote about this a few weeks ago in the context of changes I was making to Dr. Twoot. Now I think it’s time for most of us to just give up our favorite third-party shorteners and let Twitter do it. Why? Two reasons:
- The carrot: If you do things the Twitter way, the Twitter web site and official client apps won’t show an ugly and inscrutable
http://t.co/xxxxxURL, they’ll show a reasonably nice looking URL that points to the original site. Other apps can do the same—and many are—by using Tweet Entities. - The stick: Twitter’s going to shorten your URL whether you like it or not. Only URLs that are shorter than 20 characters will escape the
t.coreshortening. That’s a pretty strict limit; of the shorteners in common use, onlyj.mpslips in under the wire.
Update 8/31/11
The stick just got bigger. Twitter announced this afternoon that all URLs, regardless of length, will get the t.co treatment as of October 10. So j.mp won’t be immune for long.
Here’s a tweet in which I pasted the full URL and let Twitter shorten it for me:
Adapting to Tweet Entities and t.co-shortened links: leancrew.com/all-this/2011/…
@drdrang Dr. Drang
The ellipsis doesn’t allow you to see the whole URL, but you at least can tell that it points to this site. And if you hover over the link, you’ll see the full URL in the status bar.
Compare that to this tweet, in which David Heinemeier Hansson included a bit.ly shortened link.
Rails 3.1.0 is out w/ asset pipeline, HTTP streaming, jQuery default, and a trillion other cool new things: bit.ly/qhFLMk
@dhh DHH
This gives you no sense of where the link will take you, which is the traditional problem with shortened URLs.
Vanity shorteners, usually tied to a specific company or site, used to be the only way around the anonymity of shortened URLs, but they are aren’t that helpful in a world of Tweet Entities. Does the URL in this link,
Floodwaters Isolate 11 Vermont Towns nyti.ms/oqBsSZ
@nytimes The New York Times
give you any more information about where the link goes than the URL in this one?
A quick test. Pay it no mind.
nytimes.com/2011/08/31/us/…
They both point to this NY Times article.
I suppose professional Twitterers, like the people who post for the Times, may still want to use third-party shorteners because they can provide traffic statistics—useful if you’re trying to determine what brings visitors to your site. But for the rest of us, letting Twitter do the shortening for us gives our readers the most useful links for the least effort.
August 31st, 2011 at 1:19 pm
I wholeheartedly agree. I think more people would do this if they understood t.co, which I think Twitter has done a poor job of.
The other thing to consider is that many people use URL shorteners like bit.ly for the purpose of analytics, which I don’t think is a bad idea.
I recently wrote a post on my blog arguing that Twitter users, especially brands, could get the best of both worlds by implementing a custom “short” URL that isn’t really short. So in your example above, the New York Times might use the URL
nytimes.com/floods-isolate-vermont. (Not the greatest example, but you get my idea.)This would allow NYT to get analytics on that link, but also provide some additional context to Twitter readers.
August 31st, 2011 at 6:15 pm
Is there some reason why they can’t just uses the HTTP referrer?
August 31st, 2011 at 9:52 pm
The HTTP referrer can’t be trusted to give you all the visitors that came from a
t.colink on Twitter. Included in the Tweet Entities are 3 URL fields:url, which contains the shortened link, e.g.,http://t.co/xxxxx.display_url, which contains what you see on the Twitter web site, e.g.,nytimes.com/2011/08/31/us/….expanded_url, which contains the original link, e.g.,http://www.nytimes.com/2011/08/31/us/31floods.html?_r=1&smid=tw-nytimes&seid=auto.When a Twitter client makes a link, it could do it via
but it’s more likely to use
because it’s more direct. In the latter case, the HTTP referrer won’t contain the
t.coURL.September 1st, 2011 at 12:33 am
I thought there was some reason, but still won’t the “direct” link still contain a referrer.
From Wikipedia
September 1st, 2011 at 8:51 am
Not if the visitor is coming from a Twitter client app instead of a web page.
I suspect that most Twitter clients don’t trigger a referrer at all, so those visits look like direct traffic. A notable exception is Twitterrific. I can tell from my site logs that Twitterrific does some HTTP header magic to set the referrer to
http://iconfactory.com/twitterrific/#iPhoneorhttp://iconfactory.com/twitterrific/#iPad, which is a cute trick to let Icon Factory’s advertisers know when visitors to their sites have come from Twitterrific. That non-advertisers see the same referrer is just a side effect. I don’t know this for sure, but I’d guess that the non-free version of Twitterrific doesn’t add the extra HTTP header.September 5th, 2011 at 7:59 am
I totally agree with you but there is another side of the story to be told, how about photos posting links? links like http://twitpic.com/ now these links are shortened automatically from apps like Twitter for Mac, iPhone, Echofon, and other apps.
September 5th, 2011 at 2:01 pm
The image links do get shortened, but clients that support Tweet Entity URLs, which should be all clients soon, will show that the link is to TwitPic, yFrog, or whatever.
Tweet Entities also have a provision for images uploaded directly to Twitter, but client apps are just now starting to support it (Tweetbot, for example, added Twitter as an image upload service only in its most recent update). As support becomes more widespread, my advice will be to forgo yFrog, TwitPic, etc. and just use Twitter for images, too.