Plug in a consent management platform to your AMP pages.
One such functionality that publishers need to have—on AMP and on any page—is a way to ask for consent to use and store user data.
As part of the data regulation laws from GDPR, CCPA—and the latest 4-letter regulation to join the gang—LGPD, publishers' best way to comply has been to a Consent Management Platform, a CMP to their website. For many publishers, a third-party company or plugin handles the CMP.
These often integrate well with popular CMSs, but they often are incompatible with AMP, or if they do integrate with AMP, they hamper the monetization.
Let’s delve into what makes up a CMP to understand why. A CMP is normally made up of two parts:
- A user banner — consisting of toggles that allows users to opt-in/out of GDPR Purpose Consents and GDPR Vendor Consents.
Even if your regular CMP works with AMP, this restriction frequently prevents publishers from making higher CPMs on these pages because the valuable audience data is not getting through to the advertising platforms.
So, AMP offers their own AMP consent management platform. The good thing about this is that it is designed to integrate properly with AMP pages so publishers can make sure they comply with data protection regulations.
Let’s take a look at the standard AMP solution.
AMP’s own consent tag
AMP provides a way to request user consent via the < amp-consent > element that can collect and store user consent. But like everything on AMP, the lightness and speed of the page come before the monetization needs of content publishers.
The consent system on AMP allows publishers to:
- Determine if the user should be asked to interact with the control.
- Capture the user’s consent decision.
- Block other AMP components based on the user's consent.
This element uses a JSON configuration object to specify the behavior required.
This consent configuration can then define consent blocking with some predefined attributes.
The blocking options that AMP provides are:
- Unblocking components until the user responds to the consent prompt, or skips it altogether.
- Default basic blocking behavior where individual components cannot override the blocking behavior.
- Or, always reject the consent automatically if consent is required but unknown. This rejected consent decision will not be stored.
After you define the behavior of the CMP in AMP, you then have a series of options to define the styling. As with anything in AMP, you have a more limited palette of options to play with.
AMP CMPs must adhere to the following requirements:
- Position of the layer is always bottom / full width
- Automatic consent via scroll/navigate is not possible
- Consent type is always domain-specific
- Size of the layer is fixed, hence paddings/borders are limited
- Once the consent is given, AMP controls the further behavior
- AdBlocking / Postponing is not possible
But, the crucial factor is that users’ data protection preferences given to the CMP are able to communicate with the advertising technology on the page.
This is usually done by forming a consent string with information regarding users’ choices, this is then included in each ad request.
The value accepted instructs AMP that the user has given consent and can then be used to serve personalized ads. But for personalized ads to be served on AMP (already a challenge that you can read more about here), the CMP has to communicate with the ad vendor.
Shared data is available to other AMP extensions but it's up to the 3rd party vendors to agree on the particular meanings of any key values shared between them. And, unlike the overall user consent, this shared data is not available in client-side storage.
To give publishers some options for personalized ads, the AMP CMP offers a DoubleClick & AdSense Integration. But for publishers with more bidders than DFP, this lowers the amount of bidders that can use their user data, dragging down eCPMs with it.
Furthermore, AMP does not support granular consent. This means users only have the choice of whether to accept or reject all the categories you set up in your CCPA rule. It’s also not possible to block specific vendors by using the IAB consent string on AMP. The only option available is general blocking/unblocking, rather than specific blocking by the vendor.
So, with limited integrations, using a CMP with AMP is another example of how AMP ends up limiting publishers’ monetization options while making the traffic too irresistible to stop using altogether. What publishers have to do is find a way to add a CMP that can communicate with every advertising partner they work with.
As a contributor to the AMP project for over 5 years, Marfeel has been working with AMP to create publisher tools that enable AMP pages to be monetized like any other page. By using server-side header bidding with AMP, and our custom CMP, Marfeel publishers are able to comply with regulations and fully monetize AMP pages.
To learn more about activating the Marfeel CMP, click here
to learn how to add it to your site today.