Twitter and the Walled Garden

In August 2012, Twitter announced the launch of API 1.1, an API suite that would be far more marketer-friendly. For good reason (namely the need to monetize the platform), Twitter needed to appropriate its API for inclusion of paid tweets and add more robust tracking, targeting, and implementation of marketing campaigns. This included the following measures:

    1. Required OAuth authentication on all API points
    2. API rate limiting
    3. More sophisticated “developer rules of the road

Additionally,  Twitter imposed a 100,000 token limit on existing, third-party Twitter clients.  Unfortunately, as full implementation of Twitter’s API 1.1 concludes today, it is worth understanding how the new API brings Twitter roundabout to the consumer experience, turning it into a “walled garden” akin to Facebook.

To understand the draconian effects of the new API on consumers is to understand the history of Twitter. Twitter was launched in 2006 at the SXSW festival. As an early adopter of many internet technologies I opened my first, personal account almost exactly a year later (putting me in the first 0.22% of Twitter users). So I’ve seen Twitter through server crashes, API rate limiting, fail whales and the likes. The early stages of Twitter existed before the deep penetration of smartphones and app proliferation; Twitter largely existed through SMS and the web as a way for a user to send mass messages to his network.

Additionally, unlike Facebook “friends”, Twitter didn’t require the reciprocated connection for information to be disseminated. The early versions of the Twitter API programming were  kept relatively open, allowing developers to build third-party desktop clients, web-based clients, and eventually, more smartphone clients. This gave users extreme latitude in freedom of choice in how to navigate the Twitter experience–that is to say, short 140 character bursts  to the user’s network. Different clients have had different features that users have adopted as they prefer–ease of use, accessibility, aesthetic, use of columns, search features, display of external content, refresh speed, and preferences.

The infrastructure was rather unsophisticated and crashed frequently–particularly during peak usage periods. For this reason, Twitter instituted its API rate limiting, which meant that any time the Twitter servers were pinged(requested) outside of SMS/twitter.com/the official Twitter app would count to this rate (June 2007 – 1440 requests in 24hrs, May 2008 – 70/30/70 requests per hour, July 2008 – 100 unauthenticated requests per hour, January 2009 – 20,000 requests per hour, June 2010 – 350 authenticated requests, 175 unauthenticated requests per hour, March 2013 – 180 authenticated requests per hour). These requests may be Twitter searches, profile views, embedded content views, Tweetstream refreshes,  and so forth. Multiply that by the simultaneous use of clients on multiple devices and the API limit can be reached rather quickly on third-party clients (e.g. I use HootSuite on my laptop, Twicca on my phone and tablet, and Falcon Pro on my tablet as well).

It becomes evident that, aside from the 100,000 token limit on third-party Twitter clients, Twitter has also closed the wall around third-party API requests, putting them back to nearly 2008 (n.b.– in 2008, Twitter had 3 million registered users; in 2013, Twitter has 500+ million registered users). For Twitter “power users” who frequently view profiles, refresh their streams for breaking news, use outside apps to post/pull from twitter, etc, this is a devastating change that conflicts with Twitter’s growth trajectory and technical scalability… unless users use twitter.com or the official Twitter app… those don’t count toward API requests. Rate limiting killed Coca-Cola’s use of Twitter for a multiscreen advertising campaign during the Super Bowl, as Coca-Cola doesn’t use twitter.com.

To put the nail in the coffin of consumer choice, Twitter yesterday announced the retirement of its TweetDeck desktop and app support (n.b.–TweetDeck started out as a third-party client until it was purchased by Twitter in May 2011, making it a viable alternative with more features and functionality than the official Twitter client). This move, along with the API rate limiting and the 100,000 tokens, officially launches Twitter’s venture into completing the wall around the garden. Effectively, it has pigeonholed any external development around the Twitter platform–development that led to the company’s explosive growth–and near mandates users to use its own software. The sacrifice of TweetDeck is nothing, if not symbolic of this shift.

I mentioned above how this is great for marketers; rather than risk third-party work-arounds for API 1.1, Twitter tightens the reins in advance of a long-speculated IPO. It demonstrates via Promoted Tweets and Promoted Trends that it can effectively monetize social. It forces any remaining developers to ensure a consistent experience, inclusive of the advertising that brings in significant revenue. And, as I teach my Internet Marketing students, it’s reaches a significant amount of eyeballs–possibly more so than Facebook display advertising.

This could have all been strategized in a more flexible manner, rather than in a muscle-flexing manner. Rather than bring 500+ million users in 2013 back to the system of 2008, Twitter could have easily required new developers to integrate the advertising software (perhaps in exchange for a proportion of revenue). It certainly didn’t need to lower the API rate. And it didn’t need to limit 100,000 tokens per developer. Twitter grew its ecosystem , the result of an open architecture system; it is killing that system in favor of Wall Street and at the expense of the user. Like Facebook’s IPO, Twitter API 1.1 may be the move that jumps the shark for its most devoted users.