Josh Speyer is CEO of US mobile mediation and monetization platform AerServ.

As a mobile publisher/developer, integrating your app across devices and marketing platforms is crucial to monetization, but it can be a fairly complex technical process that, for those just entering the wild world of marketing, can seem overwhelming.

This is especially true given the fact that new devices are constantly emerging and churn in the digital marketing space is never-ending as new platforms come to market, new channels become viable, and as M&A activity changes the landscape on a regular basis.

Time to bloat

Integration involves incorporating multiple SDKs into an app to enable advertising but, of course, no two SDKs are the same due to the fact that they are specific to the environments in which the app will run.

This means completely different code bases, different processes for building and deploying and a separate process for submitting to the app store.

Apple, for instance, requires a 1-2 week review and approval process and, if an app doesn't pass, it's back to the drawing board for the developer to fix the issues and resubmit for another review.

With Android, the process is much faster, but then it also has its own, different, set of guidelines and policies to which a developer must adhere.

The biggest challenge today is that every vendor and tech provider a developer partners with for monetization purposes wants their own SDK integrated into the app.

Ad networks and exchanges, servers, attribution and analytics tools, mediation platforms, retargeting solutions, etc. are all important elements of an effective mobile marketing strategy, but developers end up with too many cooks in their kitchens.

Creative tensions

This "SDK fatigue" is extremely common amongst app developers, especially indie developers and those without the support of a large publishing company and its marketing machine behind them.

These people who, after all, are techies, not marketers, often become frustrated with or confused by the integration process and can end up hurting their own revenue potential.

A developer might spend a week working on a new SDK integration, only to give up after running into roadblocks after spending hours of time on the integration. There is also possibility that a publisher might scoff at a new opportunity due to a required SDK integration, possibly turning their back on a great revenue opportunity.

Not to mention, app developers are protective of their creations, and rightly so, given the talent, time and resources that go into making an app.

No publisher actually wants to "taint" their carefully crafted app with the foreign code that goes along with integrating multiple and varied SDKs. The user experience is paramount to a developer, and the chance of disrupting that experience as a result of integration is unacceptable to them.

Each SDK integration requires development resources, time and money, and the developer must take time to integrate each one and ensure they all play nicely together. Again, these are developers, not marketers, and they want to spend those resources improving their apps and creating new ones rather than navigating their way through a cluttered marketing environment that most don't entirely understand.

APIs all the way

Publishers are clamoring for strategies and solutions that streamline the process, either by reducing the number of SDKs required or reducing the amount of development needed to complete the integration.

Using APIs makes the process run more smoothly, as they can be added, modified and removed without the need to update the SDK, re-submit to the app store or encourage end users to update to the most recent version.

There are a few challenges with ad networks requiring SDKs:

• When pressed for the reason why their SDK is required, most ad networks will tell you their SDK is necessary to render the creatives properly, whether they be interactive, or utilizing some data that the SDK picks up. This may be true today, but could be partially or completely resolved by using IAB standards for ad delivery. Instead of using custom delivery for interactive elements, networks and agencies could utilize MRAID and VPAID. And if the publisher has a single SDK for ad serving that can handle those IAB standards, they would be able to integrate all networks via tag or API instead of doing a custom SDK integration each time.
• There are too many ad networks offering the same exact thing. If I'm a publisher, I don't want to put 5 SDKs in my app if they're offering me the same ad product. In the absence of the above standards, some consolidation needs to happen in the space.

Developers need to push back on companies requiring a SDK integration and determine the true value, and whether it is truly necessary.

At worst, integration is a complex process that drains resources; at best, it's merely tedious and, in many ways, it is outside a developer's wheelhouse despite being a technical process.

However, there are multiple tools and techniques to smooth out the bumps along the way, so developers can get back to the business of developing with the confidence that their advertising/monetization strategy is moving forward effectively and efficiently.

You can find out more about AerServ's approach to ad tech via its website.