Growing ad revenues with Accelerated Mobile Pages

Accelerated Mobile Pages (AMP) came out to the market with a promise of faster mobile web browsing and better user experience. The advantages emphasized by their creators seemed noble on paper; nevertheless, there are always two sides to every story. Like any other technology, this one also comes with some limitations. The aim of this blog entry is to discuss challenges publishers face when it comes to AMP.

How can I monetize my AMP inventory?

Every publisher is unique and has its own needs. Based on that, we can point out three primary ways AMP inventory can be monetized.

Basic: programmatic ad networks such as AdSense (ADX)

This method is all about simple copy-pasting tags generated by your ad network of choice. It’s really simple but doesn’t offer any flexibility other than changing the size of the ad unit.

Intermediate: ad servers that consolidate both direct and programmatic campaigns

The implementation of an ad server on a website gives publishers a possibility to deliver different campaigns with ad formats supporting different technologies, standard JavaScript and HTML5, for instance. While it is true when applied to standard desktop devices, the story for ad servers supporting AMP is slightly different. Don’t get it wrong, you would still be able to deliver most of ad formats, i.e. display ads, rich media that doesn’t resize, native, HTML5 and some video ads, but due to AMP limitations JavaScript formats such as interstitials and expandables are out of a question for now. Obviously, Flash formats won’t work too. In addition, both your web servers and creatives are required to have a valid SSL certificate and use HTTPS protocol. Tracking campaigns delivery is also affected. Standard 3rd party tracking codes won’t work. What you need are components designed specifically for AMP like <amp-pixel> and <amp-ad-exit>. Depending on the ad server campaign delivery troubleshooting might be more problematic than usual. Let’s use Google Ad Manager as an example. Normally, you would use Google Publisher Console to analyze the delivery of your campaigns. This is a handy tool that provides plenty of valuable information, but can’t be used in AMP environment.

Advanced: AMP Header Bidding combining conventional ad server and Prebid ad server with AMP Real Time Config (RTC) protocol

Most of publishers are familiar with Header Bidding, but AMP Header Bidding is a different pair of shoes. For the sake of the page load time and performance AMP creators abandoned standard web techniques in place of more efficient ones. It means that standard client-side header bidding auction simply won’t work there.

To make an HB auction run on AMP you’ll need a comprehensive approach. First, your AdOps team needs to configure the ad units and create thousands of price priority line items with proper creatives on standard ad server. Second, your IT team configures Prebid Server with Stored BidRequests JSON file and prepares ad unit codes with properly set Real Time Config attributes. Unfortunately, at this point there is no standard solution on the market. Along the way you’ll come across issues such as different targeting options and creatives across different vendors which results in abundance of work (e.g. a few groups of adserver orders instead of just one) and problems with currency unification.  In addition, there aren’t many vendors that support AMP HB auctions right now.

On top of that, there is no single configuration file for every ad unit on the website. They’re independent and if you want to make a change globally you need to edit every single one of them.

Is there anything else I should keep in mind?

Regrettably there are a few other things that you should know. If you receive traffic from the European Union you are probably familiar with GDPR and Consent Management Platforms. With AMP you need a separate <amp-consent> component. Does your website include a highly positioned ATF ad unit? There is a great chance that users will scroll past it before the ad renders the creative as the page itself loads rocket-fast. The same goes for video ad units. Along with that, it’s impossible to use multi-size ad units that start loading with not visible 1×1 px. You need to proceed with fixed width and height and resize it using a proper attribute that cannot exceed original sizing.

Okay, it seems like a lot of hassle. Are there any benefits?

The biggest advantages of AMP are decreased page load time and improved user experience which translates to a lower bounce rate and higher viewability and CTRs. This results in higher CPMs and revenues. In addition, Google promises that AMP brings additional organic traffic to your website thanks to higher search engine scores – who wouldn’t want additional traffic volumes waiting to be monetized?

Another benefit is a better performance on slower mobile devices, not only due to the nature of the technology, but also due to special mechanisms, i.e. default ad units lazy loading and pausing animated ads when they are not in the viewport. Last but not least, malware advertising or infamous redirects are less likely to occur given AMP runtime.

Should I do it?

The modern advertising world is constantly evolving. If you want to stay strong in the game, you need to follow new trends. Clearly, the implementation of the most effective AMP ad stack is time and resource consuming and has its drawbacks such as limited delivery options and complicated setup, but higher speed, better performance as well as increasing volume of traffic and revenues make up for it.

Want to know more?
E-mail us at [email protected]

No comments yet

Your
comment