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:

• Vendors supporting amp-consent and blocking the tag by default

• Vendors supporting amp-consent without blocking the tag by default

• Other tags/vendors

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:

<amp-analytics type="comscore">
  <script type="application/json">{ "vars": { "c2": "1234"}} </script>
</amp-analytics>

...

<amp-consent layout="nodisplay" id="didomi" type="didomi">
  <script type="application/json">
    {
      "clientConfig": {...},
      "policy": {
        "default": {
          "waitFor": {
            "didomi": []
          },
          "timeout": {
            "seconds": 0, // Tell AMP to load the tag immediately
            "fallbackAction": "reject" // Reject OR dismiss
          }
        }
      }
    }
  </script>
  ...
</amp-consent>

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:

• Analytics

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 is dismiss (default configuration)

• insufficient if the fallbackAction is reject

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)

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 a data-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.

<amp-ad 
  data-block-on-consent
  width="300"
  height="200"
  type="doubleclick"
  data-slot="/1234"
  rtc-config='{
    "vendors": {
        "aps": {
          "sendRegardlessOfConsentState": true // Always send the consent regardless of the state
        }
      }
    }'>
  </amp-ad>

...

<amp-consent layout="nodisplay" id="didomi" type="didomi">
  <script type="application/json">
    {
      "clientConfig": {...},
      "policy": {
        "default": {
          "waitFor": {
            "didomi": []
          },
          "timeout": {
            "seconds": 0, // load immediately
            "fallbackAction": "reject" // reject OR dismiss
          }
        }
      }
    }
  </script>
  ...
</amp-consent>

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:

• Ads

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 is dismiss (default configuration)

• insufficient if the fallbackAction is reject

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 data-block-on-consent)	Tag is loaded on page load.
With data-block-on-consent	Tag is loaded once a positive consent is given.
With data-block-on-consent="_till_responded"	Tag is loaded once a consent (positive or negative) is given.