Bringing Header Bidding to Life for Mobile Apps

Fyber in-app header bidding unified auction breaking down the barriers

Have you felt it?

There was an awakening in the ad tech industry.

As if thousands of publishers suddenly cried out in joy.

No, not the awakening of the Force from Star Wars. An awakening of a digital advertising solution called header bidding. The solution granted publishers greater control over yield management, more transparency into the true value of every ad impression, and a fair competition among all sources of demand. And the most significant impact of all was, not surprisingly, more ad revenue.

Header bidding was a stark departure from the publisher waterfall setup Twitter logo share, the prevailing method for desktop and mobile web publishers to monetize with ads programmatically.

In fact, it didn’t take long for header bidding to supersede the waterfall’s stronghold on the ad tech industry as the preeminent setup for browser ad delivery. Within months, the majority of top websites integrated header bidding support. And in August of this year, Facebook claimed that over 70% of the top North American web publishers now monetize with ads via header bidding. Twitter logo share

But what about mobile app and game publishers?

Header bidding has cured web publishers of the toxic waterfall. As the name implies, header bidding involves injecting code into the head element of a website. Native mobile apps don’t have a web page or head element, for that matter. But the idea header bidding was built on—putting control of the auction in the hands of publishers, where they themselves simultaneously reach out to multiple demand sources at the same time—is an idea that can manifest in mobile app publishing—only not through the head element, of course.

In order to fully understand how the idea of header bidding can come to life in-app, we’ll uncover the origin of header bidding on the web, how header bidding swiftly collapsed the publisher waterfall, and what we’re currently building at Fyber to bring the technique of header bidding to life for mobile app and game publishers like you.

Unravelling header bidding’s origin

The true origin of the header bidding method is somewhat shrouded in mystery—kind of like the debate behind who built the Stonehenge monument.

Some say the term header bidding was first seen in an AdExchanger article on June 18, 2015, titled “The Rise Of ‘Header Bidding’ And The End Of The Publisher Waterfall.” But the header bidding technique was already being utilized by web publishers prior. The term header bidding just hadn’t been widely adopted yet. Rather, the concept of header bidding was just referred to by other monikers, such as pre-bidding, advance bidding, and tagless (even though JavaScript tags are a part of header bidding).

Once the AdExchanger article hit the web, though, header bidding started to become a searched term on Google, as Google Trends shows. Now everyone’s ears perk up when they hear the word “header bidding.” Twitter logo share

The rise of header bidding

Header bidding was born out of the desire to circumvent the leading ad serving platform at the time for the large chunk of web publishers monetizing with ads—Google’s DoubleClick for Publishers or, simply, DFP. With DFP, web publishers were able to manage multiple sources of advertising providers—be it direct deals with advertisers, ad exchanges and DSPs, Google’s own ad exchange (commonly referred to as AdX), and house ads (ads promoting a publisher’s own content).

DFP, like many web-based ad servers, operates under a sequential waterfall method. In essence, a publisher would manually order demand sources—like direct buys, RTB demand, and house ads—based on their average historical CPM. So, the demand source in the first position would get the first opportunity to supply an ad, even if the source didn’t want to act on the impression at all. The opportunity to respond to the ad request would then move to the demand source in the second position, and so on and so forth until a demand source that wanted the impression filled the ad request.

Ad tech waterfall setup

Many publishers felt that Google’s inclusion of AdX in the waterfall meant that the search giant was giving itself an unfair advantage over other demand sources, taking the most valuable ad impressions to itself.

With header bidding, all demand sources would be offered an impression at the exact same time Twitter logo share, not in any set order and well before calling DFP, severing Google’s ability to handpick the best ad impressions. Ultimately, this created a unified auction, with demand sources competing side-by-side, helping publishers maximize their fill rate and overall ad revenue.

History repeats itself

“Once an idea has taken hold of the brain it’s almost impossible to eradicate,” said Leonardo DiCaprio in the movie Inception. Header bidding has already stuck in the collective subconscious of the ad tech industry on the web. It’s only a matter of time until header bidding, in other words a unified auction, sticks in mobile in-app. At Fyber, we’re currently working on a solution to level the playing field for advertisers, where all of the different types of demand compete within a fair, unified auction.

This is a big change from our current mediation platform, which operates on a similar sequential waterfall setup seen in the web space, using a predictive algorithm to estimate the eCPMs of demand sources. As such, we’re figuratively knocking the waterfall down, flattening it to where demand sources compete in real time and side-by-side.

As such, we’re figuratively knocking the waterfall down, flattening it to where demand sources compete in real time and side-by-side.

What’s special is that mediated ad networks, RTB demand sources, and everything in between will gain the ability to compete together on 100% of impression opportunities, not just the small percentage of impressions they would see based on their position in the waterfall. Mediated networks in particular will be able to compete in this real time, unified auction, bidding simultaneously with all other types of demand—all the while maintaining their direct SDK integration with publishers.

None of this would be possible without putting together the best technologies and ad tech expertise across Fyber’s sister companies, including Inneractive, Heyzap, and Fyber RTB. Together, we’ll achieve the goal in bringing a unified auction for mobile apps and games to advertisers and publishers such as you. Stay tuned!

Read these next

Contact Us

    By sharing your information you are agreeing to receive communications in regards to any questions or requests submitted on this form. Fyber will keep your information solely for internal tracking purposes and will not use this information for any other purpose. You may request to delete the information provided at any time.

    If you send us a message by clicking the "Send" button, we use a recaptcha service provided by Google LLC to check whether the message was sent by a natural person or a computer program ("bot") in order to ensure that only valid user requests are forwarded to us. Google LLC processes personal information from your browser, such as your browser settings and your click behavior on this screen. Please refer to the Privacy Policy for further information on data processing procedures of our third-party services.

    Error: SSL certificate problem: certificate has expired