The AdTech industry is always searching for new practices and monetization tactics. The adoption of header bidding technology is a bright example of how a new industry standard grew out of an AdTech monetization hypothesis.
Header bidding solutions are now effective tools that give publishers more power and flexibility to manage demand partners and increase revenue. Demand partners – which in this case are often supply-side platforms (SSP), demand side platforms (DSPs), or ad exchanges – can now count on increased transparency and winning the best inventory.
Is header bidding technology really all roses or does it have pitfalls all interested parties should learn to avoid? Let’s take a look.
Header bidding in programmatic advertising came to replace or, at least augment and complete, the waterfall method. The latter was known for prioritizing the buyers, sending out ad requests. and evaluating bids in a cascade-like order. The historical performance of each demand header bidding partner often played a decisive role in this case.
The waterfall method was popular but was it fair and profitable for publishers and demand partners? Not really. Mostly because of its latency and decreased access to the best inventory to bid on, not to mention inaccurate bids and suboptimal ad revenue. Header bidding entered to make a difference.
We’ve talked a lot about the mechanics behind header bidding solutions in this article. You’re welcome to read it to get down to the nitty-gritty of the header bidding technology. Today we’d like to highlight the most challenging moments publishers, SSPs, and exchanges may have with header bidding and find solutions together.
To start a publisher adds a container, aka a header bidding wrapper, in the header markup element of their website. In this article, we’ll often refer to Prebid wrapper as a core wrapping technology since the majority of modern client-side wrappers are built on Prebid.js (71%, to be exact). A page with a header-bidding container on it sends a particular number of bid requests to all demand partners. Before the client receives a response with the biggest bid and ad creative each partner might run its own auction internally. Once the bids from each header bidding partner are collected on the client (partners could drop due to timeout) the client chooses the winning bid and sends it to the ad server, as a targeting keyword. It’s not uncommon that, on the ad server, the winning bid from the header bidding client-side auction continues competition with other ad sources in the waterfall. Finally, the ad server decides which ad creative to return to the client.
Sounds rational and straightforward, so what’s the catch? The answer is page performance. Every demand partner adds to the page load time. From the publishers’ perspective, the more demand partners that are added to the header bidding wrapper the more earnings they get, thanks to the prices they’re ready to pay for the inventory. However, inadequate page performance results in poor user experience and lower revenue if users leave the website.
For this reason, the number of demand header bidding partners a publisher should add to the client-side header bidding setup should be somewhere between 3 and 7. It’s better to keep it below 5 though. To fight latency with client-side header bidding it’s a common practice to configure a timeout. With Prebid, for instance, there is a timeout for each impression. It is recommended to be set as 1,000 milliseconds or less for the internal auction timeout.
This means that all header bidding partners have a similar amount of time to respond. Any bid that responds later than the timeout is canceled. In other words, the web page of a mobile app sends one request per placement to Prebid. The wrapper sends one request for each demand partner simultaneously, even if there are more than the recommended 3-7 (say, 20 partners simultaneously). In case there is no response within 500-1000ms, Prebid discards the request. This way the auction lasts no more than a second, regardless of the demand header bidding partner number.
Under the server-to-server (S2S) header bidding model the client is relieved from its request-sending duty. Instead of a browser, it’s now a server that sends requests to demand partners. The main difference is the number of requests done on the client-side. Now it’s a single request to the header bidding server, which is sent when the page loads. The header bidding server sends the required number of requests to all demand partners, basically serving as an auction proxy. Respectively, the auction is now done remotely.
And what about performance? Page latency is not a big deal anymore. All because a web page calls the external header bidding server with a single request, which later returns winning bids to the publishers’ server through only one tag. The outcome is the ad creative being served by a publisher’s server.
For in-app header bidding, S2S is nothing new. Server-side auctions work well for mobile ads since mobile device engineers strive to limit the number of SDKs shipped as a part of the app. The number of SDKs directly influences the disk footprint of the app, its launch time, and performance. This way, increasing the number of S2S connections an ad server makes instead of increasing the number of SDKs is a rational decision for in-app header bidding.
It seems that server-side header bidding offers advantages, but there’s a catch. As with any emerging technology, header bidding is a long way from being fully featured as of yet.
While S2S header bidding is a logical step in the auction dynamics, it does have its flaws. Publishers like that it improves speed and overall performance, leading to an increase in yield and bid density. Unfortunately for advertisers, the cost of fine performance is the loss of cookies.
When SSPs and exchanges sync their cookies with publishers they can identify the user on the publisher’s site. With client-side header bidding, each SSP has access to the user’s browser to collect matching data and sync it with the publishers’ matching data. This is how targeted and retargeted ad campaigns exist and flourish, which is profitable for both publishers and advertisers.
But when calls go from the server cookie mapping becomes an issue. An SSP has to match IDs first; with the SSP rounding up all the bids and then with the publisher. With every additional ID sync it gets even more complicated to map the IDs. Without a matching cookie, there is less data behind each impression, so they lose their value. As a result, all parties miss out on the revenue.
Solving the identity puzzle is a critical task for header bidding as an advanced header bidding programmatic advertising technique. While AdTech players are concerned with cookie mapping in S2S bidding, the cookie-matching benefit of classic bidding is on it’s way out. Safari has been successfully blocking first-party and third-party cookie usage in terms of Apple’s Intelligent Tracking Prevention (ITP) program. Firefox does the same and Chrome will join them by 2022. While AdTech players may try to take chances with potential workarounds, it’s clear that the advertising industry should be better prepared for a non-cookie future.
Prebid.org features a specific endpoint that is used during cookie syncing. Calling /cookie_sync initiates a process that creates or updates the cookie file. The request enlists a set of URLs to enable cookie syncing across specified bidders.
But it’s possible only if the bidders who want to support cookie syncs implement an endpoint under their domain that accepts an encoded URI for redirects. Next, cookies must be consolidated under the Prebid Server domain so that they can be sent to each demand partner.
To read more about the mechanics used by Prebid Server, check out their Cookie Sync developer docs.
Prebid User ID module is a nice try to move away from classical cookie mapping. For publishers, it’s an opportunity to access several standardized identity solutions that support a variety of ways to establish IDs for users.
How does it add value to header bidding when compared to cookie sync? The more SSPs, DSPs, ad exchanges, and publishers agree on user ID sharing, the less headache they have with cookie matching in S2S header bidding. While match rates improve, publishers can sell more inventory. Quality and transparency – everything the parties strive for.
From the technical point of view, instead of exchanging several IDs with a high number of demand partners, a publisher can integrate with the ID solutions featuring not only identifiers but even groups of publishers, exchanges, and DSPs.
As of this article’s publication date, there are 11 modules available in Prebid and they plan to increase this number. Check out User ID sub-modules that allow publishers to administer first-party cookies in the Prebid wrapper and determine which ID goes to a specific user:
Publishers can intentionally omit a certain number of ad units and formats in their header bidding configuration. First, to avoid latency caused by calling too many demand partners. Second, because it simply might not be lucrative.
Think of video ads. This format is popular, expensive, and time-consuming to produce. For publishers, it might be more profitable to sell inventory for such creatives directly, without trying to increase competition among rare demand partners through header bidding. But publishers should be cautious against missing out on monetization opportunities simply because they don’t know how to include formats like video, native, and mobile ads into their header bidding.
Even when working with just one header bidding partner, a publisher can spin up revenue with the programmatic competition. It’s necessary to decide which ad units to expose to the header bidding demand and to make sure they’re called out in the header. To do this with a Prebid wrapper a publisher should include the parameters for each bidder they’re working with to serve ads on each ad unit.
Header bidding wrappers might be preconfigured to use $0.50, $0.25, or $0.10 granularity price buckets. Also, they can be manually configured to a higher granularity. If the price of a header bidding wrapper and corresponding line items aren’t granular enough, the bids can be rounded too low, making them non-competitive in ad server auction. Look at the example offered by Prebid: “If your site’s price granularity setup is at $0.10 increment, but the line items are expecting $0.50 increments, bid prices such as $0.71 or $0.99 would not match any line items.”
Along with custom granularities there might also be non-uniform granularities. For instance, with Prebid Mobile, via key-values, the line items can be set up to tell the ad server how much money the “bidder” demand is worth. This process is done via key-values.
You need to make sure the price buckets match if you want header bidding servers to catch all the bids. Whether you’re using Prebid or other wrappers, choose your price and granularity settings carefully and pay special attention to the bid ranges reports. It will help analyze bid ranges and finetune configuration if the ad server misses the bids.
To avoid monotonous and error-prone work, we’ve created PubMonkey, a Chrome extension that helps you set up your Header Bidding in the mediation platform such as MoPub or Google Ad Manager.
Analytical features are valuable, but many header bidding platforms fail to provide the required insights. For instance, while the Prebid.org solution allows you to log events, it needs extra efforts to develop a custom solution to aggregate the logs and extract insights. Without analytical insights, publishers won’t be able to rationally assess and improve their performance. The basics the Prebid analytics offer to manage header bidding partners include:
Prebid also offers several analytics adapter plugins to track header bidding performance, but none of them are endorsed or supported by the company. You can check out adapter plugins here.
To get better insights, publishers need to either integrate third-party bidding analytics tools or develop their own dashboards. As long as programmers are on their own to set up analytics they should consider the following features and parameters to be added into the dashboard or report:
Header bidding analytics should serve as a response to the following questions:
Open source solutions, with Prebid.org leading the pack, are supposed to be like a breath of fresh air. A free and transparent approach was called to eliminate complexity and increase quality and demand in the header bidding programmatic marketing domain. The only problem is that despite numerous positive changes it has already invoked, open-source header bidding still has a long way to go in terms of simplicity.
For most publishers, integrating open-source header bidding, including the Prebid wrapper, remains rocket science. The most significant issues are the complexity of header bidding integration with multiple demand partners, the absence of decent UI, and a poor UX presence.
Although Prebid declared its target audience as publishers, not all categories of publishers fall into their target groups. In fact, only the large publishers with either bright engineering teams or enough capacities to contract DSPs would use Prebid directly.
But DSPs have learned how to use Prebid rationally. By developing their solutions based on Prebid open source, they can offer publishers simpler UI and better UX, along with support and control over the header bidding integration and processes.
Header bidding technology is now a near-golden-standard to monetize on ads through programmatic channels. Although we don’t see it being dethroned in the coming years, there is a lot to overhaul.
Implementing header bidding is a tall task. Moreover, issues like cookie mapping, latency, performance or lack of analytical capacities form a gap between header bidding platforms and better monetization and UX. But we believe that tech advancements and the joint efforts of advertising value chain participants will yield the much-anticipated results.
