As the consumption of content on hand-held devices continues to skyrocket, optimizing for speed has become a priority for the open web. Publishers, regardless of traffic volume, experimented with various frameworks and strategies to double/triple the page load speed on mobile. With the increasing demand, Google eventually launched ‘AMP’. Accelerated Mobile Pages (AMP), in its essence, is about changing the way publishers design web pages for mobile internet.
While it’s great to have a common, widely-accepted framework to design faster pages, publishers are faced with a new set of problems – Audience tracking, measurement, and most importantly, monetization. As you’re here, we assume you know that monetizing AMP pages isn’t a straightforward process. Why?
Well, AMP removes third-party JS tags from the pages and instead, uses its own library files.
So, can’t we monetize AMP pages at all? Of course, we can. But not as you monetize regular (non-AMP) pages. In this post, we’ll clear all the questions (comments are always open for more) and help you setup header bidding for AMP pages.
Why Implementing Header Bidding on AMP is Different?
Yes, Implementing header bidding on AMP is different. As the AMP framework doesn’t support any third party, Monetizing amp pages is a bit difficult for publishers. If no JS means publishers couldn’t run header bidding as they used to on their regular sites. As time went on, the demand for better AMP monetization support increased, AMP came up with Real-Time Config (RTC). To put it simply, RTC enabled publishers to connect up to five demand partners, thus emulating a header bidding setup. But RTC had its limitations.
Table of Contents
- Real Time Config (RTC)
- Limitations of RTC
- AMP Header Bidding
- Fast Fetch
- Header Bidding Wrapper Vs RTC
- Video ads on AMP Pages
- Next Steps
Real Time Config (RTC)
AMP wouldn’t be adopted by the majority of the open web if there’s no way to effectively monetize the page views. After all, publishers wouldn’t want to trade their mobile ad revenue for incremental pageviews facilitated by Google.
Soon, AMP came up with Real Time Config, shortened as ‘RTC’ to step up AMP monetization. RTC is a simple way to call 5 different vendors to request bids within the span of a second. It allows publishers to connect to 5 different header bidding partners to monetize their AMP pages. That being said, RTC has its own limitations – making it a second choice.
Limitations of RTC
You can use RTC, at its maximum capacity, to send bid requests to just 5 demand partners. Typically, publishers would experiment with more than seven bidder partners to find the optimal setup and ensure the best possible CPMs. In fact, a Prebid study shows that page load time for ten bids vs five bids doesn’t differ as much as we think. In addition, user sync can be done for just one of the five demand partners as AMP permits only one non-visible iframe.
As RTC call-outs are limited, you can utilize a maximum of five vendors and that includes viewability vendor, DMP, audience tracking vendor, etc. So, you can’t send bid requests to five demand partners, if you need to use DMP or a viewability vendor.
Usability and Reporting:
To be precise, we are pushed back to an era – where a wrapper or container doesn’t exist. You need a developer to add or remove demand partners into your AMP pages, increasing the chances of errors. Further, there’ll be no dashboard or any reporting for you to analyze and optimize.
As per the AMP Project GitHub directory, only the following demand partners can be called via RTC implementation: AppNexus, APS, Criteo, IndexExchange, Lotame, Media.net, PubMatic OpenWrap, Purch, Rubicon, Salesforce, and Yieldbot.
Can I Implement Header Bidding on AMP?
Yes, you can use a header bidding wrapper to monetize AMP pages. Either you can use Real-Time Config (RTC) but it has its limitations or you can use a wrapper along with RTC. A wrapper can help you overcome all the limitations of RTC. From connecting to multiple demand partners to manageability to reporting, you can do it all via a wrapper interface and dashboards. Apparently, the wrapper should support Real-Time Config, AMP, and use server-side bidding to run auctions seamlessly.
Note that using a header bidding wrapper doesn’t mean you are getting rid of RTC framework. Let’s see how it works so that you get the complete picture.
So, how header bidding wrapper works with RTC?
You can define the AMP ad element and send a single call to the wrapper’s server (for instance, prebid server) using RTC. Here’s an example:
<amp-ad width=320 height=50
The server then conducts the auctions (server-side header bidding) and returns the key-value targeting to the AMP runtime*.
*AMP runtime is a piece of JS loaded in the head of every AMP page to provide the implementation for custom AMP elements (like AMP ad elements), manage and prioritize resource loading.
The best part is, as a publisher, you don’t have to deal with any of the dev. and implementation work involved in setting up a header bidding wrapper. Of course, if you have your own wrapper and an in-house team, it’s on your head. Most managed header bidding providers will take care of the setup and implementation for you.
Now, what about the ad server (Here, we refer to the publisher’s primary ad server. For instance, Google Ad Manager) setup? It’s basically the same.
By that time, you should have heard about ‘fast fetch’. Fast fetch is an AMP feature introduced in mid-2017 to render ads faster to the users. Fast fetch separates ad requests from the rest of the content and in fact, makes them earlier in the lifecycle of the page, as opposed to traditional ad requests where ad requests and rendering are done at the same time.
Besides, fast fetch will only render ads when the ads are likely to be viewed by the user. If you’re familiar with header bidding wrapper, you can correlate this to asynchronous requests and lazy loading.
RTC is one of the features of fast fetch.
Header Bidding Wrapper Vs RTC?
Like everyone, You will be confused with which one to go with – header bidding wrapper or RTC. Unlike client-side and server-side header bidding, here the benefits of wrapper clearly precede over that of RTC.
It isn’t one or another. You need RTC if you want to use the wrapper. So, you can either go with RTC alone or use RTC to connect to a header bidding wrapper. Now, RTC can be considered for a small publisher who would like to just get bids from a few demand partners. If you need reporting, easy manageability, and intense competition, the header bidding wrapper is the one to opt-in.
You can either use RTC alone or RTC with an s2s header bidding wrapper.
Note: Automatad can help you set up and run header bidding on the AMP site. Automatad is an AMP Real-Time Config supported vendor.
Can I implement Video ads on AMP Pages?
It isn’t simple to run video ads on AMP pages. The extensions were released last year and so it (video monetization) is very much in the developing phase. AMP has specific extensions to help you run both in-stream and out-stream video ads.
Instream video ads can be implemented via
– AMP Components:
A publisher can use <amp-ima-video> extension to specify where to source the ads and where to source the video content with respective attributes. It has all the basic features including auto-play, docking on a scroll, and analytics.
– Using players integrated with AMP:
Some of the video players in the market support AMP and run in-stream ads on AMP pages.
Outstream video ads can be rendered using the <amp-ad> element. You can check this post for more information on video ads.
If you’re new to AMP monetization and want to know the best route, opt-in for a header bidding wrapper. As we mentioned earlier RTC wouldn’t help you to see expected revenues typically. AMP monetization, as a whole, is still a developing feature. If you would like to experiment with video ads (which we don’t recommend at this point – especially without an in-house team), start slow and scale later.
Have more questions or need help to set up header bidding on AMP pages, we’re a message away.