We’ve migrated our documentation to a new site, which means some URLs have changed.
Audience

TCF 2.0 in Audience


Introduction 

The intent of the TCF 2.0 to Piano Audience consent class feature in cx.js is intended to make automatic decisions on what data the Piano Audience collects based on the indications from TCF 2.0 strings. 

When activated alongside any compatible CMP (one that implements the TCF standard), the function will be able to read a TCF 2.0 string and turn on and off Audience consent classes based on the indications given in the string.

Mapping Method and Strategy 

The integration has a strategy on how it should map TCF 2.0 purposes and features that apply to Audience use cases. 

  1. If GDPR applies, it will continue, otherwise, it will turn on all consents.

  2. It checks for a vendor allowance. If the CMP turns off “Cxense ASA” (vendor ID: 412) then all consents will be turned off. 

  3. It will check publisher restrictions and use a mapping strategy to correctly map what the publisher requires. The mapping strategy is described below. 

  4. It will then check user consent and use the same mapping strategy. 

Piano Audience consent classes were originally designed in the context of representing the purpose of PII (personally identifiable information). What is considered PII for the purposes of the GDPR is any identifier that can be used to identify a profile of a user. Audience consent classes are stored along with page views and are stored in user profiles to govern what we can and can’t do with the information we have collected for that user. 

TCF 1.1 had a less granular mapping than all of our consents at the time mapped to TCF consents. However, in TCF 2.0, there is more granularity in purposes and features. So keeping with our original intent, our consent classes are driven by the same principle.

The logic of the mapping is that if one type of purpose is turned off in the TCF string, Audience' relevant consent class will be turned off. For example, if one of “serving basic ads” and “personalizing ads” is not allowed, the “ad” consent class will be turned off. Definitions of each consent class are provided below:

  • pv: The Pageview consent class. When this is disabled, Piano will not store any information generated from any pageviews generated by the user.

  • recs: The Recommendations consent class. When this is disabled, Piano will not display any content recommendations to the user based on their personal browsing habits.

  • ad: The Advertising consent class. When this is disabled, Piano will not allow for personalized or targeted ads to be displayed to the user. Piano will prevent this user from being activated in Connectivity.

  • segment: The Segment consent class. When this is disabled, Piano will not make accessible any information on the segments to which that user belongs. The user's actions on site are reflected in reporting, but that user cannot be classified under any particular segment.

  • device: The Device consent class. When this is disabled, Piano will scrub any characteristics pertaining to the user's device, such as browser, IP address, OS, MAID, etc.

  • geo: The Geolocation consent class. When this is disabled, Piano will not collect the user's geolocation from pageview metadata such as IP address.

The current mapping of these consent classes to TCF purposes is as follows:

PURPOSE/FEATURE #

PURPOSES CLASSIFIED BY TCF 2.0

CONSENT CLASS

NOTES

1

Store and/or access information on a device 

pv, recs

2

Select basic ads

ad, segment

3

Create a personalized ad profile

ad, segment

4

Select personalized ads

ad, segment

5

Create a personalized content profile

recs

6

Select a personalized content profile

recs

7

Measure ad performance

ad, segment

8

Measure content performance

recs

9

Apply market research to generate audience insights 

pv, ad, segment

10

Develop and improve products

pv

1 (Special purpose)

Ensure security, prevent fraud, and debug 

-

This will always be a required activity.

2 (Special purpose)

Technically deliver ads or content 

ad, recs

1 (Feature)

Match and combine offline data sources 

-

This is a customer-defined activity, not related to internal processing.

2 (Feature)

Link different devices

-

This is a customer-defined activity, not related to internal processing.

3 (Feature)

Receive and use automatically sent device characteristics for identification

-

We do not use device information for identification.

1 (Special feature)

User-precise geolocation data

geo

2 (Special feature)

Actively scan device characteristics for identification

device

Mappings can be modified based on the publisher’s need and will be described in the usage documentation.

Notes:

  1. When checking publisher restrictions, it will only see if 412 is disallowed for each purpose. At the moment, there is no more logic and will assume that the intent is to request consent from the user. 

Set up your CMP 

There are certain considerations that you need to take before you implement this feature. The feature will respect anything that is said in the TCF string. 

  1. If there is a vendor-level block, it might be necessary to set the Cxense vendor (ID: 412). Otherwise, it will immediately turn off all consents. 

  2. Does the Cxense vendor ID have any configured publisher restrictions? If there are any publisher restrictions, it will turn off functions automatically. 

Ensure these are set up correctly before testing this function. 

How to use this integration

To activate this integration, set a flag when setting up the cX object: 

var cX = window.cX || { options: { tcf20: true } };

or you can launch it at another point on the page: 

cX.requireTcf20();

This will turn on the consent functionality, set the Audience consent class version to “2” (activates the use of “device” and “geo”), and set up a TCF-compatible function (will call window.__tcfapi) to wait for a valid TCF string.

The settings that can be modified apply to purposes (device and geo are special cases and are simply mapped to the TCF special features.) 

The default structure used maps a consent class to a list of TCF purposes (based on the numbering provided above.) 

{ 
pv: [1,9,10], 
ad: [2,3,4,7,9], 
recs: [1,5,6,8], 
segment: [2,3,4,7,9] 
}

This means for example, that if EITHER purpose 1, purpose 9, or purpose 10 are not allowed as a publisher restriction or a user consent, then "pv" is turned off. (Note: In this circumstance, it is important to remember that "pv" is critical to get useful analytics about a user. Most other features will not work in terms of personalization and segmentation if this flag is not set correctly.) 

Customizing the impact of the consent class’s state might be necessary for publishers who have different views or expect a different impact than the strategy used above. The approach however will use the same “if one purpose is not allowed, the whole consent class is turned off” method. 

This can be changed with the cX.setRestrictionsToConsentClasses() function: 

cX.setRestrictionsToConsentClasses({ 
pv: [1,9,10], 
ad: [2,3,4,7,9], 
recs: [1,5,6,8], 
segment: [2,3,4,7,9] 
});

This can also be done before boot: 

var cX = window.cX || { options: { tcf20: true, tcf20Restrictions: { pv: [1,9,10], 
ad: [2,3,4,7,9], 
recs: [1,5,6,8], 
segment: [2,3,4,7,9] 
} } };

 More information about GDPR and the CX.js is available here.

TCF 2.2

At Piano, we are dedicated to ensuring the highest standards of data privacy and user consent management. We are pleased to announce our full compliance with the latest Transparency and Consent Framework (TCF) Protocol Version 2.2.

Last updated: