As you probably heard, Twitter recently tightened the noose around API developers with new limits and restrictions. Twitter is possibly the biggest public API provider today, with 13 billion API calls a day in 2011. This makes sense if you’re Twitter, and are trying to increase your revenue from ad sales – you need people on your site, consuming those ads, not using API apps to consume their feed indirectly. At the same time, they reduce their biggest cost – supporting their API infrastructure.
But if I were Twitter, I’d go about it a different way – why put hard limits when you can just add tax instead? charge a small amount for every API request over the limit (or sell bulk packages) – suddenly you have a major revenue stream, and API developers still get a chance to scale using your API.
Soft cap vs. Hard cap
If you’re into sports, this is somewhat similar to the difference between the salary cap system implemented in the NFL vs. the one implemented in the NBA. The NFL has a hard cap, which means teams have to stay under a specific total number for player salaries at all times. The NBA on the other hand, has a soft cap, which allows teams to exceed the cap number by paying increasingly larger tax for every dollar spent over the cap.
Both of those cap system exist as an attempt to create competitive parity in those leagues, by preventing teams from bigger markets outspending teams from smaller markets. Each has its own merits in the context of sports competitiveness, but in Twitter’s case there is no reason for a hard cap at all. What does Twitter gain by putting a hard limit on API usage?
A Win-Win Scenario
Twitter’s focus on monetizing through ad sales already created a small rift in their user base. People concerned with becoming the product and not the client in an ad-driven ecosystem, have started a new initiative for a subscription based Twitter clone. Personally, I do not believe such a model is the right direction as the network effects of Twitter are what make it valuable – and you can’t have the same effects with a paid service (because of the barrier to entry).
But if Twitter found API taxing a more profitable channel than ads, suddenly it has motivation to allow federated usage of its data and can focus again on delivering the best signal-to-noise ratio in social media (as it has in the past). Now it’s the data (and access to it) and not the users that is the product. Developers should be satisfied knowing that they can scale beyond arbitrary, fixed limits (even if it means they have to pay), and at the same time it addresses the issues disgruntled users have with the service. (By the way, consider this story as a precaution for Twitter advertising)
Perhaps (even likely) there is more to it than I’m aware of, but it seems to me that it’s the most obvious way for Twitter to monetize going forward.
To know when the next article is published, please subscribe to new articles using your Email below or follow me on Twitter.