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 TrustCommander 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 TrustCommander, setup guides per platform, user guides per feature and a knowledge base for frequently asked questions.

Components

TrustCommander consists of following components:

Frameworks

TrustCommander supports following frameworks:

• IAB TCF 2.0

• Google ACM

Extensions

It is possible to extend TrustCommander with following modules:

Setup

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

This documentation is deprecated

Please refer to this page

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.

TrustCommander 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 TrustCommander setup.

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

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

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

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

5. Implement TrustCommander tag (see below)

6. Manage Adobe Launch tags with TrustCommander (see below).

Implement TrustCommander tag on website and inside Adobe Launch.

1 - Website configuration

Delay your Adobe container

TrustCommander creates the consent variables when the privacy javascript file is loaded. You have to delay your Adobe container until TrustCommander 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 TrustCommander 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 TrustCommander is ready Add the TrustCommander 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 TrustCommander is loaded and gets the consent, a variable tcCategoriesConsent is created by TrustCommander 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.

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.

TrustCommander can be directly integrated with websites. The setup requires technical installation steps.

Setup

Following you will find the required steps to implement a standard TrustCommander setup.

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

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

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

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

5. Install TrustCommander tag (see below)

6. Manage onsite tags with TrustCommander (see below).

Install TrustCommander tag

To hardcode TrustCommander on websites you need to add following JavaScript tag 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 TrustCommander

Add tag triggers

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

This TrustCommander 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 TrustCommander.

{{ category_or_subcategory_id }} has to be replaced with the category or sub-category of the TrustCommander 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 TrustCommander category named "Retargeting".

Retargeting was assigned to sub-category ID 6. In case a sub-category is used you should never use the main category (4 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>

TrustCommander provides a plug-in to integrate with Google Tag Manager. The setup requires technical installation steps.

This method to integrate GTM is outdated. See the page “Consent Mode in GTM” for a smoother integration.

Setup

Following you will find the required steps to implement a standard TrustCommander setup.

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

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

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

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

5. Install TrustCommander tag (see below)

6. Manage GTM tags with TrustCommander (see below).

Install TrustCommander tag

To install TrustCommander with Google Tag Manager you need to add following JavaScript tag to your website. This snippet can be added in the <head> of the website or via a custom HTML tag in Google Tag Manager.

<script type="text/javascript">
    var tCPrivacyTagManager = "gtm";
</script>
<script type="text/javascript" src="{{ privacy_tag_url }}"></script>

tCPrivacyTagManager hast to be set to "gtm". This variable allows TrustCommander to send privacy settings to GTM. It will push a tcConsentChanged event to the GTM data layer that includes the privacy settings of a visitor in the tcCategoriesConsent variable. The event is pushed as soon as TrustCommander loads on a page and in case a visitor updates his privacy settings.

{{ 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 GTM tags with TrustCommander

Add tag triggers in Google Tag Manager

Setup Consent Changed Trigger

Create a new Trigger for each TrustCommander category and sub-category. These trigger can then be used to only fire your tags when a visitor accepts a certain TrustCommander category. Create each trigger with following settings:

Call the Privacy banner

There are 4 steps to add triggers to tags in Google Tag Manager (GTM).

Setup Consent Variable

In the GTM interface, "Variables" tab, create a custom variable to calculate the status of the consent given by the user: no consent, optout, optin or partially optin. Create a "User Defined" variable.

• Variable name: tcCategoriesConsent (the name that will appear in your interface, so you can choose another name)

• Variable Type: "Data Layer Variable"

• Data Layer Variable Name: tcCategoriesConsent (the variable used by Commanders Act Privacy when you add tCPrivacyTagManager = "gtm" in the website’s source code)

• Data Layer version: choose the latest data layer version available

function(){
    if (typeof tC.privacy == "undefined") {

        var cookieName = "TC_PRIVACY=";
        var cookieSeparator = "@"

        var privacyCookie = "";
        var cookieCategoryName = cookieName+"_CENTER=";
        var cookieData = null;
        var categories = null;
        var decodedCookie = decodeURIComponent(document.cookie);
        var ca = decodedCookie.split(';');

        for (var i = 0; i <ca.length; i++) {
            var c = ca[i];
            while (c.charAt(0) == ' ') {
                c = c.substring(1);
            }
            if (c.indexOf(cookieName) == 0) {
                privacyCookie = c.substring(cookieName.length, c.length);
            } else if (c.indexOf(cookieCategoryName) == 0) {
                categories = c.substring(cookieCategoryName.length, c.length);
            }
        }

        if (privacyCookie === "") {
            return "no_consent";
        } else if (privacyCookie) {
            cookieData = privacyCookie.split(cookieSeparator);
        } else {
            cookieData = [];
        }

        var optType = parseInt(cookieData[0] || 0);

        if (categories == "ALL") {
            if (optType === 1) {
                return "optout";
            } else {
                return "all_consent";
            }
        }

        return optType === 0 && categories != -1 ? categories : "optout";
    }

    if (tC.getCookie(tC.privacy.getCN()) === "")  {
        return "no_consent";
    } else if (tC.privacy.getOptinCategories().join(",") === ""){
        return "optout";
    } else {
        return tC.privacy.getOptinCategories().join(",");
    }
}

Configure the trigger as follows:

• Trigger name: Retargeting category (this name depends on the category names that you create and the name that you want to be displayed on your interface)

• Trigger Type: "Custom Event"

• Event name: tcConsentChanged (this is the event sent by the Commanders Act Privacy when you use tCPrivacyTagManager = "gtm" in your website’s source code)

• This trigger fires on: "Some Custom Events"

• Fire this trigger when an Event occurs and all of these conditions are true: pick the tcCategoriesConsent variable created in the previous step, the operator “equals” (or “contains”), and the name of the category as you declared it in the Commanders Act Privacy interface.

Assign Consent Changed Trigger to Tags

• Name of the trigger: "trust_commander".

• Trigger Type: "Custom Event"

• Event name: "trust_commander"

• This trigger fires on: "All Custom Events"

In the "Triggers" section, start by creating the following trigger that allows you to not activate the tags if the user has not yet given his consent :

If you want your site to be in "default optout" mode (blocking of tags when the visitor arrives on your site, in accordance with the General Data Protection Regulations, the GDPR), you must also make the following configuration.

Then create a custom tag that you will trigger on all pages (this is the TrustCommander event listener) in the "Tags" section:

• Name of the tag: "Trust commander event listener"

• Trigger Type: "Custom HTML"

• HTML: copy and paste the following code :

<script>
//No choice expressed by the user yet
if({{Trust commander values}} === "no_consent"){
window.tc_closePrivacyButton = window.tc_closePrivacyButton || function (){
window.dataLayer.push({"event":"trust_commander"});  
}
window.tc_closePrivacyCenter = window.tc_closePrivacyCenter || function (close_type){
if(close_type !== "cross"){  
window.dataLayer.push({"event":"trust_commander"});  
}  
}
} 
//Choice already expressed
else{

}
</script>  

• Triggering : "All pages"

Step 4 :Trigger your tags based on user consent

In the GTM interface, in the Tags section, assign the previously created trigger to your tags to fire them based on the TrustCommander categories. These triggers will replace your normal "pageview" trigger.

TrustCommander and TagCommander 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 TrustCommander setup.

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

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

3. Assign your TrustCommander categories & vendors to your TagCommander tags (see Assign Categories)

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

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

6. Connect your privacy banner templates with TagCommander container and implement rules for which the banner should be played out (see below).

Install TrustCommander banner with TagCommander container

To deploy a TrustCommander banner with TagCommander it needs to be linked to a container. TagCommander can then be use to implement detailed rules for which a TrustCommander banner is shown to visitors.

Implement rules to show TrustCommander banner

TAG > Tag Management > Edition (tab RULES)

In TagCommander 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 TagCommander documentation for more information.

Link TrustCommander banner with TagCommander container

TAG > Tag Management > Edition (tab GENERATE)

TagCommander makes it easy to implement TustCommander banner on websites. To link a privacy banner with a TagCommander 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.

Release 7.90.40 - 15/11/2021

The calculation of the Click reject button statistic has been revised.

The metric is now calculated directly from the raw data to better reflect the mobile applications.

In the old formula this metric was derived from other metrics, which could result in an imprecise measurement on mobile app banners.

The recalculation is retroactive and does not affect other metrics in the report. The raw data from the exports are not changed either.

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 .

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 TrustCommander 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 TrustCommander

For some customer's this solution worked also :

1. Open the TrustCommander popin

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

This documentation is deprecated

Please refer to this page

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)

TRUST> Categories & Tags (tab MANAGE VENDORS)

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

Vendors

Click ADD VENDOR to add vendors to your TrustCommander installation. You can select vendors available on TagCommander (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 TrustCommander 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.

IAB vendors

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

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

TrustCommander automatically configures purposes, special purposes, features and special features in the CATEGORIES tab depending on the selected vendors.

Google ACM vendors

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

Descriptions for the ATP that are shown in the TrustCommander privacy center are automatically loaded from the Google ACM list.

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

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)

TRUST > 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.

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.

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 TagCommander and TrustCommander 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.

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);

TrustCommander offers multiple banner templates for different kind of privacy workflows.

TRUST > Categories & Tags (tab ASSIGN TAGS)

TagCommander tags can be assigned to TrustCommander categories & vendors in following locations.

• In ASSIGN TAGS section of TrustCommander.

• In the EDIT tab of TagCommander.

Assign categories & vendors in TrustCommander interface

Categories & vendors are managed per TagCommander container. You can select a TagCommander container in the left column. Then you can manage following TrustCommander setting per tag on the right side of the interface.

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

Assign categories in TagCommander interface

For convenience it is also possible to directly assign TrustCommander categories & vendors inside the Edit tab of TagCommander. 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.0 option

In case you choose to manage tags with IAB 2.0 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 TrustCommander to manage them directly with TagCommander.

TRUST > Options.

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.

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.

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.

Interface

Filter options

The dashboard provides KPIs for each individual TrustCommander banner. You can customise the dashboard by adjusting filter settings at the top left of the interface. TrustCommander provides the following filters:

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.

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.

Measurement approach

TrustCommander measures privacy banner interactions to calculate consent KPIs.

All metrics are visitor/ traffic based and not user based. TrustCommander 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. TrustCommander 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 TrustCommander measures optin and optout actions.

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 TrustCommander privacy 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. TrustCommander 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 TrustCommander privacy 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%.

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

Consent methods

How engaged visitors react to CMP?

How visitors interact with the CMP banner?

How visitors use 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 TrustCommander 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

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.

TrustCommander 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.

TRUST> Categories & Tags (tab MANAGE CATEGORIES)

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

Category options

Each TrustCommander privacy category has following options:

Managing categories

Default category

In case you use TrustCommander with TagCommander you can select a default category with a dropdown on the top left of the interface. New tags in TagCommander 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 TrustCommander category by pressing the pencil icon to the right of the category.

Deleting categories

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

IAB categories

TrustCommander is compliant with IAB TCF 2.0 (Link to official listing) and can use predefined IAB TCF purposes instead of manually configuring categories. Go to TRUST > Options tab to activate IAB TCF 2.0 option for your account.

IAB TCF 2.0 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.0 categories is automatically loaded from the IAB TCF 2.0 framework.

Admin > 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 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.

Step 4

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

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.

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

Step 6

Click COPY in the top right corner of the interface to copy the banner with the selected options.

TRUST > 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:

Update Privacy Banner

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

Customise banner content

TRUST > Privacy banners (tab EDIT BANNER)

Options for banner customisation

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

Changes have to be saved with the SAVE button.

Options for privacy center customisation

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

Changes have to be saved with the SAVE button.

Advanced Options for IAB TCF Banner

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.

TrustCommander 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

TrustCommander 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.

Synchronisation mode between vendors and categories

You can choose to synchronise 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

TrustCommander 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 TrustCommander. They are activated with a JavaScript command that needs to be added to the privacy center CUSTOM JS field JS BLOCK BEFORE.

TrustCommander offers two options to activate Stacks:

pc.iab.useAutoStack();

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

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');

For its own operations, TrustCommander sets 1st party cookies to store the 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:

• v1 templates (deprecated): TC_OPTOUT & TC_OPTOUT_categories

• v2 tempaltes: TC_PRIVACY & TC_PRIVACY_CENTER

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

Cookie for anonymous statistics (TCPID)

A 1st party cookie is set to be able to collect anonymous statistics of consent: TCPID. 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 enacted by the CNIL in 2019.

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 processings 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

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

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

• tracers are completely independent from each other

What is our Marketing Preferences Center?

Marketing Preferences Center is part of our Trust 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 consents on this database ()

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

· Consents coming from a CRM database could be added with our FTP importer files or our 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

Overview

TagFirewall blocks unauthorised 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

TagCommander

TagFirewall can be set up and configured with the tag template "TagCommander - TagFirewall" in TagCommander.

Standalone

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

Examples

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, function(tcData, success) {
  if(success &&
    (tcData.eventStatus === 'tcloaded' || tcData.eventStatus === 'useractioncomplete')) {

    // do something with tcData.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(tcData, success) {
  if(success &&
    (tcData.eventStatus === 'tcloaded' || tcData.eventStatus === 'useractioncomplete')) {

    // do something with tcData.tcString

    // remove ourselves to not get called more than once
    __tcfapi('removeEventListener', 2, tcData.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 TrustCommander Options, an additional addtlConsent property will be available on the tcData object.

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

    // do something with tcData.addtlConsent

  } else {

    // do something else

  }
});

• Reference: Google Additional Consent Mode Technical Specification

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. TrustCommander 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 unconfigured 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

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 TrustCommander JavaScript loaded and validated the stored consent.

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 TrustCommander.

cact('consent.get', function (result) {

   const ANALYTICS_ID = 2;
   const 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 TrustCommander.

cact('consent.get', function (result) {
   
   const ANALYTICS_ID = 2;
   const analyticsCategory = result.consent.categories[ANALYTICS_ID] || {};

   const GOOGLE_ID = 5;
   const 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) {

    const dateExpires = result.meta.dateExpires;
                
});

User Consents

GET https://api.commander1.com/engage/user/

This endpoint allows you to get categorie's consent for one specific user

Query Parameters

{
    "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

{
    "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

{"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
  }
}

The TrustCommander OnSite API is used to interact with TrustCommander 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 TrustCommander JavaScript is loaded and ready to process the methods. This allows to use the OnSite API before TrustCommander JavaScript 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.

Methods

After installing the stub it is then possible to use any of the OnSite API methods via the window.cact function.

Each method follows a strict signature:

cact(command, [options,] [callback])

Below you will find an example method that is used to receive the TrustCommander consent 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.
        
    }
    
});

TrustCommander 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 TrustCommander cookies.

Name

The default name of the consent cookie is TC_PRIVACY. It can be configured in TRUST > Options.

Domain

The cookie is set as a 1st party cookie. The subdomain/domain of the cookie can be configured in TRUST > Options

Value

The value consist of multiple fields separated by @ symbols. The separator can be configured in TRUST > Options .

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>[@<vendor_consent_string>]

Examples

Example1: Optin for some categories

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

Example 2: Optout for all categories

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

/!\ good to know : special caracters such as "@" or "|" are encoded in the cooke value %2C = "," %7C = "|" %40 = "@"

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.

How to enable Google ACM Vendors

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.

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 TrustCommander 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 : .

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.

Overview

TrustCommander offers a cookie scanner that continuously monitors websites for cookies in realtime. 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.

Scan Cookies

Mechanisms