Better than Header Bidding -> AMP RTC

It’s more performant, easy to configure and supports many other use cases

This post is part of a larger AMP monetization series that you can read about here.

Header Bidding & Challenges on non-AMP

If you don’t know what header bidding is, this is a fine place to start.

For most publishers, header bidding sounds good to do in theory, but, given the business dynamics of a very complicated ecosystem, things that ought to happen on the server side ended up happening on the client side. On non-AMP pages, it’s common to see header bidding JS tags block the ad request for 2–5 seconds before the ad request is even made to the ad server. This is bad because it’s blocking the web page from rendering page content. On some sites, this problem is exacerbated when there are multiple header bidders causing these tags to sequentially execute, leaving the page unresponsive for an unreasonable amount of time.

Due to complicated operational setup, poor measurement and accountability, the negative impact on user experience and revenue caused because of the additional latency & device stress is often not tallied with the lift received by plugging in the additional competition.

If you step back & look at it, what’s happening is pretty straightforward. The publisher page wants to communicate some additional information to the ad server. Such a requirement extends beyond header bidding to other important use cases like audience targeting and measurement. (Examples below). Which is why the AMP team developed a generic framework to solve this using Real Time Config (RTC).

What is Real Time Config?

Since AMP strives towards a user-first web, while helping publishers maximize revenue, it allows competition between vendors but also ensures vendor timeouts in a way that vendors respond back as quickly as possible.

RTC allows 5 parallel callouts to end points configured by the publisher. AMP waits for a maximum of 1 second (which can be further tightened by the publisher) before it merges the responses from the callouts and makes the ad request to the publisher defined ad server, so the right ad can be selected in the ad server.

AMP RTC configured with 5 endpoints

RTC also makes it easy for publishers by allowing vendors to integrate with the RTC framework instead of publishers having to manually configure each of the URLs and necessary meta data that ought to be passed to the vendor.

Vendors support with RTC

At the moment, the following vendors have directly integrated with the framework:

• Media.Net
• AppNexus (using Prebid)
• Rubicon (using Prebid)
• Index Exchange
• Lotame
• YieldBot
• SalesForce DMP (Data Management Platform)
• Purch
• Amazon
• PubMatic
• Criteo

Publishers can select the vendors they want to work with using a a few lines of code.

<amp-ad width="320" height="50"
        type="network-foo"
        data-slot="/1234/5678"
        rtc-config='{
            "vendors": {
              "indexexchange": {"SITE_ID": "14572"}
              },
            "urls": [
              "https://www.AmpPublisher.biz/targetingA"
            ],
            "timeoutMillis": 750}'>
</amp-ad>

AMP also makes a number of system-based macros available (e.g. canonical site name) that can be passed to the vendors.

When Metro.co.uk implemented RTC with AppNexus Prebid, they saw a 6X increase in revenue from their AMP pages compared to their AMP pages implemented using Remote.html (a deprecated mechanism to run custom JS in AMP) with AppNexus Prebid.

Other use cases for RTC

In addition, the publishers can call out to custom end points by pointing to custom URLs using the urlsattribute. Here are a few examples:

1. Targeting ads to a user based on the context of the article. For example, if the article is about cars, a publisher could pass that contextual information down to the auction to get car advertisers to bid for the ad slot.
2. Ability to call out to a 3rd party service that returns the weather based on the user’s geo-location that can be passed to the auction, so an ad that matches the weather outside could be shown.

Using RTC with <amp-consent>

By default, when <amp-consent> is implemented on an AMP page to gather user consent, RTC callouts will be blocked without a positive consent state. For publishers, there are ways to enable callouts based on consent status that you can read about here.

Giving RTC a spin

Maybe there’ll be a day when there’ll be no reason to block on the client side for such information. Until that day, RTC provides a framework within AMP to help vendors integrate with a publisher page in a performant way. At the same time, also providing flexibility to enhance ad requests that helps publishers make better revenue.

If you are a vendor, you can find more information here to integrate with RTC and if you are a publisher, please head over to this link.