Though we all know how header bidding serves to maximize the yield of the publishers and embraces transparency, publishers are always concerned about the discrepancies. Who likes it, anyway?
In fact, header bidding was supposed to minimize discrepancies as it slashes down the traditional waterfall model in your ad server. However, a certain percentage of discrepancies between header bidding partners and Google Ad Manager always exists. After all, they are different systems serving varied purposes in the complex ad tech ecosystem.
However, the truth is no one wants to see more than a 10 percent discrepancy between Ad Manager and header bidding partners, regardless of the metric in question. While it is true that discrepancies are inevitable, publishers need to know what’s happening behind the scene. This way they know what to do and what not to do (ahem, panicking).
Why there’s a discrepancy?
The answer can’t be put in a line. In the present ad chain, there are a number of ways from which the problem may arise, resulting in discrepancies.
Don’t worry, we’ll take you behind the curtain and show you what’s happening.
When a user loads a web page, the header bidding wrapper code staying on the page will make calls to the bidder partners to receive bids for the impression. The bidder partners will conduct their own auctions and return bids only if the impression matches the advertiser’s user persona. The returned bids are sent to the ad server and the ad server (Google Ad Manager) triggers the respective line items.
These line items compete with Google’s own demand (AdX/Adsense). In the end, the highest bid wins the impression.
Hold on, the impressions discrepancy starts right here.
As soon as any bidder wins the auction in the server, Google Ad Manager records an impression. But the header bidding partners wouldn’t record the impression until the actual creative is delivered while the user is on the page.
At first, you might think it’s pretty linear. Ad Manager records when the bidder wins the impression, header bidding partners record when the ad creative is delivered. There shouldn’t much be happening between these two.
“Even the best-managed sites can expect discrepancies between 20% and 30%. That’s significant.”
– James Curran, STAQ
No. In fact, there are a lot of ways things can go wrong between these two recording instances.
#1 User didn’t stay on the page
Once the Ad Manager records the impression, the winning line item will be allowed to serve the creative. In most cases, it will be a third-party tag, where the ad server has to fetch the creative from the different ad servers. Of course, it takes milliseconds and sometimes, users might move on to the next page without giving time to render the creative. So, Google Ad Manager says it has the impression delivered, while the header bidding partners say ‘no’.
#2 Network and Page Speed
The network connectivity of the user isn’t enough to render the ad creatives properly. For instance, Uber reported almost 50 percent of the ads weren’t rendered on mobile environments during a test campaign. That means of 1 million impressions, only 500,000 impressions were rendered to the user. In the end, header bidding partners will pay 50 percent lesser than what’s on your Ad Manager.
#3 Ad blockers
Ad blockers have the ability to block calls to certain URLs completely. As there are no ad calls, this doesn’t result in any discrepancy. But when it only blocks certain classes (class= Ad), the ad server might record the impression while the bidder partner wouldn’t as no creative has been fetched and rendered.
#4 Viewability and performance
Certain post-auction parameters could cause the discrepancy. Most common among all is viewability. After seeing the viewability of the ad delivered, bidder partners might not record any impressions at all. MRC has a standard to determine whether the impression is considered viewable or not. If the rendered ad doesn’t qualify, bidder partners won’t record this as an impression. On the other hand, the Ad Manager would have recorded as soon as the bidder won the impression.
#5 Ad fraud and bot filters
Besides, Demand-side platforms (DSPs) need to make sure the traffic is legit. So, they use ad fraud detection technologies and sometimes, proprietary bot filters to prevent wasting advertisers’ ad dollars. And, occasionally, your users have a chance of being flagged as bots by the technologies used by the bidders. So, bidder partners disregard the impression and will not pay the publisher.
#6 Cache busters
Sometimes, the configuration might not be perfect 100% of the time. The DSPs would have neglected to cross-check the cache busters. Cache busters are used to ensure ad calls are made whenever a user loads or reloads a webpage. As the latest browsers cache the data, ignoring the buster might result in a discrepancy.
#7 Configuration Issues
Remember the Uber example we mentioned above, the testing team found that most of the discrepancies were due to the misconfiguration of DSP. DSP was trying to fill an MRAID ad creative into a non-MRAID-compatible impression. If the demand-side was properly configured, there won’t any bids and ultimately, there won’t be any discrepancy.
