All pages
Powered by GitBook
1 of 62

Consent management

Overview

Increase brand loyalty by allowing users to control the data collected about them & establish trust through transparency.As a result of the increasing number of data breaches and the misuse of personal information, privacy management is a growing part of the modern marketing landscape.The General Data Protection Regulation (GDPR) has largely been perceived as a legal issue, due to the fines that can be imposed because of non-compliance, but it’s also created opportunities for brands to build greater trust with their users. In fact, according to research conducted by iProspect, 88% of global marketers say trust is a priority in 2019, and they are looking to build this trust through credibility, relevancy, and reliability.Fueled by consumer privacy laws like the GDPR, most marketers are turning to solutions like Commanders Act CMP that alert website and mobile app users of the personal data that’s being captured, stored, and shared with third parties.This documentation will provide you with an overview of Commanders Act CMP, setup guides per platform, user guides per feature and a knowledge base for frequently asked questions.ComponentsCommanders Act CMP consists of following components:

Component

Description

Privacy banner

Banner that is shown to visitors to inform them about privacy settings and to ask for permission to collect their personal data.

Privacy center

Banner that provides fine-grained privacy controls for website visitors for different privacy categories, vendors or tools. The privacy center is usually linked in the privacy banner and privacy policy.

Privacy manager

A technical layer below the privacy banner and privacy center that manages and stores the privacy settings of the visitor. It connects with other tools like tag managers to control which features, services or tags are loaded for a visitor based on his privacy settings.

Privacy cookies

First party cookies that are used to store the privacy settings of a user.

Privacy log

A database that logs visitor consent settings so that they can be proofed in case of an information request by the visitor.

Categories

Groups of services and features that require personal data. These categories are used by the privacy center to present consent controls and are used by the privacy manager to communicate privacy settings to other tools. Typical categories are "Analytics" and "Personalisation".

Vendors

Individual services and vendors that require personal data. These vendors are used by the privacy center to present consent controls and are used by the privacy manager to communicate privacy settings to other tools. Typical vendors are e.g. "Google" and "Facebook".

Dashboard

Dashboard that provides performance KPIs of each privacy banner.

OnSite API

Allows to interact with Consent module with code.

Frameworks

Commanders Act CMP supports following frameworks:

  • IAB TCF 2.0 (v2.2 will be supported before September 30)

  • Google ACM

Extensions

It is possible to extend Commanders Act CMP with following modules:

Cookie Scanner

TagFirewall

Tag Hierarchy

These modules are set up and configured by a Commanders Act consultant.

Setup

Please refer to the Setup Guides section for detailed installation instructions of Commanders Act CMP per platform. In case your platform is not listed you can reach out to a Commanders Act consultant for a custom implementation.

Setup Guides

Responsability of actors

The collection of personal information is regulated by law at European level with the GDPR.As a European player, Commanders Act fits into this framework and pays particular attention to the governance of its data.This page explains the positioning of Commanders Act and that of its customers within this regulatory framework.​

Commanders Act

Under RGPD rules, Commanders Act acts as a data processor. Therefore, Commanders Act is responsible for the following obligations:- maintain data security- continuously improve security processes- duty of cooperation, in particular in the event of control by the CNIL- appointment of a data protection officer- keep a processing register- notify any data breach to the data controller​

The customer

Customers of Commanders Act, users of the platform, are considered data controllers. Therefore their obligations are:- decide on the purpose of the processing (reasons for the processing, categories of data)- decide on the means of processing (retention period, recipient, right of opposition, right of rectification)Commanders Act puts its technical expertise at the service of its customers in order to guarantee the protection of users' personal data.As your partner and processor, we are at your disposal for all questions on data protection subjects.

Setup Guides

In this section, you will find information about Consent setup on your website(s) and mobile application(s)

Tag Manager

Commanders Act TMS

Steps to implement Consent Module with TMS Commanders Act

Consent Module and TMS Commanders Act are natively integrated with each other. This setup requires minimal technical knowledge and can be done entirely in the interface.

Setup

Following you will find the required steps to implement a standard Commanders Act Consent module setup.

  1. Choose the default account configuration mode for your account (see Options).

  2. Setup your Consent categories & vendors (see Manage Categories).

  3. Assign your Consent categories & vendors to your Commanders Act Web Container tags (see Assign categories)

  4. Create one or multiple Consent banner templates (see Manage Banner)

  5. Deploy your Consent banner templates to the Commanders Act CDN or on premise target (see Deploy Banner).

  6. Connect your privacy banner templates with Commanders Act Web Container and implement rules for which the banner should be played out (see below).

Install Consent banner with TMS Commanders Act

To deploy a Consent banner with the Commanders Act TMS it needs to be linked to a container. Commanders Act TMS can then be use to implement detailed rules for which a Consent banner is shown to visitors.

Implement rules to display Consent banners

Sources > Overview > Web Containers > tab RULES > Privacy Banners Constraints​

In Commanders Act TMS it is possible to provide exact conditions to decide when each of the linked privacy banners should be shown to visitors. Typical use cases consist of:

  • Implement different banner for different languages or regions

  • Avoid to deploy the banner on legal pages (privacy policy) so that users can read them before providing consent.

  • Implement AB test for two banner designs.

You can create constrains under the PRIVACY BANNERS section to define under which conditions a privacy banner should be shown. Privacy banner constraint work the same way as tag constraints. Please reference constraints in the Web Container documentation for more information.

You have to first deploy a banner to the Commanders Act CDN or on premise location before being able to configure constraints (see Deploy Banner).

Link Consent banner with Commanders Act Web Container

Sources > Overview > Web Containers > tab GENERATE

Commanders Act TMS makes it easy to implement Consent banner on websites. To link a privacy banner with a Commanders Act TMS container it just has to be activated in the GENERATE tab with the ACTIVATION checkbox. This installs the selected privacy banner in the generated container version.

You have to first deploy a banner to the Commanders Act CDN or on premise location before boing able to link it (see Deploy Banner).

All web containers of your website should be re-generated and deployed when installing a new privacy banner.

Go further with OnSite API

The OnSite API allows you to reload your container(s) on consent, manage behaviour or create custom variables/rules!

You can find the full list of commands in the dedicated section.

To reload your web container(s) on user consent, here's a sample code that you can use in the custom js block of your privacy banner, or directly in your web containers

/* Reload web containers on user interaction */

cact('consent.onUpdate', function (result) {      
        tC.script.add("https://cdn.tagcommander.com/xxxx/my_container_name.js");
});
/* Different approach for container reoad - based on work environment variable */

cact('consent.onUpdate', function (result) {      
    if (tc_vars.env_work === 'prod') {    
        tC.script.add("https://cdn.tagcommander.com/xxxx/my_container_name.js");
    } else {          
        tC.script.add("https://cdn.tagcommander.com/xxxx/uat/my_container_name.js"); 
    } 
});

Google Tag Manager (GTM)

Introduction

Google recommends that GTM customers use our "Commanders Act CMP" This template includes the Google Consent Mode feature.

For further information, please read the documentation Google Tag Manager (GTM) - Consent Mode

In this section, you will find a complete guide to integrate Commanders Act Consent banners in your Google Tag Manager

Enclosed you'll find two sample configuration files, a very simple setup that you'll need to reproduce you'll need to reproduce on your site. The first and most common configuration is the gtm_category_template.json, a category-based configuration (example with only 1 category). The other possibility is a vendor-based configuration, with only the Cact allows Statistical variable changing in gtm_partner_template..json.

13KB
gtm_category_template.json
11KB
gtm_partner_template.json

Getting Started

  1. In GTM, create a new account so as not to overwrite your current configuration.

  2. In this new test account, go to Admin, then on the right side of the screen click on Import Container and select the file attachment gtm_category_template.json

  1. Observe the configuration to constrain a simple Google Analytics page view tag

Added elements

Understand and personalize the json

Tags

  1. "Google Analytics Page view" is only a basic tag example, "Cact consent given Statistical" trigger is applied on

  2. "Consent Cact - Start" tag refers to the "Consent Banner - URL" variable, and is the tag that "activates" the privacy module* and is the only tag that will be triggered with a simple All pages trigger. All other tags must have a trigger that includes the user's consent. *if you need more information about setup of your Consent banner, you can read our Consent management starter kit documentation)

Trigger

"Cact consent given Statistical" which triggers the page view tag as soon as the user has given consent on a first visit. consent has been given by the user on a first visit. The page view hit from consent pushes a tcConsentChanged event in GTM's dataLayer for each interaction with the privacy module

Field
Value

Trigger name

Cact consent given Statistical

Trigger Type

CUSTOM_EVENT

Event name

Cact allows Statistical

This trigger fires on

When the user interact with the consent banner and on each page view

Tips about trigger

"Cact consent given Statistical" is an arbitrary name, you can call it "Consent on page view for Analytics" or "Consent Analytics".

It is dedicated to a specific category, you will need to create "Cact on page view Advertising" and/or "Consent on page view Functional" for example, depending on your needs.

"Cact consent given Statistical" should also be reproduced and adapted for your other categories and coupled with custom triggers

Configuration example

The trigger should therefore refer to the variable for its category and trigger the associated tag if it returns "allowed"

Variables

  1. "Cact - User consent": will return different values, depending of user consent choice (no_consent, optout, all_consent or the list of consent categories IDs accepted by the user)

  2. "Cact allows Statistical": return "allowed" or "refused", depending of the choice of the user *Don't forget to personalize the ID with the value of your own setup on the Commanders Act Platform

  1. "GA4 - ID": Change this value by your own GA4 - ID

  1. "Browser language": will detect the browser language, do not modify this variable. It will be helpful if you have a multi-language website

  2. "Consent banner - URL": to be personalized with the your Consent banners url. To obtain your privacy banner url, go on the page Sources > Privacy banners > Deploy You can also have a look on this page for more information

To make your tags are submitted to user consent, you need to verify consent in each of your triggers

Google Tag Manager (GTM) - Consent Mode

Steps to implement Commanders Act Consent Module with Google Tag Manager.

Commanders Act provides a tag template to manage the "Consent Mode" in Google Tag Manager. This seamless integration takes advantage of our Commanders Act OnSite API.

Please note: Google only requires a validated consent signal only for EEA countries and UK.

Implementing Google Consent Mode in regions beyond may negatively impact campaign performance and is not recommended.

Setup

Summarizing all recommended steps:

  1. Access GTM.

  2. Select your "Web" type container.

  3. Add our tag template from the "Community Template Gallery".

  4. Configure the related tag and its trigger.

  5. Configure your third-party vendor tags.

  6. Test and deploy your container.

Configure the related tag and its trigger

Following the above steps, adding our template "Commanders Act CMP" from the Google "Community Template Gallery", you're presented with the following "Tag Configuration" which is the core area where you can manage your consent needs with GTM:

First, you need to input your consent category identifiers for the following 7 categories: Ad Storage, Analytics Storage, Functionality Storage, Personalization Storage, Security Storage, Ad User Data and Ad Personalization. You can define/find these identifiers by logging in to our platform and follow the section: (A)"Data Governance" → (1)"Consent Management" → (2)"Categories".

Your identifiers are shown between round parentheses (see highlighted in green below):

If you have sub-categories with the same scope of the five defined by Google, you need to use their ids instead of the main category ones. You can also rename your categories or change their ids by checking the subsection "Managing categories".

If your CMP loads asynchronously, it might not always run before your GTM container. That’s why you have the option to set a "Wait for update" value in milliseconds to control how long to wait before data is sent. This field is optional and its default value is 0. In case you need to set it, we recommend starting from the base value of 500 milliseconds.

You also need to set the default status, for each of the 7 categories, before users interact with your privacy banner and taking into account region-specific behavior. This is done by clicking the "Add Row" button and selecting either "Denied" or "Granted" to match with your input regions and/or sub-regions.

Ensure that your default command accounts for regional variations in your consent strategy. For more information on customizing the default command, you can see Google’s documentation here.

To make sure that the consent is correctly managed by GTM with third-party vendor tags, we strongly recommend to enable reactive events. Turn on the (3) "Advanced Features", (4) "Activate Reactive Events" and (5) "Activate [Storage-Name] Reactive Event" for each [Storage Name] you're using. Finally, enter their (6) "Event Name". These events will be used in the next section when configuring your third-party vendor tags.

You also have the option to directly inject your CMP script by turning on the (7) "Advanced Features", (8) "Inject CMP Script" and input your (9) "URL".

Disabling the default consent may come handy when you don't want to use the Consent Mode. This is done by turning on the (10) "Advanced Features" and (11) "Disable Default Consent".

As the last step, you need to select the "Consent Initialization - All Pages" trigger in the "Triggering" lower area:

Modify Permissions

If your banner is hosted on your servers (on premise) or if you use our CDN 1st party feature, then you need to update the Permissions of the template.

Simply add your host URL in the tab "Injects scripts" (see block "allowed patterns").

Configure your third-party vendor tags

While Google native product tags, such as "Google Analytics" or "Google Ads" ones, work out of the box, third-party vendor tags require additional settings to properly operate with the user consent. First, open your tag configuration and check under the (12) "Advanced Settings" and (13)"Consent Settings" if a consent type (E.g. "ad_storage") is already preconfigured, if not you need to add it by selecting the option (14) "Require additional consent for tag to fire" and (15) input the consent type(s) you want to include.

Then, you need to configure its triggers and this is where we're going to use our reactive events we prepared in the previous section. Locate the "Triggering" area in your tag configuration and add a "Trigger Group".

In the trigger group add (16) any preexisting triggers and (17)a trigger named as your configured reactive event.

The latter has to be configured as a (18)"Custom Event" with the same (19)"Event Name" you used in the previous section and it has to fire on (20)"All Custom Events".

This completes your configuration. You can now start the testing phase, leading to the final deployment in production. Learn more on how you can configure and run tests with your tags in GTM by checking the section "Consent configuration" in the "Help Center". You can also read the page Consent Mode setup provided by Google for Developers

Look our "Test your configuration" page for debbuging hints!

Google Consent Mode in Commanders Act CMP

Introduction

Google Consent Mode will evolve in March 2024!

As Google strongly recommends the use of Consent Mode on their tags, Commanders Act has developed a new built-in feature for clients who wish to implement it.

Just use our new native feature for a super smooth implementation! Please read the following documentation to learn more about this new feature, and how to use it. If you have already implemented Consent Mode v1 using our tag template and would like to keep it, you can update it on v2. Please see the following section for instructions: Migration Guide Consent Mode v1 tag template to v2

Please note: Google only requires a validated consent signal only for EEA countries and UK.

Implementing Google Consent Mode in regions beyond may negatively impact campaign performance and is not recommended.

Difference between Basic & Advanced mode

Google Consent Mode provides 2 approaches: Basic & Advanced In both cases, you will have to activate the feature Google Consent Mode on your account. The only difference will be the following: Basic Mode: Google tags aren't triggered before consent & remains submitted to Commanders Act Consent Rules, there will be no tags firing in case of Optout Advanced Mode: Google tags are triggered before consent & the collected data will depend on the Consent Mode Signal. Tags remains fired even when user has Optout.

How to use the Google Consent Mode feature ?

Just follow these 6 steps:

1- Activate the feature on your workspace

Login on your workspace Go on page Data Governance > Consent Management > Settings Turn On the option Google Consent Mode. The sub-menu "Google Consent Mode settings" will appears

2-Configure your settings

Categories

Select your appropriate Privacy category from the drop-down list for each Google's category.

Default Status

The Default Status will determine the behaviour of your tags BEFORE consent. If set on "denied": Google will collect minimum information (as if the user has Optout) If set on "granted": Google will collect all information (as if the user has Optin) *You should ask to your DPO before to set a "granted" default status for any of theses categories

In all cases: once the user has given his consent (optin or optout), the default status will no longer apply. The user's choice will determine the status after consent.

If you do not set a category, the status will always be "denied". The "Default Status" dropdown menu will no longer be displayed. Example below for "security_storage" with no privacy category assigned:

Additional Settings

  • enable_tcf_support If you use TCF 2.2 CMP template: TCData update (TCData.enableAdvertiserConsentMode) allows Google to infer ad_storage, ad_personalization, and ad_user_data settings from the TC string. This will incorporate consent mode v2 updates directly into the TC string. Enable the feature tcf_support to let your IAB TCF privacy banner manage the advertising categories. *Google recommends to activate this feature if your website use an IAB TCF banner template Don't forget to add your Google associated Vendors (see dedicated documentation for more details)

  • wait_for_update Enabling this optional feature will send a signal to Google's tags to wait for an update. Enter a value in milliseconds to control the waiting time before the data is sent. This can be useful if you are experiencing timing issues. Otherwise, you can leave it blank!

  • ads_data_redaction set ads_data_redaction to ON to further redact your advertising data when "ad_storage" is "denied"

  • url_passthrough URL passthrough option can be used to send event and session-based analytics (including conversions) without cookies across pages.

3-Activate the feature on your privacy banner(s)

Sources > Privacy Banners > Select your banner(s) Go at the edition step of your privacy banner, open the settings menu to turn ON Google Consent Mode Signal

The privacy setup is done! You can now Generate and Deploy your Privacy Banner. *At this point, Consent Mode will not affect the behaviour of your tags. Please follow the next steps!

The activation of this option will automatically add an Google Policy URL, it's a legal requirement for using Google Consent Mode on your website. Feel free to adapt your introduction text if needed

4- Advanced Mode: Remove your privacy constraints from Google tags

To setup the version "Advanced" of the Consent Mode, remove Commanders Act Privacy rules from all the Google tags, now it's managed by Google Consent Mode Data Governance > Consent Management > Categories see tab assign tags - Remove the privacy constraints from Google tags - Save

For Basic Consent Mode, skip the step 4! Keep your Privacy rules applied on your tags

5-Generate your container(s)

Go on Sources > WebContainers > generation step For a single container setup, generate your container with privacy banner(s) included

For a multiple container setup, generate all your containers. The privacy banner(s) must be linked to the first loaded container to ensure that the Consent Mode signal is always sent correctly.

If you was using the Consent Mode v1 tag, don't forget to delete or deactivate it! It's useless now.

What about the triggers ?

The consent mode is compatible with the container loaded trigger. If your Google tags are already set to this, it will work without any trigger modification

But we also provide a custom trigger, if needed! When a Consent Mode signal is sent, our product pushes tC.event.consent_signal_ready You can use it to trigger your tags.

If your site is an SPA, you can keep your tC.event.page/pageview... as trigger for your Google tags. The same goes for your click/scroll tags.

6-Tests & deployment

Deployment

We recommend to test you setup on a UAT environment if possible.

Test your configuration

There's 3 different ways to verify your Consent Mode setup:

The easiest way to verify your setup is using the Tag Assistant plugin provided by Google. The "Consent" event should always be sent before any hits from the tags The status "On-page Default" should be the same then the ones you setup at the step 2

After Consent, the "On-page Update" status should correspond to the consent given on the privacy banner

Feel as a developer? You can also look into the console to verify the Google arguments pushed in dataLayer Google. Type dataLayer then press Enter

One last method to verify your setup is possible: check into the payload of your hits in the network. The consent status is fed by the "gcd" parameter

Possibles values for gcd parameter

gcd is included in all hits to Google services, even if Consent Mode isn’t active.

It encodes values for four consent signals (ad_storage, analytics_storage, ad_user_data, and ad_personalization), and it includes information how the consent signal was generated.

The format of the string is this:

&gcd=11<ad_storage>1<analytics_storage>1<ad_user_data>1<ad_personalization>5

The string starts with 11, uses 1 to separate the different consent signals, and ends with a number like 5 (or sometimes something else) to mark the end.

Letter
Description
Example value
Meaning

l

The lowercase L means that the signal has not been set with Consent Mode

11l1p1l1l5

only analytics_storage has been denied by default

p

denied by default (no update)

11p1p1p1p5

all consent states are denied by default

q

denied both by default and after update

11p1q1p1p5

the user updated their consent choice to set analytics_storage to denied after it was already set to denied by default

t

granted by default (no update)

11t1t1t1t5

all consent states are granted by default

r

denied by default and granted after update.

11r1r1r1r5

the user grants consent to all services after they were first denied by default

m

denied after update (no default)

11p1m1p1p5

all other states were denied by default, but analytics_storage was only set after the user denied it

n

granted after update (no default)

11n1n1n1n5

the site did not set a default consent state and instead set all states to granted after the user chose so

u

granted by default and denied after update.

11u1u1u1u5

the user withdrew all consents after they were set to granted by default

v

granted both by default and after update.

11v1v1v1v5

all states were granted by default and by user confirmation

Verify the Consent Mode sequencing with our tC. method

To help you ensure that the consent signal is sent before your Google tags, we offer a method to get logs in the browser console

tC.privacy.explainGCMSequencingValidation() If the Consent is set before any Google tags triggered, you will obtain the log 'valid sequencing' If Google tags are triggered before the Consent is set, then your implementation is incorrect. The log will returns the value 'Consent is set too late, Google tags are triggered before consent set. Please verify your Consent Mode sequencing'

Need a boolean value for specific use cases ? Use tC.privacy.validateGCMSequencing() Will simply return true if your sequencing is correct, otherwise the result will be false

If Google tags haven't been fired yet, the result will always be "false". To get a "valid sequencing" result, Google tags must have been fired at least once.

FAQ

Modification/Update Configuration

In case of setup modification, such as activation/deactivation of a parameter, mapping changes on categories, etc.... Web Containers & Privacy banners must be regenerated & deployed.

Parameter "Region"

Google Consent Mode allows the consent management only for the declared Region(s) Our native feature does not include this parameter, for web performance reasons. If you need to use this parameter, we recommend using our TMS Tag template. Please refer to the next section of documentation for configuration details.

Support & assistance

Still facing trouble shooting on your implementation, and looking for help ? Contact our technical support team ! As a Google CMP partner with a Gold status, we provide a dedicated email support : cact_support_cmp_google@commandersact.com They will ever gave you a personalized reply to your questions!

Migration guide

For customers who has already implemented the Consent Mode v1: You can activate the built in feature as described above (don't forget to deactivate your actual consent mode tag) However, if you really want to keep your actual setup and simply update your tag, then you can refer to this documentation!

Summarizing all recommended steps:

  1. Access your Commanders Act account.

  2. Update your tag template.

  3. Test and deploy your container(s).

Update your tag template

Go on page "Sources" > "Web containers" Select you "Google Consent Mode with Trust" tag.

Update the js code block of your tag with the following code, then save to obtain the new fields

code snippet to update
<script language="javascript">
window.dataLayer = window.dataLayer || [];
var gtag = function (){
	dataLayer.push(arguments);
};
tC.internalvars.getRegion = function(a){
	a = a.toString().replace(/\s/g, '');
	a = a.split(",");
	return a;
};
tC.internalvars.setRegion = function(a) {
	tC.internalvars.regionArray = tC.internalvars.getRegion(a);
	if (((typeof tC.privacy.isEnable !== "undefined") && tC.privacy.isEnable()) && (tC.internalvars.regionArray.length > 0) && (tC.internalvars.regionArray[0] !== "") && (typeof tC.internalvars.consentSettings !== "undefined")) {
		tC.internalvars.consentSettings.region = tC.internalvars.regionArray;
		return true;
	} else return false;
};
tC.internalvars.setWait = function(a){
	if (((typeof tC.privacy.isEnable !== "undefined") && tC.privacy.isEnable()) && (isNaN(parseInt(a, 10)) === false) && (parseInt(a, 10) > 0) && (typeof tC.internalvars.consentSettings !== "undefined")) {
    	tC.internalvars.consentSettings.wait_for_update = parseInt(a, 10);
      	return true;
    } else return false;
};
tC.internalvars.setConsentCommand = function(a, b, c){
	tC.internalvars.isRegionSet = tC.internalvars.setRegion(b);
	tC.internalvars.isDelaySet = tC.internalvars.setWait(c);
  	if (((typeof tC.privacy.isEnable !== "undefined") && tC.privacy.isEnable()) && (tC.internalvars.isRegionSet || tC.internalvars.isDelaySet)){
    	return "default";
    }
  	if ((a.toString() === "default") || (a.toString() === "update")){
		return a;
	}
	if ((typeof tC.privacy.isEnable !== "undefined") && tC.privacy.isEnable()) return "default";
	else return "update";
	return "default";
};
gtag('set', 'developer_id.dOWVhY2', true);
tC.internalvars.consentSettings = {
	'ad_storage': (#DEFAULT_AD_CATEGORY# !== "")?#DEFAULT_AD_CATEGORY#:"denied",
	'analytics_storage': (#DEFAULT_ANALYTICS_CATEGORY# !== "")?#DEFAULT_ANALYTICS_CATEGORY#:"denied",
	'functionality_storage': (#DEFAULT_FUCTIONALITY_CATEGORY# !== "")?#DEFAULT_FUCTIONALITY_CATEGORY#:"denied",
	'personalization_storage': (#DEFAULT_PERSONALIZATION_CATEGORY# !== "")?#DEFAULT_PERSONALIZATION_CATEGORY#:"denied",
	'security_storage': (#DEFAULT_SECURITY_CATEGORY# !== "")?#DEFAULT_SECURITY_CATEGORY#:"denied",
  'ad_personalization':(#DEFAULT_AD_PERSONALIZATION_CATEGORY# !== "")?#DEFAULT_AD_PERSONALIZATION_CATEGORY#:"denied",
  'ad_user_data':(#DEFAULT_AD_USER_DATA_CATEGORY# !== "")?#DEFAULT_AD_USER_DATA_CATEGORY#:"denied" 
}
console.log(tC.internalvars.consentSettings);
console.log("REGION: " + #REGION#);
console.log("WAIT_FOR_UPDATE: " + #WAIT_FOR_UPDATE#);
// Default command on page load
console.log("INFO: default command");
gtag('consent', tC.internalvars.setConsentCommand("default", #REGION#, #WAIT_FOR_UPDATE#), tC.internalvars.consentSettings);
tC.internalvars.ga_url_passthrough = #URL_PASSTHROUGH#;
tC.internalvars.ga_ads_data_redaction = #ADS_DATA_REDACTION#;
if ((typeof tC.internalvars.consentSettings !== "undefined") && (tC.internalvars.consentSettings.ad_storage === "denied")) {
	if ((tC.internalvars.ga_url_passthrough !== "") && ((tC.internalvars.ga_url_passthrough.toLowerCase() === "true") || (tC.internalvars.ga_url_passthrough.toLowerCase() === "false"))) {
		gtag('set', 'url_passthrough', (tC.internalvars.ga_url_passthrough.toLowerCase() === "true"));
	}
	if ((tC.internalvars.ga_ads_data_redaction !== "") && ((tC.internalvars.ga_ads_data_redaction.toLowerCase() === "true") || (tC.internalvars.ga_ads_data_redaction.toLowerCase() === "false"))) {
		gtag('set', 'ads_data_redaction', (tC.internalvars.ga_ads_data_redaction.toLowerCase() === "true"));
	}
}
tC.internalvars.setConsentUpdateCommand = function(result){
	tC.internalvars.consentSettings = {
	    'ad_storage': (result.consent.categories[#TRUST_AD_CATEGORY_ID#].status === "on") ? "granted" : "denied",
	    'analytics_storage': (result.consent.categories[#TRUST_ANALYTICS_CATEGORY_ID#].status === "on") ? "granted" : "denied",
	    'functionality_storage': (result.consent.categories[#TRUST_FUNCTIONALITY_CATEGORY_ID#].status === "on") ? "granted" : "denied",
	    'personalization_storage': (result.consent.categories[#TRUST_PERSONALIZATION_CATEGORY_ID#].status === "on") ? "granted" : "denied",
	    'security_storage': (result.consent.categories[#TRUST_SECURITY_CATEGORY_ID#].status === "on") ? "granted" : "denied",
	  'ad_personalization':(result.consent.categories[#TRUST_AD_PERSONALIZATION_CATEGORY_ID#].status === "on") ? "granted" : "denied",
  'ad_user_data':(result.consent.categories[#TRUST_AD_USER_DATA_CATEGORY_ID#].status === "on") ? "granted" : "denied"
    }
	console.log(tC.internalvars.consentSettings);
	console.log("REGION: " + #REGION#);
	console.log("WAIT_FOR_UPDATE: " + #WAIT_FOR_UPDATE#);
	// Update command on page load
	console.log("INFO: update command");
	gtag('consent', tC.internalvars.setConsentCommand("update", #REGION#, #WAIT_FOR_UPDATE#), tC.internalvars.consentSettings);
};
cact('consent.get', function (result) {
	if (result.consent.status !== "unset") {
      tC.internalvars.setConsentUpdateCommand(result);
	}
});
// Triggered on consent changes
cact('consent.onUpdate', function (result) {
  	tC.internalvars.setConsentUpdateCommand(result);
});
</script>

You can do your mapping on the new fields & Save again your tag

Set the by default status of the *new categories (denied or granted)

Enter the ID of your privacy categories to link them with the Google's *new categories If needed, you can find your privacy ID on the page Data Governance > Consent Management > Categories

Don't forget to save your settings

Generate & Deploy your container

Update your Privacy Banner(s)

Go on page Source > Privacy Banners > edition step

LEGAL REQUIREMENT

Add the following link to the Google Consent Mode Policy in your Privacy Center or in your Vendors menu

https://business.safety.google/privacy/

Don't forget to generate & deploy your privacy banner(s) once you've made this additional setting.

You can now Generate & Deploy your privacy banner(s)

You are up to date, you can test your settings on your website. Don't hesitate to refer at the test step above to get tips & tricks.

Adobe Launch

Steps to implement Consent Module with Adobe Launch.

Commanders Act provides a plug-in to integrate with Adobe Launch. The setup requires technical installation steps.

Setup

Following you will find the required steps to implement a standard Commanders Act Consent setup.

  1. Choose the default account configuration mode for your account (see Settings).

  2. Setup your Commanders Act Consent categories & vendors (see Manage Categories).

  3. Create one or multiple banner templates (see Manage Banner).

  4. Deploy your Consent banner templates to the Commanders Act CDN or on premise target (see Deploy Banner).

  5. Implement Commanders Act Consent JavaScript tag (see below)

  6. Manage Adobe Launch tags with Commanders Act Consent (see below).

Implement Commanders Act Consent JavaScript tag on website and inside Adobe Launch

1 - Website configuration

Delay your Adobe container. Commanders Act creates the consent variables when the privacy javascript file is loaded. You have to delay your Adobe container until Consent is ready otherwise the variables containing the consent status will be undefined.

To delay your container, update your <script> tags loading your Adobe container in order to execute it after Commanders Act Consent JavaScript tag is loaded.

<script type="text/javascript" src="/path/to/adobe_launch_script.js"></script>

is replaced by:

<script type="text/tc_privacy" src="/path/to/adobe_launch_script.js"></script>

The text/javascript script type has to be replaced by text/tc_privacy. In this way, Adobe is loaded only when Commanders Act Consent is ready.

Add the Consent javascript file (if possible, call it before Adobe container and after datalayer):

<script type="text/javascript">
var tCPrivacyTagManager = "adobe";
</script>
<script type="text/javascript" src="my-privacy.js"></script>

2 - Configure consent variables

When Commanders Act Consent is loaded and gets the consent, a variable tcCategoriesConsent is created by Commanders Act Consent in the Adobe datalayer:

window.digitalData.user.tcCategoriesConsent = tcCategoriesConsent;

This variable contains the ID of the categories accepted by the user and separated by a coma.

You have to declare this variable in Adobe Launch interface, in the Data Elements configuration. From a Property page, open the Data Elements tab, then click Add Data Element, and add "tcCategoriesConsent" variable.

​​If your datalayer is not set in the digitalData object, set the path to tcCategoriesConsent (in this case the variable is created in the window scope: window.tcCategoriesConsent)

Then, you have to create the rules that will fire your tags based on the categories ID accepted by the users. You have to create a separate rule for each category you want to use as a firing condition (ex: "Retargeting category accepted", "Analytics category accepted"...).

In the Adobe Launch interface, open the "Rules" tab and click Create New Rule.

Set a rule based on the previously created tcCategoriesConsent. Ex: if you want to trigger a tag based on the Retargeting category (ID 6), you will have to create a rule "if tcCategoriesConsent contains 6", then the Criteo tag has to be triggered.

Websites (Hardcoded)

Steps to hard code Commanders Act Consent on websites.

Commanders Act Consent can be directly integrated with websites. The setup requires technical installation steps.

Setup

Following you will find the required steps to implement a standard Commanders Act Consent setup.

  1. Choose the default account configuration mode for your account (see Settings).

  2. Setup your Commanders Act Consent categories & vendors (see Manage Categories).

  3. Create one or multiple banner templates (see Manage Banner)

  4. Deploy your Commanders Act Consent banner templates to the Commanders Act CDN or on premise target (see Deploy Banner).

  5. Install Commanders Act Consent JavaScript tag (see below)

  6. Manage onsite tags with Commanders Act Consent (see below).

Install Commanders Act Consent script

To hard code Commanders act Consent on websites you need to add following JavaScript code to your website. This snippet should be added to the <head> of your website.

<script type="text/javascript" src="{{ privacy_tag_url }}"></script>

{{ privacy_tag_url }} has to be replaced with your privacy JavaScript tag URL. This URL can be found in the GENERATE & DEPLOY tab of each privacy banner.

Manage onsite tags with Commanders Act Consent

Add tag triggers with OnSite API

We recommend to use our OnSite API, to trigger your tags only if user has accepted the related category. If you are looking for your categories ID's, please refer to the section 'Manage Categories'

Add tag triggers without OnSite API

If, for some specific reasons, you cannot use our OnSite API, there's an alternative approach.

Commanders Act can manage onsite JavaScript tags by wrapping them in a script tag with a custom MIME type.

This approach only works when you install Commanders Act Consent tag in the <head> of the document (e.g. not when injecting the Commanders Act Consent tag via Google Tag Manager)!

This Commander Act wrapper does only fire that wrapped JavaScript code in case a visitor provided consent for the specified privacy category ID.

<script type="text/tc_privacy" data-category="{{ category_or_sub-category_id }}" data-vendor="{{ vendor_id }}">
    {{ tag_javascript_code }}
</script>

The <script> has to have type="text/tc_privacy" .

{{ tag_javascript_code }} has to be replaced with the JavaScript code of the tag you want to manage with Commanders Act Consent.

{{ category_or_subcategory_id }} has to be replaced with the category or sub-category of the Commanders Act Consent category that should manage this tag (see Manage Categories). Be careful when you create sub-categories associated to a category: you have to enter the sub-category ID in the attribute, not the category ID, as the user will be able to activate or deactivate only sub-categories and not the main category in the banner:

{{ vendor_id }} has to be replaced with the vendor ID of the vendor related to the tag (Only available when native vendors are activated for the account).

Example

Following examples shows how you would manage a Criteo Tag based on a Consent category named "retargetting".

"Retargetting" was assigned to sub-category ID 6. In case a sub-category is used you should never use the main category (2 in this case) to manage tags.

The Tag wrapper for the Criteo JavaScript tag might look like this (example shortened):

<script type="text/tc_privacy" data-category="6" src="//static.criteo.net/js/ld/ld.js" async="true">
</script>

<script type="text/tc_privacy" data-category="6">
    window.criteo_q = window.criteo_q || [];
    window.criteo_q.push(...);
</script>

FR : Suppression des cookies lors du retrait du consentement

Lorsque l’utilisateur retire son consentement, il est parfois nécessaire de supprimer les cookies déposés précédemment (cas de la France notamment). Nous mettons à disposition un script simple et personnalisable qui permet de supprimer automatiquement les cookies first-party (déposés par votre propre site) et cookies tiers (via appel API)

Certains cookies spécifiques nécessitent une approche ciblée. Voici comment procéder étape par étape :


1. Identifier les cookies à conserver

Avant toute chose, il vous faut lister les cookies indispensables au bon fonctionnement de votre site. Exemples de cookies techniques ou liés à la gestion du consentement à conserver :

  • TCPID

  • TC_PRIVACY

  • TC_PRIVACY_CENTER

👉 Comment identifier ces cookies essentiels ? Nous mettons à votre disposition la fonctionnalité Cookie Scanner, qui vous permet de lister les cookies présents sur votre site, pour vous aider à identifier ceux qui doivent être conservés. Cela évite d’en oublier et assure un bon fonctionnement après la suppression des cookies non essentiels. Il est conseillé de vérifier avec vos équipes techniques ou votre prestataire les cookies techniques qui ne doivent pas être supprimés.

💡 Action : Utilisez Cookie Scanner pour obtenir une liste complète des cookies présents sur votre site


2. Utiliser un script pour supprimer automatiquement les cookies non essentiels

Nous proposons un script JavaScript simple et personnalisable qui se déclenche automatiquement lorsque l’utilisateur retire son consentement via la CMP Commanders Act. Le script réalise les actions suivantes :

  • Détection du retrait de consentement : Le script s’abonne à un événement de mise à jour du consentement. Dès que l’utilisateur opte pour le refus, le script se lance.

  • Suppression des cookies first-party : Il parcourt l’ensemble des cookies déposés par votre domaine et supprime ceux qui ne figurent pas dans votre liste blanche. Pour être efficace, il teste plusieurs variantes de domaine (votre domaine et ses sous-domaines).

  • Optionnel – Appel de services côté serveur et partenaires : Le script peut également appeler des URL que vous aurez renseignées pour demander la suppression de cookies déposés côté serveur (cookies HTTP-only) ou par des partenaires externes (cookies tiers). 👉 Voir le chapitre 3 pour en savoir plus sur la gestion des cookies HTTP-only et tiers.

    ⚠️ Note : L’ajout de ces URL est facultatif. Si vous ne souhaitez pas utiliser cette fonctionnalité, il vous suffit de laisser le tableau des URL vide ou de supprimer cette partie du code. Vous pouvez aussi gérer ces suppressions par vous-même ou avec vos partenaires.

📌 Où intégrer ce script ?

Vous pouvez insérer ce code JavaScript : ✅ Dans la section "Custom JS" de la bannière Commanders Act (recommandé dans la plus part des cas). ✅ Dans votre Tag Management System (TMS) (si vous souhaitez une gestion plus centralisée).

Télécharger le script JavaScript :

Code JavaScript - suppression de cookies
/**
 * This script listens for consent updates via the Commanders Act OnSite API.
 * When a user revokes consent (opt-out), it removes all 1st party cookies
 * except for those explicitly allowed. It also calls configured URLs to delete cookies
 * on the server side (e.g., httpOnly or third-party cookies).
 */
(function () {
  // List of cookies to retain (system cookies, technical storage items)
  var allowedCookies = ["TCPID", "TC_PRIVACY", "TC_PRIVACY_CENTER"];
  // Optional: Regex to match additional cookies or storage keys to retain
  var allowedCookiesPattern = /your_regex_[a-z0-9]*/; // Adjust this pattern if necessary

  // Array of server URLs to call for server-side deletion of cookies (httpOnly/partner cookies). Leave empty if you don't have such urls/api
  var serverDeletionUrls = [
    "https://server1.example.com/delete-cookies",
    "https://server2.example2.com/delete-cookies"
  ];

  // Subscribe to consent updates using the Commanders Act OnSite API
  cact("consent.onUpdate", function (consentData) {
    if (consentData.updateEvent === "revoked" || consentData.consent.status === 'all-off') {
      // Retrieve all cookies
      var allCookies = document.cookie.split(";").map(function (item) {
        return item.split("=")[0].trim();
      });
      // Determine which cookies need to be removed (i.e. not allowed)
      var cookiesForRemoval = allCookies.filter(function (cookieName) {
        return allowedCookies.indexOf(cookieName) === -1 && !allowedCookiesPattern.test(cookieName);
      });

      // Remove each cookie from all possible domain variants
      cookiesForRemoval.forEach(function (cookieName) {
        var hostParts = window.location.hostname.split(".");
        while (hostParts.length > 0) {
          var domainCandidate = "." + hostParts.join(".");
          tC.removeCookie(cookieName, domainCandidate);
          hostParts.shift();
        }
        // Also try removing the cookie without a domain specification
         document.cookie = `${cookieName}=;expires=Thu, 01 Jan 1970 00:00:01 GMT;path=/`;
      });

      // Call server-side endpoints to delete httpOnly and partner cookies
      serverDeletionUrls.forEach(function (url) {
        // Use fetch with no-cors mode to trigger the deletion endpoints
        fetch(url, { mode: "no-cors" }).catch(function (error) {
          console.error("Error calling server deletion URL:", url, error);
        });
      });
    }
  });
})();

3. Supprimer les cookies créés côté serveur et les cookies tiers

Cookies HTTP-only sur votre domaine

Certains cookies sont créés côté serveur et marqués comme HTTP-only. Ils ne sont pas accessibles par JavaScript et ne peuvent être supprimés que par le serveur.

  • Origine : Ils peuvent être déposés par vos propres serveurs ou par un partenaire à qui vous avez délégué la gestion de votre domaine (via un CNAME, un WAF, un proxy, etc.).

👉 Que pouvez-vous faire ?

  • Créer une API sur votre serveur pour supprimer ces cookies.

  • Ajouter l’URL de votre API dans le script, afin qu’elle soit automatiquement appelée lors du retrait du consentement.


Cookies tiers

Ces cookies sont déposés par des services externes (publicité, analyses, widgets, etc.) et ne sont pas générés directement sur votre domaine.

  • Limitation : Le script JavaScript ne peut pas supprimer directement ces cookies, sauf si ces fournisseurs offrent une API ou une URL dédiée permettant leur suppression.

  • Que faire ? 👉 Demandez à vos partenaires s’ils proposent un mécanisme de suppression (API ou URL dédiée). Si c’est le cas, ajoutez ces URL dans le script pour automatiser leur appel lors du retrait du consentement. Sinon, utilisez le mécanisme proposé par le partenaire.


4. Ce que fait (et ne fait pas) notre script

✅ Il supprime automatiquement les cookies déposés sur votre domaine (first-party), en conservant ceux que vous avez explicitement listés. ✅ Il permet d’appeler des URL de suppression pour les cookies HTTP-only et tiers (optionnel). ❌ Il ne peut pas supprimer directement les cookies tiers, sauf si ces derniers proposent une url ou API dédiée. ❌ Il ne peut pas supprimer les cookies HTTP-only, sauf si ces derniers proposent une url ou API dédiée.

Mobile apps

Please refer to the subpages for implementation on mobile apps

iOS

Having the user consent is essential to send sensible information like the IDFA/AAID. To prevent having to manually save the consent asked to the user and manually using it with our SDKs, we created a module helping you do it automatically.

This module will gather the consent and will:

  • Display a consent page (if needed)

  • Save consent and reload it every time the application is launched.

  • Save and check the validity of the consent. The validity duration is set to 13 months.

  • Send a hit to our servers to record the consent.

  • Enable or disable the SDK. (if used alongside the SDK ServerSide)

  • Add the categories automatically to the hits the SDK sends. (if used alongside the SDK ServerSide)

Privacy's Implementation Guide:

https://github.com/CommandersAct/iOSV5/tree/master/TCConsent

ATT - App Tracking Transparency (iOS 14.5+)

Since April 2021, Apple requires that your app provide a transparency popup to ask user permission for tracking, beginning with iOS 14.5 () and the ATT framework.

When and how should you request permission from the ATT?

Before attempting to use the IDFA from an iOS device, you must first display the ATT tracking permission alert, according to Apple's guidelines. If permission is not requested or if the user declines, the IDFA will be unavailable to your app and any embedded third-party SDKs. Third-party SDKs may not function properly in this case.To really complies with both Apple and GDPR requirements, you must open the ATT popup to get user permission as well as open CMP popup to get user consent for GDPR purpose. ATT isn't currently compliant with the IAB TCF or with GDPR prerequisites, so it can't be utilized as the lone consent collection system and should be utilized with the Commanders Act CMP.

Our recommended solutions

1. Most accepted solution : ATT first

From customer's experiences, the most accepted solution by Apple is to :

  1. Open the ATT popin

  2. Depending of user's choice on ATT :

    1. if the user choose to allow the tracking, then open the TrustCommander popin to collect the consent

    2. If the user refuse the tracking in the ATT popin, the user has to be considered as optout without opening the TrustCommander popin

2. ATT after Commanders Act Consent banner

For some customer's this solution worked also :

  1. Open the Commanders Act Consent popin

  2. Whatever the consent, open the ATT popin just after

This setup offers the advantage of allowing the user to consent certain purposes whatever his choice regarding the popin ATT tracking. Neverthe less this implementation is some time refused by some Apple reviewers

To go further, here a for France customers the position of the competition authority on this subject: https://www.autoritedelaconcurrence.fr/fr/communiques-de-presse/ciblage-publicitairemise-en-place-par-apple-de-la-sollicitation-att-lautorite

Android

Having the user consent is essential to send sensible information like the IDFA/AAID. To prevent having to manually save the consent asked to the user and manually using it with our SDKs, we created a module helping you do it automatically.This module will gather the consent and will:

  • Display a consent page (if needed)

  • Save consent and reload it every time the application is launched.

  • Save and check the validity of the consent. The validity duration is set to 13 months.

  • Send a hit to our servers to record the consent.

  • Enable or disable the SDK. (if used alongside the SDK)

  • Add the categories automatically to the hits the SDK sends. (if used alongside the SDK)

Privacy's Implementation Guide: https://github.com/CommandersAct/AndroidV5/tree/master/TCConsent

User Guides

In this section, you will find information about Consent configuration on Platform Commanders Act

Categories & Tags

Manage Categories

Data Governance > Consent Management > Categories

In this section you can manage your Commanders Act Consent categories and sub-categories. These categories will be used by your privacy center to provide users with detailed privacy management options.

Category options

Each Commanders Act Consent category has following options:

Option

Description

Name

Name of the category (e.g. "Analytics", "Advertising", etc.). Privacy centers use this name as the default label for this category in case no localisation was provided in the banner editor.

ID

ID of the category. This ID is used in raw data exports and for technical setup of certain functionalities. It is possible to manually provide an ID. In case the field is left empty a category ID will be assigned automatically.

Description

Description of the category. Privacy centers use this description as the default description for this category in case no localisation was provided in the banner editor.

Sub-categories

It is possible to provide sub-categories for each category (e.g. "Universal Analytics", "Matomo", etc. for an "Analytics" category). Each sub-category has a name and an ID. Privacy center use this name as the default label for this sub-category in case no localisation was provided in the banner editor. The ID is used in raw data exports and for technical setup of certain functionalities. It is possible to manually provide an ID. In case the field is left empty a sub-category ID will be assigned automatically.

Managing categories

Default category

In case you use Consent module with TMS Web Container you can select a default category with a drop down on the top left of the interface. New tags in TMS client-side will automatically receive the default category as their privacy category. The default category has a * in the category list.

Creating categories

To add a new category press ADD CATEGORY on the the top right of the interface.

Editing categories

You can edit a Consent category by pressing the pencil icon to the right of the category.

Deleting categories

You can delete Consent categories by pressing the x icon to the right of the category.

You need to regenerate your consent banners after adjusting pconsent categories. In case you install Consent module with TMS Web Container you will also need to regenerate your Web Container so that your tags have access to the updated categories.

iAB categories

Commanders Act Consent module is compliant with IAB TCF 2.2 (Link to official listing). To enable IAB categories go to Data Governance > Consent Management > Settings and activate the IAB option. You can also have a look on our dedicated page

Commanders Act Consent module is compliant with IAB TCF 2.2 (Link to official listing) and can use predefined IAB TCF purposes instead of manually configuring categories. Go to Data Governance > Consent Management > Settings tab to activate IAB TCF 2.2 option for your account.

IAB TCF 2.2 purposes, special purposes, features and special features are automatically added to the CATEGORIES tab depending the vendors you add in the MANAGE VENDORS tab. You can still add custom categories that you can use side by side with the predefined IAB categories.

The description of IAB TCF 2.2 categories is automatically loaded from the IAB TCF 2.2 framework.

Manage Vendors

Management of Commanders Act Consent vendors.

Data Governance > Consent Management > Vendors

In this section you can manage your Commanders Act Consent vendors. These vendors will be used by your privacy center to provide users with detailed privacy management options.

Vendors

To enable native vendors go to Data Governance > Consent Management > Settings and activate the custom vendors option.

For customers still using the v1.0 privacy center template (deprecated as of 2019) Vendor activation will automatically upgrade your privacy center to version 2.0.

Click ADD VENDOR to add vendors to your Commanders Act Consent installation. You can select vendors available on Commanders Act TMS (Predefined Vendors) or add custom vendors (Custom Vendor) by selecting the respective tab. A Commanders Act vendor is available by default.

Each vendor can be mapped to Consent categories with the respective dropdown. This allows users to provide consent to all vendors of a category at once in the privacy center. A PEN icon allows to edit information of the vendor that is displayed in the privacy center. Following fields are available per vendor. A TRASH icon allows to remove the vendor.

Option

Description

Name

Name of the vendor. Privacy centers will display this name.

ID

ID of the vendor. This ID is used in raw data exports and for technical setup of certain functionalities. It is possible to manually provide an ID. In case the field is left empty a category ID will be assigned automatically.

Description

Description of the vendor. Privacy centers use this description as the default description for this vendor in case no localisation was provided in the banner editor.

Policy URL

Privacy Policy Link of the vendor. Privacy centers display this URL for each vendor.

It is possible to map vendors to multiple categories for stand-alone installation of Commanders Act Consent. Tags in your Web Container can only be mapped to one category and vendor.

It is necessary to generate and deploy new version of Consent banners to deploy updates in the vendor section.

IAB vendors

Commanders Act is compliant with IAB TCF 2.2 (Link to official listing). To enable IAB vendors go to Data Governance > Consent Management > Settings and activate the IAB option.

Click ADD IAB TCF 2.2 VENDORS to manage the IAB vendors with your Commanders Act Consent installation. You can either select all vendors or select specific vendors that are relevant for your setup.

The description of IAB TCF 2.2 vendors is automatically loaded from the IAB TCF 2.2 framework.

Commanders Act Consent will automatically configures purposes, special purposes, features and special features in the CATEGORIES tab depending on the selected vendors.

Google ACM vendors

To enable Google ACM vendors go to Data Governance > Consent Management > Settings and activate the IAB option and the Google ACM vendors.

Google Additional Consent Mode (ACM) allows to manage consent for Google Ad Technology Providers (ATP) (that are not part of the IAB TCF Global Vendors List) alongside IAB TCF vendors.

Add Google ACM vendor allows to add Google ACM vendors to add a Google ATP to your Commanders Act Consent installation. Each vendor has to be mapped to a TrustCommander category.

Descriptions for the ATP that are shown in the Consent banner (into the privacy center) are automatically loaded from the Google ACM list.

Google ACM vendor management only works with IAB TCF 2.0 & 2.2 banner templates.

Assign Categories

Assign Web Container tags to Consent categories.

Data Governance > Consent Management > Categories (tab ASSIGN TAGS)

Commanders Act TMS tags can be assigned to Consent categories & vendors in following locations.

  • In ASSIGN TAGS tab of Data Governance > Consent Management > Categories.

  • In the EDIT tab of TMS Commanders Act.

This section is only available in case you use Commanders Act Consent with TMS Commanders Act (Web Container).

Assign categories & vendors in Commanders Act Consent interface

Categories & Vendors are managed separately for each web container. You can select a Web Commander container in the left column. Then you can manage following Consent setting per tag on the right side of the interface.

This option enables Commanders Act Consent to block a tag depending on a visitors privacy setting. It is possible to activate or deactivate this setting for all tags via the all and none buttons on top of the column.

You can assign one Consent category to each tag. This allows visitors to block tags by deactivating the related categories in the privacy center.

You can assign one Consent vendor to each tag. This allows visitors to block tags by deactivating the related vendor in the privacy center.

This option allows you to bypass the default behaviour of tags that are managed with Commanders Act Consent. e.g. Consent will blocks tags that are included in the privacy scope until a visitor provides his consent in case the default account configuration is set to Optout. Bypassing this option would allow you to therefore load tags before the visitor provided his privacy settings (e.g. on the first page). In case such tags are included in the privacy scope they can still be deactivated by the user depending on his privacy settings.

It is possible to activate or deactivate this setting for all tags via the all and none buttons on top of the column.

Additionally you can also manage these Consent settings for following elements:

Element

Description

COMMANDERS ACT HITS

Commanders Act related hits that are initiated from the container (this includes hits for functionalities like tag deduplication, tag hierarchy, and other). A separate category is available for the cookie sync option. This setting is synced between all client-side TagCommander container.

STATIC AND DYNAMIC JAVASCRIPT CODE

Custom JavaScript that can be implemented in TagCommander container (found in ADVANCED section of the Edit tab).

Containers have to be re-generated and deployed to apply these changes.

Assign categories in Commanders Act TMS interface

For convenience it is also possible to directly assign Commanders Act Consent categories & vendors inside the Edit tab of TMS Commanders Act (Web Containers). Assigning a category & vendor also includes the tag in the privacy scope.

In case a new vendor is added to the account the tag will not be fired when a user provided an optin for the corresponding category. Therefore it is necessary to activate the "Re-activate privacy" option during the generation of a new banner version to re-ask consent. The option "Don't re-ask the consent to trigger this tag" will change this default behaviour so that the vendor will receive an automatic optin based on the corresponding category.

IAB TCF V2.2 option

In case you choose to manage tags with IAB 2.2 you do not need to assign IAB compliant tags in the category assignation tab. IAB compliant tags are automatically controlled by the IAB framework.

It is still possible to assign tags to categories to allow Commanders Act Consent to manage them directly with TMS Commanders Act.

Privacy Banners

Here are the articles in this section:

Banner templates

Manage Banner

Deploy Banner

Copy Banner

Banner Templates

A list of available banner templates in Commanders Act Consent

Commanders Act offers multiple banner templates for different kind of privacy workflows.

Template

Description

Header (with Privacy Center)

Floating overlay banner (is layered on top of the website), positioned at the top of the page. This banner includes a text message and customizables buttons. You can add a link to another page (e.g. privacy policy).

This template exists with and without an optional privacy center.

Popin (with Privacy Center)

A floating modal dialogue (pop-up), positioned in the center of the page. This banner includes a text message and customizable buttons. It supports links to another page (e.g. privacy policy).

This template exists with and without an optional privacy center.

Footer (with Privacy Center)

Floating overlay banner, positioned at the bottom of the page. This banner includes a text message and customizable buttons. It supports links to another page (e.g. privacy policy).

A variation of this template exists with extended accessibility support.

Popin with categories

This template directly opens the privacy center that allows visitors to select Commanders Act Consent categories and sub-categories they want to activate/deactivate.

Footer / Popin / Header

Floating information banner, no buttons to refuse or accept. Not compliant for GDPR & CCPA

Footer without button

Floating overlay banner, positioned at the bottom of the page. This banner includes a text message and cross icon to close the banner. It supports links to another page (e.g. privacy policy). Not compliant for GDPR & CCPA

IAB TCF 2.2 Popin

Template available if IAB TCF compliancy option is activated in the Data Governance > Consent Management > Settings section.

A floating modal dialogue (pop-up), positioned in the centre of the page. This template offers consent controls following the IAB TCF 2.2 standard.

IAB TCF 2.2 Footer

Template available if IAB TCF compliancy option is activated in the Data Governance > Consent Management > Settings section.

Floating overlay banner, positioned at the bottom of the page. This template offers consent controls following the IABTCF 2.2 standard.

IAB TCF 2.0 Popin (deprecated)

Template available if IAB TCF 2.0 option is activated in the Data Governance > Consent Management > Settings section.

A floating modal dialogue (pop-up), positioned in the centre of the page. This template offers consent controls following the IAB TCF 2.0 standard.

IAB TCF 2.0 Footer (deprecated)

Template available if IAB TCF compliancy option is activated in the Data Governance > Consent Management > Settings section.

Floating overlay banner, positioned at the bottom of the page. This template offers consent controls following the IABTCF 2.0 standard.

Footer with privacy center (accessibility)

Floating overlay banner, positioned at the bottom of the page. This banner includes a text message and customizable buttons. It supports links to another page (e.g. privacy policy). Includes standards for WCAG 2.0 for more details, look at this page of our documentation

Popin with privacy center (accessibility)

A floating modal dialogue (pop-up), positioned in the center of the page.This banner includes a text message and customizable buttons. It supports links to another page (e.g. privacy policy). Includes standards for WCAG 2.0 for more details, look at this page of our documentation

Accessibility Template

WCAG standards : offer a privacy fully functional for people with disabilities

Among the available templates, one is dedicated to accessibility. It ensures compatibility with RGAA and WCAG 2.0 level AA standards.

Web Content Accessibility Guidelines (WCAG) is developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.

More information here : https://www.w3.org/WAI/standards-guidelines/wcag/

What is Web Accessibility ?

When websites and web tools are properly designed and coded, people with disabilities can use them. However, currently many sites and tools are developed with accessibility barriers that make them difficult or impossible for some people to use.

Making the web accessible benefits individuals, businesses, and society. International web standards define what is needed for accessibility.

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can:

  • perceive, understand, navigate, and interact with the Web

  • contribute to the Web

With this template the main key point is to offer a privacy fully functional for people with disabilities.

Translation

The Accessibility template provides an automatic translation of different labels. This translation is based on navigator language. Currently, it supports : Italian, English, German, French and Russian.

Options :

1. Personalize translation

Banners

You can either add new translation or override aria labels by using the function tC.privacy.addTranslation() in the custom JS.

Labels available :

iframeTitle : Title attribute of the iframe

privacyLabel : Aria Label of the footer

acceptAria : Aria Label of the accept button

refuseAria : Aria Label of the refuse button

showPcAria : Aria Label of the “Show Privacy Center“ Button

Exemple :

tC.privacy.addTranslation({
  en : {
    // overriding
    iframeTitle : 'the iframe title you want',
    privacyLabel : 'the aria label you want',
    acceptAria: 'the aria label you want for accept button',
    refuseAria: 'the aria label you want for refuse button',
    showPcAria: 'the aria label you want for display the pc button'
  },
  ru: {
    // add new translation
    iframeTitle : 'the iframe title you want',
    privacyLabel : 'the aria label you want',
    acceptAria: 'the aria label you want for accept button',
    refuseAria: 'the aria label you want for refuse button',
    showPcAria: 'the aria label you want for display the pc button'
  }
})

Privacy Center

⚠️ To translate the privacy you must use another function: pc.addTranslation()

Available keys and their values :

var en = {
    "pcAria":"Cookie settings",
    "closePrivacyCenter":"Close the cookie setting dialog",
    "acceptAll":"Accept all",
    "refuseAll":"Refuse all",
    "saveLabel":"Save",
    "saveAria":"Save the current cookie settings",
    "acceptAllAria":"Accept all cookies",
    "refuseAllAria":"Refuse all cookies",
    "showVendors":"Show vendors",
    "showPurposes":"Show purposes",
    "vendors":"Vendors",
    "enableCookieLabel":"Enabled:",
    "enableCookieAria":"{label} cookies enabled",
    "disableCookieAria":"{label} disabled cookies",
    "turnOnSubCategoriesAria":"Enable {label} cookies",
    "turnOffSubCategoriesAria":"Disable {label} cookies",
    "cookieAlwaysOnSrPrefix":"",
    "cookieAlwaysOnSrSuffix":"",
    "cookieSrPrefix":"",
    "cookieSrSuffix":"",
    "showRelatedVendors":"Show related vendors",
    "privacyPolicy":"Privacy policy",
    "categories":"Categories"
}

Some of the translation accept a label as {label}. The label here is always the label of the category.

The last keys with SrPrefix/SrSuffix have empty translation by default. These keys are used for “sr-only” text which are prefixing and suffixing the category name. These text are only readable by a screen reader.

cookieSr are used when the category isn’t locked

cookieAlwaysOnSr replaces cookieSr if the category is blocked to on

Example:

pc.addTranslation({
  en : {
    // Override english Aria Label
    closePrivacyCenter: 'Close the privacy center', 

  },
  ru : {
    // you can also add a new language
    closePrivacyCenter: 'Close the privacy center',
      },
})

2. Force Translation

By default, texts provided to screen readers is translated depending on the navigator language. In some case you may want to display a privacy in english for example even if the navigator language is another one. ie : with an ISO language code in the url

You can force the privacy to take a language by using the function setLocale in the Privacy Center > Custom JS field > JS Block Before :

pc.setLocale("fr");

Value can be : fr, it, de, ru or en

Note : this function must be placed after the translation declaration.

3. Focus Trap

The focus trap is an accessibility option designed so that keyboard user have their navigation locked to the banner. Pressing the TAB key would cycle between the different navigation elements of the banner without going on your website. This is an accessibility recommendation when using modal on a webpage.

You can deactivate the focus trap by adding the following JavaScript snippet to the custom JS of the accessibility template banner:

tC.privacy.enableFocusTrap(false);

Manage Banner

Manage Banner

Options to create and edit banner templates.Sources > Privacy banners

Creating Privacy Banner

Click ADD PRIVACY BANNER in the top right of the interface to add a new banner to your account. Each template has following options:

Field

Description

Name

Label of the banner used in the interface.

Template

Dropdown to select a template for this banner.

Hosting

Hosting method used for this banner (see Deploy Banner).

Consent duration

Duration how long the consent cookie is valid. After this duration the consent cookie is not valid anymore and a new banner will be presented to the user. It is possible to configure a duration in full months between 1 and 13 month. This has no impact on the storage duration of the consent in the Commanders Act Consent database.

Use the new privacy center

This option allows to use the old privacy center template of Commanders Act Consent Banners. This option allows to use custom CSS and custom JS that was created for old banner templates. In case you are not sure if a banner was customized please check with your Commanders Act consultant or support contact before creating a new template. This option is not available on all templates.

Example: Configuring options of a privacy banner.

Update Privacy Banner

You can open and edit the privacy banner settings via the gear icon on the top left of the interface.

Changing banner templates might not work for customized privacy banner templates. Please contact your Commanders Act consultant or support in case you are unsure if your banner was customized before using this option.

Customize banner content

Sources > Privacy banners (tab EDIT BANNER)

Options for banner customization

All banner templates can be customized with a WYSIWYG editor. Following options are available for all banners (except IAB TCF and Popin with Categories templates).

Options to manage the main text content of your banner.

  • Content: Text content (supports HTML formatting and links).

  • Font color: Text color.

  • Background color: Background color of the content area.

Options to manage up to three buttons.

  • Label: Button text.

  • Font color: Color of the button text.

  • Background color: Background color of the button.

  • Button action: Action the button performs (e.g. optin to all categories or open privacy center).

  • Button Position: Change Button Position to Top/Bottom of the banner. Only one button can be positioned to top.

Custom CSS that can be used by advanced users to customise the banner style. This CSS is applied globally to your website, avoid to use global selectors and use the HTML ID attribute of the banner elements instead.

Advanced customization options. Please contact your Commanders Act consultant or support before using these.

Changes have to be saved with the SAVE button.

Options for privacy center customization

Following options are available for the privacy center and "Popin with categories" templates.

Options to manage the header text of your privacy center.

  • Title: Text content.

  • Font color: Text color.

  • Background color: Background color of the header area.

Options to manage the main text content of your banner.

  • Categories introduction: Introductory text of the category tab (supports HTML formatting and links)

  • Vendors introduction: Introductory text of the vendor tab (supports HTML formatting and links, only visible in case IAB TCF 2.0 or custom vendors were activated)

  • Font color: Text color.

  • Background color: Background color of the content area.

Options to manage the privacy categories of the privacy center. These categories are based on the categories managed in the Categories & Tags part of the interface.

  • Order: Drag and Drop sorting of Categories.

  • edit icon that allows to overwrite the default name and description of categories and sub-categories that have been provided in the

    Categories & Tags section of the interface for this banner (used for localisation).

  • Checkbox that allows to hide a category (below edit icon).

  • Categories Blocked On: Checkbox that permanently enables a category that can not be deactivated by visitors (e.g. for an "essential cookies" category)

  • IAB TCF 2.0 option: IAB purposes, special purposes, features and special features are automatically displayed on the basis of selected vendors in Categories & Tags / Manage vendorssection. The categories translation is done automatically depending on the user’s browser language settings. Non-IAB categories will be displayed after the official IAB categories in the banner.

Options to manage and translate descriptions of custom vendors. IAB TCF 2.0 vendor descriptions and translations are managed automatically by the IAB TCF 2.0 framework.

  • Vendor Description: Description displayed in the vendor tab.

  • Hide Vendor: Options to hide the vendor from the banner.

  • Order of vendors can be changed via drag & drop. (IAB TCF 2.0 vendors are always displayed before custom vendors).

Custom CSS that can be used by advanced users to customise the banner style.Options to manage the save button, and the category controls of the privacy center.

  • Label: Button text.

  • Font color: Color of the button text.

  • Background color: Background color of the button.

  • Default status of buttons (IAB and non-IAB) to accept or refuse categories and sub-categories:

    • "On": "On" is chosen by default for categories/sub-categories (IAB and non-IAB) in the Privacy Center. When the visitor leaves it as such, their status for browsing is “optin”.

    • "Off": "Off" is chosen by default for categories/sub-categories in the Privacy Center. When the visitor leaves it as such, their status for browsing is “optout”.

    • "Neutral position": In this position, neither "On" nor "Off" is chosen by default for categories/sub-categories in the Privacy Center. The user must choose “On” or “Off” for each of the categories and sub-categories to be able to save their preferences and continue browsing. The “Warning message” field allows you to personalise the message that will appear to the left of the save button in the Privacy Center: this will inform the user that they must give or refuse their consent for all the categories before saving.

  • Default status of buttons to accept or refuse vendors (IAB and non-IAB):

    • "Off": The default status of vendors is "Off". When a new visitor accepts consent categories in the privacy center for the first time the vendors are not not activated based on their linked categories.

    • "Neutral position": The default status of vendors is "Undecided". When a new visitor accepts consent categories in the privacy center for the first time the vendors activate based on their linked categories (see Manage Vendors).

  • Label for "Off for all": "Off for all" button text if the user wants to give their choice for all of a category’s sub-categories in one click.

  • Label for "Off" button: "Off" button text which appears in the Privacy Center (e.g. you can replace it by “No”).

  • Label for "On for all": "On for all" button text if the user wants to give their choice for all of a category’s sub-categories in one click.

  • Label for "On" button: "On" button text which appears in the Privacy Center (e.g. you can replace it by “Yes”).

  • "ON blocked" look & feel: Styling of on blocked Categories (Checkbox or Text)

Custom CSS that can be used by advanced users to customise the banner style.

Advanced customisation options. Please contact your Commanders Act consultant or support before using these.

Changes have to be saved with the SAVE button.

IAB TCF banners advanced options

Customise Publisher Country Code Field

Option to manage the publisherCC field of the IAB TCF API.

​Country code of the country that determines the legislation of reference. Normally corresponds to the country code of the country in which the publisher's business entity is established.

Consent banners sets this value to "FR" by default in the IAB response. The publisher country code field can be customised with following JavaScript snippet (should be implemented in the first container on the website.).

tC.privacy.iabPublisherCC = "<country_code>";

Example to set the publisher country code field to a German country code:

tC.privacy.iabPublisherCC = "DE";

Customise Purpose One Treatment Field

Option to manage the purposeOneTreatment field of the IAB TCF API.

IAB TCF offers this field to specify how purpose one should be treated in specific scenarios.

true: Purpose 1 not disclosed at all. CMPs use publisherCC to indicate the publisher's country of establishment to help Vendors determine whether the vendor requires Purpose 1 consent.

false: There is no special Purpose 1 treatment status. Purpose 1 was disclosed normally (consent) as expected by TCF Policy

Consent banner sets this value to false by default in the IAB response. The purpose one treatment field can be customised with following JavaScript snippet (should be implemented in the first container on the website.).

tC.privacy.iabPublisherCC = (true|false);

Neutral vendor buttons

You can change the vendor button type to neutral if you choose the neutral position as the default status.f

You can't choose a neutral position for IAB categories (purposes) as it's not allowed by the framework policy

Synchronization mode between vendors and categories

You can choose to synchronize vendors status with categories, choosing to do it only for neutral buttons or always. If you use an IAB TCF template, this option will not have any effects on TCF vendors, as the TCF framework doesn't allow this.

IAB TCF Stacks Beta

Commanders Act Consent offers IAB TCF Stacks to reduce the size of the purpose list in the privacy center. IAB TCF Stacks group purposes and special features in a foldable panel and allows visitors to configure consent for all purposes and special feature in a Stack at once. More information on IAB TCF Stacks can be found in the IAB TCF Policy.

Right now IAB TCF Stacks are in beta in Commanders Act Consent. They are activated with a JavaScript command that needs to be added to the privacy center CUSTOM JS field JS BLOCK BEFORE.Example: Activating Auto Stacks

Commanders Act Consent offers two options to activate Stacks:

pc.iab.useAutoStack();

This option uses an algorithm to automatically find the tightest Stack combination for the configured vendors. This option is the recommended approach.

pc.iab.useStackIds(1,2); // activates Stacks with ID 1 and 2

This option allows to manually activate IAB TCF Stacks by providing a list of Stack IDs. The Stack IDs can be found in the IAB TCF Policy.

Purposes may only be included in one Stack. In case of a bad configuration Commanders Act Consent ignores IAB Stack configuration and provides an error in the browser console.

Move native Categories above IAB Purposes

Per default IAB Purpose controls are placed above native category controls. It is possible to display native categories above IAB TCF Purpose controls by adding following JavaScript snippet to the CUSTOM JS field JS BLOCK BEFORE of the privacy center.

pc.tc.categoriesSectionTop(true);

The "Other" headline of the native category controls can be translated by adding following configuration snippet to the CUSTOM JS field JS BLOCK BEFORE of the privacy center.

pc.addTranslation({en: { others: 'My Headline' }});pc.setLocale('en');

Deploy Banner

Options to generate and deploy banner.

Sources > Privacy banners ( tab GENERATE & DEPLOY)

Generate Banner Versions

To deploy a new or updated banner it is first necessary to generate a new version of the banner. Click GENERATE to open the modal dialogue.

You will have following option when generating a new container version.

Option

Description

Comment

You can provide a comment to document the changes of the new banner version (e.g. change text of accept button).

Reactivate privacy

In case you check this option all visitors of the website will be re-asked for consent, they will again see the banner when visiting the website the next time.

Preview New Banner Versions

You can preview and test new banner versions by clicking the TEST option on the right site of the banner version in the banner version list. This will preview the banner on a demo website.

It is recommended to test new banner on a test environment of the real website before deploying it.

Banner Deployment Options

The deployment process of a new banner version varies depending on the selected hosting method of the privacy banner. You can select the hosting method of a banner in the privacy banner settings that can be accessed with the gear icon on the top left of the interface (beside the privacy banner name).

Commanders Act CDN

Commanders Act CDN ensures a reliable and performant hosting of your banner. It allows to deploy banners automatically and in real-time.

Click DEPLOY to deploy a banner to the Commanders Act CDN.

On premise (self-hosted)

This option allows to self-host privacy banner. It therefore requires manual effort on each update. For on premise hosting it is necessary to provide the URL of the folder where the on premise banner is hosted. Example:

http(s)://www.mydomain.com/myfolder/

Click DOWNLOAD to download on the right side of the new banner files and manually update them on your server.

Container vs. Banner Deployment

In case both TMS and Consent Commanders Act are used to manage tags it is important to understand what needs to be generated and deployed for different update scenarios. Following table lists the elements that needs a generation and deployment for common scenarios.

Scenario

Affected Web Container

All Web Container

Consent Banner

Global options change (Data Governance > Consent Management > Settings)

Yes

Yes

Yes

Category or vendor is added, deleted or updated on a used banner

Yes

Yes

Yes

Tag is added to a container (Source > Web Containers)

Yes

No

No

Tag is assigned to a category or vendor in the used banner (Data Governance > Consent Management > Categories (Tab ASSIGN TAGS))

Yes

No

No

Banner text or style change

No

No

Yes

Banner button actions change

No

No

Yes

On your website, don't forget to integrate a button or a link to allow your users to modify their consent choices

Use our Onsite API, command consentCenter.show

Copy Banner

Administration > Copy management

Commanders Act copy management allows to copy privacy banner. Privacy banners can be copied within the same account or transferred to another account.

Copying a Banner

Steps to copy a banner with copy management.

Step 1

Select Privacy banner(s) in the Elements to copy dropdown.

Step 2

Use the Site containing the privacy banner(s) to copy dropdown menu to select the site where the privacy banner is located that you want to copy.

Step 3

Select one or more privacy banner that you would like to copy in the Privacy banner(s) to copy dropdown menu.

Step 4

Choose one or multiple target sites where you want to copy the selected privacy banner with the Destination site(s) dropdown menu.

Step 5

You can copy your privacy banner to a new template by selecting Yes in the Copy the privacy content to a new template option.

After this you will be able to select the new template in the Destination template dropdown menu.

This will keep the content (text, selected color, etc.) of the banner and change the template.

This option might not work for customized privacy banner templates. Please contact your Commanders Act consultant or support in case you are unsure if your banner was customized before using this option.

Step 6

Click on blue buttonCOPY at the top right corner of the interface to copy the banner with the selected options.

Consent Analysis

The Commanders Act Consent Analysis dashboard provides insights into critical KPIs of your consent management setup.

Interface

Filter options

The dashboard provides KPIs for each individual Commanders Act Consent banner. You can customize the dashboard by adjusting filter settings at the top left of the interface. Commanders Act Consent Analysis provides the following filters:

Configures which privacy banners are displayed in the dashboard table.

Allows to filter dashboard metrics for typical device types. Depending on the browser settings of your website visitors, device recognition might not be 100% accurate.

Allows to filter dashboard metrics for data inside and outside the EU.

Now the top 10 banners that have at least 1,000 views are displayed. To view other banners, use the PRIVACY selection menu

Time selection

On the top right you will find options to filter data for a specific time range by specifying a start and end date. The dashboard will show metrics including the selected start and end date.

To select only one day, the day has to be clicked twice in the date picker so that both the start and end date are set to the needed day.

Export options

It is possible to export CSV reports via the EXPORT option on the top right in the interface. Reports will only include data for the selected timeframe.

Data collection is done in real-time, but metrics calculation is updated overnight, therefore no data is available in the dashboard for the current day (if you need immediate data, you can export the raw consent data via the "Data Governance > Consent Management > Settings" page).

Measurement approach

Commanders Act Consent Analysis measures privacy banner interactions to calculate consent KPIs.

All metrics are visitor/ traffic based and not user based. Commanders Act Consent Banner therefore sets a 1st party cookie TCPID on website visitors. It deduplicates certain metrics (e.g. opt-in actions) of a visitor based on this cookie. Commanders Act identifies visitors as new visitors in case they delete this cookie.

Optin vs. optout action

To understand dashboard metrics it is important to understand how Commanders Act Consent Analysis measures optin and optout actions.

An optin action occurs when a visitor...

  • clicks the accept button of the privacy banner.

  • saves the privacy center with at least one category set to "on".

  • navigates to a second page (only in case implicit "on navigation" consent was installed).

  • scrolls on the landing page (only in case implicit "on scroll" consent was installed).

  • clicks any element on the website (only in case implicit "on click" consent was installed).

An optout action occurs when a visitor...

  • clicks the reject button of the privacy banner.

  • saves the privacy center with all categories off.

Examples

Following examples outline a hypothetical scenario with only one website visitor to explain the measurement approach:

Example 1

  1. A new visitor arrives at a website with a Commanders Act Consent banner.

  2. He accepts the privacy banner and immediately navigates to the privacy policy page.

  3. There he re-opens the privacy center and revokes his prior consent.

This would lead to one optin action and one optout action and two banner views. Commanders Act Consent Analysis deduplicates action and therefore only uses the last action of a visitor to calculate the consent KPIs per day. Additionally it deduplicates the banner views per visitor per day therefore only counts one banner view in this scenario. This user journey leads to an optin rate of 0%, a no choice rate of 0%, and optout rate of 100%.

Example 2

  1. A new visitor arrives at a website with a Commanders Act Consent banner.

  2. He does not interact with the banner and leaves the site immediately.

  3. On the next day he returns to the website.

  4. He accepts the privacy banner and immediately navigates to the privacy policy page.

  5. There he re-opens the privacy center and revokes his prior consent.

On the first day this would lead to no action and one deduplicated banner view. On the second day this leads to one deduplicated optout action (see Example 1) and one deduplicated banner view.

For a selected timeframe that only includes the first day this would result in a no choice rate of 100%. For a selected timeframe that only includes the second day this would result in a optout rate of 100%. For a selected timeframe that includes both days this would result in an optin rate of 0%, a no choice rate of 50%, and an optout rate of 50%.

This measurement approach and the following metrics are based on the standard usage of Commanders Act Consent banners templates. In case of a banner customization or custom workflow, part of the metrics might have a different meaning.

Dashboard metrics

Following you will find detailed descriptions of each metric in the dashboard. When available you can expand the line to get the break down by categories.

Global

Metrics are deduplicated each day. On 23/09/2021 the calculation method has changed to take into account both banner displays and Privacy Center displays (previously, only banner displays were taken into account). When displaying the dashboard after this date, every date range will take into account Privacy Center display.

Metric

Description

Visitors exposed to CMP

The number of visitors viewing a screen of the CMP for the requested time period. It includes visitors viewing the first layer as well as visitors opening the privacy center.

Give consent

The number of visitors who at least consent to one category. It includes consent collected via the first layer (accept all, reject all buttons) as well as consent collected via the privacy center. In case several consent actions are collected during the same day (consent, no consent), only the last one is taken into account.

Do not give consent

The number of visitors who consent to no category. It includes visitors who explicitly don’t give consent (e.g. click reject all button) and “no choice visitors” with no action recorded. In case several consent actions are collected during the same day (consent, no consent), only the last one is taken into account.

Consent methods

Metric

Description

Banner button

The number of visitors who explicitly consent to all categories by clicking the accept button on the first layer.

Privacy center

The number of visitors who explicitly consent to at least one category by clicking the save button on the privacy center.

Implicit > Continue browsing

The number of visitors who implicitly consent to all categories by navigating to a second page on the website.

Implicit > Page click

The number of visitors who implicitly consent to all categories by clicking any element on the page.

Implicit > Page scroll

The number of visitors who implicitly consent to all categories by scrolling down on the page.

How engaged visitors react to CMP?

Metric

Description

Visitors making an explicit choice

The number of visitors saving a consent choice. It includes choices made by clicking consent or refuse buttons on the first layer as well as choices saved via the privacy center.

Explicitly consent (at least 1 category)

The number of visitors who at least consent to one category. It includes consent collected via the global layer (accept all, reject all buttons) as well as consent collected via the privacy center.

Explicitly reject

The number of visitors who consent to no category. It only includes visitors who explicitly don’t give consent (e.g. click reject all button). It excludes “no choice visitors” with no action recorded. In case several consent actions are collected during the same day (consent, no consent), only the last one is taken into account.

How visitors interact with the CMP banner?

Metric

Description

Interaction rate

The number of visitors who at least interact with one element of the CMP first layer. It includes clicks on accept button, reject button, configure button (opening the privacy center) and text links.

How visitors use the privacy center?

Metric

Description

Visitors exposed to privacy center categories

The number of visitors viewing the category section of the privacy center for the requested time period.

Visitors exposed to privacy center vendors

The number of visitors viewing the vendor section of the privacy center for the requested time period.

Visitors saving a configuration

The number of visitors clicking the privacy center save button. It includes visitors using the save button as well as the accept all or reject all buttons.

Visitors not saving a configuration

The number of visitors viewing the privacy center and not saving a configuration. It includes visitors using the closing cross to go back to the first layer and visitor leaving the website from the privacy center.

Understanding metrics

No choice vs. Bounce rate

In an optin configuration (no tracking before a user provides consent), bounce rate tracking is not possible anymore as bouncers usually won't interact with the website and therefore won't provide consent for analytic services. The no choice metric of Commanders Act Consent Analysis can help to get an idea on your bounce rate, but it is not the same metric!

In a default optin configuration, the "no choice" is expected to include:

Normal cases:

  • Visitors who do not provide an optin and leave the website (bounce)

  • Visitors who do not provide an optin and continue to browse the website without closing the privacy consent message (possible with header/ footer banner templates, less likely with a popin template that blocks website navigation)

  • Visitors who do not provide an optin who continue browsing the website after closing the privacy consent message with the closing cross

Special cases:

  • Visitors that are redirected by an internal redirect of the website (for example due to a language redirect on the landing page)

  • Mobile visitors who are redirected to the mobile app when arriving on the landing page in a mobile browser

  • Visits of bots like web crawlers. Common bot traffic is excluded but industry specific crawlers might increase "no choice" percentage

At the time of the first release of Commanders Act Consent Analysis the no choice rate is expected to be close to your bounce rate. The metrics will then start to differ over the following time.

AB testing

The performance of privacy banner is crucial for the success of any data driven marketing activity. Therefore it is especially important to perform AB tests of your privacy banner to improve the user experience of your website visitors and to improve your consent KPIs. For AB tests it is common to set a goal to minimise the no choice and optout KPIs.

Commanders Act Consent Analysis dashboard makes it very easy to compare metrics of two banners set up for AB test side by side by adding the AB test banners via the PRIVACY filter option.

Please contact your Commanders Act consultant in case you need support in setting up AB tests for your Commanders Act Consent setup.

Exports

Manual or Scheduled export

You can export the raw consent data in the Options menu.

You can download consent data once, or schedule a recurrent export, by email or FTP.

Export fields

The export includes the following fields:

Field

Description

id_hit

ID of the hit (autoincrement id)

id_tagcommander

ID of the TagCommander container that installed the privacy banner that initiated the consent hit.

id_privacy

ID of the privacy banner that initiated the consent hit.

version

Version of the privacy banner at the time the consent hit was initiated.

cookie

Consent categories that were accepted in the privacy center.

tcpid

cookie ID of the consent (hashed).

date_hit

Timestamp of the consent hit.

privacy_action

Action that initiated the hit.

  • V: View of the banner

  • 1: Opt-In click

  • 0: Opt-out click

  • -1: User refused all consent (only on deprecated version 1.0)

type_action

Type of action that generated the hit.

Ex of possible values:

  • banner : click in the banner

  • pc : action in the privacy center

device

device type identifier (1=phone, 2=tablet, 3=desktop, 0=other)

In case vendors are activated for the account, it is possible to include vendor optins in the export by switching the "Include Vendors in Export" toggle. This will increase export size considerably.

IP address is not stored

Storage retention

The option "Consent storage duration in database" allows to set a duration (in month) the consent data is stored in the consent database (which is used to prove consent). Be careful when changing the setting to not lose old consents by accident! You will be shown a prompt after changing the value to confirm the new duration. The maximum storage duration is 13 months. In case you need a longer storage duration, please contact your Commanders Act support or consultant.

Settings

Data Governance > Consent Management > Settings.

Only administrators can view and change these account configurations.

Account Default Configuration

Default optout / optin

This setting allows you to handle how tags should be handled in case no consent was yet provided by a user.

Your tags are not loaded when a user visits your site. They will be fired when the user continues browsing, unless they refuse cookies beforehand.

With the General Data Protection Regulation (GDPR), this is the default setting you should choose.

Your tags are loaded when a user visits your site. They are only disabled if the user explicitly refuses cookies.

This setting is not compatible with the General Data Protection Regulation (GDPR).

By default, accounts are configured in optout mode since it is the most popular and is GDPR compliant.

IAB TCF compliancy

This option enables the IAB TCF 2.0 framework for your account. This will enable IAB TCF 2.0 banner, categories and vendors.

Google Additional Consent Mode

This option enables the Additional Consent Mode (ACM) for Google Ad Technology Providers (ATP) for your account. This will enable Google ACM vendor management in the Categories & Tags section and extends the IAB TCF API according to the ACM specification.

Vendor management

This option activates vendors. This will enable vendor management options in the Categories & Tags section and enables a vendor management screen in your privacy centers that allows users to manage consent per vendor (requires re-deployment or banners).

Localisation

This option allows to select country codes (e.g. fr for French) that are used to localise the cookie notice of the cookie scanner feature. It is possible to add default country codes by clicking in the white area and selecting a country code from the dropdown. Additionally custom country codes can be added by clicking in the white area and typing the custom country code. The custom country code is saved after pressing Enter.

It is recommended to use the default country codes listed in the auto-complete dropdown. This allows to localise the cookie notice based on language settings of browsers.

Consent Export Options

See dedicated documentation here.

Privacy Cookie Name, Separator and Subdomain

These settings allow you to modify the default name, separator and subdomain of your privacy cookie.

Changing the cookie name, separator or subdomain can have unwanted side-effects depending on your Commanders Act consent setup. Please contact your Commanders Act consultant or support before applying changes.

Extensions

Cookie Scanner

The cookie scanner module allows Commanders Act users to monitor cookies on their website and to provide users with an automated cookie notice.

Overview

Commanders Act offers a cookie scanner that continuously monitors websites for cookies in real time. The scanner has access to a database of common analytics and marketing cookies and can therefore provide ready to use descriptions and information. This cookie information can be used to install a dynamic cookie notice on the website that provides transparent information about the used cookies and their purpose to visitors.

Activation

Simply follow these 3 steps to enjoy this feature on your account:

1-Cookie Scanner is an optional module. Only a Commanders Act consultant (or support team) can activate it. So the first step will be to ask to our team to activate the feature on your Commanders Act site.

2-Declare the domains that you need to be scanned with the Cookie Scanner Data Governance > Consent Management > Settings > Cookie Scanner Domains

3-Regenerate and Deploy your privacy banner(s)

Scan Cookies

Mechanisms

Cookie scanner combines three mechanisms to identify cookies on websites:

Cookie Scanner uses a JavaScript tag that is directly deployed on the website (e.g. with Commanders Act TMS). The JavaScript tag scans cookies of website users in real time. This allows to identify cookies that are set in very specific scenarios e.g. it allows to identify cookies that are only set for a specific geolocation or behind a log-in form.

The tag also monitors the 3rd party domains the website communicates with (e.g. for an Analytics service). This information is used to infer 3rd party cookies via the cookie scanner cookie database.

JavaScript tags have limited access to cookie information—therefore cookie scanner enriches the information identified with the JavaScript tag with information received with the Chrome extension and cookie database.

Not all cookies are accessible to JavaScript tags. The Commanders Act Assistant Chrome extension has more technical capabilities to scan missing cookie information. To use the Chrome extension it just needs to be installed in an up to date Chrome browser. After that it starts scanning cookies while surfing the website. This provides a powerful mechanism to identify cookies in all areas of the website, no matter they require a log-in.

Commanders Act recommends to install the Chrome extension on multiple team members across different country teams to cover a wide range of use cases.

Cookie Scanner uses a cookie database to enrich missing information that can not be identified with the tag and extension. For example it provides ready to use descriptions for common tracking and marketing cookies.

Additionally the cookie database provides the tag with a mechanism to infer typical 3rd party cookies based on the communication of the website with 3rd party domains.

Some technical systems (like Drupal) create dynamic cookie names. Cookie Scanner therefore groups cookies when 5 or more cookies start with the same 4 characters. (e.g. abcd123, abcd2345, abcd3456, etc.)

Cookie Types

Cookie scanner can scan following types of cookies:

Cookie Type

Description

Scanned with

1st Party Cookie

1st party cookies are cookies that are stored on the domain of the website.

  • Tag client-side

  • Chrome Extension

3rd Party Cookie

3rd party cookies are cookies that are stored on a 3rd party domain.

  • Chrome Extension

  • Cookie Database

HttpOnly 1st Party Cookie

HttpOnly 1st Party Cookie are server cookies that are stored on the domain of the website and that have a HttpOnly flag.

  • Tag client-side

  • Chrome Extension

HttpOnly 3rd Party Cookie

HttpOnly 3rd Party Cookie are server cookies that are stored on a 3rd party domain and that have a HttpOnly flag.

  • Chrome Extension

  • Cookie Database

Local Storage

localStorage is a JavaScript accessible browser storage.

  • Tag client-side

  • Chrome Extension

Session Storage

sessionStorage is a JavaScript accessible session based browser storage.

  • Tag client-side

  • Chrome Extension

Cookie Fields

Cookie Scanner scans following fields per cookie:

Name

Name of cookie e.g. _ga *In case of multiple (more than 3) cookies with common pattern, they re grouped by patterns

  • Tag client-side

  • Chrome Extension

Vendor

Name of the vendor that uses the cookie e.g. Google

  • Cookie Database

Category

Category of the cookie that give a high level information on the purpose of the cookie e.g. Technical Cookie

  • Cookie Database

Storage Location

Storage location of the cookie (combination of cookie type and storage domain). It has one of the following values:

  • 1st Party Cookie (www.example.de)

  • 3rd Party Cookie (www.example.de)

  • HttpOnly 1st Party Cookie (www.example.de)

  • HttpOnly 3rd Party Cookie (www.example.de)

  • localStorage (www.example.de)

  • sessionStorage (www.example.de)

The domain in brackets is the domain where the cookie is stored. For 1st party cookies it is the domain or subdomain of the website. For 3rd party cookies it is a 3rd party domain or subdomain that is different from the website.

  • Tag client-side

  • Chrome Extension

Storage Duration

Storage duration of the cookie. An algorithm is used to smoothen technical inaccuracies and to optimise readability for users:

  • For Session Cookies it displays "Session"

  • Under 1 month it displays in days, e.g. "7 days"

  • Above 1 month it displays in month, e.g. "13 months"

  • Above 36 month it displays in years, e.g. "5 years".

  • Above 100 years it displays “Unlimited”

Local storage always has duration "Unlimited" and session storage always has duration "Session".

  • Tag client-side

  • Chrome Extension

  • Cookie Database

Description

Description for what the cookie is used, e.g. “Base64 UUID used to identify users on this website to optimise usage across sessions. Used on all pages.”

  • Cookie Database

Website

Domain(s) of the website(s) the cookie is scanned. For 1st party cookies, the full URL of the latest scan is also displayed

  • Tag client-side

  • Chrome Extension

Cookie scanner doesn't store cookie's values

Manage Cookie Information

Health > Website Monitoring > Cookie Scanner > EDIT (Tab)

In the edit step of the cookie notice it is possible to investigate, edit and enrich cookie information.

Sections

All identified cookies are listed in three groups:

  1. New lists new Cookies that have not yet been manually investigated

  2. Active lists Cookies that should be shown in the cookie notice

  3. Ignored lists (internal) Cookies that should not be shown in the cookie notice

Edit Cookie Information

It is possible to edit the information of each cookie by pressing the Pen icon to the right on the table. This will open a cookie dialogue with following options:

Option

Description

Name

The name of the cookie can not be edited.

Vendor

Dropdown menu that allows to map the cookie to a Commanders Act vendor managed under Data Governance > Consent Management > Vendors.

Vendor Label

Defines the name of the cookie vendor listed on the cookie notice.

Vendor URL

A URL of the vendor that is used in the cookie notice. This allows customers to click the name of the vendor.

Category

Dropdown menu that allows to map the cookie to a Commanders Act category managed under Data Governance > Consent Management > Categories.

Category Label

Defines the name of the cookie category listed on the cookie notice.

Storage Type

One of the storage types listed under Cookie Fields.

Storage Domain

The domain where the cookie is stored.

Storage Duration

The duration the cookie is valid on users browsers.

Description

A description of the cookie. If possible this field is automatically filled from the cookie database. In case it is overwritten the description is not anymore synced with the cookie database. Clicking the Reset Default button will re-sync the description with the cookie database descriptions.

Custom Fields

All custom fields created in the cookie scanner options.

Create Custom Cookie

It is possible to add custom cookies by pressing the ADD COOKIE button on the top right of the interface. This will open a cookie dialogue that has the same fields as the edit cookie information dialogue. Additionally it has a Name field that allows to set the name of the custom cookie.

Activate, Deactivate or Delete Cookies

New cookies and inactive cookies can be activated via the Checkmark icon. This adds them to the Active cookies list.

Active cookies and be deactivated by clicking the Stop sign icon. This adds them to the Inactive cookies list.

Inactive cookies can be deleted with the Trash can icon. This removes the cookie from the list entirely.

Cookies that should not be shown in the cookie notice should be kept in the inactive list and not deleted. Otherwise they will re-appear as soon as the cookie scanner identifies them again.

Localize Cookie Information

Localisation is not available yet.

It is possible to localize cookie information. This allows to translate important information of each cookie for the cookie notice that can be embedded on a website.

To localize cookie information it is first necessary to select supported languages. To select supported languages go to Data Governance > Consent Management > Settings and select the country codes of the languages the cookie notice should be made available in. It is recommended to select country codes from the dropdown menu, but it is also possible to add custom country codes. Cookie Scanner offers automatic translation of predefined information for common languages (EN, FR, DE, IT).

After selecting the needed country codes the cookie information can be translated in the EDIT step of the interface. To translate a cookie click the Pen icon to open the edit modal. There it is possible to select a country code via a dropdown. Then adjust the setting the fields to translate them. You can preview the cookie list in a specific language by using the country code dropdown in the top right of the interface.

Following fields support localisation:

  • Vendor Label

  • Category Label

  • Description

  • Custom Fields

Labels

The cookie list displays optional labels for each cookie in the cookie list to inform about important information and notifications.

Label

Description

Inferred

The cookie was not identified directly, but inferred via the cookie database. It might be a false positive.

Missing

The cookie was not scanned for over one month. It might not be in active use anymore.

Custom

The cookie was manually created.

Set before consent

The cookie is set before a customer provides consent via Commanders Act CMP. This can be intentional for essential cookies.

Occurrence frequency

For all types of cookies & storage you can visualize the percentage of detection frequency

Manage Cookie Notice

Health > Website Monitoring > Cookie Scanner > DEPLOY (Tab)

The DEPLOY (Tab) interface is used to install, create and deploy a cookie notice on a website. It provides a versioned list of cookie notices that were created within the account.

Install Cookie Notice

After all cookie information was setup in the EDIT (Tab) it is possible to install the cookie notice on a website. The cookie notice is available in 3 versions:

1. Javascript snippet

Copy/past the js code on your legal page to automatically build the cookies list table.

2. HTML Table

The HTML table is the recommended way to install a dynamic cookie notice on websites.

For this it is recommended to setup both a JavaScript tag (e.g. tag template 'TRUST | Install Cookie Notice' in TagCommander) and a placeholder <div> on the website (e.g. in the Content Management System). The placeholder is a slot where the table should be inserted and the tag loads the table and inserts it into the slot.

Both the <div> and the tag need to be configured with a common id. e.g. in case the placeholder <div> has following id: <div id="ca-slot--cookie-notice"></div> it is necessary to set the parameter #PLACEHOLDER_DIV_ID# of the tag template TRUST | Install Cookie Notice to ca-slot--cookie-notice .

Endpoint of the HTML file:

https://cdn.tagcommander.com/cookie-scanner/<site_id>/v1/cookies-<language_code>.html

site_id: Commanders Act site ID (e.g. 1234).

language_code: Language of the cookie notice (e.g. fr, default language is en).

The HTML table uses semantic and accessible table HTML. This ensures that the table uses the default styling of your website. The style of the table can be directly adjusted with the CSS of the website. In case you need help styling you can reach out to your Commanders Act consultant.

3. JSON API

The JSON API provides a method to install a cookie notice for advanced use cases. It provides all cookie information in a structured data format that can be used by technical users to create custom functionalities. The JSON API can e.g. be used to inject a custom cookie notice into a native App.

Endpoint of the json file:

https://cdn.tagcommander.com/cookie-scanner/<site_id>/v1/cookies-<language_code>.json

site_id: Commanders Act site ID (e.g. 1234).

language_code: Language of the cookie notice (e.g. fr, default language is en).

Create Cookie Notice Version

Before it is possible to deploy updates to the cookie notice it is necessary to create a new version. To create a new cookie notice version click the NEW VERSION button on the top right of the interface. This will take all cookies in the Active list of the EDIT (Tab) to create the cookie notice. In the new version dialogue it is possible to provide a comment that explains changes in the new version for internal reference.

Preview Cookie Notice Version

The Play button to the right of a cookie notice version can be used to preview a cookie notice. This will not apply any styling of the website so the look will differ compared to the cookie notice on the website.

Export Cookie Notice Version

A Down Arrow button is available for each cookie notice version. It allows to download the cookie notice in all localisations in HTML, JSON, CSV and XSLX format. In the XSLX one tab is included per language. For all other formats a ZIP will be provided that includes one file per language.

Deploy Cookie Notice Version

The DEPLOY button to the right of each cookie notice version can be used to deploy a cookie notice to the website. This allows to deploy new versions, but allows to roll back to older version in case of issues.

Options

Custom Fields

Cookie Scanners allows to add custom fields to provide additional details per cookie. These fields can be added inside of the feature settings accessible via the Gear icon. It is possible to re-arrange the fields by changing their order via drag and drop.

Filters

You can filter your cookie's list by host (website), language and storage type (1st party, 3rd party, local storage, session storage)

If you select 3rd party type, you will obtain an additional filter to view cookies from a specific domain:

Rare cookies filter

By default, the rare cookies (scanned on less than 5% of pages) are now excluded from your list. Use the cursor to manage the scanner's tolerance. If it is positioned on 10%, the list will displays only the cookies scanned more often than 9.9%. You can modify this value, it's up to you!

User Rights

User Rights for Cookie Scanner are not yet available.

Cookie Scanner offers following user rights:

User Right

Description

View Cookie List

User can see the cookie list.

Manage Cookie List

User can edit the cookie list and create custom cookies.

Generate Cookie Notice

User can view the Deploy Step and generate a cookie notice version.

Deploy Cookie Notice

User can deploy cookie notice versions.

Manage Cookie Scanner Settings

User can adjust cookie scanner settings (e.g. custom fields).

Piggybacking

Tag mapping: View all your site's tags and their relationships on a map.

Focus by page type: Filter by page type (conversion page, product page, cart, etc.) and optimize the orchestration of your different tags for these pages in particular.

Health > Website Monitoring > Piggybacking

Tag Firewall

TagFirewall can whitelist or blacklist tags.

TagFirewall is a paid extension that can be installed with Commanders Act TMS or run in standalone mode. Please contact a Commanders Act consultant or account manager to activate it.

Overview

TagFirewall blocks unauthorized tags (domains) in real time. This can e.g. help to block and reduce the risk of piggybacking tags. TagFirewall is highly dynamic and can therefore enrich an existing Content Security Policy (CSP) setup to resolve critical issues with tags in minutes or replace the need for a Content Security Policy (CSP) entirely. TagFirewall offers two modes:

Blacklist Mode

This mode blocks tag communication with a configurable list of domains. Communication with all other domains is still permitted.

Whitelist Mode

This mode blocks tag communication with all domains except a configured whitelist.

Setup

Commanders Act

TagFirewall can be set up and configured with the tag template "Commanders Act - TagFirewall" in Commanders Act TMS tag library.

Option

Description

Mode

Allows to select Blacklist or Whitelist mode.

Blacklist domains

Domains that should be blacklisted. Enclosed in " and and separated by, . (Only for Blacklist Mode)

Internal domains

Tag domains that should be whitelisted. Enclosed in " and and separated by, . (Only for Whitelist Mode)

Tag domains

Internal domains (domain the website needs to function) that should be whitelisted. Enclosed in " and and separated by, . (Only for Whitelist Mode)

Check SSL

This option allows to block all http script hits (it will only allows https script hits).

Standalone

TagFirewall can be set up and configured with a custom JavaScript tag for all other installations. The tag has following options.

Option

Description

<whitelist_tags>

Array of domains used by tags that should not be blocked. (Only for Whitelist Mode)

<whitelist_internal>

Array of internal domains (domain the website needs to function) that should not be blocked. (Only for Whitelist Mode)

<blacklist_tags>

Array of domains used by tags that should be blacklisted. (Only for Blacklist Mode)

<active_flag>

This option activates TagFirewall. Set to true to activate TagFirewall.

<check_ssl>

This option allows to block all http script hits (it will only allows https script hits). Set to true to activate it.

<script_url>

URL of the TagFirewall library JavaScript file. This URL will be provided by a Commanders Act Consultant or Account Manager.

<script>
tC = tC || {};
tC.tagFirewall = tC.tagFirewall || {};

tC.tagFirewall.list = {
    "blacklist": {
        "tags": <blacklist_tags>
    }
};

tC.tagFirewall.checkSSL = <check_ssl>;
tC.tagFirewall.blocked  = <active_flag>;  
</script>
<script src="<script_url>"></script>
<script>
tC = tC || {};
tC.tagFirewall = tC.tagFirewall || {};

tC.tagFirewall.list = {
    "whitelist": {
        "internal": <whitelist_internal>,
        "tags": <whitelist_tags>
    }
};

tC.tagFirewall.checkSSL = <check_ssl>;
tC.tagFirewall.blocked  = <active_flag>; 
</script>
<script src="<script_url>"></script> 

Examples

<script>
tC = tC || {};
tC.tagFirewall = tC.tagFirewall || {};

tC.tagFirewall.list = {
    "blacklist": {
        "tags": ["bad-domain1.com", "bad-domain2.com"]
    }
};

tC.tagFirewall.checkSSL = true;
tC.tagFirewall.blocked  = true;  
</script>
<script src="<script_url>"></script>
<script>
tC = tC || {};
tC.tagFirewall = tC.tagFirewall || {};

tC.tagFirewall.list = {
    "whitelist": {
        "internal": ["cdn.yourdomain.com", "cdn.yourdomain2.com"],
        "tags": ["facebook.com","twitter.com"]
    }
};

tC.tagFirewall.checkSSL = true;
tC.tagFirewall.blocked  = true;
</script>
<script src="<script_url>"></script>

The tag should be included in the <head> of your document. It can only block tags that are loaded after the TagFirewall tag and JavaScript library file.

Marketing Preferences Center (additional module)

What is our Marketing Preferences Center?

Marketing Preferences Center is part of our Consent management Premium offer. It allows you to build a personalized Preferences Center where online and offline consents are merged around unified users and stored in the same database.

Then, you can easily create and customize a web page to display this information to visitors who want to manage their consents and personal information.

It turns a legal page into a preference center that is way more valuable for a customer as it is more like a sharing space between the brand and their visitors/clients rather than just a way to collect the consent.

How it works?

Marketing Preferences Center is a realtime searchable nosql database. We provide also a dedicated API to read and/or write preferences/consents on this database

LogoGET/PUT Consents / preferencesConsent management

· Consents are collected through our CMP solution (native integration)

· Preferences coming from a CRM database could be added with the FTP importer files or API

· Our customers can personalize the look and feel of their marketing preferences center page, we don’t host the webpage.

· Paid option: our customers can choose to receive regularly a full consents database copy to have a backup on their side

Limitations:

  • The API accepts a maximum of 20 preferences

Knowledge Base

Consent Object

Description of the Consent Object format that is used by the onsite API to receive and update consent.

The Consent Object is a standardized way to represent consent throughout all methods of the onsite JavaScript API (similar to the IAB TCF consent string). The object holds a meta property that includes metadata like the validity of the cookie and a consent property that holds that current consent settings stored on the browser.The onsite API and Consent Object is the official way to access the consent settings of Commanders Act CMP with JavaScript. The direct usage of the Consent Cookie is deprecated.

Example Consent Object

{
    meta: {
        version: "1.0",
        tcfPolicyVersion: "2",
        siteId: "1234",
        bannerId: "12",
        bannerVersion: "50",
        consentId: "183049723840253",
        dateCreated: 1614174067000,
        dateUpdated: 1614185078030,
        dateExpires: 1614236789942
    },
    consent: {
        status: "all-on|all-off|mixed|unset",
        categories: {
            "1": {
                status: "on",
                required: true
            },
            "2": {
                status: "on|off|unset"
            },
            "tcf2_1": {
                status: "on|off|unset"
            },
            "tcf2_2": {
                status: "on|off|unset",
                legIntStatus: "on|off|unset"
            },
            "tcf2_sf_1": {
                status: "on|off|unset"
            }
        },
        vendors: {
          "1": {
                status: "on|off|unset"
          },
          "tcf2_1": {
                status: "on|off|unset"
          },
          "tcf2_2": {
                status: "on|off|unset",
                legIntStatus: "on|off|unset"
          },
          "acm_1": {
                status: "on|off|unset"
          }
        }
    }
}

Meta Properties

The meta property includes metadata and context for the consent that was provided on a browser.

Property

Description

Type

meta.version

Version of the Consent Object.

String

meta.tcfPolicyVersion

Version of the IAB TCF consent.

String

meta.siteId

Commanders Act site id associated to the consent.

String

meta.bannerId

Banner id associated to the consent.

String

meta.bannerVersion

Banner version associated to the consent.

String

meta.consentId

Id of the consent stored in the TCPID cookie.

String

meta.dateCreated

Timestamp when the consent was provided (UNIX Epoch in Milliseconds).

Number

meta.dateUpdated

Timestamp when the consent was updated the last time (UNIX Epoch in Milliseconds).

Number

meta.dateExpires

Timestamp when the consent will expire (UNIX Epoch in Milliseconds).

Number

Consent Properties

The consent property includes detailed information about the consent provided on the browser.

Property

Description

consent.status

Global status of the consent that can have one of the following values: all-on: All consent categories have been accepted.all-off: All consent categories have been refused (except blocked on).mixed: Some consent categories have been refused.unset: No consent has been provided yet.

consent.categories[category_id].status

Status of an individual category:on: Consent was provided.off: Consent was rejected.unset: No consent has been provided yet (In case neutral button position is configured it will switch to neutral button position for this category).​category_id is the category id configured under Data Governance > Consent Management > Settings > Categories.

consent.categories[category_id].required

The property was set to blocked on and the status is always on.

consent.vendors[vendor_id].status

Status of an individual vendor:on: Consent was provided.off: Consent was rejected.unset: No consent has been provided yet (In case neutral button position is configured it will switch to neutral button position for this vendor).​vendor_id is the vendor id configured under Data Governance > Consent Management > Settings > Vendors.

Category and Vendor IDs are prefixed with an identifier in case they are managed by a consent framework.

Framework

Prefix

tcf2_

IAB TCF 2 framework. Special features are additionally prefixed with sf_

acm_

Google's Additional Consent Mode vendors.

​

Consent cookies exemption

For its own operations, our Consent Module sets 1st party cookies to store the user's consent and to report anonymous consent statistics.

These cookies are necessary for the proper functioning of the collection of consent and the reporting of anonymous statistics. To this regard they are exempt from the obligation of consent.

Consent storage cookies

Consent storage cookies differ depending on the banner template used:

  • standard templates: TC_PRIVACY & TC_PRIVACY_CENTER

  • IAB TCF templates (local storage) : TC_PRIVACY_IAB_VENDORLIST & TC_PRIVACY_TCF

Cookie for anonymous statistics and consent proof (TCPID)

A 1st party cookie is set to be able to collect anonymous statistics of consent: TCPID. This cookie is also used as a unique identifier to provide proof of consent when required (for auditing or when requested by the user). We have worked together with the CNIL France to design the setting and processing of this cookie to strictly comply with the rules of the RGPD and in particular the rules enacted by the CNIL in 2019.

If for any reason you wish to block this cookie before consent, please use the following code in your first custom js block of the web container. The cookie will still be created after the consent action to provide a proof of consent.

  if (tC.getCookie("TC_PRIVACY") == "") {
    tC.privacyCookieDisallowed = true;
  }

When are cookies exempt from consent?

In order to be exempt from consent in accordance with article 82 of the Data Protection Act, these tracers must:

  • have a purpose strictly limited to measure the audience of the site or application (performance measurement, detection of navigation problems, optimization of technical performance or its ergonomics, estimation of the power of the necessary servers, analysis of content consulted) for the exclusive account of the publisher

  • be used to produce anonymous statistical data only

Conversely, to be exempt from consent, these tracers must not:

  • lead to a cross-checking of the data with other processing or the data to be transmitted to third parties

  • do not allow the aggregate tracking of the user's navigation across different applications or websites. Any solution using the same identifier across several websites (for example via cookies placed on a third-party domain loaded by several websites) to cross, split or measure a unified coverage of a content is excluded.

CNIL recommendations

To put in place solutions that respect people's rights, the CNIL also recommends that:

  • users are informed of the implementation of these tracers, for example via the privacy policy of the site or the mobile application

  • the lifespan of the tracers is limited to a period allowing a relevant comparison of audiences over time, as is the case with a period of 13 months, and that it is not automatically extended on new visits

  • the information collected through these tracers is kept for a maximum period of 25 months

  • the above-mentioned retention periods are subject to periodic review in order to be limited to what is strictly necessary

  • for FR market : link the Consent Statistics to a category of cookies which can be turn off by the users on 'refuse all'

  • for FR market : if you decide to do not link the Consent Statistics to a cookies category, you will be must to provide to your users another way to be Optout of Consent Statistics. We provide an FR implementation guide for Optout statistics, as recommended for CNIL compliance

A subcontractor can provide a benchmark service to multiple publishers if:

  • the data is collected, processed and stored independently for each publisher

  • tracers are completely independent from each other

Implementation guide for exempted consent statistics FR market

Please download our implementation guide for Commanders Act Consent exempted statistics for CNIL compliance of France market

325KB
guide_configuration_mesure_daudience_exemptee_cmp_commandersact_2023.pdf
pdf

Consent Cookie

Format of the Commanders Act Consent cookie.

The Consent Object received via the onsite API is now the official way to access the consent settings of Commanders Act Consent with JavaScript. The direct usage of the consent cookie is deprecated.

Commanders Act Consent stores the consent of website visitors in a 1st party cookie.

This article only explains the consent cookie. Here you can find a list of all Commanders Act Consent cookies.

Name

The default name of the consent cookie is TC_PRIVACY. It can be configured in Data Governance > Consent > Settings.

Domain

The cookie is set as a 1st party cookie. The subdomain/domain of the cookie can be configured in Data Governance > Consent > Settings

Value

The value consist of multiple fields separated by @ symbols. The separator can be configured in Data Governance > Consent > Settings .

The consent cookie format is not 100% guaranteed to stay stable. We try to keep the format as stable as possible and extend it with "append only approach (adding new information with a new @)", but changes might happen in the unforeseeable future due to limited storage space in cookies.

The cookie value follows following pattern (optional elements are wrapped in []).

<status>@<privacy_version>[|<tcf_version>]|<banner_id>|<site_id>@<consent_categories>@<blocked_on_categories>@<updated_timestamp>,<creation_timestamp>,<to_expire_timestamp>[@<tcf_vendor_consent_string>]

Field

Description

Example Value

<status>

Status that indicates if a visitor provided his optin or optout.

1: Visitor is optout

0: Visitor is optin

<privacy_version>

Version of the privacy banner the visitor interacted with.

008

<tcf_version>

Version of the IAB TCF framework. Only available in case IAB is activated for the account and an IAB banner is used to manage consent. It follows this format:<tcf_global_vendor_list_specification_version>|<tcf_policy_version>|<tcf_global_vendor_list_version>

2|2|42

<banner_id>

ID of the privacy banner the visitor interacted with.

12

<site_id>

ID of the site in the Commanders Act Platform.

34

<consent_categories>

Comma-separated-list of optin, or optout categories. Meaning depends on <status> field. E.g. when <status> is 0 then the visitor provides consent for the listed categories. The value is URL encoded. Therefore the comma separator is replaced with %2C. Some old banner versions might have the value ALL in case all categories are opted out.

2%2C12%2C13

<blocked_on_categories>

Comma-separated-list of blocked on categories. The value is URL encoded. Therefore the comma separator is replaced with %2C. These categories are not repeated in the <consent_categories> field.

2%2C12

<updated_timestamp>

UNIX timestamp for when the consent was last updated

<creation_timestamp>

UNIX timestamp in milliseconds when the consent was provided.

1592900933049

<to_expire_timestamp>

UNIX timestamp for when the consent will expire

<tcf_vendor_consent_string>

Vendor consent information (e.g. for IAB TCF vendors). Only available when vendors are activated for the account and in case vendors are used in the banner. The value is compressed and encoded to keep the cookie size small.

AAAAAjkb23...

Examples

Example1: Optin for some categories

0@002|12|3441@1%2C3@4@1592900933049@1592900933049

Field

Description

0

Visitor is optin.

002

Visitor provided optin on banner version 002.

12

Banner ID is 12.

3441

Site ID is 3441.

1%2C3

Visitor provided optin for categories 1 and 3.

4

The category 4 is blocked on.

1592900933049

Visitor provided optin on Tue Jun 23 2020 08:28:53.

Example 2: Optout for all categories

1@012|26|4221@@4@1592900933049@1592900933049

Field

Description

1

Visitor is optout

012

Visitor provided optin on banner version 012.

26

Banner ID is 26.

4221

Site ID is 4221.

Visitor provided optout to all categories.

4

The category 4 is blocked on.

1592900933049

Visitor provided optout on Tue Jun 23 2020 08:28:53.

Good to know: special characters such as "@" or "|" are encoded in the cookie value %2C = "," %7C = "|" %40 = "@"

IAB TCF V2.2 Release details

Introduction

In February last year, the Belgian Data Protection Authority (APD, “Autorité de Protection des Données”) issued a decision against IAB Europe related to the Transparency and Consent Framework (TCF), fining the organization 250k€ and instructing it to come up with a plan to solve the issues that were identified.

Since then, IAB Europe has come up with a plan to update its TCF, which will come into action over the following months. In this article, we review the context surrounding the APD decision, catching you up on the events from last before presenting IAB Europe’s action plan, and finally going over what these changes will mean in practice for Commanders Act users.

March 2023 update: On March 15th, 2023, IAB Europe confirmed that the Belgian APD has voluntarily suspended the six-month implementation period of IAB Europe’s action plan. As a result, the July 2023 deadline no longer applies. It’s now reported for Q4 2023

For more details and pending additional information, read the official IAB communication here.

Context about the Belgian APD and the Transparency and Consent Framework

More than a year ago, on February 2nd, 2022, the Belgian APD issued a decision against IAB Europe citing 4 issues with its Transparency and Consent Framework (what’s the TCF? Learn more here). According to the Belgian APD:

The Transparency & Consent (TC) string, the consent signal stored by players in the advertising industry, is personal information. As such, participants should establish a legal basis.

IAB Europe is a data controller of that information, whether or not it processes the consent information

IAB Europe is a joint controller with TCF participants (vendors, CMPs, publishers)

Security measures in place to protect the integrity of the consent signal were not sufficient

IAB Europe was subsequently fined and instructed to come up with an action plan to solve these issues. The IAB Europe, along with some TCF participants, has worked on the action plan and submitted it to the APD in April 2022. Despite additional procedural events in September, the action plan was reviewed on January 11th by the Belgian APD.

Of course, we will communicate with Commanders Act customers with specific action points before then.

What is going to change in 2023 for the TCF?

Here are the main changes and obligations that will impact your Consent Management Platform if you’re using the TCF after April 2023:

New TC string special purpose

Users of the TCF will be required to add a new (special) purpose to the classification of purposes in the TCF, informing their users that they are capturing and sharing data subject choices via the TC String.

No more legitimate interest for targeted advertising

Going forward, users won’t be able to rely on legitimate interest for personalized advertising.

Specifically, the purposes impacted will be purpose 3 (create a personalized ads profile), purpose 4 (select personalized ads), purpose 5 (create a personalized content profile), and purpose 6 (select a personalized content profile).

Mandatory disclosures in the second layer of the CMP

After April, users of the TCF will be required to disclose new information in their CMP second layer:

  • The legitimate interests at stake

  • The categories of data collected and/or already held by Vendors

  • The retention periods (in the Vendors’ description)

Vendor-related changes

Publishers will be presented with a warning about the impact that a large number of vendors can have on the ability of users to make informed choices.

Additionally, the number of vendors will need to be disclosed in the first layer of the CMP. Finally, we will recommend using event listeners to ensure proactive communication of changed TC String to vendors.

As a Commanders Act customer, what am I supposed to do?

As a Commanders Act customer, what do these changes in the TCF mean and what are you supposed to do? Don’t worry, we’ve got it all planned out.

Not a lot will be expected from Commanders Act customers. However, if you decide to continue using the Transparency and Consent Framework, you must know that consent notices/consent banners will be changing slightly (based on the changes listed in the previous section), and you should therefore be ready for it.

The migration from the TFC v2.2 will take place on November 20, 2023 serving as the hard deadline for the change. You will be must to regenerate your consent banners TCF before this deadline.

Once the migration will be complete, we will recommend that you recollect consent from your customers, as previously collected consent was deemed invalid following the Belgian APD decision. Additionally, you’ll most likely have to reduce your vendor list, and updating mobile SDK versions to get the new TCF various updates will be compulsory.

But don’t worry, we will remind you about this before the deadline.

Conclusion

To conclude, and while it’s important to be aware of the upcoming changes following this important industry decision, the impact on Commanders Act customers should be minimal, and we’re hoping to provide thorough assistance to everyone along the way If you wish to go further, you will be able to verify your TCF compliancy, since IAB Europe has released a new CMP Validator Chrome Extension available here that includes all requirements of TCF v2.2.

IAB TCF v2.2 CMP requirements

The IAB TCF v2.2 has new requirements. This page listing the new elements of the CMP IAB TCF UI standard.

This is an informative page. Almost every listed points above are automatically managed by our Consent Module (only the buttons "accept all" and "refuse all" are not automatically added). Simply follow our Migration guides for Web and for App to update you banner with these new requirement

1st Layer

The standard text has evolved with more precise list of usage of datas, and the total number of IAB TCF vendors must be displayed

If your banner has a custom text, you can use this function to display the number of vendors on the first layer tC.privacy.getNbIabVendors()

IAB TCF requirements are very strict. If you wish to display a custom text, we strongly recommend you to ask a validation from IAB team. You can also refer to this cmp UX UI requirements guide

2nd Layer (purposes menu)

Buttons Accept All/Refuse All are required

If you don't have yet an accept all / refuse all buttons in your privacy center, you must add them manually. You can refer to the step n°2 of this page for setup help

The automatic text of Purposes has evolved

There's no more "Legal Description" it is replaced by "Examples"

New TC string special purpose

The TCF will add a new (special) purpose to the classification of purposes in the TCF, informing their users that they are capturing and sharing data subject choices via the TC String. The name of this new special purpose is "Use limited data to select content" (ID 11)

Legitimate interest buttons will be removed on the following Purposes:

  • purpose 3 (create a personalized ads profile)

  • purpose 4 (select personalized ads)

  • purpose 5 (create a personalized content profile)

  • purpose 6 (select a personalized content profile)

3rd Layer (Vendors Menu)

3 major changes for the information provided by the Vendors

  • They can provide a cookie policy url in multiple languages (the displayed url will be the same then the browser language)

  • They must show the data retention period for each purpose

  • They must show data they will collect

IAB TCF v2.2 Migration guide Web

Step by step guide to remains compliant on the Web for TCF v2.2

Here's the 5 steps to follow to remains compliant with the TCF on your website

  1. Verify/Update your IAB Vendors The Vendors List has evolved, we recommend to verify your IAB Vendors selected. Data Governance > Consent Management > Vendors

  2. Setup an Accept All/Refuse all buttons in your privacy center Sources > Privacy Banners > Edit (select your banner) > Privacy Center tab > Buttons *don't forget to save your changes !

  3. Generate a new version of your Consent banner Sources > Privacy Banners > Edit (select your banner) > Generate *We recommend to check the option 'reactivate the privacy', so all you users will have the new consent string format, including the new purpose and the updated vendors

  4. Generate a new version of the Web Container related to you Consent Banner Sources > Web Containers > Edit (select your container) > Generate

  5. Deploy your latest versions of Web Container and Consent Banner

IAB Europe has released a new CMP Validator Chrome Extension available here

The deadline to migrate is November 20, 2023

IAB TCF v2.2 Migration guide App

This page is to the attention the customers using the Commanders Act SDK with the IAB Consent Module in their mobile application

Introduction

Here's the 2 steps to follow to remains compliant with the TCF on your mobile application

Requirements To be allowed to migrate on IAB TCF v2.2, your application must use the v5 of our SDKs If you're still using the v4, please refer to the main SDK Migration Guide

Please note: this documentation is a user friendly step by step guide. For technical details please refer to our GitHub Android and iOS

1-Update the SDK Module

Simply download the latest versions of our TCIAB SDK Modules

  • Android

  • iOS

2-Update the json files

Upload the latest version to update your offline json's

  • vendor-list.json

  • purposes-xx.json (required if you're using other languages then EN, this link example is for FR language)

  • your privacy json file updated (needs to be modified, following the step "Update the content of your privacy json file")

Upload your CDN json file

Your privacy json file updated needs to be uploaded on CDN Commanders Act, please contact your consultant or our support team to upload the latest version of your json on our servers. (the content of this json file needs to be updated, following the next step.)

Update the content of your privacy json file

  1. Verify your vendor list "vendors": "15,48,501,506,520,539,512,895", *if you left the "vendors" empty, it will be considered as ALL vendors by our SDK Pay attention to your Vendor List, some Vendors aren't existing anymore in the GVL v3

  2. Add the new required fields texts -> generic -> "illustationsButton": "illustrations"

    texts -> generic -> "dataCategoriesDef" : "Data Categories" texts -> vendors -> "legIntClaimTitle": "Legal policies"

Full json example:

{
	"information": {
		"update": "2023-06-30",
		"version": "1",
		"vendors": "8,241",
		"google_vendors" : "323,389,385,424",
		"consentDurationInMonths": 6,
		"significantChanges": "",
		"resetSave": ""
	},
	"components": {
		"firstLayerButton": ["RefuseAll", "Detail", "AcceptAll"],
		"secondLayerButton": ["RefuseAll", "Save", "AcceptAll"]
	},
	"customisation": {
		"content": {
			"fontcolor": "#000000",
			"backgroundcolor": "#ffffff",
			"bordercolor": "#806423"
		},
		"button": {
			"fontcolor": "#ffffff",
			"backgroundcolor": "#4287f5",
			"disabledBackground": "#E1E1E1",
			"linkcolor": "#0907F7"
		},
		"order": ["Custom", "IAB"]
	},
	"texts": {
		"generic": {
			"saveButton": "Save & Exit",
			"detailButton": "Details",
			"acceptAllButton": "Accept All",
			"refuseAllButton": "Refuse All",
			"vendorButton": "Vendors",
			"purposeButton": "Purposes",
			"legalButton": "Legals",
			"illustationsButton": "illustrations",
			"backButton": "Back",
			"purposeDef": "Purposes",
			"consentDef": "Consent",
			"legIntPurposeDef": "Legitimate Interest",
			"flexiblePurposeDef": "Flexible Purpose",
			"specialPurposeDef": "Special Purpose",
			"featureDef": "Features",
			"specialFeatureDef": "Special Features",
            		"dataCategoriesDef" : "Data Categories",
			"partnersLinkText": "our partners",
			"relatedVendorsButton": "show related vendors",
			"month": "month",
			"day": "day",
			"seconds": "seconds",
			"hours": "hours"
		},
		"popup": {
			"title": "We respect your privacy",
			"content": "We and our partners use technologies, such as cookies, and process personal data, such as IP addresses and cookie identifiers, to personalise ads and content based on your interests, measure the performance of ads and content, and derive insights about the audiences who saw ads and content. Click below to consent to the use of this technology and the processing of your personal data for these purposes. You can change your mind and change your consent choices at any time by returning to this site.\n",
			"purposeTitle": "We and our {total_number} partners:",
			"specialPurposeTitle": "We need your consent for all the purposes above, but we have legitimate interest for these purposes:",
			"featureTitle": "For some of the purposes above we and our partners:",
			"specialFeatureTitle": "For some of the purposes above we and our partners:"
		},
		"purposes": {
			"title": "Find out more about how your personal data is processed and set your preferences below.",
			"content": "You can set your consent preferences and determine how you want your data to be used based on the purposes below. You may set your preferences for us independently from those of third-party partners. Each purpose has a description so that you know how we and partners use your data.",
            "privacy_policy_text": "Check our privacy policies",
			"privacy_policy_url": "https://ourcompany.com/privacypolicies"
		},
		"vendors": {
			"title": "See the partners we work with below. Expend each one to see how they process your data.",
			"content": "You can set consent preferences for individual third-party partners we work with below. Expand each company list item to see what purposes they use data for to help make your choices. In some cases, companies may use your data without asking for your consent, based on their legitimate interests. You can click on their privacy policy links for more information and to object to such processing.",
			"privacyPolicyText": "Privacy Policy",
			"legIntClaimTitle": "Legal policies",
			"deviceStorageTitle": "Storage Type:",
			"deviceStorageCookieLifetime": "Cookie lifetime: ",
			"deviceStorageOther": "Others",
			"deviceStorageCookies": "Cookies",
            "googleVendorsDef" : "Google Ad Technology Providers",
            "domainsDef" : "Domain list", 
            "IABVendorsDef" : "IAB TCF Vendors"
		},
		"others": {
			"title_purpose": "Other categories EN",
			"title_vendors": "Other vendors EN"
		}
	},
	"texts_fr": {
		"generic": {
			"saveButton": "J'accepte",
			"detailButton": "Détail",
			"acceptAllButton": "Tout Accepter",
			"refuseAllButton": "Tout Refuser",
			"vendorButton": "Afficher les partenaires",
			"purposeButton": "Afficher les finalités",
			"legalButton": "Informations légales",
            "illustationsButton": "illustrations",
			"backButton": "Retour",
			"purposeDef": "Finalités",
			"consentDef": "Consentement",
			"legIntPurposeDef": "Intérêts légitimes",
			"flexiblePurposeDef": "Finalités flexibles",
			"specialPurposeDef": "Finalités spéciales",
			"featureDef": "Fonctionnalités",
			"specialFeatureDef": "Fonctionnalités spéciales",
            "dataCategoriesDef" : "Categories de Data",
			"partnersLinkText": "nos partenaires",
			"relatedVendorsButton": "Voir les partenaires",
			"month": "mois",
			"day": "jours",
			"seconds": "secondes",
			"hours": "heures"
		},
		"popup": {
			"title": "Le respect de votre vie privée est notre priorité",
			"content": "Nous et nos {total_number} partenaires pouvons stocker et/ou accéder à des informations sur un terminal, sélectionner des publicités standard, créer un profil personnalisé de publicités, sélectionner des publicités personnalisées, mesurer la performance des publicités, mesurer la performance du contenu, exploiter des études de marché afin de générer des données d’audience, développer et améliorer les produits, créer un profil pour afficher un contenu personnalisé, sélectionner du contenu personnalisé, mesurer la performance des publicités, exploiter des études de marché afin de générer des données d’audience, développer et améliorer les produits, sélectionner des publicités standard, mesurer la performance du contenu, créer un profil personnalisé de publicités, sélectionner des publicités personnalisées, créer un profil pour afficher un contenu personnalisé, sélectionner du contenu personnalisé. Ces technologies peuvent traiter des données personnelles comme l'adresse IP et les données de navigation pour assurer la sécurité, prévenir la fraude et déboguer, diffuser techniquement les publicités ou le contenu. Elles peuvent mettre en correspondance et combiner des sources de données hors ligne, recevoir et utiliser des caractéristiques d’identification d’appareil envoyées automatiquement, relier différents terminaux. Elles peuvent analyser activement les caractéristiques du terminal pour l’identification, utiliser des données de géolocalisation précises.\n",
			"purposeTitle": "Gérer vos préférences",
			"specialPurposeTitle": "Gérer vos special purposes",
			"featureTitle": "Gérer vos features ",
			"specialFeatureTitle": "Gérer vos specialFeatures"
		},
		"purposes": {
			"title": "Gérer vos préférences P",
			"content": "Nos partenaires P et nous déposons des cookies afin d'assurer la sécurité, améliorer votre expérience digitale et afficher des publicités et contenus personnalisés Vous pouvez accepter ou refuser ces différentes opérations.",
			"privacy_policy_text": "Notre politique de confidentialitée",
			"privacy_policy_url": "https://ourcompany.com/privacypolicies"
		},
		"vendors": {
			"title": "Gérer vos préférences V",
			"content": "Nos partenaires V et nous déposons des cookies afin d'assurer la sécurité, améliorer votre expérience digitale et afficher des publicités et contenus personnalisés Vous pouvez accepter ou refuser ces différentes opérations.",
			"privacyPolicyText": "Politique de confidentialité",
			"deviceStorageTitle": "Type de stockage:",
			"legIntClaimTitle": "Legal policies" 
			"deviceStorageCookieLifetime": "Durée du cookie: ",
			"deviceStorageOther": "Autres",
			"deviceStorageCookies": "Cookies",
            "googleVendorsDef" : "Partenaires Google Ad Technology",
            "domainsDef" : "liste des domaines utilisés", 
            "IABVendorsDef" : "liste des partenaires IAB"
		},
		"others": {
			"title_purpose": "Other categories FR",
			"title_vendors": "Other vendors FR"
		}
	},
	"categories": [{
			"name": "Statistics",
			"ID": "1",
			/* Ajouter "isMandatory": "true" pour bloquer la category sur ON 
			   If you are using sub-categories, only sub can be marked as mandatories */
			"isMandatory": "true",
			"related_vendors": [1],
			"description": "These cookies allow us analyze user behavior on the site, measure and improve performance and the quality of our service."
		},
		{
			"name": "Advertising",
			"ID": "2",
			"related_vendors": [2],
			"description": "These cookies allow us display adverts matching your interests on the websites you visit."
		},
		{
			"name": "Big category",
			"ID": "30",
			"description": "Here you can select the vendors.",
			"subcategories": [{
					"name": "GA",
					"ID": "31",
					"description": "Should we send information to GA."
				},
				{
					"name": "Xiti",
					"ID": "32",
					"description": "Should we send information to AT Internet."
				},
				{
					"name": "Vendor3",
					"ID": "33",
					"related_vendors": [1, 2],
					"description": "Should we send information to this vendor3."
				}
			]
		}
	],
	"vendors": [{ /* list here all the not IAB Vendors */
			"name": "Commanders Act",
			"ID": "1",
			"description": "Allow Commanders Act",
			"privacy_policy": "http://commandersact.com/privacypolicy"
		},
		{
			"name": "Another non IAB Vendor",
			"ID": "2",
			"description": "The desc of another vendor",
			"privacy_policy": "http://anothervendor.free.fr/privacypolicy"
		}
	],
	"categories_fr": [{
			"name": "Statistiques",
			"ID": "1",
			"related_vendors": [1],
			"description": "Avec cette catégorie on remonte les stats."
		},
		{
			"name": "Pub",
			"ID": "2",
			"related_vendors": [2],
			"description": "Pour afficher de superbes pubs personalisées"
		},
		{
			"name": "Super cat",
			"ID": "30",
			"description": "Une super cat.",
			"subcategories": [{
					"name": "Sous cat 1",
					"ID": "31",
					"description": "Mais on peut choisir que cette sous cat."
				},
				{
					"name": "Sous cat 2",
					"ID": "32",
					"description": "Ou alors uniquement celle-ci."
				},
				{
					"name": "Sous cat 3",
					"ID": "33",
					"related_vendors": [1, 2],
					"description": "Ou plus en fait, mais la 3 c'est pareil."
				}
			]
		}
	],
	"vendors_fr": [{
			"name": "Commanders Act",
			"ID": "1",
			"description": "Permettre à Commanders Act d'envoyer des informations",
			"privacy_policy": "http://commandersact.com/privacypolicy"
		},
		{
			"name": "Autre Vendors",
			"ID": "2",
			"description": "Permettre à cet autre vendor d'envoyer pleins d'informations",
			"privacy_policy": "http://anothervendor.free.fr/privacypolicy"
		}
	]
}

The value {total_number} in the "purposeTitle" is a dynamic field. The total number of your IAB vendors will be displayed here

The deadline to migrate is November 20, 2023

IAB TCF V2.2 Consent

Description of how to interact with IAB consent API

If you are using IAB TCF option (see this page to setup IAB TCF on your account), you will be able to use IAB TCF's __tcfapi where your privacy banner is deployed.

That function is defined in your container and in your privacy banner so that you can use it before your privacy banner has finished loading. It is sometimes referred by IAB as the TCF API stub.

IAB TCF consent is encoded in a format called the Consent-String.

How to use the TCF API

The recommended way of getting the value of TCF's consent-string (tcData.tcString in the example below) is by using the addEventListener command.

__tcfapi('addEventListener', 2, (pingReturn, success) =>{
 if(success &&
    (pingReturn.eventStatus === 'tcloaded' || pingReturn.eventStatus === 'useractioncomplete')) {
 
    // do something with pingReturn.tcString

  } else {

    // do something else

  }
});

Sometimes you do not want to be notified of consent updates. You can achieve this by using the more advanced code below:

__tcfapi('addEventListener', 2, function(pingReturn, success) {
  if(success &&
    (pingReturn.eventStatus === 'tcloaded' || pingReturn.eventStatus === 'useractioncomplete')) {

    // do something with pingReturn.tcString

    // remove ourselves to not get called more than once
    __tcfapi('removeEventListener', 2, pingReturn.listenerId);

  } else {

    // do something else

  }
});
  • Reference: IAB TCF commands

How to decode the Consent-String

You can use this copy-paste a Consent-String on this page: https://iabtcf.com/#/decode.

  • Reference: IAB TCF Consent-String format

Google Additional Consent Mode

This an optional extension to IAB TCF. Once setup in Consent Management Settings, an additional addtlConsent property will be available on the tcData object.

__tcfapi('addEventListener', 2, function(pingResult, success) {
  if(success &&
    (pingResult.eventStatus === 'tcloaded' || pingResult.eventStatus === 'useractioncomplete')) {

    // do something with pingResult.addtlConsent

  } else {

    // do something else

  }
});
  • Reference: Google Additional Consent Mode Technical Specification

IAB TCF V2.2 and Google FAQ

Google is a TCF 2.0 member, and Google Ad Manager (GAM), Adsense, and Admob can use the IAB TCF API to get the user consent status (the TC string) from Commanders Act CMP.

How to enable Google ACM Vendors

To enable Google ACM vendors go to Data Governance > Consent Management > Settings and follow this instruction

Common issues encountered while using the TCF 2 to integrate with Google Advertising Products

GAM's recorded errors

GAM's recorded errors GAM displays an error message in your GAM Console if it is unable to collect a TC string from the CMP:

The specific errors found are detailed in a report, which you can compare to the GAM documentation in the Troubleshooting TCF 2 implementation post.

We've mentioned some of the most common error codes we've seen while integrating with GAM below.

1.x (1.1 or 1.2 or 1.3) : Google is not approved as a vendor regarding consent or legitimate interest. 1.x errors are to be anticipated, it's normal to expect a certain amount of these errors as they mean that the user has refused permission for Google, main Google purposes, or that you have publisher restrictions that prohibit Google from running.

The rate of negative consent for a given website or mobile app should be approximately matched by the 1.x errors.

Checklist for determining why 1.x errors are so common:

  1. Verify that your 1.x errors as a percentage of all ad requests are approximately equal to your negative consent rate (within a 5 points margin). For instance, if Commanders Act Consent Analysis reports a 90% consent rate per page view, a typical 1.x error rate is beetween 5% to15%.

  2. Examine whether the IAB TCF 2 was implemented on your website or mobile app prior to September 2020.

  3. Check to see if there are publisher restrictions. If so, make sure they don't affect Google or do so in a way that's compliant with Google's requirements : https://support.google.com/admanager/answer/9805023?hl=en.

Errors are found in the following ways:

1.1 Errors: Google is not permitted as a vendor along with consent or legitimate interest.

1.2 errors: For EEA countries and the UK, there is no consent for Purpose 1. Before determining whether or not the TC string causes an error, Google will always check whether Purpose 1 has permission before determining whether or not Google, as a vendor, is allowed.

Google ACM requires IAB TCF

New requirement for publishers from February 1st 2024: IAB TCF mandatory

Publishers using Google AdSense, Ad Manager, or AdMob must use a CMP certified by Google and must integrate the IAB’s TCF

In addition to the Google EU user consent policy, publishers and developers using Google AdSense, Ad Manager, or AdMob will be required to use a Consent Management Platform (CMP) that has been certified by Google and has integrated with the IAB's Transparency and Consent Framework (TCF) when serving ads to users in the European Economic Area or the UK.

source: https://support.google.com/adsense/answer/13554116

What needs to be done ? 3 situations

Commanders Act CMP provides you all the keys to be compliant with this new requirement. Depending on your configuration, you’ll fit into one of these use cases:

Situation #1
Situation #2
Situation #3

You already have

a TCF privacy banner

with Google Vendors?

You already use an IAB TCF banner template, but you have no Google ACM Vendors?

You don’t

currently use

an IAB TCF banner template

Status: You’re already compliant. Nothing to do

Status: You’re 3 steps away from being compliant. Follow the instructions below

Status: You’re 4 steps away from being compliant. Follow the instructions below

Step 1

Go on page: “Data Governance > Consent Management > Settings”

  • Situation #2: Activate the Google ACM option

  • Situation #3: Activate the IAB TCF Compliancy & the Google ACM options

Step 2

Go on page: “Data Governance > Consent Management > Vendors”

  • Situation #2 and #3 : Add your Google ACM Vendors

Step 3

Go on page: “Data Governance > Consent Management > Settings”

  • Situation #2: not required if you already have a TCF privacy banner with “Google Advertising Products Vendors”

  • Situation #3: Activate the IAB TCF Compliancy & the Google ACM options

Final Step

Go on page: “Sources > Privacy Banners”

  • Situation #2 and #3: • Select your banner, go on tab Generate & Deploy • Generate your new version of the privacy banner It’s ready to be deployed in production!

CCPA & Global Privacy control

Introduction to CCPA

The California Consumer Privacy Act of 2018 (CCPA) gives consumers more control over the personal information that businesses collect about them and the CCPA regulations provide guidance on how to implement the law. This landmark law secures new privacy rights for California consumers, including:

  • The right to know about the personal information a business collects about them and how it is used and shared;

  • The right to delete personal information collected from them (with some exceptions);

  • The right to opt-out of the sale or sharing of their personal information; and

  • The right to non-discrimination for exercising their CCPA rights.

In November of 2020, California voters approved Proposition 24, the CPRA, which amended the CCPA and added new additional privacy protections that began on January 1, 2023. As of January 1, 2023, consumers have new rights in addition to those above, such as:

  • The right to correct inaccurate personal information that a business has about them; and

  • The right to limit the use and disclosure of sensitive personal information collected about them.

Businesses that are subject to the CCPA have several responsibilities, including responding to consumer requests to exercise these rights and giving consumers certain notices explaining their privacy practices. The CCPA applies to many businesses, including data brokers.

Changes for CCPA in 2023 due to CPRA

It is required under CPRA to retain a minimum amount of data that is only essential for the organization to fulfill its requirements. In addition, businesses should not keep data for longer than necessary; if they do, a justification must be presented, and they must notify the user. The criteria to Comply with CPRA remained almost the same as in CCPA, but with a slight change:

  1. Businesses should comply if they obtain a revenue of more than $25 million or gain 50% from selling personal data.

  2. Businesses should comply if they process data of more than 100,000 users instead of 50,000.

The California Privacy Protection Agency was created to enforce the CPRA starting July 1, 2023. It is responsible for raising awareness about data privacy and ensuring that consumers’ rights are protected while implementing penalties on non-compliant entities.

For more information, please visit the official CCPA website https://oag.ca.gov/privacy/ccpa

As a Commanders Act customer, what should I'm supposed to do?

To to be compliant with CCPA, simply follow these steps:

  1. Create a dedicated ccpa banner: use the "footer with privacy center" template

    • Add your text about cookies: must list the categories of personal information businesses collect about consumers and the purposes for which they use the categories of information. Don't forget to integrate a link for your cookie policy.

    • Add a button with this exact text : “Do Not Sell My Personal Information” This button should Optout the user (value refuse all) or open a privacy center with one category “Personalized advertisement”. Please note: this category is a requirement (must contains all tags that can sell personal information).

    • Set your consent duration for at least 12 months

  2. Enable the Global Privacy Control option on your Commanders Act privacy banner

  3. Integrate in your website footer a link or a button to manage consent choices example of html code to integrate: <a href="#" onclick="tC.privacyCenter.showPrivacyCenter();return false">privacy center</a>

  4. Update your Privacy Policy: Businesses that sell personal information about California residents, or allow information to be collected on their websites or apps, need to provide information in their privacy policies about that collection or sale. The CA Attorney General has provided draft regulations on how and what information should be included in privacy policies, which you can find here.

  5. Add file "well-known.json" on your site Not mandatory, but recommended, GPC makes use of .well-known identifiers for sites to signal compliance with the GPC specification. The existence of this file indicates you are using GPC as part of your compliance with privacy laws. There may be a variety of tools available to implement the .well-known file on your site.

    The following is a basic example of how to specify a static folder and files for your site.

    First, create a folder called .well-known at the root of your site, so that the path is yoursite.com/.well-known/. Within this folder, create a file called gpc.json. The value of the file should then look something like this, with lastUpdate set to the date you last updated the file. { "gpc": true, "lastUpdate": "2025-04-20" } This will give you a valid GPC file which states that you comply with the GPC in the context in which you understand it. Adopters will usually supplement the .well-known file with a statement in their privacy policy that explains exactly how they interpret the GPC within their own systems. The exact message in your privacy policy is up to you and may require review by your legal team.

What is Global Privacy Control ?

The Global Privacy Control is an initiative aimed at enabling users to easily exercise their privacy preferences across multiple websites and online services. It is designed to give users more control over how their personal information is collected, used, and shared online.

The GPC operates through a browser signal or an HTTP header that users can activate to indicate their privacy preferences. When a user enables the GPC signal in their browser, it sends a request to websites and online services, indicating that the user wishes to opt out of the sale or sharing of their personal information.

For more information, you can visit their website

How to enable the Global Privacy Control ?

Simply follow these 2 easy steps:

1 - Enable on the option Global Privacy Control directly on your CCPA Banner

Sources > Privacy Banners > Settings

2- Regenerate and Deploy your Consent Banner

Sources > Privacy Banners > Generate

3 - Verify your setup! You can use a dedicated GPC plugin to check your implementation

Rest Data API

GET/PUT Consents / preferences

Get/put user consent stored in DataCommander

User Consents

GET https://api.commander1.com/engage/user/

This endpoint allows you to get categorie's consent for one specific user

Query Parameters

Name
Type
Description

token

string

Security token

user_id

string

ID of the user

site

integer

ID of the site

{
    "user_privacy_optin": 1,
    "user_privacy_categories": [
      "11",
      "12",
      "13"
    ]
}
{
    "message": "Person not found"
}

Visitor Consents

GET https://api.commander1.com/v1.0/engage/visitors/

This endpoint allows you to get categorie's consent for one specific visitor

Query Parameters

Name
Type
Description

callback

string

(optional) Callback for jsonp request

token

string

Security token

site

integer

ID of the site

tc_id

String

Optional. Cookie id of the user

{
    "user_privacy_optin": 1,
    "user_privacy_categories": [
      "11",
      "12",
      "13"
    ]
}
{
    "user_privacy_optin": 0,
    "user_privacy_categories": []
}
{
    "message": "visitor not found"
}

User

PUT https://api.commander1.com/engage/user/

Insert or update a preference in the database (require to have the DataCommander module activated)

Query Parameters

Name
Type
Description

site

string

Id of the site (account)

user_id

string

Id of the user. Required if tc_id parameter is not set

token

string

Security token

{"success":true}

Syntax and limitations

  • The json playload is represented by a key/value for each preference.

  • Each preference property (key) start with "preferences." followed by the preference name : preferences.your_preference_name

  • The preference name should not contain white space, dot or special characters. Its format is [A-Za-z0-9_-]

  • The preference value can contain white space, dot but not special characters.

  • The API accepts a maximum of 20 preferences

Example Request

PUT

https://api.commander1.com/engage/user/?site=1234&user_id=1234&token=WvNIX8955cnZ7WF0f632s0Wb99Ql3rtA

{
  "preferences": {
    "news_monthly": true,
    "news_sales": true
  }
}

OnSite API

Getting Started

Overview on the Commanders Act Consent OnSite API.

The Commanders Act Consent API is used to interact with Commanders Act Consent with JavaScript. It currently only offers methods to receive and update consent, but it will be improved with additional methods in the future.

API Stub

It is necessary to install a JavaScript stub before any of the OnSite API methods can be used. The stub is used to buffer all methods in a JavaScript array until Commanders Act consent banner JavaScript is loaded and ready to process the methods. This allows to use the OnSite API before Commanders Act Consent Banner (JavaScript file) was loaded.

window.caReady = window.caReady || []; 
window.cact = function() { window.caReady.push(arguments); };

window.caReady is a JavaScript array that buffers the interactions with the API. window.cact is a JavaScript function used to interact with the OnSite API.

In case you work in a big team and are unsure the stub was already installed it is ok to install the JavaScript stub multiple times.

Methods

After installing the stub it is then possible to use any of the OnSite API methods via the window.cact function.

The available methods are listed in the documentation under ONSITE API.

Each method follows a strict signature:

cact(command, [options,] [callback])

Argument

Descriptions

Required

command

A string identifier used to select the desired method.

Required

options

A JavaScript object that includes data passed to the method.

Optional

callback

A JavaScript callback function that is used to receive information or events from the OnSite API.

Optional

Below you will find an example method that is used to receive the Commanders Act consent status with the OnSite API. This example only provides a callback to receive the consent without providing any options.

cact('consent.get', function (result) {
    
    if (result.consent.status === "all-on") {
        
        // Consent available for all categories.
        
    }
    
});

The OnSite API methods are called asynchronously. In case e.g. you need information synchronous in the <head> of the document it is recommended to cache and retrieve the result of the API in localStorage.

consent.get

Method to receive Commanders Act consent and consent metadata OnSite via JavaScript.

The Commanders Act OnSite API stub has to be installed before using any of the OnSite API functions.

cact('consent.get', function (result) { ... });

The consent.get method takes one callback JavaScript function as an argument that gets called with the Consent Object that is currently stored on the browser. The callback is called once after Commanders Act CMP JavaScript loaded and validated the stored consent.

The OnSite API works asynchronous. In case you need the consent synchronous (e.g. in the <head> of a document for AB Testing or personalisation solutions) it is recommended to cache the object in the localStorage of the browser. In this case it is crucial to implement the consent.onUpdate method to keep the cached consent in sync.

Examples

Executing code based on the consent setting of a category

In this example the Analytics category was configured with the consent category id 2 in Commanders Act banner.

cact('consent.get', function (result) {

   var ANALYTICS_ID = 2;
   var analyticsCategory = result.consent.categories[ANALYTICS_ID] || {};
   
   if (analyticsCategory.status === 'on') {
         
      // Consent was provided for the category. 
      
   } else {
      
      // Consent was not provided for the category.
   
   }
        
});

Executing code based on the consent setting of a category and vendor

In this example the Analytics category was configured with the consent category id 2 and the vendor Google with vendor id 5 in Commanders Act CMP.

cact('consent.get', function (result) {
   
   var ANALYTICS_ID = 2;
   var analyticsCategory = result.consent.categories[ANALYTICS_ID] || {};

   var GOOGLE_ID = 5;
   var googleVendor = result.consent.vendors[GOOGLE_ID] || {};
   
   if (analyticsCategory.status === 'on' && googleVendor.status === 'on') {
         
      // Consent was provided for the category. 
      
   } else {
      
      // Consent was not provided for the category.
   
   }
        
});

Check if consent was already set by the visitor

cact('consent.get', function (result) {
   
   if (result.consent.status === 'unset') {
         
      // Consent was not yet provided.
      
   } else {
      
      // Consent was accepted or refused.
   
   }
        
});

Checking when the current consent expires

cact('consent.get', function (result) {

    var dateExpires = result.meta.dateExpires;
                
});

consent.update

Method to update Commanders Act consent status OnSite via JavaScript.

The Commanders Act OnSite API stub has to be installed before using any of the OnSite API functions.

cact('consent.update', consentObject)

The consent.update method allows to update the consent with JavaScript. It has to be called with a Consent Object that includes the updated settings. Commanders Act will deep merge the status fields of the current Consent Object with the provided object and automatically update all meta properties and the consent.status property automatically. In case a consent.status field is provided with value all-on, all-off or unset all other updates are ignored and all categories and vendor settings will be set to on, off or unset accordingly.

All not configured categories and vendors are ignored when deep-merging the consent objects.

Examples

Update categories and vendors

cact('consent.update', {
    categories: {
        '2': { status: 'on' }
    },
    vendors: {
        '1': { status: 'on' }
    }
});

Below you can see how the Consent Object is affected by this update.

/* Consent Object Before Update
{
    meta: { ... },
    consent: {
        status: "mixed",
        categories: {
            "1": { status: "on" },
            "2": { status: "off" }
        },
        vendors: {
            "1": { status: "off" },
            "2": { status: "on"}
        }     
    }
}
*/

// Update
cact('consent.update', {
    categories: {
        '2': { status: 'on' }
    },
    vendors: {
        '1': { status: 'on' }
    }
});

/* Consent Object After Update
{
    meta: { ... }, // automatically updated
    consent: {
        status: "all-on", // automatically updated
        categories: {
            "1": { status: "on" },
            "2": { status: "on" } // updated
        },
        vendors: {
            "1": { status: "on" }, // updated
            "2": { status: "on"}
        }     
    }
}
*/

Update IAB TCF/ACM categories and vendors

cact('consent.update', {
    categories: {
        '1': { // non-IAB category
            status: 'on' 
        },
        'tcf2_1': { // TCF purpose 1
            status: 'on' // no legintStatus for purpose 1
        },
        'tcf2_2': { // TCF purpose 2
            status: 'off',
            legIntStatus: 'on'
        },
        'tcf2_sf_1': { // TCF special feature 1
            status: 'on'
        }
    },
    vendors: {
        'tcf2_1': { // TCF vendor 1
            status: 'on',
            legIntStatus: 'off'
        },
        'tcf2_2': { // TCF vendor 2
            status: 'on',
            legIntStatus: 'on'
        },
        'acm_1': { // ACM vendor 1
            status: 'on'
        }
    }
});

Accept all categories and vendors

cact('consent.update', { 
    status: 'all-on'
});

Specifying a category or vendor will not have any effect.

cact('consent.update', { 
    status: 'all-on', 
    categories: {
        '2': { status: 'unset' } // ignored as global status is specified
    }
});

Below you can see how the Consent Object is affected by this update.

/* Consent Object Before Update
{
    meta: { ... },
    consent: {
        status: "unset",
        categories: {
            "1": { status: "unset" },
            "2": { status: "unset" }
        },
        vendors: {
            "1": { status: "unset" },
            "2": { status: "unset"}
        }     
    }
}
*/

// Update Method
cact('consent.update', { 
    status: 'all-on'
});

/* Consent Object After Update
{
    meta: { ... }, // automatically updated
    consent: {
        status: "all-on",
        categories: {
            "1": { status: "on" }, // automatically updated
            "2": { status: "on" } // automatically updated
        },
        vendors: {
            "1": { status: "on" }, // automatically updated
            "2": { status: "on"} // automatically updated
        }     
    }
}
*/

Refuse all categories and vendors

cact('consent.update', { 
    status: 'all-off'
});

Specifying a category or vendor will not have any effect.

cact('consent.update', { 
    status: 'all-off', 
    categories: {
        '2': { status: 'on' } // ignored as global status is specified
    }
});

Below you can see how the Consent Object is affected by this update. Note: required categories are not affected.

/* Consent Object Before Update
{
    meta: { ... },
    consent: {
        status: "mixed",
        categories: {
            "1": { status: "on" },
            "2": { status: "off" },
            "3": { status: "on", required: true }
        },
        vendors: {
            "1": { status: "on" },
            "2": { status: "on"}
        }     
    }
}
*/

// Update Method
cact('consent.update', { 
    status: 'all-off'
});

/* Consent Object After Update
{
    meta: { ... }, // automatically updated
    consent: {
        status: "all-off",
        categories: {
            "1": { status: "off" }, // automatically updated
            "2": { status: "off" }, // automatically updated
            "3": { status: "on", required: true } // unchanged
        },
        vendors: {
            "1": { status: "off" }, // automatically updated
            "2": { status: "off"} // automatically updated
        }     
    }
}
*/

Specify update action

You can specify an action inside the update parameters:

cact('consent.update', {
    action: 'banner_button',
    categories: {
        '2': { status: 'on' }
    },
    vendors: {
        '1': { status: 'on' }
    }
});

This action value will be used to compute your dashboard metrics. If it is omitted, the default value is banner_button.

The allowed values are:

  • banner_button

  • pc_save

  • page_click

  • scroll

  • browse

Additionally, the following values are allowed for optout only (status: 'all-off' ):

  • banner_cross

consent.revoke

Method to revoke Commanders Act consent OnSite via JavaScript.

The Commanders Act OnSite API stub has to be installed before using any of the OnSite API functions.

cact('consent.revoke')

consent.revoke is called with no options and no callback function. It resets the consent, consent id and initiates two consen.onUpdate events, one with the updateEvent set to changed, and a second one set torevoked that allows to perform cleanup tasks like removing cookie identifiers.

consent.onUpdate

Method to subscribe to Commanders Act consent status updates OnSite via JavaScript.

Method to subscribe to Commanders Act consent updates OnSite via JavaScript.The Commanders Act OnSite API stub has to be installed before using any of the OnSite API functions.

cact('consent.onUpdate', function (result) { ... })

The consent.onUpdate method allow to subscribe a callback function for consent updates. The callback function will be called with the updated Consent Object. It is called whenever the consent is changed via a Commanders Act banner interaction or the consent.update method of the OnSite API.

The consentObject argument will also be enriched with an additional property updateEvent to signal how the update happened. It can have following values:

Value

Description

set

The consent was set.

changed

Consent was already established and then changed.

revoked

Consent was revoked by the user. Used for cleanup tasks like deleting cookie identifiers.

When consent is revoked it fires two events: One changed followed by one revoked.

Examples

Example to react to consent changes of a specific category

In this example the Analytics category was configured with the consent category id 2 in Commanders Act Consent settings.

cact('consent.onUpdate', function (result) { 
    
    var ANALYTICS_ID = 2;
    var analyticsCategory = result.consent.categories[ANALYTICS_ID] || {};
     
    if (analyticsCategory.status === 'on') {
    
        // Consent was provided for the category. 
    
    } else {
        
        // Consent was not provided for the category. 
           
    }
    
});

Example only react to consent changes of a specific category after the initial consent was given

In this example the Analytics category was configured with the consent category id 2 in TrustCommander.

cact('consent.onUpdate', function (result) { 

    var ANALYTICS_ID = 2;
    var analyticsCategory = result.consent.categories[ANALYTICS_ID] || {};

    if (result.updateEvent === "changed" && analyticsCategory.status === 'on') {
    
        // Consent was provided for the category during an update.
    
    } 
    
});

consent.onReady

Method to obtain Commanders Act consent when it becomes available.

Method to obtain consent when it becomes available.The Commanders Act OnSite API stub has to be installed before using any of the OnSite API functions.

cact('consent.onReady', function (result) { ... })

The consent.onReady method allow to subscribe a callback function for when consent is set. The callback function will be called only once, with the updated Consent Object. It is called whenever the consent is set via a consent banner interaction or when a consent cookie is already set.

Like in the command consent.onUpdate, the consentObject argument will be enriched with the property updateEvent, but only with the value 'set'.

Example

Example to wait for consent availability and do something on a specific category

In this example, the code is waiting for the user's interaction with the consent banner. The Analytics category was configured with the consent category id 2 on privacy banner.

cact('consent.onReady', function (result) { 
    
    var ANALYTICS_ID = 2;
    var analyticsCategory = result.consent.categories[ANALYTICS_ID] || {};
     
    if (analyticsCategory.status === 'on') {
    
        // Consent was provided for the category. 
    
    } else {
        
        // Consent was not provided for the category. 
           
    }
    
});

At the container level, consent.onReady cannot work with a blocked on category. The blocked on categories are defined in the banner. For this specific usage, we recommend to use the consent.get method

consentBanner.show

JavaScript method to display your consent banner.

The command consentBanner.show allows to redisplay the consent banner for specific reasons. Simply use the following Javascript method:

cact('consentBanner.show')

This command allows you to display the consent banner after the user consent is given

consentBanner.hide

JavaScript method to hide your consent banner.

The command consentBanner.hideallows to hide the consent banner for specific reasons. Simply use the following Javascript method:

cact('consentBanner.hide')

consentCenter.show

JavaScript method to display your consent center (consent categories menu).

The command consentCenter.show allows to redisplay the consent center for specific reasons. Simply use the following Javascript method:

cact('consentCenter.show')

This command allows you to display the consent center after the user consent is given

consentCenter.hide

JavaScript method to hide your consent center (consent categories menu).

The command consentCenter.hide allows to hide the consent center for specific reasons. Simply use the following Javascript method:

cact('consentCenter.hide')

Platform API

Get statistics

Get data from the consent dashboard (aggregated data)

Get Statistics

GET https://api-internal.commander1.com/v2/{siteId}/privacy/statistics

This endpoint allows you to get the data from the consent dashboard on a specific date range

Path Parameters

Name
Type
Description

{siteId} (*required)

string

Account ID example: '12345'

Query Parameters

Name
Type
Description

filter[sup_filters][location][]

integer

Data inside and outside of the EU 0 : Out of EU 1 : EU

filter[sup_filters][device][]

integer

Typical device types 0 : others 1 : mobile 2 : tablet 3 : desktop

token (*required)

string

Authentication token. Optional if the header "Authorization' parameter is used instead.

filter[begin_date] (*required)

string

example: '2021-04-30'

filter[end_date] (*required)

string

example: '2021-04-31'

{
    "data": [
        {
            "type": "privacy/statistic",
            "id": "1",
            "attributes": {
                "nb_banner_views": 198,
                "nb_banner_clicks_button": 32,
                "nb_optin": 34,
                "nb_optin_all": 33,
                "nb_optin_all_on_click_banner": 23,
                "nb_banner_clicks_links_not_PC": 1,
                "nb_PC_views": 1,
                "nb_optin_all_on_browsing": 10,
                "optin_rate": 0.1717171717171717,
                "optout_rate": 0,
                "nb_optin_category_1": 35,
                "optin_rate_category_1": 0.17676767676767677,
                "nb_optin_category_2": 35,
                "optin_rate_category_2": 0.17676767676767677,
                "nb_optin_category_3": 35,
                "optin_rate_category_3": 0.17676767676767677,
                "nb_optin_category_4": 35,
                "optin_rate_category_4": 0.17676767676767677,
                "nb_optin_category_5": 14,
                "optin_rate_category_5": 0.0707070707070707,
                "nb_optin_category_10001": 7,
                "optin_rate_category_10001": 0.03535353535353535,
                "nb_optin_category_10003": 7,
                "optin_rate_category_10003": 0.03535353535353535,
                "nb_optin_category_10005": 7,
                "optin_rate_category_10005": 0.03535353535353535,
                "nb_optin_category_10007": 7,
                "optin_rate_category_10007": 0.03535353535353535,
                "nb_optin_category_10009": 7,
                "optin_rate_category_10009": 0.03535353535353535,
                "nb_optin_category_10011": 7,
                "optin_rate_category_10011": 0.03535353535353535,
                "nb_optin_category_10013": 7,
                "optin_rate_category_10013": 0.03535353535353535,
                "nb_optin_category_10015": 7,
                "optin_rate_category_10015": 0.03535353535353535,
                "nb_optin_category_10017": 7,
                "optin_rate_category_10017": 0.03535353535353535,
                "nb_optin_category_10019": 7,
                "optin_rate_category_10019": 0.03535353535353535,
                "nb_optin_category_13001": 7,
                "optin_rate_category_13001": 0.03535353535353535,
                "nb_optin_category_13003": 7,
                "optin_rate_category_13003": 0.03535353535353535
            }
        },
        {
            "type": "privacy/statistic",
            "id": "20",
            "attributes": {
                "nb_PC_views": 1,
                "optin_rate": 0,
                "optout_rate": 0
            }
        }
    ]
}
{
    "errors": [
        {
            "status": 401,
            "title": "Unauthenticated.",
            "detail": "The access token provided is expired, revoked, malformed, or invalid.",
            "context": []
        }
    ]
}
https://api-internal.commander1.com/v2/siteId/privacy/statistics?token=XXXXXX&filter%5Bbegin_date%5D=YYYY-MM-DD&filter%5Bend_date%5D=YYYY-MM-DD&filter%5Bsup_filters%5D%5Bdevice%5D%5B%5D=1&filter%5Bsup_filters%5D%5Blocation%5D%5B%5D=0&filter%5Bsup_filters%5D%5Blocation%5D%5B%5D=1

How to get the token

For each API, you'll have to ask a token to your account manager or support team.

How to use additional parameters

Device filters &filter[sup_filters][device][]=2&filter[sup_filters][device][]=3&filter[sup_filters][device][]=0 1 = Mobile 2 = Tablet 3 = Desktop 0 = Others (in the example above, mobile device is excluded) Location filters &filter[sup_filters][location][]=0 1 = EU 0 = Out of EU (in the example above, EU user's location is excluded)

Result example

{
    "data": [{
        "type": "privacy\/statistic",
        "id": "2",
        "attributes": {
            "nb_visitors_exposed_to_privacy": 11448,
            "nb_banner_views": 11445,
            "nb_banner_clicks_button": 10478,
            "nb_PC_views": 1863,
            "nb_PC_vendor_views": 100,
            "nb_PC_clicks_save": 1089,
            "nb_optin_PC_save": 373,
            "nb_optin": 8724,
            "nb_explicit_optin": 8776,
            "nb_optout": 2769,
            "nb_optout_on_click_banner": 2075,
            "optin_rate": 0.7620545073375262,
            "optout_rate": 0.2418763102725367,
            "nb_optin_category_1": 8718,
            "optin_rate_category_1": 0.7615303983228512,
            "nb_optin_category_3": 8708,
            "optin_rate_category_3": 0.7606568832983928,
            "nb_optin_category_5": 8708,
            "optin_rate_category_5": 0.7606568832983928
           
        }
    }, {
        "type": "privacy\/statistic",
        "id": "4",
        "attributes": {
            "nb_visitors_exposed_to_privacy": 17623,
            "nb_banner_views": 17618,
            "nb_banner_clicks_button": 15029,
            "nb_PC_views": 2377,
            "nb_PC_vendor_views": 465,
            "nb_PC_clicks_save": 1917,
            "nb_optin_PC_save": 713,
            "nb_optin": 13280,
            "nb_explicit_optin": 13460,
            "nb_optout": 3484,
            "nb_optout_on_click_banner": 2282,
            "optin_rate": 0.7535606877376156,
            "optout_rate": 0.19769619247574194,
            "nb_optin_category_1": 13331,
            "optin_rate_category_1": 0.7564546331498609,
            "nb_optin_category_3": 13318,
            "optin_rate_category_3": 0.7557169607898768,
            "nb_optin_category_5": 13302,
            "optin_rate_category_5": 0.7548090563468195,
            "nb_optin_category_7": 13303,
            "optin_rate_category_7": 0.7548658003745106,
            "nb_optin_category_9": 13308,
            "optin_rate_category_9": 0.755149520512966
        }
    }]
}