The Twitter Crackdown
I think most would agree that Twitter is taking an increasingly antagonistic tack with its third-party developers.
First, Twitter banned third-party clients from providing their own “in-stream” advertising — which in my opinion was a necessary move.
But then, Twitter made it clear that it intended to dominate the Twitter client market. It’s reasonable that Twitter would want to control its own destiny rather than rely on developers to guide the user experience ship, but those developers were left wondering exactly where they stood with Twitter. Was Twitter simply providing fair warning that they intended to compete with their developers? Or would they go further, actively undermining the many apps that had helped make Twitter the popular service it is today?
It now seems to be the latter. Twitter is actively degrading the user experience on third-party client apps by requiring them to jump through extra authorization hoops that Twitter’s own clients can ignore. Third-party developers are understandably displeased.
As Ars Technica points out, “Twitter clearly felt threatened by the ease with which users were able to switch to alternative clients when Twitter tried to inject intrusive ad-like elements in its own application.” Yes, this is likely further fallout from the #dickbar debacle. Twitter realized that as long as third-party alternatives continue to thrive, its own ability to advertise via its clients was limited. It’s too easy for users to abandon Twitter’s in-house apps.
It doesn’t have to be this way. Rather than seeing third-party Twitter clients as The Enemy, Twitter should view them as ad-serving opportunities. And they can accomplish this by simply doing what many assumed they’d end up doing all along — inserting ads into user’s tweet streams.
Twitter can’t control whether a third-party client gives as much prominence to promoted trends as Twitter would prefer. But Twitter absolutely controls which tweets make into your timeline. When a third-party client requests your current “home” timeline via Twitter’s API, it receives every tweet Twitter chooses to send it. If Twitter decided tomorrow that some of those tweets would be ads, well — every existing API-compliant Twitter app would begin showing them, automatically, with no other change being made.
(Of course, third-party developers could update their apps to examine each tweet [perhaps by authorship] and hide promotional tweets after pulling the home timeline. But Twitter could simply declare this against its terms and revoke the API key of any app that tried it.)
With this change, Twitter and its developers would all be on the same team, expanding the reach of Twitter’s advertising. What’s more, should Twitter decide to allow users to pay a monthly fee to avoid seeing ads, it could easily do so and third-party clients would again automatically reflect the change. Users who upgraded to the paid membership would simply no longer be served ads in their tweets, and clients would carelessly serve up the new timelines.
So why doesn’t Twitter go the in-stream advertising route? (They already provide Promoted Tweets, but only for search results pages and as follow-ons to Promoted Trends.) I suspect Twitter is worried about user backlash. But what’s the alternative? Twitter’s best recent advertising idea turned out to be far more obnoxious than any in-stream ad would be. Promoted Trends in the #dickbar overlaied the content users were interested in and were likely less effective than in-stream advertising would be. While a trend is a context-free word or phrase that provides no reason to follow up, an in-stream ad can convey as much content as an ordinary tweet.
More importantly, in-stream advertising aligns Twitter’s goals with those of its developers. Under such a model, both parties gain from any Twitter client succeeding. And users don’t have to give up the rich ecosystem of Twitter clients and services that we’ve become accustomed to.