It’s Getting Harder And Harder For Mobile Ad Companies To Woo Developers

hero image


App developer Guy Tal isn’t interested in cold calls from mobile service providers he isn’t familiar with who want him to test their software development kit (SDK).

“I get approached by companies through email and at conferences all the time and, to be honest, I really can’t be bothered,” said Tal, CEO and founder of Appllica, a Tel Aviv-based Android game studio, whose apps have around 20 million downloads. “If it’s not based on a strong personal recommendation from a developer I trust, I won’t even consider it.”

It’s not just Tal who feels this way.

“We didn’t have a single prospective customer that didn’t show some aversion to the thought of installing yet another SDK,” said Andrew Boos, former founding CEO of Appfuel, an app cross-promotion startup that was acquired by TUNE in June.

These days, developers avoid installing new SDKs at all – if they can help it – or at least try to use as few of them as possible, said Boos.

Over the past two or three years, a mob of mobile ad companies sprang up to support the burgeoning app economy.

But as that economy matures, it’s becoming increasingly difficult for mobile ad startups to get their SDKs integrated. Most developers have already chosen their partners. It’s cold out there for a newly launched company looking for SDK installs.

That doesn’t mean SDKs don’t provide developers with a vital service. Rather, it means that they are being inundated by too many service providers. It’s an industrywide phenomenon. Agencies and marketers are also experiencing their own versions of vendor fatigue.

“The days where developers are implementing dozens of different SDKs are ending if not over,” said Omer Kaplan, deputy CEO and co-founder of app discovery platform ironSource. “Most developers, especially the larger ones, are limiting the number of partners they work with. Even just a year ago, it was significantly easier to get a developer to integrate an SDK than it is today.”

While it’s true that news apps are being developed all the time, most of them are coming out of established studios with existing SDK relationships.

“If a developer likes a certain SDK, they’ll usually use it in more than one of their apps,” said Gil Dudkiewicz, CEO of mobile ad network StartApp, whose sees around 300 million downloads of its SDK per month. “And a developer has 10 or 20 apps, they’ll probably use it in all 10 or 20.”

How Did We Get Here?

SDKcrunchSDKs are simply pieces of code written by third parties that interface with the apps in which they’re integrated to perform specific functions. Some SDKs help developers tackle testing, other deal with measurement. There are also SDKs that handle analytics, monetization, data collection, security measurement, customer support, crash reporting or other necessary services.

Both small developers (those with 10,000 installs or less) and medium-sized developers (10,000 to 1 million downloads) have an average of 9.6 SDKs integrated into their apps, according to Datanyze, a sales intelligence platform that recently launched a mobile solution to help companies identify which apps are using which SDKs. That number jumps to 14 for large app developers with 1 million installs or more.

Those are a lot of relationships to have to manage.

Before Appfuel became a part of TUNE’s unified marketing console, Boos and his co-founders were constantly courting developers looking for SDK installs to enable devs to fetch and display Appfuel’s cross-promotion ad units within those developers’ apps.

“We ran into huge friction, though, because asking folks to install an SDK is a huge vulnerability for developers to take on,” Boos said. “You’re opening your front door to a bunch of potential problems.”

Club SDK

Mainly, it boils down to what Boos referred to as a “basic fear of the unknown.” A foreign piece of code like an SDK could crash an app or introduce bugs that mess with the user experience. Developers also need to make sure that the SDKs they integrate are compatible.

“With each SDK that gets integrated, great care must be taken to keep it up to date with each app upgrade cycle,” said Boos, noting that developers that accumulate a significant number of SDKs are on the hook to monitor and perform regular upgrades in order to keep their apps running smoothly.

If developers do their due diligence and rigorously test an SDK and audit its code before deploying it, crashes and bugs can likely be avoided – but all of that effort represents valuable time spent away from developing their core apps, Boos said.

It’s a lot of work, and developers are time crunched as it is.

For his part, Tal tries to keep his ad network-related SDK load as streamlined as possible. He doesn’t consider SDK testing all that much of a hassle, but he already has a small stable of favorites that give him favorable returns – StartApp, AdColony and ironSource are his go-tos – and there isn’t much at this point that’ll convince him it’s worthwhile to switch.

“The rates would have to be at least twice as much as I’m getting now. I wouldn’t change for a couple of percentage points of increase here and there,” Tal said. “It’s more important to me to have a good relationship with the company and to have open lines of communications – and that takes time to develop.”

That said, Tal is thinking about testing more regional service providers down the line. Local providers can often perform better than the big guys in specific, smaller markets.

One SDK To Rule Them All?

Some larger developers don’t seem to be as concerned with SDK bloat. They build a lot of their own technology in-house and have the resources to manage wide-scale testing. The only consideration behind whether it integrates a new SDK is whether it can get better scale or higher ROI.

TalkingTomOne such developer is Outfit7, the multinational studio best known for its Talking Tom and Friends apps, each of which has an average of 15+ SDKs integrated.

But Outfit7 is still very particular about who it works with. Networks need to come highly recommended and prove their ability to perform. And even after Outfit7 integrates a dev kit, it continues to put that SDK through its paces.

“It’s a process of constant due diligence,” said Outfit7 CRO Mika Kuusisto.

SDKs aren’t the only option, though. APIs provide developers with a viable alternative that allows them to bypass the need to integrate foreign code into their app, said Boos.

There are pros and cons, though.

SDKs exist as the interface between an app and a service provider’s API, which means that developers don’t need to build that interface themselves. If a developer opts for direct API integration, however, the process is generally long and complex, requiring a “deep understanding of the API layout” and code that has to be “written from scratch,” Boos said.

For that reason, the market is moving toward greater consolidation – meaning the use of fewer all-in-one SDKs rather than lots of separate smaller ones.

“The ideal solution will eventually be consolidated into a single or semi-single SDK that will be able to provide all or almost all of the offerings that developers need,” said ironSource’s Kaplan.

A number of companies are already moving in that direction. IronSource, for example, claims to be working on product, while Urban Airship recently announced a mobile streaming data tool, the “broader mission” of which is to “make mobile information accessible to the entire business, from analytics providers to marketing automation platforms, through a single SDK,” said company co-founder and senior product director Michael Richardson.

The “SDK convergence” is a big part of what’s driving M&A activity across the mobile ecosystem, Boos said.

“As the emerging winners work toward the ‘one SDK to rule them all,’ or an SDK that can take care of all of an app’s external service needs,” he said, “they often find it makes sense to acquire these adjacent service providers in order to merge SDKs.”


Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>