We said desktop, what about mobile app header-bidding? Since header element exists only in a browser and there’s no browser in the mobile app, the implementation of the header-bidding for mobile apps was unavailable for a long time.
The header-bidding for mobile apps is the next point in the ad tech technology evolution that helps app marketers, developers, and publishers to remove the boundaries of waterfall bidding. The better demand delivered by header-bidding technology means much better yield opportunities for publishers. As a result, the great share of publishers might shift from waterfall to header-bidding app monetization in the future.
At the same time, we have significant technological differences between mobile and desktop advertising ecosystems. There is a crucial distinction between waterfall, header-bidding desktop, and mobile app bidding, which mobile app owners should understand.
Header-Bidding Technology vs. Waterfall
During the waterfall, the publisher sets a CPM floor and keeps sending sequential requests for every advertiser in turns, until the impression is bought. Advertisers are lined up in the hierarchy, where bidders who reserved impressions are in the top priority. The inventory slot will be definitely sold, but not at the highest price as advertisers are not bidding simultaneously which restricts the competition.
Some of the potential buyers will never be considered. Here is a vivid illustration of the case:
In this example, an impression was sold to the second buyer with a bid of $3.25. However, the highest bidder was the third one who was ready to pay $3.30 but didn’t reach his turn in the queue. The publisher loses $0.05 of potential earnings that could have been gained if the third bidder wasn’t standing third in the priority line.
The header-bidding auction is not based on the hierarchy. A header code brings all interested advertisers up on stage at once and a Supply-Side Platform sells an impression to the bidder that offers the highest price. Everyone is equal in the auction so that only the bid amount defines the outcome. The increased competition among media buyers boosts the publisher revenues by 15-100%. By May 2018, 76.3% of publishers adopted the technology on desktop and mobile including.
Mobile Web Header-Bidding vs In-App Header-Bidding
Mobile web header-bidding is not much different from the desktop. Same rules: you insert a code into a header, it sends requests to demand sources, the buyers bid on impression, the highest bid wins. Solutions applied to desktop web work for mobile web as well, serving mobile responsive ads on user’s devices.
However, the mass adoption of mobile web header-bidding has gained traction only in the last two years, especially in the EMEA and APAC regions. According to Statista, the Americas accounted for the largest share of monetized impressions in Q4 2016 comprising 86% of the total number, when EMEA took only 13%. In APAC, mobile web header-bidding practically did not exist with its minuscule share of 1%.
We observe a drastic change in Q4 2017. Just in one year, the distribution leveled off: EMEA and APAC started to serve a far bigger number of impressions through programmatic header-bidding on mobile, occupying a share of 30% and 27% respectively and aligning with a 43% America’s share.
Mobile web CPMs also experience an amazing breakthrough due to mobile web header-bidding. CPMs in the Americas grew by 92% YoY, in EMEA — by 20%, and by 48% in APAC.
The header-bidding technology for apps, however, only starts budding. Even though there’s no header in a mobile app, it’s possible to connect an app to ad exchanges and SSPs through mediation platforms and integrated (SDKs) software development kits. The provider of in-app header-bidding solution provides their own SDK to the publisher or developer for free, which afterward is integrated inside the app. That’s a client-side wrapper header-bidding.
It’s worth to mention, the header-bidding solution providers have a connection only to the certain number of demand platforms, so it’s always worth to make sure they feature extensive network beforehand. Otherwise, the developers end up integrating too many SDKs from different partners. This significantly increases the app’s file size, downloading time, and causes the battery drain.
The (S2S) server-to-server in-app header-bidding mediation moves all “heavy” files to the cloud and doesn’t let them overload the app. Instead of using in-app SDK, the publisher needs to include only a small string of code in an app to start a unified auction. The server-to-server approach reduces latency and maintains a right balance between effective in-app header bidding and top-notch user experience.
But even this seemingly cure-all solution has its drawbacks. Firstly, it becomes harder to match cookies with advertisers because the auction is held on the 3rd party server instead of the browser, where cookies are usually stored. Secondly, S2S lacks transparency — you can’t track down the process as you could with client-side apps header-bidding unless you partner with an open-source S2S provider.
To maximize the benefits from mobile app header-bidding, we need to find a “golden mean” — a hybrid combination of server-side and client-side technologies. It gives publishers more control over their in-app header-bidding processes on the one hand and eliminates latency issues on the other.
For now, we offer mobile advertising SDK to ensure seamless in-app mobile header-bidding monetization experience for our clients. Extra-lightweight SmartyAds SDK wrings the most out of client-side technology, minimizing the latency and connecting publishers to the widest network of demand partners at once. Our SDK solution supports every popular app ad format including playable, video, and rewarded ads and helps you access the robust analytic tools for ad campaign results monitoring.