SDKs (Software Development Kits) have provided a unique opportunity and puzzle for our development teams. In the past, the distribution was small and there was often frustration about the challenges we were seeing in SDK development and integration. However, because mobile is such an important priority, we have been investing in a better understanding of where we are and what we need to change to develop improved products.
What Is an SDK?
To better understand the nuances of SDKs, it is important to first understand what makes up an SDK. Aside from basic code and the occasional sample app and license, SDKs include documentation and instructions on implementation. Within ad tech, they frequently are necessary for app integration with an existing platform and to update existing app capabilities. Simply put, they provide extra support and functionality to the apps they are integrated with.
In-app monetization SDKs are different
In ad tech, there is a clear divide between legacy desktop web-based and in-app based integrations. Developers working on each type often do not have a full understanding of the challenges involved in the other type. As a result, many attempts by legacy web-based ad tech players to enter into in-app ad tech have simply not been successful. It’s this lack of understanding of the other side that is at the core of failed attempts. Simply put, legacy web-based tech does not translate into in-app ad tech success.
App Developer Priorities
In-app ad tech success starts with understanding that the primary integrator is an app-developer. The app-developer is the one who will be integrating the SDK. As a developer, the integrator will want to make sure the integration works, monetizes as expected and doesn’t crash the app. Here are their main priorities:
Monetization is a prime motivation for the developer to integrate an ad tech SDK. Thus, the SDK will need to support multiple ad formats. Additionally, the SDK must support high-quality demand integrations and have quality filters in place. This is, of course, also expected in web-based ad tech.
Simplicity of integration helps speed the process. App developers are very busy, so if an SDK is not simple to integrate, takes too long or is too complicated, you risk getting cut. Most app companies have small monetization teams, so an SDK needs to operate pretty seamlessly.
Stability and reliability are paramount. Coming from a legacy web-based environment, it’s easy to underestimate how important an SDK’s stability is to an app-developer. Unlike web-based ad tech, an SDK is shipped software. This means that the SDK is distributed as part of the app’s code-base to app developer’s customers.
If there is a problem with the SDK, it’s extremely hard to fix it. In a web-based environment, if there is a problem with the code, the server gets the bug-fix and all is well. In an in-app environment, the app dev fixes the code and then hopes that the upgrade with the user base goes quickly and smoothly. If your SDK is responsible for a major headache (and revenue loss), your SDK might not make it. Testing, testing and more testing is needed to ensure an SDK will be stable and reliable.
Code footprint is also very important to an app developer. If your SDK is consuming a large amount of device resources, the app-dev will not want to integrate. Your SDK must be a good, solid, well-behaved partner for the app developer.
UX Priorities
The app developer is also laser focused on the consumer user experience (UX). Most have very sophisticated drop-off models and analytics to know how each change affects their distribution and revenue stream. Other key UX factors include:
Connectivity robustness, which means the app needs to behave well and operate smoothly even though the carrier connection may not be clean or fast. This is very different than the web-based ad tech environment, where most connections happen on a fast, clean Wi-Fi connection. Further, consumers pay for carrier data connections on a metered basis. An SDK should eliminate the need to deliver payloads over carrier connections and only download payloads during Wi-Fi sessions, then cache for later use.
Battery life is also a major UX concern. A consumer will not be happy if an app (and the SDK) drains their battery. Pay close attention to this.
What’s Next?
At PubMatic, we are working hard to provide a great developer experience with our SDK technology and we strive to be an empathetic partner for increased ad monetization. Stay tuned for some great in-app technology soon to come. In the meantime, check out additional mobile insights here and download our recent Quarterly Mobile Index.