Load immediately on page load
In this scenario, tags are loaded immediately on page load. If the user consent status is available because the user has already given consent through the CMP, the user consent status is passed to the tag. If the user consent status is not available yet (the CMP is still displayed), the tag is loaded with the consent status "unknown".
Tags and vendors are split into three categories:
The behavior varies depending on the type of tags and vendors. Please contact your vendors if the behavior you are looking for is not the one that you observe.
Vendors that block the tag by default
Some vendors are automatically collecting the user consent status from AMP. By default, the tag from those vendors will wait for a response from the user to the CMP before executing on the page.
Those tags do not need a data-block-on-consent
attribute but will require a custom policy object on the amp-consent
tag to be loaded on page load irrespective of the consent status.
comScore
with an amp-analytics
tag is an example of such tag:
Vendors
There is no clear list of vendors that automatically collect the user consent status from AMP. They can usually be identified through their AMP configuration by checking if they reference the consentState
parameter.
List of vendors and their configurations:
Policy config
A policy config can be added to the amp-consent element's JSON configuration object to customize consent blocking behaviors. For more information concerning the custom policy, you can visit the AMP documentation.
When adding a policy config, the analytics will be sent with a consent status:
unknown
if the fallbackAction isdismiss
(default configuration)insufficient
if the fallbackAction isreject
Some advertising providers will not display non-personalized ads if the consent status is unknown. Hence, we recommend to set the fallbackAction
to reject
to display non-personalized ads or send analytics before consent is given. Consent from the fallback action is not persisted in the local storage and only applies to the current page.
Once the consent state has been updated, the status will change on the next page load.
Note the didomi
ID in the waitFor
object. This is the consent ID and should not be changed.
Summary
Configuration | When is the tag loaded |
Default (no policy config) | Tag is loaded after the user gives consent with the consent status from the user choices. |
Policy config | Tag is loaded immediately on page load with an unknown consent status until the user makes a choice. |
Vendors sharing consent but do not block the tag by default (Ex: amp-ad
with DoubleClick)
amp-ad
with DoubleClick)If you want to link the consent to your tag but still be able to load it immediately on page load, you will have to follow those 2 steps:
Block the tag either with the meta tag
amp-consent-blocking
or by adding adata-block-on-consent
to the tag itself.Add a custom policy object on the
amp-consent
tag.
One common use case is adding a timeout after which the consent will be either dismissed
or rejected
so non-personalized ads will be displayed before any interaction from the user.
Example of amp-ad
with the type DoubleClick
and a RTC Config with APS
.
Vendors
Vendors on amp-ad
are not able to share consents. However, with the use of RTC configuration, some vendors are able to pass some information to their requests. There is no clear list of vendors that are able to collect the user consent string/status from AMP with the RTC configuration. They can usually be identified through their AMP configuration by checking if they reference the CONSENT_STRING
and/or CONSENT_STATE
parameters.
List of vendors supporting RTC configuration and their configurations:
Send RTC call regardless of consent state
This option allows you to send the bid requests of the vendors present in the RTC configuration regardless of the consent state (accept/reject/dismiss). By default, the bid request is only sent if the user accept the consent.
You can find more information on the AMP documentation.
Policy config
A policy config can be added to the amp-consent element's JSON configuration object to customize consent blocking behaviors. For more information concerning the custom policy, you can visit the AMP documentation.
When adding a policy config, the analytics/bid request will be sent with a consent status:
unknown
if the fallbackAction isdismiss
(default configuration)insufficient
if the fallbackAction isreject
Some advertising providers will not display non-personalized ads if the consent status is unknown. Hence, we recommend to set the fallbackAction
to reject
to display non-personalized ads before consent is given. Consent from the fallback action is not persisted in the local storage and only applies to the current page.
Once the consent state has been updated, the status will change on the next page load.
Note the didomi
ID in the waitFor
object. This is the consent ID and should not be changed.
Summary
Configuration | When is the tag loaded |
Default (no policy config) | Tag is loaded after the user gives consent with the consent status from the user choices. |
Policy config | Tag is loaded immediately on page load with an unknown consent status until the user makes a choice. |
For more information concerning the custom policy, you can visit the AMP documentation.
Other tags/vendors
Some tags/vendors are not able to load or send requests on page load without any consent being previously given if they are blocked by a data-block-on-consent
.
A common case can be the unavailability for a vendor present on an amp-ad
to display non-personalized ads if the consent status is unknown
. In that case, there is no current solution to load the tag on page load except removing the data-block-on-consent
attribute.
Summary
Configuration | When is the tag loaded |
Default (no | Tag is loaded on page load. |
With | Tag is loaded once a positive consent is given. |
With | Tag is loaded once a consent (positive or negative) is given. |
Last updated