SDKs: Software Development Kits — or — Such Dumb Know-how?
A: There are multiple reasons why app developers have grown weary of SDKs, but in general it comes down to work and risk. Working with a partner via SDK is more involved than integrating via tag, API, or RTB – it requires development resources to integrate the SDK code, test the integration, and deploy. It also requires ongoing maintenance, updates, and QA to ensure no new conflicts have been introduced. In general, this means that a SDK integration takes more time and resources to complete than integrating a tag into an ad server. Once it is live, the SDK code has the risk of crashing the app, and when problems arise the app developer needs to remove the SDK or work with the SDK company to resolve any issues.
Q: What value does a SDK bring to publishers?
A: SDKs can bring a wide variety of functionality. There are companies that offer SDKs for analytics, marketing automation, push notifications, advertising attribution, video technology, and much more. In terms of advertising and monetization, the SDK brings a number of valuable features. The SDK handles the collection of data relating to the user’s device, the rendering and associated functionality of the ad unit, analytics relating to the ad events, fraud detection, viewability and audibility measures, processing and handling of buyer responses, and more. In short, a monetization SDK brings ad serving technology as well as unique ad campaigns.
Q: What are the negatives of SDK integrations?
A: There are a few challenges that SDK integrations pose. First, the SDK will increase the size of your app, which needs to be taken into consideration due to size limitations with the app stores and user’s downloading the apps to their devices. Second, developers that integrate SDKs need to be conscious of update schedules and maintenance of those SDKs.
A: When we look at the majority of SDKs in the space, primarily the ones offered by ad networks, they are very light in features and functionality. The main function of these ad network SDKs is to collect data from the device and render ads. In mobile, and in mobile video in particular, the ad units have largely all fallen into a specific template – we see a full screen video play, and it is followed by an end card. This functionality, as well as 90% of the other ad unit functionality seen across mobile advertising, could easily be accomplished using the functionality available in MRAID, VPAID, and VAST 3.0. If the ads were created using those specifications, it would be a win-win! The developer would have less SDKs to integrate, and the ad network would be able to access a greater pool of supply for their campaigns.
Q: Where do you see this heading in the next two to three years?
A: I think we’ll see continued consolidation in the ad tech space, which ultimately means less SDKs for developers to integrate. I think we’ll continue to see a shift towards programmatic, and a continued shift and greater adoption of these IAB standards. These are all positive signs and steps as the industry continues to evolve and mature, with mobile taking over as the dominant digital medium.
No comments yet