When installing AudienceProject services, it is essential to ensure that a proper integration between various publishers preferred consent collection methods and the AudienceProject Publisher script is carried out, to ensure that both Publisher and User consent signals are being respected. This document outlines the most typical scenarios we encounter and draw up a path to proper installation/integration in each case. This is a high-level commercial presentation with the aim of communicating principles, not an in-depth technical presentation containing code-examples.

The Publisher Script and different types of consent management platforms

When installing the AudienceProject Publisher script, there are 4 different Publisher scenarios that need to be taken into account in regard to cookie and GDPR consent compliance considerations:

To understand the four different positions is important in order to discuss how to address the many different requirements that different Publishers have due to different legal positions as well as different levels of technical preparedness. The purpose of this document is not to be a judge of what constitutes a “best in class” approach, it’s more to bring awareness of the many different requirements.

This is primarily a position that pre-dates the GDPR. Before GDPR many websites only took a position on the cookie-directive (ePrivacy), and many Publishers decided that implicit opt-in was sufficient legal basis for dropping and using cookies, which resulted in the absence of user-facing cookie consent mechanisms on their websites. It is important to recognize that in some jurisdictions, for example Germany and Norway, in certain situations, cookie-consent is not being collected post-GDPR either, but instead operated under the assumption of legitimate interest. This is however a position that might be subject to change based on future legal developments and evolving regulator guidance.

The majority of Publishers we work with currently operate with explicit cookie consent platforms as a consequence of regulator guidance. They can however be divided into two sub-groups: Those with static consent platforms and those with dynamic consent platforms. By static consent platform we refer to platforms that inform users about the use of cookies and require them to accept such usage, but where the cookie-consent mechanism is incapable of communicating user-choice to services / applications present on the website/media. Or to third party services operating through the Publishers ad-tech stack.

‘A dynamic cookie consent platform is capable of either communicating user-choice to services / applications on the website/media and/or to control execution of scripts on the website based on user-choice. The typical use-case is to withhold further execution of scripts that utilize cookies until consent has been explicitly granted by the user. The cookie-consent platform can however typically not communicate consent to third party services operating through the Publishers ad-tech stack, only block select services if deemed not permitted to operate given the absence of cookie consent.

The TCF 2.0 platform is capable of not only handling purpose specific GDPR consent signals and cookie consent, but also to communicate user- as well as publisher-consent signals to third party vendors and services, either through the CMP installed directly on the website, which communicates directly with installed services, or indirectly by distributing consent signal strings through ad-tech services installed on the website.

It is however important to pay attention to the detail, that the TCF framework is not just about user-consent Yes/No on specific purposes, it also allows the Publisher to define which purposes they consider covered under legitimate interest? And which they consider require explicit consent from users? This approach will eventually lead to different publishers applying different legal reasoning for why consent is/is not required. A good example at the moment is the previously mentioned discrepancy between how cookie/storage consent is handled (purpose 1) in Germany/Norway versus the rest of the industry.

The diagram below shows how the Publisher script will behave in the case of a dynamic cookie consent platform being present on the website.

Cookie-consent is collected from the user arriving on the website or read from a previous engagement. If consent is granted, the Publisher script will execute with full permission to perform analytics data collection. The data points sent to AP will be enriched with a hardcoded permission string to ensure the data point only is used according to Media Metric defined purposes.

If there is no cookie permission granted? A special flag will be set when the Publisher script is invoked to ensure we still collect the impression / pageview information, but without being able to add cookies/identifiers to the user.

Consequences of this approach on measurement: All impressions counted, some will be without cookie-id’s. Statistical model is designed to handle the absence of cookie-id’s on a certain proportion of all logged impressions. As long as that proportion does not exceed 50%, the model will be able to correct the estimates.

The diagram below shows how the Publisher script will behave in the case of a static cookie consent platform being present on the website.

Cookie-consent is collected from the user arriving on the website. If consent is granted, the Publisher script will execute with full permission to perform analytics data collection. The data points sent to AP will be enriched with a hardcoded permission string to ensure the data point only is used according to media metric defined purposes.

If there is no cookie permission granted? Execution of the Publisher script will be suppressed to avoid any cookies being dropped. It is not an optimal solution compared to the dynamic variant, but sometimes the only option in the absence of a dynamic cookie-consent platform.

Consequences of this approach on measurement: Some impressions will be lost due to the script being suppressed when user do not grant cookie-consent. Underreporting of pageviews, users and reach will be the consequence.

Before the Planet49 ruling, a quite lively debate around explicit versus implicit consent mechanisms took place amongst Publishers. At that point in time we had to facilitate both camps. Which is why this documentation exists to support European Publishers who operate under implicit cookie-consent signals as well as non-European publishers.

Consequences of this approach on measurement: No limitations in measurement.

If a Publisher has decided to use TCF and utilize the TCF platform for communicating cookie and purpose consent, it is important as step 1 that AudienceProject is added as TCF vendor in the CMP with the AudienceProject vendor ID.

When the Publisher script is triggered it will fetch consent signals directly from the Publishers CMP. Further actions of the Publisher script depends on individual Publishers configuration of purposes and legal grounds as well as the users permissions.

TCF does add an additional level of complexity in terms of Media Metrics coordination. Step one is for Media Metrics to agree on a Purpose category for the measurement being performed under the contract. Two TCF 2.0 purposes can be used:

We recommend utilizing purpose 9, but have to respect individual publishers' choice in this matter since the configuration of permitted purposes happens solely at the Publishers discretion.

Another TCF 2.0 purpose that needs to be taken into consideration is:

Purpose 1 specifies if cookies / mobile identifiers can be used or not? TCF 2.0 purpose 1 should be used as the primary cookie-consent mechanism, and will be treated as such unless special arrangements have been agreed upon. But in some jurisdictions, for example Germany and Norway, in certain situations, consent for Purpose 1 may not be asked for by the publisher via the CMP. So long as the TCF string appropriately represents this, AudienceProject can handle such exceptions. This position is however subject to change based on legal developments and evolving regulator guidance.

We also have to consider that Purpose 8/9 can either happen under legitimate interest? Or with a consent requirement? Below we have outlined the different scenarios dependent on the individual publishers Purpose 8/9 requirements.

Assumptions: Assuming no special arrangements are in place and Purpose 1 always operates under the assumption of consent and Purpose 8/9 requires consent, we will have three potential outcomes.

Outcome 1: Publisher script will be able to collect data and embed the TCF consent signal string to the data collected.

Outcome 2: Since consent is not granted on purpose 8/9, the Publisher script will stand-down.

Outcome 3: Since consent is not granted on Purpose 1, the Publisher script will trigger with cookie-exception flag and embed the TCF consent signal string to the data collected.

Consequence on measurement: Some impressions will not be counted, some will be without cookie-id’s. Statistical model is designed to handle the absence of cookie-id’s on a certain proportion of all logged impressions. As long as that proportion does not exceed 50% the model will be able to correct the estimate bias introduced by the missing cookie/device id’s. Since some impressions will be lost, there will be underreporting of pageviews, users and reach as a consequence.

Assumptions: Assuming no special arrangements are in place and Purpose 1 always operates under the assumption of consent and Purpose 8/9 operates under legitimate interest, we will have two potential outcomes.

Outcome 1: Publisher script will be able to collect data and embed the TCF consent signal string to the data collected.

Outcome 2: Since consent is not granted on Purpose 1, the Publisher script will trigger with cookie-exception flag and embed the TCF consent signal string to the data collected.

Consequence on measurement: All impressions will be counted, some will be without cookie-id’s. Statistical model is designed to handle the absence of cookie-id’s on a certain proportion of all logged impressions. As long as that proportion does not exceed 50% the model will be able to correct the estimate bias introduced by the missing cookie/device id’s.

The IAB Europe Transparency and Consent Framework (TCF) is the only GDPR consent solution built by the industry for the industry, creating a true industry-standard approach.

The TCF’s simple objective is to help all parties in the digital advertising chain ensure that they comply with the EU’s GDPR and ePrivacy Directive when processing personal data or accessing and/or storing information on a user’s device, such as cookies, advertising identifiers, device identifiers and other tracking technologies.

The TCF creates an environment where website publishers can tell visitors what data is being collected and how their website and the companies they partner with intend to use it. The TCF gives the publishing and advertising industries a common language with which to communicate consumer consent for the delivery of relevant online advertising and content.

Read more here: https://iabeurope.eu/transparency-consent-framework/

AudienceProject is a certified TCF vendor.

On 25 April 2018, IAB Europe launched TCF v1 and on 21 August 2019, IAB Europe launched TCF v2. TCF V2 will become the defacto standard Q2 2020.

The TCF 2.0 framework allows Publishers to communicate a wide range of permission purposes and user consent settings to their partners and installed services. The full list available is:

This documentation contains the technical implementation details required to work with scenario 3:

Description of the consent flow

Cookie-consent is collected from the user arriving on the website or read from a previous engagement.

If consent is granted, the Publisher script will execute with full permission to perform analytics data collection. The data points sent to AP will be enriched with a hardcoded permission string to ensure the data point only is used according to Media Metric defined purposes.

If there is no cookie consent granted, a special flag will be set when the Publisher script is invoked to ensure we still collect the impression / pageview information, but without being able to deploy cookies/identifiers on the device.

Technical implementation

The following script code needs to be loaded before the Publisher script is added to the page. The user’s cookie consent needs to be passed using the storage flag.

If cookie consent is given, storage should be set to true. If no cookie is given, storage should be set to false.

Example of loading the Publisher script when cookie storage consent is given:

<script>

window.audienceProjectLayer = window.audienceProjectLayer || [];

window.audienceProjectLayer.push(['setConsents', {

storage: true

}]);

</script>

<script src="https://sak.userreport.com/<customerID>/launcher.js"></script>

Example of loading the Publisher script when cookie storage consent is not given:

<script>

window.audienceProjectLayer = window.audienceProjectLayer || [];

window.audienceProjectLayer.push(['setConsents', {

storage: false

}]);

</script>

<script src="https://sak.userreport.com/<customerID>/launcher.js"></script>

Validating the implementation

The implementation can be validated by checking whether requests to https://tag.userreport.com are executed or not. This can be done by looking at the network requests in your browser’s “Developer Mode”. Note that this should always be validated in a fresh browsing session, i.e. in Private Mode or Incognito Mode.

If the user consented to cookie storage, a request to https://tag.userreport.com will be executed.

If the user did not consent to cookie storage, no request to https://tag.userreport.com will be executed.