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 limits third-party JS tags from the pages and instead, uses its own library files*.
*Custom JavaScript tags can be added via amp-script. However, your code will run in a Web Worker and certain restrictions will be applied.
So, how can you monetize AMP pages? In this post, we’ll clear all the questions (comments are always open for more) and help you set up header bidding for AMP pages.
Why Implementing Header Bidding on AMP is Different?
Since the AMP framework limits custom third-party JS tags, monetizing amp pages is a bit difficult for publishers. Such constraints made it impossible for publishers to run header bidding as they used to on their regular sites.
As time went on, the demand for better AMP monetization support increased, and 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.
Table of Contents
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 set-up through which you can 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.
Limitations of RTC
Demand partners:
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 addition, user sync can be done for just one of the five demand partners as AMP permits only one non-visible iframe.
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.
Vendors:
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.
Can I Implement Header Bidding on AMP?
Yes, you can.
You can use Real-Time Configuration (RTC). But as we discussed, it can call only 5 demand partners. To increase the demand, you must have a header bidding wrapper. From connecting to multiple demand partners to manageability to reporting, you can do it all via the wrapper and dashboards. Apparently, the wrapper should support Real-Time Configuration, and use server-side bidding to run auctions seamlessly.
Note that using a header bidding wrapper doesn’t mean you are getting rid of the 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
type=”server-type”
data-slot=”/21804848220/Parent_ad_unit/Child_ad_unit”
data-multi-size=”320×50″
rtc-config={“urls”:[“wrapper-server-url”]}>
</amp-ad>
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.
Fast Fetch
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 the 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.
Next Steps
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.
