Accelerated Mobile Pages (AMP) has been widely adopted with over 25 million web domains now publishing AMP. However, ad monetization of AMP pages remains a challenge for many publishers.
Why the struggle to monetize?
One of the core reasons that AMP monetization has lagged behind mobile web is it’s been difficult to bring a large set of demand sources for the monetization of AMP traffic. Header bidding on the web has demonstrated that bringing in additional demand sources boosts CPMs and improves overall yield for publishers. This logic carries over to the AMP traffic and the benefits can be dramatic. Although this may not be representative, one Alexa 500 publisher who added header bidding to their AMP, using PubMatic’s OpenWrap, saw a 30 percent boost in total ad revenue on their AMP traffic.
Until recently, the options for bringing in multiple demand sources for AMP traffic were limited and the options for doing so were quite difficult to deploy. In 2018, AMP added support for Real Time Config (RTC) which made it much easier to use a header bidding wrapper for AMP traffic. In fact, it’s now easier to set up header bidding for AMP than it is on a regular web page.
How to monetize AMP traffic
When considering how to best monetize AMP traffic, publishers should utilize criteria similar to their web traffic. The best options provide the ability to easily add multiple demand partners, make the configuration of partners easy and provide analytics to help publishers maximize their monetization.
There are two distinct approaches a publisher can utilize. One is to add individual demand partners into their AMP configs. This style of AMP monetization is reminiscent of the early days of web header bidding where publishers ran separate header tags for each demand partner. Using individual tags is cumbersome and hard to manage over the long run. AMP’s restrictions also cause the individual tag approach to limit potential monetization.
Specifically, AMP restricts the number of RTC calls per ad tag to five, meaning only five demand partners can be used. The number of demand partners goes down if RTC slots are needed for other purposes such as using a DMP. Additionally, AMP only allows one non-visible iframe which means user sync can only be done for one of the five demand partners.
The second option involves using a header bidding wrapper that supports AMP. This alternative overcomes the aforementioned limitations. A wrapper can support multiple demand partners from a single RTC slot so there’s no limit to the number demand partners. A wrapper will also user-sync for all demand from a single iframe.
Additionally, a wrapper will provide advantages around manageability and analytics. With the individual tag approach, each time a publisher wishes to add, remove or change a demand partner, a developer will be needed to make the update. Using a wrapper, the wrapper’s config can be updated without changing any code or configuration on the page. The best wrappers will provide a user-friendly UI to make these changes seamless.
By using a wrapper, publishers can reduce the gap between AMP monetization and mobile web monetization. Over time, the advantages of using a wrapper for AMP traffic will continue to increase.
Today, in major wrappers supporting AMP, the number of the demand partners is more limited than for client-side header bidding on the web. Because of the nature of AMP, only server-to-server (S2S) bidding is feasible. However, fewer SSPs have embraced S2S header bidding; currently, many only support client-side header bidding. As more publishers start using header bidding for AMP, more SSPs will start supporting S2S header bidding to better monetize AMP traffic.
Given the strong yield boost from adding header bidding for AMP traffic, coupled with the ease of implementation, adding header bidding to AMP traffic is one of the biggest opportunities for additional yield that publishers have available to them.