Global Privacy Platform (GPP)

About the Global Privacy Platform

The Global Privacy Platform (GPP) is an IAB specification helping all stakeholders in digital advertising to support regional privacy regulations more easily.
GPP streamlines the transmission of privacy and consent signals from sites and apps across jurisdictions to ad tech providers. The framework currently supports the following consent strings:

• US Privacy
• IAB Europe TCF
• IAB Canada TCF
• various US state-specific consent strings 

Equativ's GPP support

GPP signal transport

Equativ always reads and transports the entire consent string payload: all GPP string sections (for all jurisdictions) are sent to demand partners.

The transported GPP fields include:

• gpp - the Global Privacy Platform (GPP) consent string
• gpp_sid - an array of the section(s) of the GPP string to be applied for the given transaction; generally, it will contain one and only one value; more than one value may apply in rare cases; see list of section IDs

The gpp and gpp_sid fields are also documented in Equativ’s Ad API references - see Ad API - GET method / Ad API - POST method - Reference.
 

GPP signal processing

Signal processing means that the privacy signals from the user/device are being decoded by Equativ and applied accordingly. If consent is negative or was withdrawn, personal data / detailed geo data for this user/device is not being shared/used/applied by Equativ - more details in chapter “Impact of negative/withdrawn consent” below. 

At this time, Equativ is able to process the following sections of the GPP string:

Section ID	String	Description
-1	n/a	there is no privacy regulations to be complied with
2	tcfeuv2	EU TCF v2
6	uspv1	USPrivacy String
7	usnat	US - national section
8	usca	US - California section
9	usva	US - Virginia section
10	usco	US - Colorado section
11	usut	US - Utah section
12	usct	US - Connecticut section

Read the IAB's documentation about each section for more details.

Jurisdictional overlap

Jurisdictional overlaps may occur in rare situations where a user interaction falls under two jurisdictions, such as a user living in Europe but visiting a website in another country (see “3. Multi-Jurisdictional Design” here). In these cases, Equativ considers the consent as being given/not withdrawn only if consent is given/not withdrawn for all jurisdictions. As soon as consent is negative or withdrawn for at least one jurisdiction, Equativ will consider consent as being negative/withdrawn.

Impact of negative/withdrawn consent

The privacy frameworks IAB Europe TCF v2 and the privacy frameworks in the United states differ in the way they treat consent. For the IAB Europe TCF v2, the logic behind GDPR is that an end-user should consent/opt-in to the processing of his/her data. If there is a negative consent, the data will not be processed. Privacy frameworks in the United States follow an opt-out logic, i. e. you can process data as long as there is no opt-out – apart from particular exceptions that require consent under American privacy laws, such as precise geolocation. In other words, by default, consent is considered to be given but can be withdrawn by the user. 

In case of the IAB Europe TCF v2, consent is interpreted to be negative if the GDPR legislation applies and if:

• the user rejects at least one of the Purposes where consent is required (see column “Consent" in the table in chapter “TCF signal registration” below) - or
• the user does not provide any response to the privacy questions asked by the CMP or there is no CMP installed
• the consent signals could not be retrieved due to other technical reasons.

In case of US Privacy v1, consent is interpreted to be negative (withdrawn) if the CCPA legislation applies and if the Opt-Out Sale field of the US Privacy string is set to "Yes", meaning that the user has opted out of the sale of his or her personal information pursuant to 1798.120 and 1798.135 of the CCPA (more details about this field here).
 
In case of US national and state-specific frameworks (e.g. California, Virginia etc.), consent is considered to be negative (withdrawn) if any of the notices (such as the SharingNotice) was not provided or if any of the opt outs (e.g. SaleOptOut) was made by the user. Note that Equativ does not consider MSPA-related fields (such as MspaCoveredTransaction or MspaOptOutOptionMode) when determining whether consent is interpreted as negative (withdrawn).
    
In case of negative/withdrawn consent, Equativ:

• does not share any personal data with demand partners 
• does not deposit any cookies (see list of cookies in Equativ’s privacy policy)
• does not deposit nor use any user identifiers (e. g. pid for desktop or mobile IDs for in-app etc.)
• blocks all cookie synching mechanisms with all demand partners
• uses the IP address only to technically deliver the creatives

In case of negative/withdrawn consent, the following features are not available/unreliable:

• personalized ads based on audience data in direct and programmatic advertising
• precise geolocation targeting (GPS latitude/longitude)
• audience targeting with third party vendors
• frequency capping
• unique visitor reporting

 

GPP report dimensions

• the report dimensions “Allowed to use personal Data” and “Allowed to Use Geolocation Data” apply to all privacy frameworks (GPP and the standalone frameworks TCF v2 and CCPA); for more details, see chapter “GDPR report dimensions” below
• the “Consent String Status Id/Name” report dimension applies to the standalone frameworks TCF v2 and CCPA only (not for GPP framework); for more details, see chapter “GDPR report dimensions” below

Fallback to GDPR / US Privacy signals

Equativ follows a waterfall model when processing GPP/TCF/US Privacy signals:

• Equativ first attempts to retrieve and process the TCF v2 and US Privacy sections from the GPP string
• if a GPP string could not be retrieved, Equativ will attempt to retrieve and process a standalone TCF v2 / US Privacy consent string 

With this fallback mechanism, Equativ embraces the new GPP standard, while still fully supporting the processing of previous TCF v2 and US Privacy consent strings passed as standalone strings outside of the GPP framework.

The IAB Europe Transparency and Consent Framework (TCF) v2

The IAB Europe Transparency and Consent Framework helps publishers who partner with third parties in processing personal data in compliance with the GDPR.

TCF signal registration

Equativ is registered as a compliant vendor with ID 45.
Note that, at this time, Equativ is in the process of registration for the new TCF Global vendor list.

The table below lists each TCF v2 signal and indicates if Equativ is registered for the signal as well as the legal basis chosen by Equativ.

Signal	Registered?	Legal basis
Purpose 1 - Store and/or access information on a device	yes	consent
Purpose 2 - Select basic ads	yes	consent
Purpose 3 - Create a personalised ads profile	no
Purpose 4 - Select personalised ads	yes	consent
Purpose 5 - Create a personalised content profile	no
Purpose 6 - Select personalised content	no
Purpose 7 - Measure ad performance	yes	consent
Purpose 8 - Measure content performance	no
Purpose 9 - Apply market research to generate audience insights	no
Purpose 10 - Develop and improve products	yes	consent
Special Purpose 1 - Ensure security, prevent fraud and debug	yes
Special purpose 2 - Technically deliver ads or content	yes
Feature 1 - Match and combine offline data sources	no
Feature 2 - Link different devices	no
Feature 3 - Receive and use automatically-sent device characteristics for identification	yes
Special Feature 1 - Use precise geolocation data	yes	consent; needed in case of GPS lat/long targeting
Special Feature 2 - Actively scan device characteristics for identification	no

Passing TCF consent signals to Equativ

TCF consent signals are passed to Equativ using two parameters: 

Field__________________	Data type	Necessity	Description
gdpr	BOOLEAN	OPTIONAL	indicates if the given request is from a location where the GDPR applies; if not provided, Equativ will attempt to leverage the geolocation of the user to determine if the GDPR applies
gdpr_consent	STRING	REQUIRED (for EU traffic)	the TCF consent string, if the GDPR applies

Consent signals are passed seamlessly and automatically in most integrations with Equativ. However, some specifics apply for some integrations:

1. AMP integrations – retrieval of the consent signals is more constrained for the AMP page integration: during the page load, Equativ’s AMP adapter will look for the window.context.consentSharedData.consentString property that can be set by an IAB compliant CMP. Please refer to your CMP contact to make sure that your CMP is compatible with the IAB standards.
2. Server to server integrations – consent signals must be passed using the gdpr and gdpr_consent parameters; the gdpr parameter is only relevant in server to server integrations where the geolocation of the end user (and thus GDPR applicability) cannot be determined.
3. Audience data provider integrations – see the Audience data — user synchronization article for more details

Dimension	Description	Possible values
GDPR Applies	indicates if the GDPR applies	-1 - Unknown 0 -  No 1 - Yes
Consent String Status	indicates the status of the consent string	-1 - Malformed 0 - No consent string 1 - Has valid consent string
Cmp	identifies the Consent Management Platform used to provide the consent	0 - Unidentified [CMP ID] - CMP ID as specified in the IAB Europe CMP list
GDPR Version	indicates the IAB Europe TCF version	0 - Unidentified 1 - TCF v1 2 - TCF v2
Is Equativ Allowed To Use Personal Data	indicates if Equativ is allowed to process personal data as mandated by the GDPR	0 - Not allowed 1 - Allowed
Is Equativ Allowed To Use Geolocation Data	indicates if Equativ is allowed to process geolocation data as mandated by the GDPR	0 - Not allowed 1 - Allowed

GDPR macros

Read about the GDPR related macros [sas_gdpr_applies] and [sas_gdpr_consent] in the Macros article.
 

The IAB CCPA Compliance Framework

Equativ supports the IAB’s CCPA Compliance Framework helping the ad tech industry to meet their compliance obligations with the California Consumer Privacy Act (CCPA). The CCPA gives consumers control over the personal information that businesses collect about them. It applies to all businesses operating in the state of California, regardless of the specificity of their data collection and processing
The user’s choices are stored in the US Privacy string, which has 4 components, specified in the official US Privacy String Format documentation.
Note that the CCPA/US Privacy framework follows an opt-out approach: the user can opt out of the sale of his or her personal information pursuant to 1798.120 and 1798.135 of the CCPA - see string component “Opt-Out Sale” specified here.

Passing the US privacy string to Equativ

The US privacy string is passed seamlessly and automatically in most integrations with Equativ. The parameter used to pass the US privacy string (payload) to Equativ is called us_privacy (see documentation in the Ad API - reference).

Targeting consent

Targeting insertions to the presence of user consent

You can target insertions to the presence of user consent using the "Personalized Ad" option available in the General settings and Delivery section in insertions.

Targeting insertions to traffic without consent

You can pursue a monetization strategy where you target insertions to users who do not consent. The user’s consent is determined client side: if it is negative or unknown, the dedicated consent=rejected keyword is sent as part of the targeting string in the ad call (default behavior – no manual activation required).
To target insertions to this traffic, go to the Targeting section of the insertion and add the keyword consent=rejected. As a result, the insertion will only be displayed to users that gave negative or unknown consent. For more about keyword targeting, click here.

Supported integration types
Targeting insertions to users who do not consent works with these integration types:

• integrations using Equativ’s library smart.js (see also "Disabling client side reading of consent string" below)
• web integrations without smart.js
• integrations with the Instream SDK
• integrations with the Display SDK
• integrations with the Video Plugin

Disabling client side reading of consent string 
In integrations with Equativ’s library smart.js, the mechanism of reading the consent string client side and sending the keyword consent=rejected can be disabled in sas.setup():
Targeting traffic without consent in non-smart.js web integrations
To target traffic without consent in web integrations without smart.js, you can use the module as a standalone library, available here.
Requesting the sas.consent.checkConsent(callback) will either return the string consent=rejected (traffic without consent) or null.

Google’s Additional Consent Mode

Google's Additional Consent Mode is used by vendors who are not yet registered on the IAB Europe Global Vendor List (GVL), but are registered as Google Ad Tech Providers (ATPs). The specification enables publishers, Consent Management Providers (CMPs) and Google partners to gather the Additional Consent (AC) and propagate it alongside their TCF v2.0 implementation (more about the AC string format here).

Using Google's Additional Consent Mode with Equativ is not enabled by default. Get back to your Technical Account Manager at Equativ to have it enabled in your network. 
 
Equativ is able to receive and process AC strings only with the following integration modes: web/mobile web (smart.js), prebid.js header bidding, simple ad calls; the integration modes instream video plugin and in-app display/instream SDKs are not supported!
Only CMPs registered officially with the IAB Europe TCF (official CMP list here) are allowed to create and pass AC strings.
Having many Google Ad Tech Providers (ATPs) leads to very long Additional Consent strings. Therefore, publishers should reduce the list of available vendors as much as possible!
 
The macro [sas_addtl_consent] is available and is being replaced by the AC string passed to Equativ (for more about this macro, see the Macros article.