Google AMP Header Bidding

How to Implement Header Bidding on AMP

Pinterest LinkedIn Tumblr

According to AMP dev blog, over 25 million websites around the world are using Google’s Accelerated Mobile Pages (AMP) to speed up their webpages on the mobile web. AMP drastically reduces page load time for webpages served on mobile devices by removing non-essential style elements and third-party JS, using its own library of optimized AMPHTML and AMPJS code, and using a CDN for content delivery.

The Limitations of AMP

While this increase in page load speed is great, it comes with a tradeoff. AMP removes most analytics tracking and ad serving scripts, making it harder for publishers to track their audience and monetize them effectively. This made a lot of early adopters remove AMP from their websites.

Meanwhile, Google has tried to drive improvements in AMP to address these concerns, including the Fast Fetch rendering feature, in which ads on AMP pages are fetched asynchronously, and only render when they are likely to be viewed by users.

So, Does Header Bidding Work on AMP?

Improvements like Fast Fetch have helped publishers with monetizing their AMP-enabled webpages. One thing that many still struggle with is setting up header bidding on AMP.

Let’s clear the air about that—yes, it is possible to setup header bidding on AMP pages. And there are more than one way to go about it.

For those who don’t know, header bidding is an auction system that allows multiple demand partners to simultaneously bid on impressions, this drives up bid competition and for some publishers, delivers up to 70% uplift in ad revenues.

Header Bidding with Real-Time Config (RTC)

RTC is a feature of Fast Fetch, released by the AMP team in 2018 as an alternative to traditional header bidding for AMP-enabled pages.

RTC allows publishers to connect 5 demand partners and has a maximum timeout of 1 second. Once the timeout expires, RTC analyzes the collected bids and makes a request to the ad server for displaying the winning creative.

Setting up RTC is relatively straightforward and publishers can define the vendors they want to work with using a few lines of code:

<amp-ad width="320" height="50"
 type="network-foo"
data-slot="/1234/5678"
 rtc-config='{
"vendors": {
"vendorA": {"SLOT_ID": "1"},
 },
  "urls": [
"https://www.AmpPublisher.biz/targetingA",
{"url": "https://www.AmpPublisher.biz/targetingB",
"errorReportingUrl": "https://www.AmpPublisher.biz?e=ERROR_TYPE&h=HREF"}
 ],
    "timeoutMillis": 750}'>
</amp-ad>

Since RTC is a native AMP feature, there are fewer chances of errors and therefore little or no debugging involved. The downside is that the publisher cannot have more than 5 demand partners, and while the timeout can be configured to be lower than 1 second, it cannot exceed it.

Apart from that, you also have to forego the analytics and reporting data that is typically standard with most header bidding wrappers these days. All things considered, RTC is a good solution for publishers who want to implement header bidding on AMP pages quickly and don’t have too many requirements or need for customisation.

As of now, the following vendors support the RTC protocol.

  • AppNexus
  • APS
  • Criteo
  • IndexExchange
  • Lotame
  • Media.net
  • PubMatic OpenWrap
  • Purch
  • Rubicon
  • Salesforce
  • Yieldbot

Wrapper-based Header Bidding

The second way is to work with a vendor who provides a header bidding wrapper with AMP support. Given the nature of AMP, only wrappers with server-to-server integration work well, and client-side implementations will have a higher chance of being blocked by AMP during runtime.

Wrapper-based header bidding gets around the 5 demand partner limitation by routing bids through a single RTC slot. This means that you can add as many demand partners as you want. But that’s not the only advantage of using a wrapper-based solution.

With RTC and its single tag approach, publishers will need a developer to make updates each time they want to add/remove a demand partner, in contrast, a good wrapper will let publishers make these changes from a user-friendly panel. Wrappers will also provide publishers with reporting and analytics data, something for which RTC has no support at this time.

Wrapper or RTC?

When AMP was launched, most publishers didn’t even know how to run standard display ads on AMP-enabled pages. So the fact that we now have more than one option for implementing header bidding is a sign that the platform is evolving to meet publisher needs. Choosing between RTC and wrapper-based header bidding for your AMP pages depends on your needs.

Do you want a quick solution but don’t really mind if it comes with limitations and lack of features? Go with Real-Time Config.

On the other hand, if you have a large inventory, need to work with more than 5 demand partners, and beyond setup—easy management is a priority for you, then you should probably consider a wrapped-based header bidding solution with S2S integration.

Write A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.