How to monetize Google AMP pages.
- Google has an out-the-box monetization system for AMP
- But, this system is limited and results in lower revenue from AMP pages
- Connecting server-side header bidding enables higher revenue and AMP performance
Google knows the average user can't stand waiting. If a mobile site takes more than a few seconds to load, it gets shut down and discarded.
But rather than making us work on patience, Google is an enabler. Like a spider, it isolates the vibrations on the web we respond to.
Marking page speed as a key factor for users, they heavily supported the release of the AMP Project, the open-source framework for lighter, faster websites.
AMP is all about the user. So what about the publishers?
Like a rally car, AMP strips away all the fat from web page structure, making them ultralight, and ultra-fast. But, a lot of this heavy code slowing down mobile pages is the monetization code that allows publishers to earn money from their content.
For users, ads were no great loss. But for publishers, ads are the basis of the information-for-attention economy. In order to monetize AMP content, publishers have to either accept Google's AMP monetization system - which often generates far lower revenue than regular pages, —or they have to find a way to connect header bidding.
In this blog post, we're going to explain, how to monetize AMP pages, best practices, and ways to make sure you earn the highest possible revenue from your AMP pages.
How Google wants you to Monetize AMP
To monetize AMP pages, publishers need a system that can:
- Get ads out of the critical path of rendering the page
- Prevent layout shift around but support multi-size ads
- Use ad formats that users can easily dismiss or scroll past
Rather than having header bidding JS tags block the page for 2-5 seconds, AMP suggests that publishers use the amp-ad component— a custom ad extension to the AMP library. This uses Google's own Real Time Config (RTC) to call up to five different endpoints, over the course of a second. While RTC is, technically, a perfectly serviceable way to monetize AMP pages, it has some major limitations.
Firstly, 5 endpoints are the maximum, and five endpoints being called does not mean five bidders. Connecting to other vendors for services like viewability measurement or audience tracking cuts down on the demand side bidders you can call. The fewer bidders you call, the lower your cid competition, and the lower your CPMs will be.
You can see in Google's diagram of how RTC serves ads for publishers that these 5 endpoints will make publishers choose between ad revenue and functionalities such as weather widgets or data services.
The single tag approach also means that when publishers want to add or remove a demand partner, a developer will have to make these updates. Good header bidding wrappers will have an intuitive interface.
Next up is the limitations on the bidders you can work with using AMP and RTC. The current list of supported ad vendors are:
- The Ozone Project
- Purch Galaxie Media
By promoting and rewarding the AMP framework, with its caveats and limitations on monetization, Google pushes publishers towards their own monetization tools. For big publishers, having to use another system, with closed reporting, can be a major issue.
How to monetize AMP for the highest possible revenue
While these tools enable some level of monetization and adhere to the AMP rules, publishers can get higher revenue and more control over their monetization by implementing header bidding on AMP. Google will tell you RTC works better—but implemented correctly a header bidding wrapper can generate far higher revenue for publishers.
For a long time, it was difficult to connect any form of monetization to Google AMP. Then it was assumed that you can't run header bidding on AMP. But, this is not the case. You can run header bidding, with as many bidders as you want, as long as it doesn't kill the lightness of the page. The way to monetize without slowing AMP down is to connect server-side header bidding as an endpoint, allowing one connection that serves multiple bidders.
Server to server header bidding allows multiple bidders to compete, without adding latency that will slow the page down. This gives the bidding pool to drive up CPMs, with no page slowdown. Client-side implementations take longer to process bids and have a greater likelihood of being blocked by AMP during runtime.
- You can define the AMP ad element and send a single call to the wrapper's server (for instance, Marfeel's MBid server) using RTC.
- The server then conducts auctions on the server-side and returns the key-value to the AMP runtime.
To ensure that AMP pages can load fully and instantly, they also use a system called Fast Fetch. Fast fetch ensures that just the ads in the first three viewports on the page are rendered. When the viewport gets within three lengths of the next ad slot, it will start to render these ads. If the user's browser is idle, AMP will take this opportunity to render up to 12 additional viewports of ads.
As Fast Fetch just does the ad request earlier, separates the content load, and lazy renders the impressions, it can still apply this process to ads requested using server-side header bidding.
But, it's important to remember that AMP is often the starting point for your user's experience. If they view a story that loads rapidly, has fast, well-appointed ads and then clicks through to the main site that takes 5X as long to load, the drop off will be massive.
Best practices for serving ads on AMPWith header bidding connected, publishers can then focus on making their monetization experience as viewable and as seamless as possible. As with any monetization strategy, the first version is rarely the most profitable.
It takes testing, experimentation, and adjustments to get the most revenue from your AMP pages. But, there are some Google-sanctioned best practices you can use to give your pages the brightest start on AMP.
AMP ads best practices
- Serve the same number of ads on AMP Pages as your non-AMP, with a maximum ad density of 30%
- Put the first ad immediately below the fold of the first viewport. The user doesn't see it load and gives them a full screen of content to scroll before they hit an ad.
- Center your ad units on the page. Unless you're using advanced CSS or media queries, centered ads provide the most agreeable user experience.
- Enable multi-size ad requests to the ad auction demand pool larger and drive up CPMS Avoid creatives with large files to download as they may get blocked during runtime.
- Avoid interstitials or any ad formats that cause the content to 'reflow' on ad load. Reflowing content makes the content shift about on the page and can lead the user into clicking places they didn't intend to.
- Set the data loading strategy to prioritize viewability over views
- Use the amp-iframe to place ads in your video content
With these techniques, you can ensure that the user experience AMP works so hard to create, will not be disrupted by your monetization efforts.
But, by connecting server-side heading bidding via RTC, publishers can monetize AMP pages as effectively as they would any other page.
This means publishers can be a part of AMP, and the clear traffic bumps Google will provide without having to set up another, new, closed-off monetization system. Create competition for higher CPMs, add or remove bidders as you please, and access detailed analytics and reporting by monetizing AMP with server-side header bidding.
If you’d like to turn your content into ready-to-rock AMP pages, fully integrated Marfeel’s server-side header bidding platform, click here to try a demo.