Over the past few years, app developers have begun to implement more advanced programmatic capabilities, like parallel bidding, into their monetization stack. This places the dual burden on developers of finding partners that have a robust and stable SDK plus a programmatic ecosystem of tools, services, and demand relationships to support their monetization goals.
With these developments and painpoints in mind, we worked hard to develop our OpenBid SDK technology. Given the recent release, I’d like to share what some of the larger technology goals are for OpenBid and how they benefit programmatic app publishers and developers.
Make It the App Developer’s Friend
First and foremost, we envisioned our new SDK from the perspective of an app developer. We took special care to empathize with what app developers look for. As developers ourselves, we continually ask “would I, personally, want to use this SDK?”
Every aspect of how we approach this SDK is first tested by that question. We know that as developers, we would want great documentation—both accurate and helpful. Additionally, as developers, we would want an SDK API that is simple to integrate, lightweight, and very stable. Perhaps most of all, we would look for the most modern “header-bidding” approach with the most experienced partner in programmatic advertising.
Focusing on One SDK
App developers are experiencing “SDK Fatigue” with about 20 unique SDK integrations, on average. The reason: SDKs often present a point of failure and maintenance. PubMatic’s SDK leverages our server-side parallel bidding (a.k.a. “header-bidding”) auction to get the best possible price for your inventory. We decided that we would have the parallel bidding environment right from the start, so it would be a pure implementation.
Further, there is no need to integrate multiple SDKs to render. Our SDK takes care of rendering the ad and managing all the aspects of the auction across multiple demand partners, automatically. We also take on the challenge of integrating any other required industry libraries, like Open Measurement Viewability. To you, as the developer, you see one single, very lightweight, very functional, highly-valuable SDK.
Easy Does It
As developers, we would also want an SDK that is easy to integrate. When the teams designed our SDK API, we had the goal of making it familiar and simple. Our API is compatible with many SDKs in the market, which is completely intentional. To create a simple integration, we held a number of focus groups with developers who had varying degrees of expertise in ad tech SDKs (or none at all). We got a lot of great feedback and found that nearly everyone in these groups was able to successfully integrate our SDK into a test app in less than an hour.
Testing, Testing, Testing
One of the major goals for OpenBid was for it to be durable and stable. To that end, our developers made testing and quality the highest priorities. We start our development with “how do we test this new feature?” as the first requirement for code design. Our team is highly integrated and our test engineering team has built-out a powerful platform that utilizes device farms to get great device and OS coverage. Our test matrix tests hundreds of combinations of devices and operating systems.
During our focus groups, we even had a session called “Break Me, Please” and challenged the group to find cracks in the design. Interesting results for sure but happily no crashes!
The focus group tests also allowed us to test our documentation and code during. We know the important connection between great code and documentation; our documentation intentionally has an app developer focus to make this SDK something they can use to gain incremental revenue, without hassle or additional effort.
What’s Next?
As developers, we’ve incorporated all our programmatic expertise into a neat package that is simple to deploy. It wasn’t easy, but then again, if it were easy it wouldn’t be as cool. To learn more about OpenBid, check out our solutions page or contact us.
