For more information about the generation step, please refer to the Generation Page of the section Tags

What is a source ?

A source is an emitter of events, more information here.

Source list

In Sources / Overview, you will find the full list of sources already configured.

You can search a source by name and filter on environment (production, staging, ...), status (active or inactive) and per destination

You can easily edit a source by clicking its name or the pencil icon.

Trend and data quality

The trend represents the evolution of number of events received on the last month.

The quality score of events is represented by a weather icon:

The browser-side container is a “box” containing all your partner solutions’ tags. Thus, tags that were formerly placed in your site’s source code are now all concentrated and managed in the same place – the container – for more effective control and faster deployment.

Note: in order to satisfy operational and organisational requirements or solve performance issues, you may have to use multiple containers for your site.

Hosting types

We offer two ways for your container's hosting:

• Via our CDN (Content Delivery Network): provides you a total autonomous deployment. Our CDN is having a 99.9% of SLA

• Via your site’s web servers, managed by your IT department or outside technical provider. With this hosting option, you can choose a synchronization method (automatic or manual) for transmitting the modifications made for your site in the Commanders Act interface. In all cases : for a new workspace, you will be must to configure the connector on the platform. Use the menu Administration => Connector Credentials to add a new connector

FTP connector configuration

Simply fill in all fields of the form: Name: Give an explicit name to your connector Containers: Select any client-side containers you want to associate with the connector Protocol: Select the type of File Transfer Protocol you need. We recommend to using SFTP, for security reasons Host: Enter the main domain or IP address of your FTP repository Port: Enter your standard port ID (SFTP is 22, FTP is 21, FTPS is 21...) Path: Enter the path of your repository. Should end with a "/" (see below example) User: Login to access of your FTP Password/Key: if there's a password or a key associated to your FTP, enter this information here

CDN connector configuration

It's almost identical to the FTP connector, there is only 2 more steps: Select a CDN vendor (EdgeCast or Akamai) Setup the "Purge" part (use the Account ID, Token and Purge URL provided by your CDN vendor)

URL connector configuration

Just give an explicit name, enter the correct URL and select any client-side container(s) you want to associate with the connector

Amazon S3 connector configuration

It's almost identical to the FTP connector. However, it requires a bucket as the host:

Google Cloud Storage connector configuration

fill in all fields of the form: Name: Give an explicit name to your connector Bucket: Enter the main domain or IP address of your FTP repository Path: Enter the path of your repository. Should end with a "/" (see below example) Project ID: Enter the id of the project in Google Cloud Storage. Can be found in Google Cloud JSON Key file Private key ID: Enter your private RSA Key Id for Google Cloud Services. Can be found in Google Cloud JSON Key file Private key: Enter the password associated to your Private Key ID. Still can be found in Google Cloud JSON Key file Google Account Email: Enter the client Google Cloud Services email used for authentication. You can find it in Google Cloud JSON Key file Client Id: Enter the client Google Cloud Services Id. Still can be found in Google Cloud JSON Key file Client X509 Cert URL: Enter the client custom X509 URL for Google Cloud Services. Can be found in Google Cloud JSON Key file

//example for the private key:

-----BEGIN PRIVATE KEY-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxp
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy0
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzA
aaaaaaaaaaaaaaaaaaaaaaa=
-----END PRIVATE KEY-----

Bing Ads connector configuration

Simply follow the step by step guide provided by Bing:

Facebook Ads connector configuration

Simply follow the step by step guide provided by Facebook:

Criteo connector configuration

Simply follow the step by step guide provided by Criteo:

Google Ads connector configuration

Simply follow the step by step guide provided by Google Ads:

Snapchat connector configuration

Simply follow the step by step guide provided by Snapchat:

Adobe Analytics connector configuration

Simply follow the step by step guide provided by Adobe: For more information, please refer to the dedicated page

Equativ connector configuration

Simply follow the step by step guide provided by Equativ:

Test & Debug

Once your connector configuration is done, you can click on the Test button to check that it's working properly. If it is correct, then you will see the following message:

To create/add a container, go to the “Web Containers” tab on the platform and click “ADD CONTAINER”:

A configuration window will appear with 3 main tabs:

• ““: to manage basic container options, such as naming your container

• ““: to manage container updating options

• ““: to manage advanced container options

After configuring the various container options, click “Add”

General

Simply fill the “Name“ field with Container’s wanted name

Synchronization

Mode: Synchronization modes for the container:

• FTP/CDN: This mode hosts the container on an FTP or CDN server (the server must be previously configured in Administration => Connector Credentials). By clicking this option, the “Set as deployed and send to FTP” synchronization mode will be proposed in the “DEPLOY” step.

• Amazon S3: This mode hosts the container on an FTP or CDN server (the server must be previously configured in Administration => Connector Credentials). By clicking this option, the “Set as deployed and send to AWS” synchronization mode will be proposed in the “DEPLOY” step.

• Update by batch from permanent link: this mode activates a permanent link to the last container version deployed. This mode can be useful when manually updating the container on your site or if you use a batch that regularly restores the last container version on the site. By clicking this option, the “Set as deployed and use external URL” synchronization mode will be proposed in the “DEPLOY” step.

• Custom URL: this mode calls a URL when deploying the container (the URL must be previously configured in Administration => Connector Credentials). This URL refers to a script placed on your servers (created by you) that must perform the operations necessary to launch the container. By clicking this option, the “Set as deployed and call the URL” synchronization mode will be proposed in the “DEPLOY” step.

• Manual: this mode allows you to load the container directly from the interface so that you can then deploy it manually on your site. You can check the “Add unminified version” function in order to load the container in either compressed (minified) or uncompressed (unminified) mode. By clicking this option, the “Set as deployed and get JavaScript file” synchronization mode will be proposed in the “DEPLOY” step.

• Send an email: this deployment mode complements the other 4 modes. It is used to send a notification email to specified users when a deployment is carried out.

Recurring synchronization:

Recurring synchronization is used to automatically deploy a container on a regular basis via the deployment mode desired (FTP, batch or send by email).

Two programming modes are available: Simplified mode and expert mode:

• “Simplified mode”: Simplified mode is used to program recurring synchronization by the day and hour (e.g. recurring synchronization every day at 2 p.m.).

• “Expert mode”: Expert mode is used to program recurring synchronization with more precision, by minute, hour, day, week and month (e.g. recurring synchronization every two weeks of the month on Tuesdays at 11:35 a.m.).

Advanced

NoScript support: This option is used to create a noscript version of the container that allows both the container and its tags to execute for users without JavaScript activated on their browser.

You can also define a JavaScript version and noscript version for each tag.

Verification by MD5 file: This option is linked to the “Manual” deployment mode and associates an MD5 code with a container version in either compressed (minified) or uncompressed (unminified) mode in order to verify the integrity of the container before putting it into production. It does this by comparing TagCommander’s MD5 code with the MD5 code calculated by your technical team upon receiving the container.

Include jQuery (at the test step): This option allows you to include the JavaScript jQuery library in the test step so that you won’t have any errors linked to its absence if it is indeed present on your site.

Display block for old tc_event function: This option allows to show/ hide the old TagCommander event section. It is hidden per default.

Default expiration date: This option allows you to set a default expiration date for all the tags to be added to the container (in this case, the tags will be deactivated). If necessary, it also allows you to send an expiration report to selected users when a tag expires (the report is sent 2 weeks and 1 week before the tags expire).

Container default trigger: Container Load is the value by default, you can modify it if needed

Linked sub-domain(s) for Phoenix: Enter your sub-domains for Phoenix, which enables you to persist 1st party cookies for longer durations to reduce the impact of ITP on your website and business.

Force Cookie SameSite setting: all cookies created through the container will get the SameSite parameter

Force Cookie Secure setting: all cookies created through the container will get the Secure parameter

*Note: this setup can be modified at any time. Simply click the 'parameter' icon:

To delete a container, click “More”, next to the blue Edit button while on the Dashboard, in the container list section.

In the new window, you will see the containers’ list, the container you selected will be highlighted. To delete it click the red “Delete” button to the right.

A confirmation message will appear

A web container is the browser-side component of Commanders Act Enterprise Tag Management system. It is composed of a set of browser-side tags, rules, triggers and enriched web data layer. It is represented by a container javascript file that is put on each pages of your website. For information about how users setup and maintain containers, see the .

Connect serverside destinations to a web container

Sending data from your web container to serverside destinations offers a lot of advantages (web performance, security, data accuracy/quality, etc.)

To start sending data, there is only one easy step to follow : .

The last tag that you will ever setup.

The One Tag allows you to send all your events to the Commanders Act platform in a normalized way, and once and for all, to benefit from all the serverside advantages that offer the platform.

Recommandations for setup

In order to take advantage of all the benefits offered by a Web container, it is essential to on every page of your website.

Moreover, the on your site will allow you to obtain a more powerful and better quality tracking

Extensions

It is possible to extend Commanders Act TMS with additional modules:

Find on this page a full list of sources you can use to gather infomation on your traffic. Sources are sorted per categories (Web, Mobile, Push notification, CRM, etc).

You can use the search bar to find the source you are looking for. Cannot find the source you want? Fill our request form to ask our team to add a new source to the list.

All requested sources are viewable by clicking the “Request” tab on the left.

To have more information on a source simply click on it and you'll get all details to use and install the souce.

A container can be deployed at the “DEPLOY” step:

Before deploying a container version, you can:

• Display all the modifications made to your container since its last deployment (technical logs) (1) in the “MODIFICATIONS SINCE LAST DEPLOYMENT” section

• View the history of generated versions in the “DEPLOY BY VERSION” section.

For each version generated, you will find his version number, creation date, status (“deployed” when it is the version currently deployed and/or “live” when it is the version currently called for the site) , the name of the person who generated the version, a comment, and the container’s size. You will also be able to load your selected container version directly from the interface or via a permanent link:

Additional information:

The “Weight Detail” section shows the container’s size (in GZIP format), its change in size since the last deployment as well as the percentage of space occupied by each of the following container elements:

• Core: The weight of the content necessary to execute the container

• Tags: Tags’ weight

• Events: Events’ weight

• Rules: Rules’ weight

• Privacy: Privacy module’s weight (if activated)

• Internal variables: Internal variables’ weight

• Deduplication channel: Deduplication channel’s weight (if activated)

Deploying a new container version or rolling back a container is done in two steps:

• Choose the version to deploy.

Note: to roll back the container, just select a previous container version.

• Choose the deployment method.

Note: the deployment method depends on your container’s hosting and synchronization, which are defined at the project’s start with your personal consultant.

Once the version and deployment method are selected, a window summarizing the deployment will appear. Click “Deploy” to validate:

Additional information

Depending on the hosting and synchronization methods defined at the project’s start and configured in the interface, different deployment options are available in the drop-down menu under “Choose the deployment method”:

Deduplication is the conditional activation on the confirmation page of a website, of the tag(s) responsible for the conversion.

This activation is possible by capturing and reading the parameters of your tracking URLs through TagCommander.

Within our interface, tags can be deduplicated with configurable rules depending on their position throughout the customer journey: at the beginning, at the end, or anywhere.

For example, if before converting on your site a user saw and clicked a banner served by your retargeting partner, you can set up a rule to call only that partner’s confirmation tag on the confirmation page.

The deduplication module in Commanders Act is included in your Commanders Act offer.

It allows you to create rules to fire confirmation tags (mostly but not only) based on:

• A digital marketing channel (SEM, Display, Retargeting, Affiliation, etc).

• A traffic source linked to that channel (digital marketing solutions such as Criteo, Netaffiliation, Marin, Tradedoubler, etc).

• The position of the touchpoint throughout the customer journey.

• Whether a click or impression – or both – are involved.

Note: Channel and source information is read and captured from the parameters in your tracking URLs if you use our “Commanders Act TMS” product only. However, if you have subscribed to other options of our platform (like “Enrichment”), you can use Commanders Act redirects, in which case there would be no URL parameter capture.

There are many benefits from activating the deduplication module:

• Preserving information confidentiality: by activating solely the tag of the partner responsible for a conversion, you limit information leakage about your sales, leads, order amounts, among others, to all your providers, and communicate only what pertains to a specific conversion generated by a specific solution to that very partner.

• Saving time: Commanders Act’s deduplication module allocates conversions to partners in real time, helping you save time and not having to allocate conversions manually afterwards from information obtained through reports generated by your analytics tools and your partners.

A web container is a JavaScript file which has two purposes:

· To be able to use native functions & methods of the TMS

· To execute the partners solutions (tags) contained inside

It is possible, as it is often the case, to have several containers for the same site or even the same page.

The URL of each JavaScript Web Container file will be provided alongside the Container IDs and Container Names by a Commanders Act Consultant during the setup process.

Implementation of the containers on the page

Web container are usually installed by implementing a <script> html node on every page of your website that holds a src attribute that points to the Container URL.

The containers can be placed in different locations in the page source’s code depending on their use and your type of business.

Here’s a common example with 3 containers:

<head> container's location is usually used for AB test and should be load synchronously, to prevent flickering effect.

We recommended to implement all <body> containers asynchronously. Simply use the async attribute in the <script> element.

Installation of <head> Container

<head> Container are used to implement A/B-testing and personalisation Tags that usually impact the visual content of a website before it is presented to the user. Therefore it is important to place them as high as possible in the <head> section of your website.

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <script src="{{ head_container_URL }}"></script>
        (...)
    </head>
    (...)
</html>

Please ensure that the <head> Container file is loaded synchronously to avoid potential content flickering effects.

Installation of <body> Container

<body> Container are used to implement Tags that measure information. These Containers are therefore placed at the end of the <body> section to make sure they have minimal impact on the loading time of the content of the website.

<!DOCTYPE html>
<html>
    (...)
    <body>
        (...)
        <script src="{{ body_container_URL }}"></script>
    </body>
</html>

In contrast to the <head> Container it is possible to implement <body> Container asynchronously. For example it is possible to load them via JavaScript on the onload event of the page or it is possible to use the async attribute in the <script> element.

Testing

Via Browser Console

It is possible to log all loaded Container files on a site via the JavaScript console of the browser. The JavaScript object tC.containersLaunched provides information of each loaded Web Container.

Following you will find an example object including its most relevant information:

{
    1234: { // TagCommander Account ID
        1: { // ID of the 1st loaded Container
            g: 15,
            v: "5.15" // Version of the 1st loaded Container
        },
        5: { // ID of the 2nd loaded Container
            g: 20,
            v: "55.16" // Version of the 2nd loaded Container
        }
}

Definitions

AMP Definition

AMP, which stands for Accelerated Mobile Pages, is a technology issued from the open source Digital News Initiative (DNI) between Google and European publishers. AMP is a format allowing the creation of optimized mobile content in a bid to improve user experience.

If you wish to learn more about AMPs, click the following links:

[FR] https://www.ampproject.org/fr/learn/about-amp/

[EN] https://www.ampproject.org/learn/about-amp/

Implementing Commanders Act on AMPs

AMP blocks synchronous JavaScript files called on your websites in order to increase mobile pages’ loading speed. For your Commanders Act container to be compatible, you need to adapt the way you set it up to be compliant with AMP’s requirements.

Below, you will find an example showing how to set up a Commanders Act container on your AMP pages. We recommend using the <amp-analytics> tag (https://www.ampproject.org/docs/reference/components/amp-analytics) to define your data layer and the container.

Important: This operation calls for Commanders Act’s API and thus requires that a server-side container be setup in Commanders Act’s user interface.

Setup example with analytics tag

<!doctype html>
<html amp lang=”en”>
<head>
<meta charset=”utf-8″>
<title>Commanders Act – AMP Analytics</title>
<link rel=”canonical” href=”http://example.ampproject.org/article-metadata.html” />
<meta name=”viewport” content=”width=device-width,minimum-scale=1,initial-scale=1″>
<!– Mandatory execution of the AMP Analytics Script “https://cdn.ampproject.org/v0/amp-analytics-0.1.js” –> 
<script async custom-element=”amp-analytics”
src=”https://cdn.ampproject.org/v0/amp-analytics-0.1.js“></script>
<style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>
<script async src=”https://cdn.ampproject.org/v0.js”></script>
</head>
<body
<amp-analytics id=”commandersact”>
<!– JSON data structure containing the TagCommander data layer –> 
<script type=”application/json”>
{
“vars”: {
“tC_SiteID”: “3503”,
“tC_ContainerID”: “1”,
“env_template” : “homepage”,
“env_work” : “prod”,
“env_device” : “m”,
“env_country” : “IT”,
“page_name” : “amp_homepage”,
“user_id” : “”,
“user_newcustomer” : “”,
“order_id” : “”
},
<!– Call to Commanders Act’s API (server-side) –> 
“requests”: {
“tC_BaseURL“: “//serverside${tC_SiteID}.tagcommander.com/${tC_ContainerID}/”,
<!– Page variables mentioned in the “tC_PageTrack” element –> 
“tC_PageTrack“: “${tC_BaseURL}?&env_template=${template}&env_work=${work_environment}&env_device=${device}&env_country=${country}&page_name=${page_name}&user_id=${user_id}&user_newcustomer=${newcustomer}&order_id=${order_id}”,
<!– Event variables mentioned in the “tC_EventTrack” element. Note: “scroll” and other such variables are natively proposed in AMP pages–> 
“tC_EventTrack“: “${tC_PageTrack}&scrollY=${scrollTop}&scrollX=${scrollLeft}&height=${availableScreenHeight}&width=${availableScreenWidth}&scrollBoundV=${verticalScrollBoundary}&scrollBoundH=${horizontalScrollBoundary}${eventLabel}”
},
<!– Additional parameters mentioned in the “extraUrlParams” element. Note: the clientId function creates a unique ID per visitor (different from the regular TCIDs)–> 
“extraUrlParams”: {
“TCID_AMP”: “${clientId(TCID_AMP)}”,
“path”: “${ampdocUrl}”,
“type”: “${type|default:page}”,
“platform”: “AMP”,
“r”: “${random}”
},
<!– Execution of Commanders Act hits on the “triggers” element. “Pageview” sends the hit to the page viewed, the “clickPings” trigger sends the hit to an event defined in the “selector” –>
“triggers”: {
“pageview”: {
“on”: “visible”,
“request”: “tC_PageTrack”,
“vars”: {
“type”: “page”
}
},
“clickPings”: {
“on”: “click”,
“selector”: “.tC_events”,
“request”: “tC_EventTrack”,
“vars”: {
“type”: “event”
}
}
}
}
</script>
</amp-analytics>
<h1 id=”header”>AMP Page</h1>
<!– data-vars-event-label2 allows to collect additional variables, such as event variables –>
<span id=”event-test” class=”tC_events” data-vars-event-label2=”22″>
Click here to generate an event
</span>
</body>

AMPs also allow you to set up your tag management tool through an iframe. Please note that if the iframe has not loaded within 5 seconds, it will not be called. You will find below an a setup example through an iframe:

Setup example with iframe

<!doctype html>
<html amp lang=”en”>
<head>
<meta charset=”utf-8″>
<title>Commanders ACT – Serverside – AMP Analytics</title>
<link rel=”canonical” href=”http://example.ampproject.org/article-metadata.html” />
<meta name=”viewport” content=”width=device-width,minimum-scale=1,initial-scale=1″>
<!– Mandatory execution of the AMP iframe script “https://cdn.ampproject.org/v0/amp-iframe-0.1.js ” –>
<script async custom-element=”amp-iframe” src=”https://cdn.ampproject.org/v0/amp-iframe-0.1.js”></script>
<style>body {opacity: 0}</style><noscript><style>body {opacity: 1}</style></noscript>
<script async src=”https://cdn.ampproject.org/v0.js”></script>
</head>
<body>
<!– Call to the TagCommander iframe “https://academy.commandersact.com/AMP/iframe.php” containing the data layer variables. Note: the iframe must belong to a different domain from that of the website (except if the allow-same-origin parameter is added) and be https –>
<amp-iframe width=1 height=1 src=”https://academy.commandersact.com/AMP/iframe.php? env_template=homepage&env_work=prod&env_device=m&env_country=IT&page_name=amp_homepage&user_id=&user_newcustomer=&order_id=” sandbox=”allow-scripts allow-same-origin” layout=”fixed” frameborder=”0″>
<!– Adding content to the iframe is mandatory (a pixel in this case)–>
<amp-img src=”https://academy.commandersact.com/AMP/pixel.gif” height=1 width=1 layout=”fill” placeholder></amp-img>25
</amp-iframe>
<h1 id=”header”>AMP Page</h1>
<span id=”event-test” class=”tC_events” data-vars-event-label2=”22″>
Click here to generate an event
</span>
</body>
</html>

Commanders Act TMS offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for Angular.

Commanders Act offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for React.

Commanders Act TMS offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for AngularJS.

Commanders Act Events Triggers are onsite events that are used by Commanders Act users to dynamically execute Tags.

Definitions

Installation

Commanders Act allows to set up common Trigger automatically without the involvement of technical team (e.g. Container loaded, DOM ready or Vertical Scroll 25%). In cases where the default Triggers are not sufficient it is possible for technical personnel to implement custom Triggers. The necessary Trigger are defined during the Commanders Act setup process, but you can find a list of native Trigger on this page.

To install a custom Trigger on the website it is necessary to call a JavaScript function with the following pattern:

tC.event.{{ Trigger Label }}(this, {{ Trigger Data Layer }});

A typical example is an Add to basket event where the product id of the selected product is sent with the event:

tC.event.add_to_basket(this, { product_id: "12345" });

if (tC && tC.event && typeof tC.event.add_to_basket === "function") {
    tC.event.add_to_basket(this, { product_id: "12345" });
}

Testing

Via Quality Assurance Tag

The Tag template Commanders Act - Event QA in the Commanders Act Tag library automatically outputs event Data Layer information to the JavaScript console when executed. Assigning this Tag with the Trigger allows to log a snapshot of the Data Layer when the respective Trigger is executed. Another way, more technical: you can type in your console tc_arrray_events when the event is executed. The Data Layer of the event variables will be displayed.

Commanders Act offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for VueJS.

A Container Strategy is the layout of the Web Container of a site. Following you will find recommended Container Strategies for common types of websites and businesses.

Ecommerce

Ecommerce websites require a mix of personalization, analytics and conversion Tags. To optimise website performance it is recommended to use three Containers.

With this setup it is possible to avoid conversion Tag JavaScript snippets on catalog pages—this results in smaller Container file sizes and therefore quicker loading times for SEO relevant catalog pages.

Publisher

Publisher websites primarily require analytics Tags. Therefore it is recommended to only use one Container.

Using one <body> Container helps to have minimal impact on the page loading time, which is crucial for SEO of Content pages like news articles.

In case A/B-testing and personalization Tags are used, the additional implementation of a <head> Container is recommended.

A Commanders Act Data Layer is a JavaScript object that holds metadata of a website as properties to make it available to Tags. In the platform this Data Layer is named "External Variables" to distinguish it from scripted "Internal Variables" that are generated within the Container JavaScript.

Installation

To install a Commanders Act Data Layer it is necessary to implement a global JavaScript object tc_vars that holds the meta data of the page as direct properties. The required Data Layer properties are defined during the Commanders Act setup process, but you can find a list of common properties on this page.

The approach to fill the Data Layer with properties depends on the technology framework that is used on the website and can reach from JavaScript web scraping to templating to hardcoding.

<script>
    window.tc_vars = {
        env_template: "homepage",
        env_work: "prod",
        page_name: "Homepage",
        page_keywords: ["homepage", "home", "entrypage", "index"],
        product_name: "",
        (…)
    };

    window.tc_vars.user_name = "myuser";
</script>
<script src="{{ container_URL }}"></script>

The Data Layer needs to be filled with information before the Web Container file is loaded—otherwise information might not be available at the time the Container JavaScript executes.

In case multiple Containers are used on the same page it is possible to fill the Data Layer in multiple steps. Global information like the page type should be made available before the first Container is loaded. Information that is only relevant for a certain Container (e.g. product information) can be appended prior to the respective Container.

Following example outlines how a Data Layer can be installed in case both a <head> and a <body> Container are used on a website.

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <script>
            window.tc_vars = Object.assign({}, window.tc_vars, {
                env_template: "homepage",
                env_work: "prod"
            });
        </script>
        <script src="{{ head_container_URL }}"></script>
        (…)
    <head>
    <body>
        (…)
        <script>
            window.tc_vars = Object.assign({}, window.tc_vars, {
                page_name: "Homepage",
                page_keywords: ["homepage", "home", "entrypage", "index"]
            });
        </script>
        <script src="{{ body_container_URL }}"></script>
    </body>
</html>

Testing

Via JavaScript Console

It is possible to investigate the Data Layer in the JavaScript console by logging tc_vars.

Following you will find an example output of a tc_vars Data Layer in the JavaScript Console.

{
    env_template: "homepage",
    env_work: "prod",
    page_name: "Homepage",
    page_keywords: ["homepage", "home", "entrypage", "index"],
    product_name: "",
    (…)
}

Via Quality Assurance Tag

The Tag template Commanders Act - Data Layer QA in the Commanders Act Tag library automatically outputs Data Layer information to the JavaScript console on each page. This approach has the advantage that it logs a snapshot of the Data Layer at the exact time the Container JavaScript was executed. This allows to identify race conditions between the Data Layer properties and the Container JavaScript to make sure all necessary properties are available in time.

It is possible to send server-side events Commanders Act TMS container via a HTTP tracking API Source (e.g. for IOT and TV apps). Please refer to this page for more details

Onsite performance of a website is one of the most important KPIs for SEO. Therefore more and more businesses are interested in optimizing onsite performance via TagCommander. This post collects topics to make TagCommander itself more performant.

Reduce File Size of TagCommander

Remove unused Data Layer Properties

Each Data Layer property that is configured in the options in the interface creates a bit of JavaScript code in the Container to initialise the variable in case it was not present in the onsite Data Layer tc_vars. Removing unused/old variables will therefore make the Container file a bit smaller (and as a side effect also improve transparency of the Container setup).

Remove Unused Internal Variables

Each internal variable that is configured in the options in the interface is a JavaScript snippet, so removing internal variables allows to make a Container file smaller. This can be done by removing unused internal variables and also by specifying which variables are used in which Container. This is especially important for clients with a <head> and <body> Container and clients that have multiple Containers for different websites.

Do Not Repeat Yourself

Sometimes the same functionality of a Tag is duplicated in multiple Tags. In these cases it is possible to save a good amount of JavaScript code and Container file size by refactoring the common functionality into an internal variable or into a common Tag. For example many Tags exist of two parts. One part loads an external JavaScript library of the vendor and one part sends the actual event to the vendor. Per default the code that loads the JavaScript library is often duplicated in every event. So extracting the first part into a base Tag allows to remove the duplicated JavaScript.

Split Large Container Files

Many Tags are deployed on every page of a website even so they are not triggered. For example many vendors have separate Tags for collecting information and only one Tag that is played out on the confirmation page. Therefore it might make sense to split the Container in two parts—one for catalogue pages and one for funnel pages. Therefore both Containers have a smaller size as they only include Tags that are relevant for their part of the website.

Also make sure to only implement Tags in <head> Container if necessary as those Tags usually have a greater impact on onpage performance than Tags in `<body>` Container.

Implement Hybrid TagCommander Setup

A hybrid setup allows to move onsite performance impact into the Server-Side TagCommander infrastructure.

Make TagCommander asynchronous

Load Container Asynchronous

Many onsite page speed crawlers measure the time until the browser event onload. So in case the IT team loads the TagCommander Container asynchronous on the onload event it is possible to make the TagCommander file invisible for some page speed metrics. This is usually only possible for <body> Containers as <head> Containers need to be executed synchronously for A/B testing and personalisation Tags that have an impact on the visual content of the website.

Load Tags Asynchronous

JavaScript is for the most part a single thread language, this means that long running JavaScript (like a long process in a loop) can block other parts of the JavaScript that should be executed right away. It is possible to put long running JavaScript on an execute later with a lower priority stack by wrapping it inside of a setTimeout with a delay of 0 ms.

setTimeout(function() {
    // My Tag Code
}, 0);

This needs to be tested with each individual Tag as some might not be compatible with this approach.

“tC.” methods are namespaced* . They come in handy when needing to perform technically advanced actions such as printing the array of launched tags within a container into the browser’s console. Please note that these functions’ availability and behavior depend on several elements like your container configuration, among others. Simply type “tC.” into your browser’s console and the list of available functions on a given site and for a given container will appear.

* “namespacing is a technique employed to avoid collisions with other objects or variables in the global namespace. They’re also extremely useful for helping organize blocks of functionality in your application into easily manageable groups that can be uniquely identified.”

Pixel Tracking, also known as 1x1 gifs, or clear gifs, lets you record data from any website (or application) where JavaScript or POST requests are not allowed, but where you can insert an image (aka GET hit)

Basic Event Call

To send a basic event call using pixel tracking, construct a GET request to the tracking endpoint URL with the necessary query parameters. The following example demonstrates a basic event call for tracking a page view:

GET  https://collect.commander1.com/events?tc_s={siteId}&token={yourSourceKey}&event_name=page_view&prop1=value1

In the above example, replace {siteId} with the ID of your site (aka workspace), {yourSourceKey} with your specific source key, and value1 with the desired value for prop1. Remember to URL encode the string values, especially if they contain special characters or spaces.

Event Call with Objects and Arrays

Pixel tracking allows for more complex data structures like objects and arrays. To include them in your event calls, you can nest parameters by indicating objects and their properties with square brackets for both objects and arrays. The property names are enclosed within the brackets and nested properties are further enclosed in their own set of brackets. The following example demonstrates an event call with objects and arrays:

{
  "event_name": "page_view",
  "tc_s": "1234",
  "token": "abcdef",
  "page_type": "product_list",
  "page_name": "Best sellers",
  "user": {
    "id": "12356",
    "email": "toto@domain.fr",
    "consent_categories": [
      "1",
      "3"
    ]
  }
}

To transform the above JSON event call to URL parameter form, follow these steps:

1. Start with an empty string for the URL parameter form.

2. Copy the key-value pairs at the top level of the JSON object (event_name, tc_s, token, page_type, page_name) as they are, separating them with ampersands (&).

3. For nested objects like user, represent them in the URL parameter form by appending the nested key using square brackets ([]).

4. For array values like user[consent_categories], append [] to the key to indicate an array parameter.

5. Include each element of the array as a separate key-value pair, appending the square brackets notation to the key as well.

6. URL encode the string values, such as replacing the space in Best sellers with %20 and the @ symbol in the email address with %40.

The transformed URL parameter form for the JSON event call would be:

GET  https://collect.commander1.com/events?tc_s=1234&token=abcdef&event_name=page_view&page_type=product_list&page_name=Best%20sellers&user[id]=12356&user[email]=toto%40domain.fr&user[consent_categories][]=1&user[consent_categories][]=3

Manage array of objects (ex: items)

Arrays of objects can also be handled in pixel tracking event calls. This allows you to include multiple items within a single event, such as a purchase event. Let's consider an example of managing an array of objects for items in a purchase event:

{
  "id": "O_12345",
  "revenue": 16.00,
  "value": 22.53,
  "shipping_amount": 3.33,
  "tax_amount": 3.20,
  "currency": "EUR",
  "user": {
    "id": "12356",
    "email": "toto@domain.fr"
  },
  "items": [
    {
      "id": "SKU_12345",
      "quantity": 1,
      "product": {
        "id": "12345",
        "name": "Trex tshirt",
        "category_1": "clothes",
        "colors": ["red"],
        "price": 9.99
      }
    },
    {
      "id": "SKU_12346",
      "quantity": 1,
      "price": 9.99,
      "product": {
        "id": "12346",
        "name": "Heart tshirt",
        "colors": ["blue", "white"],
        "price": 9.99
      }
    }
  ]
}

To include the array of objects within the event call, follow these steps:

1. Include the key-value pairs at the top level of the JSON object as usual (id, revenue, value, shipping_amount, tax_amount, currency, user).

2. For the array of objects, specify the key (e.g., items) and use square brackets ([]) to indicate an array parameter.

3. Include each object within the array as a separate set of key-value pairs, preserving the structure of the objects.

4. If necessary, nest additional objects or arrays within the objects of the array.

Example of transforming the JSON event call to URL parameter form:

id=O_12345&revenue=16.00&value=22.53&shipping_amount=3.33&tax_amount=3.20&currency=EUR&user[id]=12356&user[email]=toto%40domain.fr&items[0][id]=SKU_12345&items[0][quantity]=1&items[0][product][id]=12345&items[0][product][name]=Trex%20tshirt&items[0][product][category_1]=clothes&items[0][product][colors][]=red&items[0][product][price]=9.99&items[1][id]=SKU_12346&items[1][quantity]=1&items[1][price]=9.99&items[1][product][id]=12346&items[1][product][name]=Heart%20tshirt&items[1][product][colors][]=blue&items[1][product][colors][]=white&items[1][product][price]=9.99

In the transformed URL parameter form, each item within the array is represented by its index, followed by the keys and values of the nested object.

Following you will find common Commanders Act Trigger setups.

Page View Trigger

In most cases page view events are covered by the inbuilt Container loaded and DOM ready Trigger within Commanders Act. Therefore it is only necessary to setup the Data Layer and the Container to execute Tags on page views. In case of JavaScript driven webpages it is sometimes necessary to further track "virtual page views", e.g. in case the process steps of a sales funnel (log-in, enter shipping details, enter payment details, confirm order, order success) are implemented via JavaScript functionally and not via individual pages with distinct URLs.

In this case it is common to track the initial page view with the Container loaded or DOM ready Trigger and subsequent virtual page views via a custom Trigger. For this scenario it would be necessary to follow these steps on each subsequent virtual page view.

1. Update tc_vars Data Layer

The Data Layer should be updated with the new metadata of the subsequent virtual page view.

window.tc_vars = {
    env_template: "homepage",
    env_work: "prod",
    page_name: "Homepage",
    page_keywords: ["homepage", "home", "entrypage", "index"],
    product_name: "",
    (…)
};

2. Reload the Container

Some internal functionality of the Container (e.g. Internal Variables) are only calculated when the Container was initially loaded. To reload these with the updated Data Layer it is necessary to reload the Container via a JavaScript function.

tC.container.reload();

3. Execute Triggers

After these steps it is then necessary to signal a custom Trigger to execute the related Tags.

cact('emit', 'page_view', {});

To use event attributes, you can specify the event or the element as first argument.

<a href="/home" onclick="cact('emit', 'pageview', { from: this, some_data: 'some_value' })">Home</a>

Old Method

tC.event.pageview({}, {});

To use event attributes, you need to specify the event or the element as argument. event is a special variable that is always available inside of onclick and on* attributes.

<a href="/home" onclick="tC.event.pageview(event, {}))">Home</a>

Click Trigger

Click Trigger implementation depends on the scenario. e.g. Is the user navigated to another site when he clicks an element? and Does the following page open in a new tab?.

Following you will find a list of common scenarios for click Trigger.

Scenarios

Click Navigates to an Internal Page

Links or interactions that navigate the user to another internal page are difficult to track. The reason for this is that Tags usually need more time to execute than the browser needs to navigate to the next page. This might accidentally cancel Tags execution and therefore its related tracking capabilities.

To successfully track these kind of scenarios it is important to align with the Tag vendor for a solutions. Typical solutions are:

• The Tag delays page navigation until the Tag finishes execution

• The Tag uses the Beacon Browser API, which sends tracking calls in the background

These options typically require configuration of the event Tag code.

Click Navigates to an External Page

External links are best opened in another browser tab by using the target="_blank" option on anchor links. This allows Tags to finish their work on the old tab, while users can already navigate the new external page in a new tab.

In case external links can not be opened in a new tab this scenario should follow the same advice than the prior scenario.

Click Does Not Navigate to Another Page

Some click events do not redirect to a new page. Typical examples are video transport controls or interactions with image carousels.

These click events can usually be tracked with less rissk due to Tags having enough time to execute on the same page.

Setup

With Commanders Act Interface

Commanders Act users can setup common click Triggers with minimal effort via the Web Containers interface by selecting them with a CSS selector path.

This Trigger works in many scenarios but has two downsides:

1. Using a generic CSS selector path to setup a Trigger is unstable and can break on future releases of the website code when the CSS is updated.

2. Commanders Act can only identify elements that are loaded synchronously on the website. Elements that are loaded asynchronously cannot be watched by the predefined Commanders Act Trigger.

Good scenarios for setting up Commanders ActTriggers with the Interface are:

1. Onsite campaign that has to be measured for a short time period (couple of weeks)

2. General click tracking until the web development team can implement a custom Trigger.

With Custom Trigger

Technical personnel can implement custom Triggers to track clicks on a website. This approach is more stable compared to setting up a click Trigger with the interface, but usually requires some time until the web development team can implement them. Therefore it is recommended to implement intermediary Triggers with the interface until they are implemented in the site.

Custom Triggers should not be implemented for short term campaigns, but should be favoured for business critical functionalities like Add to basket or Successful Registration.

A common way to setup click Trigger is done by setting up data-attributes on all elements where clicks should be tracked. These attributes could then be filled by the website CMS with values, so e.g. the marketing team can setup a "Click Trigger" for a new Teaser on their own. In HTML this might look like this:

<a href="..." class="btn btn--cta" data-tracking-action="click" data-tracking-label="My CTA" data-tracking-value="campaign-1234">Buy now!</a>

Inside of Commanders Act Platform it is then possible to catch clicks on these elements to execute a custom Trigger. With jQuery this might look like this:

(function(){

    if (!$) {
        console.log("Commanders Act | Error | jQuery not available in Commanders Act Click Trigger!");
        return;
    }

    var eventActionSelector = '[data-tracking-action="click"]';
    var eventLabelAttribute = 'data-tracking-label';
    var eventValueAttribute = 'data-tracking-value';

    var eventHandler = function(event) {

        var eventData = {};
        eventData.event_action = "click";
        eventData.event_label = $(this).attr("data-tracking-label");
        eventData.event_value = $(this).attr("data-tracking-value");

      	if (tC.event && typeof tC.event[triggerName] === "function"){
            // old method
            // tC.event["my_click_trigger"](event, eventData);

            eventData.from = event; // necessary to use event attributes inside the tag
            cact('emit', 'my_click_trigger', eventData);
      	}

    }

    // Setup event handler on body via event delegation to include asynchronous elements
    $("body").on("click", eventElementSelector, eventHandler);

}());

Documentation in progress

Example of event triggered from a browser-side user interraction

Example use case : trigger a view_content event when the user scroll to 80% of the page.

import React, { useEffect } from 'react';

const MyPage = () => {
  useEffect(() => {
    let eventTriggered = false; // Flag to track if the event has been triggered

    function handleScroll() {
      if (eventTriggered) return; // If the event has already been triggered, do nothing

      const { scrollTop, scrollHeight, clientHeight } = document.documentElement;
      if (scrollTop + clientHeight >= scrollHeight * 0.8) {
        if (window.cact) {
          window.cact('trigger', 'my_event_name', {
            myprop1: '1234',
            myprop2: 'abcd',
          }, {
            collectionDomain: "my.firstdomain.com",
            siteId: "1234", 
            sourceKey: "abcd1234",
          });
          eventTriggered = true; // Update the flag to avoid triggering the event again
        }
      }
    }

    window.addEventListener('scroll', handleScroll);

    return () => {
      window.removeEventListener('scroll', handleScroll);
    };
  }, []);

  return (
    <div>
      {/* Your server-side rendered content here */}
      <script
        dangerouslySetInnerHTML={{
          __html: `
            (function() {
              var tc = document.createElement('script');
              tc.type = 'text/javascript';
              tc.async = true;
              tc.src = 'https://cdn.tagcommander.com/events/sdk.js';
              var s = document.getElementsByTagName('script')[0];
              s.parentNode.insertBefore(tc, s);
            })();
          `
        }}
      />
    </div>
  );
};

export default MyPage;

GET Tags List

Returns the tags list

Call URL

GET api.commander1.com/api/1.0/manage/container/tags/list?id_site=X&access_token=Y&id_container=Z

Call parameters

Return code:

Response format :

The response is in JSON format.

GET

Response example

{  
    "idSite":26,
    "containers":[  
        {  
            "id":1,
            "label":"Container1",
            "is_active": true,
            "tags":[  
                {  
                    "id":1,
                    "label":"Click&Site Tracking"
                },
                {  
                    "id":3,
                    "label":"commanders act"
                }
            ]
        }
    ]

Get Users

Get platform users.

Users

GET https://api.commander1.com/v2/{siteId}/users

Two usages : GET /users/ : Returns a list of user properties (depending on the parameters requested) linked to the users of a site. GET /users/123 : Return properties of one user (id 123) on one site. Click below to download complete API documentation

Query Parameters

1. What is an SPA environment?

An SPA (Single Page Application) is a website or a web application that loads elements dynamically according to user actions rather than loading new pages after every interaction. Commanders Act web container offers functions allowing you to load all or a part of the container within an SPA environment, allowing you to call desired tags on every action performed by a user. These functions need to be implemented in your site’s source code by either your technical partner or by your own technical staff.

2.How to implement Commanders Act web container in an SPA environment?

2.1 Loading containers

Commanders Act web containers are loaded once upon page load within a Single Page Application Environment. In order to reload containers on user actions, you can use the following features:

• tC.container.reload() : this function allows you to reload all the containers on a page. Elements shared by containers (deduplication calculation, external variables initialization, internal variables calculation, calculation of cookies dropped with data storage and the initialization of the Privacy cookie) are only loaded once to optimize performance.

tC.container.reload({ exclusions: ["datastorage","deduplication","internalvars","privacy"], events: {label1: [{targeted_element},{event_variables}], label2: [{},{}]}})

This function allows to reload all of a page’s containers while excluding some of their elements. Elements to exclude need to be mentioned in the “exclusions” table. Ex: if you wish to reload the container without recalculating internal variables, you need to call this function: tC.container.reload({exclusions:["internalvars"]}) This function also allows to call the tC.event function that loads selected tags upon user action. The tC.event function is executed after the container elements reloading. label: specify the name you wish to call your function (ex : "click", "add_to_cart"…). targeted_element: DOM elements on which the event applies. {} if not necessary. event_variables: variables specific to the event. {} if not necessary.Ex:

tC.container.reload({events: {label1: [{target: document.getElementById('targeted_element'}, {"page_name":"", "product_id":""}]}})

• tC.container_IDS_IDC.reload() : this function allows loading a single container (to do so, you will have to specify the site’s and the container’s ID) on a page that contains more than one.

IDS : Commanders Act site ID IDC : Commanders Act container ID

• tC.container_IDS_IDC.reload({ exclusions: ["datastorage","deduplication","internalvars","privacy"], events: {label1: [{targeted_element},{event_variables}], label2: [{},{}]} })

This function allows loading a single container (to do so, you will have to specify the site’s and the container’s ID) on a page that contains more than one while excluding some of their elements. Elements to exclude need to be mentioned in the “exclusions” table, and event functions need to be mentioned in the “events” object, as for the tC.container.reload({exclusions:["datastorage","deduplication","internalvars","privacy"]}) function.

2.2 Loading tags

To load selected tags upon user action, you will need to implement this function:

• tC.event.label() : this function allows loading selected tags upon user action.

label: specify the name you wish to call your function. Ex: implement the tC.event.step2_basket function if your wish to call specific tags on the 2nd step in the purchase cart. You can also set-up a “generic” function like tC.event.all on all of your virtual pages to call tags on all of your SPA sites (Analytics tags, for instance). You will then use perimeters and constraints from the Commanders Act interface to control other tags’ execution.

• tC.event.label(this, {"page_name":"", "product_id":""}) : this function allows loading selected tags based on user action and to define variables specific to said action (ex : the name of a virtual page, a specific product id …).

2.3 Going further: Structure of a Commanders Act web Ccontainer

You will find below a list of all the elements that load inside the Commanders Act web container upon first load, as well as the tC.container.reload,(tC.container_IDS_IDC.reload()) and tC.event.XXX() functions that are called.

Documentation in progress

Documentation in progress

You can send us your users' data in 2 ways :

• API users

• Files importer (Get in touch with your Account Manager)

Getting Started

The onsite API is used to interact with Commanders Act features with JavaScript.

How to use

The onsite API consists of a single function, cact(), with the following strict signature:

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

Onsite API is included in each containers and privacy banners.

Send event

To send event data to the serverside Commanders Act platform, use this command:

cact('<event_name>', {<event_params>});

Example : to send a purchase event :

cact('purchase', { 
  id:'1234',
  currency: 'EUR',
  //...
});

Get information

To get various values from Commanders Act, use this command:

cact(get command, [callback])

Example : to get consent from TrustCommander, you can call the consent.get API like this:

cact('consent.get', function(result) {
    if (result.consent.status === "all-on") {
        
        // Consent available for all categories.
        
    }
});

Error handling

You can handle errors through error property in the callback object. Example:

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

    if (result.error) {
    
        // Manage the error
    
    }
    else if (result.consent.status === "all-on") {
        
        // Consent available for all categories.
        
    }
});

API Stub (optional)

For advance usage, we provide also an API stub that can be added when you need to interact with the API before containers or banners have loaded. This stub is already included in containers and privacy banners, so you do not have to add in most use cases. The stub is used to buffer all methods in a JavaScript array until Commanders Act JavaScript is loaded and ready to process the methods. This allows for example 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.

Documentation in progress

React native

We currently don't offer an official bridge for ReactNative as it's usualy quite easy for developpers to create it themselves.

Short version step by step process to use our solutions with React Native are as follow:

1. Read our SDKs documentations here: iOS & Android

2. Create your bridges for Android and iOS

3. Create an Android and/or iOS sources in our plateform.

4. Code the events and start sending them!

Long version:

Read our documentation

Before starting to code you will need to read our documentation here : iOS & Android We have many ways of using our solutions so you need to find the one fitting your needs. You might need the consent module for example.

Understanding this documentation will make the next step easier.

Create your bridges

It usually consist of one file translating the native functions to React Native. You'll most likely need one method to initialize the ServerSide class, several methods to create the events you need and one to send data.

Creating a source

To send and validate data to CommandersAct you need a SourceKey. To get it, you need to create a source inside our plateform.

Here's how to create a source

The source type is actually only here to help you sort your sources.

This source will also contain information about what is collected and the health of the implementation. Since you're using React Native you might only need to create one source and get one key. But you might also want to separate information coming from Android and the information from iOS it that's the case, simply create one source of each and in the wrappers check that you're giving the right key in the right wrapper.

Send events

This should be quite easy and straightforward now!

FAQ

What will happen if you release an official wrapper afterwards

Nothing. We will simply do the same thing as you've already done so you won't need to change anything!

You can send us your conversion's data in 4 ways :

• Conversion API (online/offline conversions)

• Files importer (FTP) online/offline conversions

• HTTP tracking API source (online/offlinepurchase event)

• Web Container (online purchase event)

Documentation in progress

Documentation in progress

Documentation in progress

Visitor

GET https://api.commander1.com/v1.0/engage/visitors/

This endpoint allows you to

get properties for one specific visitor

. When you create the token, you can define which properties to return.

\

This API is more designed to be called from a tag in each user's browser.

Query Parameters

{
    "user_age": 39,
    "user_privacy_categories": [
      "11",
      "12",
      "13"
    ]
}

User

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

This endpoint allows you to

get properties for one specific user

based on a

user_id

. When you create the token, you can define which properties to return.

Query Parameters

{
    "user_age": 39,
    "user_privacy_categories": [
      "11",
      "12",
      "13"
    ]
}

{
    "message": "Person not found"
}

User

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

Insert or update a user

Query Parameters

{"success":true}

Example Request

PUT

https://api.commander1.com/engage/user/?site=1234&user_id=1234&token=WvNIX8955cnZ7WF0f632s0Wb99Ql3rtA

{
"preferences.channel":"email",
"preference.frequency":"30d",
...
}

DELETE user

Delete a user

Resource URL

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

Resource Information

Parameters

Example Request

DELETE

https://api.commander1.com/engage/user/?site=1234&user_id=1234&tc_id=1234&token=WvNIX8955cnZ7WF0f632s0Wb99Ql3rtA

Response

{"success":true}

The HTTP Tracking API 1.0 lets you record data from any website or application. Requests are routed to our servers, and your data is routed to any destination you desire.

Setup

Headers

Authentication

Authenticate to the Tracking API by sending your project’s Source Key along with a request in the headers like so: Authorization: Bearer NJtcKaoCYu...mGZDxRgMBMUw==

Content-Type

To send data to our HTTP API, a content-type header must be set to 'application/json'.

Errors

We presently return a 200 response for all API requests, thus debugging should be done using the platform interface or our config API (event inspector or event delivery API). The sole exception is that if the request is too large or the JSON is invalid, it will return a 400.

Max Request Size

There is a maximum of 32KB per API request.

Rate limit

There is no real rate limit above which the system will discard your data. But if you need to import at a rate faster than 500 requests per second, please contact us beforehand.

Event API

You may use the event API to capture the actions that your users perform. Every action results in what is known as an "event," which have associated properties.

You should keep track of activities that are indications of your app's performance, such as Signed Up, Item Purchased, and Article Bookmarked. To begin, we recommend tracking only a few key events. More may easily be added later!

Example event call: (deprecated)

POST  https://collect.commander1.com/events?tc_s={siteId}

{
  "event_name": "search",
  "event_id": "202110130000000000",
  "event_timestamp": 1639044446636,
  "properties": {
      "search_term": "t-shirts", 
      "user": {
          "id": "12345",
          "email":"toto@domain.fr",
          "consent_categories": [1,3]
      }
  },
  "page": {
    "title": "Search page",
    "location": "https://shop.com/search?q=..."
  },
  "device": {
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36",
    "ip": "102.3.4.56", 
    "cookie":"_fbp=123; _fbc=456; _ga=789"
 }
}

Find details on best practices in event naming as well as the event method payload in our Spec.

You can send your product catalog data in 2 ways :

• Product API

• Files importer (FTP)

The “TEST” step seeks to prevent problems in production by testing the version of a container and diagnosing its compatibility and reliability.

At first, it will block deployment of the faulty container, but you can ignore some of the errors found, such as those resulting from incompatible JavaScript elements with old versions of browsers (IE8 for example).

A total of 8 browsers/OS are tested:

• The latest version of Edge

• The latest version of Chrome

• The latest version of Firefox

• The latest version of Opera

• The latest version of Safari (for the Mac OS)

• The latest version of Safari (for tablets)

• The latest version of Android (for tablets)

Tests are performed on five levels:

• Container: The container’s code (the JavaScript file) is tested globally

• Data layer: The data layer (internal and external variables, etc.) is tested in isolation

• Custom JS blocks: The static and dynamic JavaScript files are tested in isolation

• Tags: All tags are tested, and errors are displayed by tag

• Events: All events are tested, and errors are displayed by event

If no errors are detected, your version is “DEPLOYABLE”:

If an error is detected in your container, it will be indicated by a red “X” under the browser returning the error and on the line of the element the error was found in (Data layer, Custom JS blocks, Tags, Events); it will also appear on the Container line .

In this case, your container version is “NOT DEPLOYABLE” until you correct or ignore the error.

We recommend that you correct the errors detected in the Data layer, Custom JS Blocks, Tags, and Event before correcting the Container errors since the latter will most often disappear after the other four levels are corrected.

To display and correct errors, click on a red “X”.

A window will appear displaying the test error details. Below is an example of a possible tag error:

Error message details returned by the tested browser

Tag name and line number where the error is found. Clicking the button redirects you to the “Edit” step where you can correct your tag’s code directly.

Note: Do not hesitate to contact your personal consultant or the Commanders Act support team (support@commandersact.com) if you need help correcting an error.

Finally, the “TEST” step allows you to consult the error history for the different container versions generated. This history is displayed at the bottom of the “Test” page, where you can click the red “X“s again to display the error details:

These variables are called external variables because they are outside the Commanders Act web container: They are embedded directly in the source code of your site’s pages, in contrast with internal variables, which are created inside the container and therefore not visible in the page’s source code. External variables are added by your technical teams or the technical provider in charge of implementing Commanders Act web containers on your site.

External variables are indispensable since they contain most of the data sent to the solutions present in the container. Their function and number vary depending on the site’s economic model (for example, media sites will not have the same external variables as e-commerce sites).

The list of external variables must be considered and established before Commanders Act web container is implemented in order to meet the embedded solutions’ medium- to long-term needs. A summary of the external variables to implement on your site will be provided by your Commanders Act consultant during the setup phase of the TMS, in an Excel file named “deliverables” or “tagging plan“.

External variables must be declared in the Commanders Act interface before you begin configuring tags in your containers. See the “Adding external variables” article in this section to find out how to declare an external variable in the interface.

All declared external variables can be used:

– To pass information to the solutions embedded in the container (linking external variables and solutions is called mapping). See the “Mapping Tags’ Variables” article to find out how to map your external variables in a tag.

– To create activation rules for your tags. See the “Adding Rules” section to find out how to create rules based on your external variables.

Additional information

As with your container, external variables must be present on all of your site’s pages and assigned values suited to the context. For example:

– The value of the “page template” variable will be different for the most important page templates on your site: homepage, product page, confirmation page, etc.

– The value of the “user id” variable will change for each visitor that connects to your site.

External variables must be declared in your site’s source code before the call to your containers (=JavaScript files). If you have a header container, the external variables will thus be present in the <head>; if you have a container in the body, they must be declared in the <body> html tag.

Here is a sample list of external variables:

<script type="text/javascript">
var tc_vars = new Array();
tc_vars["env_work"] = 'Prod';
tc_vars["env_channel"] = 'Web';
tc_vars["env_language"] = 'fr';
tc_vars["env_country"] = 'FR';
tc_vars['page_type'] = 'Homepage';
tc_vars["page_name"] = 'Tag Commander Market';
tc_vars["page_category_1"] = '';
tc_vars["page_category_2"] = '';
tc_vars["page_category_3"] = '';
</script>

/* Data layer is setup - call the Web Container Script underneath */

<script type="text/javascript" src="//cdn.tagcommander.com/674/my_web_container.js"></script>

Adding external variables

There are two situations in which you may need to declare your variables in the external variable management interface:

1) You wish to install Commanders Act on a new site: prior to having your technical teams or technical provider implement the data layer/variables in your site’s source code, you need to declare the variables in the Commanders Act interface so they are available for mapping.

2) Information is missing from your current tagging plan (e.g. customer status): Again, this variable must be declared in the interface first, before it can be used in your tags and rules.

Note: If necessary, you can click “Download“, to retrieve your external variables in JavaScript format and send them to your technical team or the technical provider in charge of implementing the variables in you site’s source code:

Clicking “Download” will open a window containing the JavaScript code to insert in the site’s source code:

To add an external variable, you must go to the “Data Management” > "Web Data layer" > “External Variables” and click “ADD VARIABLE”

The “add variable” window contains various fields:

“Name“: the variable’s name (mandatory field).

“Category“: used to categorize the variable according to its application (e.g. variable relative to users, product pages, confirmation pages, etc.) See the “Categorizing External Variables” article in this section.

“Type“: The type of variable. See the “Managing Variable Types” article in this section.

“Use in noscript“: Check the box so that the variable is present in the tag’s noscript code.

“Description“: A description of the variable, to clarify the variable’s name (e.g. “Page template” can be the description of the variable named “env_template”).

“Detailed description“: A detailed description of the variable, to further clarify the variable’s name (e.g. “possible values: homepage/category/product/funnel_confirmation” can be the detailed description of the “env_template” variable).

Once the variable is added, it will appear on the variables list:

Categorizing external variables

Variables can be categorized for easier management.

Categories allow you to classify variables according to their application (e.g. variables relative to site users in the “Users” category, variables for product pages in the “Product page” category, generic cross-functional variables for the site in the “Environment” category, etc.)

Categories are managed by clicking the “manage categories” button to the left of the “ADD VARIABLE” button:

Once your category is created, it can be used in the window to add and edit external variables; you can edit them by clicking the pencil icon, delete them by clicking the cross and adding them by entering a name and clicking the blue "+" button :

Managing variable types

The variable “type” (also called “processing function“) allows you to modify the variable format on the fly when mapping your tags.

They are useful when one of your solutions requires a variable format that is different from the format used in the external variables by the technical teams in charge of implementing the data layer.

For example, if your “page_name” variable contains special characters in the source code, the processing functions allow you to correct them so that your solutions can receive the value without special characters.

The most commonly used types are:

• Order amount: this allows you to modify the number format (amount) on the fly.

You can change separating commas into periods (e.g. “12,50” becomes “12.50”), choose the number of decimal places to retain (e.g. “12.50 becomes “12.5”), or convert the amount into pennies (“12.50 becomes “1250”).

• Alphanumeric & Special chars: this allows you to modify the character string format on the fly.

You can replace special characters with “_” (e.g. “the company&its values” changes to “the company_its values”) or truncate a character string (e.g. limiting the variable’s value to 10 characters).

After assigning a variable type, you can modify its value on the fly, tag by tag, in the “EDIT” interface. Variables with a type added will have a blue symbol in front of their name (1):

Once you have mapped your variable, click the link symbol:

A window will appear with a list of different operations corresponding to the type chosen. Check the box corresponding to the operation you want (for example, remove special characters and replace them by “_”) and click “SAVE” :

Advanced : 2-dimensional array

This type can be assigned to variables having a two-dimensional array as a value. On an ecommerce site, this will deal very often with “list_product” and “order_product” variables that return, respectively, information on products displayed on a category page or added to the cart.

We speak of “two-dimensional arrays” since these variables return an array of values for each product (e.g. for all the products on the site’s page, their ID, name, price, quantity, etc.).

Certain partner solutions may request that you send product data in their tag that are separated by a character called a “separator” (e.g. all product IDs separated by “|“, or all product prices separated by a comma in their confirmation tag).

The operation will be much easier if you select the “Two-dimensional array” processing function for your “order_product” variable.

You will then be able to send your partners the information they expect without requiring any knowledge of JavaScript.

The first step in the configuration process is to select the “Two-dimensional array” type (1) for your variable:

Once this type is added, click on the “List” icon that appears next to your variable to see a summary of the external variables:

Enter all your array keys in the window that appears (e.g. if your main variable is “list_products”, the keys will be characteristics of your products, i.e. the ID, name, price, etc.):

After selecting the “Two-dimensional array” type for your variable go to the “EDIT” step. Click the symbol appearing to the left of the variable that you just mapped:

Enter the array key in the configuration window (e.g. the product ID) and the separator:

You can also use the “Two-dimensional array” type to create internal variables that return product keys separated by the symbol of your choice. For more information, go to the “Adding Custom Internal Variables – Builder Mode” article.

Editing and deleting external variables

You can edit an external variable by clicking the “Edit” icon and delete it by clicking the trash can. The flag next to the variable’s name will tell you if it is mapped and the tag(s) it is mapped with:

Note: The variables used in a container (to be added to a tag, for example) cannot be deleted, and their names cannot be modified.

By clicking on the flag, you will see which container(s), tag(s) or rule(s) use this variable:

These variables are called internal variables because they are created inside the Commanders Act web container: They are integrated directly into your site’s container, in contrast with external variables, which are added into the page’s source code by the technical staff.

Internal variables are used to collect data to enrich data through the external variables. A library of predefined internal variables is available, but you can also create your own.

Internal variables must be created in the Commanders Act interface before they can be used in containers. See the rest of the articles in the “internal variables” section to know more about the different options available to create such variables.

All internal variables created can be used:

• To be added to the solutions embedded in the container (linking internal variables and solutions is called mapping). See the “Mapping tags’ variables” article to find out how to map your internal variables in a tag.

• To create activation rules for your tags. See the “Adding Rules” article to find out how to create rules based on your internal variables.

Additional information

Internal variables are all coded in JavaScript, but you do not need any technical knowledge of JavaScript in order to use the “Predefined” variables or the “Builder” modes, since the code is generated automatically by the Commanders Act. However, you will need to know JavaScript or seek help from the Commanders Act support team in order to create your own custom internal variables.

Here are some examples of predefined internal variables:

• Internal variable for retrieving the URL of the page:
• Internal variable for retrieving the URL of the previous page/site:
• Internal variable for retrieving what comes between the first “/” and second “/” of the URL:

  Copy

  tC.internalvars.tc_url_1 =(function(){
  tC.internalvars.tc_url_1_tmp = document.location.href.split('?');
  tC.internalvars.tc_url_1_tmp2 = tC.internalvars.tc_url_1_tmp[0].split('/');
  return tC.internalvars.tc_url_1_tmp2[3];
  })();

When to add an internal variable

There are several situations in which you may need to create an internal variable using the internal variable management interface:

• You want to retrieve elements available on your web pages, but they do not have external variables implemented by technical staff (for example: the value of a cookie, HTML tag, URL, etc.).

• You want to create a new variable based on the values of external variables already implemented by technical staff (for example: calculating the cart’s total before tax using the external variable that returns the cart’s total including tax).

• You want to create a lookup table based on an external variable (for example: when the external “country” variable is “FR”, you send an account number to your analytics tool that is different from when the variable is “IT”).

• Etc.

The link created between the internal variables and the solutions is called “mapping“. This is performed in the “EDIT” tab during the container deployment process.

Types of internal variables

There are two types of internal variables: predefined and custom.

• Predefined internal variables, have already been created and are ready to use (e.g. variables that retrieve URL fragments).

• You can also configure your own internal variables, using pre-existing variables (e.g. external variables) or retrieving elements available on your sites’ pages (e.g. cookies).

To declare a predefined internal variable, click "Data Management” > "Web Datalayer" > “Internal Variables” > “ADD PREDEFINED VARIABLE”:

You will then be prompted to select a predefined variable universe.

The “add variable” window contains various fields:

“Predefined universe“: Selection of predefined internal variable categories

“Name“: Variable’s name

“Description“: Variable’s description

“Code“: Variable’s code

Checkbox: The selection of predefined internal variables to add to the container (it is futile to include variables you do not wish to use).

Four predefined variable universes (“Predefined universe”) are available:

• Common variables: The most used variables by both Commanders Act consultants and customers.

• Customer journey variables: Variables that exploit the visitor’s customer journey (prerequisite: the "deduplication" module must be activated).

• AT Internet plugin: Variables that exploit data collected by the AT Internet digital analytics solution (prerequisite: the AT Internet solution must be present on your site).

• Partner tags: Code snippets adapted and adaptable to partner tags to increase their potential and perform additional actions.

Add build-in internal common variable

You will find below a list of the variables available in the “Common variables” category and their description

Page title: it stores the title of the page (from the <title> html tag).

Example:

The value of this variable (on the http://www.tagcommander.com/fr/) page will be “Commanders Act – Tag Universel – Tag Management – Commanders Act”. It takes the value of the html <title> tab.

***

Page URL: it stores the URL of the current page.

Example:

The value of this variable for the “http://www.tagcommander.com/fr/” page will be “http://www.tagcommander.com/fr/”

***

Previously Visited URL: it stores the URL of the previous page

Example:

If the visitor arrives at the Commanders Act site via the Google search engine, the value of this variable will contain “google.fr”

***

Page URL without query string: it stores the URL of the current page without the tracking parameters (Commanders Act will remove the “?” from the URL and everything after it.

Example:

If the visitor is on the page “https://www.google.fr/webhp?tab=ww&ei=-ATjVPTyFaWqywOpqoHYDw&ved=0CAcQ1S4#q=inurl&start=10″, the value of this variable will be “https://www.google.fr/webhp”

***

Page query string only: it stores the the current page’s URL parameters (Commanders Act a will save everything that follows the “?” without including it).

Example:

If the visitor is on the page “https://www.google.fr/webhp?tab=ww&ei=-ATjVPTyFaWqywOpqoHYDw&ved=0CAcQ1S4#q=inurl&start=10″, the value of this variable will be “tab=ww&ei=-ATjVPTyFaWqywOpqoHYDw&ved=0CAcQ1S4#q=inurl&start=10”

***

URL parameters: it stores the current page’s array of URL parameters.

Example:

If the visitor is on the page “https://www.google.fr/webhp?tab=ww&ei=-ATjVPTyFaWqywOpqoHYDw&ved=0CAcQ1S4#q=inurl&start=10″, this variable will contain the value of these three parameters: “tab”, “ei” and “ved”, and their values will be accessible in the following manner: “tc_array_url_vars[‘tab’]”, “tc_array_url_vars[‘ei’]” and “tc_array_url_vars[‘ved’]”

***

Folder #1 in URL: it stores the First “folder” in the current page’s URL

Example:

If the visitor is on the page “http://www.tagcommander.com/fr/fonctionnalites/tag-management”, the value of this variable will be “fr”.

***

Folder #2 in URL: it stores the second “folder” in the current page’s URL

Example:

If the visitor is on the page “http://www.tagcommander.com/fr/fonctionnalites/tag-management”, the value of this page will be “fonctionnalites”

***

Folder #3 in URL: it stores Third “folder” in the current page’s URL

Example:

If the visitor is on the page “http://www.tagcommander.com/fr/fonctionnalites/tag-management“, the value of this variable will be “tag-management”

***

Random value(integer 9 digits): it creates and stores a random number composed of 9 digits

Example:

With each pageview/loading of this variable, the variable will return a random 9-digit number; for example, “255103492”

***

URL pathname without query string /…/…/….html: it stores the current page’s URL without the parameters (including the “/”)

Example:

If the visitor is on the page “https://www.google.fr/webhp?tab=ww&ei=-ATjVPTyFaWqywOpqoHYDw&ved=0CAcQ1S4#q=inurl&start=10″, the value of this variable will be “/webhp”

***

Https protocol? “yes”/”no”: Sends “yes” if the page uses the “https” protocol and “no” if it does not

Example:

If the visitor is on the page “https://www.google.fr/webhp?tab=ww&ei=-ATjVPTyFaWqywOpqoHYDw&ved=0CAcQ1S4#q=inurl&start=10″, the value of this variable will be “yes”

***

Current domain name (www.domain.com): it stores the current page’s domain name

Example:

If the visitor is on the page “http://www.tagcommander.com/fr/fonctionnalites/tag-management”, the value of this variable will be “www.tagcommander.com”

***

Main domain name without subdomains: it stores the current page’s domain name without the subdomains

Example:

If the visitor is on the page “http://www.tagcommander.com/fr/fonctionnalites/tag-management”, the value of this variable will be “tagcommander.com”

***

Unix timestamp: Current UNIX time (the number of seconds since January 1, 1970 00:00:00)

Example:

The current UNIX time when this document was written was “142166467”

***

Device: This variable provides information regarding a user’s device based on their screen resolution.

Adding built-in customer journey internal variables

You will find below a list of the variables available in the “Customer journey variables” category and their corresponding description:

Last touch name (channel): Channel of the last touchpoint saved (prerequisite: deduplication must be active on your site).

Example:

For customer journey “SEO/Google -> SEM/Bing -> Display/Criteo” the value of this variable will be “Display”.

***

Last touch name (source): Source of the last touchpoint saved (prerequisite: deduplication must be active on your site).

Example :

For customer journey “SEO/Google -> SEM/Bing -> Display/Criteo” the value of this variable will be “Criteo”.

Adding customer internal variables

You can create your own internal variable in two ways:

• Via the “Builder” tab: The “Builder” mode assists you in creating customized internal variables without any technical knowledge or expertise;

• Via the “Custom” tab: “Custom” is a completely customized mode used to write your own JavaScript code. This method requires technical knowledge and expertise (but your Commanders Act consultant or support team can create custom variables for you if necessary).

To create your own internal variable, click "Data Management” > "Web Datalayer" > “Internal Variables” > “ADD VARIABLE”:

The “add variable” window contains various fields:

“tC.internalvars.“: The variable’s name (caution: it must not contain any accents or special characters, especially “-“).

Note: The variable’s name is always prefixed by “tC.internalvars.” in order to avoid conflict with other variables on your site. For example, to see the content of an internal variable directly on your site or use a variable on another site, do not forget to specify the full name of the variable, which includes the prefix “tC.internalvars.” along with the variable’s name.

“Builder“/”Custom“: Select “Builder” or “Custom” creation mode

Area to create the variable (see details below for the Builder and Custom modes)

“Type“: The type of variable. Please refer to the article “Managing Variable Types“.

“Description“: A description of the variable, to clarify the variable’s name (e.g. “Product IDs separated by a /” can be the description of the variable named “tC.internalvars.concatid”)

“Detailed description“: A detailed description of the variable, to further clarify its name (e.g. “ID1/ID1/ID2…” can be the description of the variable named “tC.internalvars.concatid”)

Builder mode

The “Builder” mode offers you three types of operations (1) that we describe below:

• “Join internal and/or external variable(s)”;

• “Join two-dimensional array variable(s)”;

• “Variable mapping”.

Join internal and/or external variable(s)

This operation allows you to join internal or external variables with the separator of your choice.

Example:

If you wish to join an external variable returning the order ID with another external variable returning the order amount, with everything separated by a “-“, select the “order_id” variable in the “External variables” tab to the left and then enter and add your separator in the “add separator” field in order to finish the “order_amount” variable in the “External variables” tab.

Join two-dimensional array variable(s)

This operation allows you to join the array keys of a “Two dimensional array” variable.

Example:

Your retargeting provider wants you to send all the prices of the products added to the cart separated by “|”. Begin by selecting the variable that contains the product information on the cart page (here the “user_id” variable) (1), then the “order id” variable (here the “order_confirmation_id” key) and the separator “|”. For example, the value obtained might be: “user@mail.com|123456789AB”.

Variable mapping

This operation allows you to create a lookup table for an input value (via an already existing internal or external variable) and an expected output value.

Example:

You want to send a different account ID to your Digital Analytics solution depending on the work environment (pre-prod or prod). Select your reference variable (here the external variable “env_work”), add its different input values in the “INPUT” field (e.g. “pre-prod” et “prod”) and then add the output account IDs of your analytics solution in the “OUTPUT” field. You can also add a default value if none of the values entered in the “INPUT” field have been foundj,yècr èuc.

This operation allows you to automatically send the correct account ID to your analytics solution depending on the work environment.

Full custom mode

The “Custom” mode allows you to write your own JavaScript code to create the internal variable of your choice:

Note: make sure that the variable’s JavaScript code always has the following syntax: tC.internalvars.nameVariable = "yourCode";

Also, make sure that nameVariable has the same name as the variable entered in the “tC.internalvars” field (see first screenshot with the variable tC.internalvars.my_custom_var):

Note: To avoid potential errors when the internal variable’s code is included, the “TEST” step of the container deployment process will test your internal variable on multiple browsers/operating systems.

Managing variable types

The variable “type” (also called “processing function“) allows you to modify the variable format on the fly when mapping your tags.

They are useful when one of your solutions requests a variable format different from the format that you return in your internal variable. For example, if your “order_discount” variable contains three decimal places, the processing functions will allow you to correct this so that your solutions receive the value with only 2 decimal places.

The most commonly used types are:

• Order amount: this allows you to modify the number format (amount) on the fly.

You can change separating commas into periods (e.g. “12,50” becomes “12.50”), choose the number of decimal places to retain (e.g. “12.50 becomes “12.5”), or convert the amount into pennies (“12.50 becomes “1250”).

• Alphanumeric & Special chars: this allows you to modify the character string format on the fly.

You can replace special characters with “_” (e.g. “the company&its values” changes to “the company_its values”) or truncate a character string (e.g. limiting the variable’s value to 10 characters)

After assigning a variable type, you can modify its value on the fly, tag by tag, in the “EDIT” interface. Variables with a type added will have a blue symbol in front of their name:

Once you have mapped your variable, click the link symbol:

A window will appear with a list of different operations corresponding to the type chosen. Check the operation you want (for example, encode an email in sha256) and click “SAVE”)

Categorizing internal variables

Since you can create a variable using other variables, it is important for you to be able to manage the order in which they are executed so as to avoid any problems.

Therefore, you must declare an internal variable A, on which an internal variable B is based, before variable B. Variable B needs variable A declared first in order to be executed without creating errors.

The variables’ order can be modified using the double-arrow icon:

To categorize an internal variable you must :

• Click the edit button (pencil icon to the right in the same row where the internal variable is located) and select the type from the drop down menu as depicted below. This applies only when you add a predefined variable.
• Select the type when you add a custom variable, whether with the “Builder” or ‘Full Custom” mode. (Similar window as the one above).

Declare an internal variable in a container

You can link an internal variable to a container if you have multiple containers on your site.

By doing this action, you declare just once the internal variable code in the linked container(s).

Consequences:

• You reduce the weight of the other containers by avoiding to declare many times the code of one single internal variable.

• If you call 2 containers on the same page, you avoid to overwrite the variable value defined in the first container by the value defined in the second container (if the value can change during the page load)

Example: two containers are on the same page, one in the header and one in the body. If you link an internal variable to the header container you will reduce the code of the page as the variable won’t be declared twice, and keep the value of the variable defined in the header.

To link an internal variable to a container, select the container of your choice when you create or modify your variable in the “Declared in container” field:

To realize a bulk action on multiple variables, check the variables of your choice, then choose the container(s) in the list:

Perimeters and Constraints are two methods to conditionally fire your tags.

• Under the Perimeter panel, tags fire if at least one rule is true.

• Under the Constraints panel, tags fire if all rules are true.

Variable

The “Variables” tab allows you to create rules based on your data layer variables (external variables, internal variables, events attributes, events variables):

Condition and behavior

“If Variable Equals“: Tag activated if the variable equals the specified value.

“If Variable is Not Equal“: Tag activated if the variable differs from the specified value.

“OR Condition (One Variable)“: Tag activated if the variable equals at least one of the specified values.

“NAND Condition (One Variable)“: Tag activated if the variable equals two or more specified values.

“OR Condition (Up To Six Possible Variables)“: Tag activated if at least one of the variables equals the specified value.

“AND Condition (Up To Six Possible Variables)“: Tag activated if all the variables equal all the specified values.

“Greater than condition“: Tag activated if the variable is greater than the specified value.

“Less than condition“: Tag activated if the variable is less than the specified value.

“If Variable Contains“: Tag activated if the variable contains the specified value.

“If Variable Does Not Contain“: Tag activated if the variable does not contain the specified value.

“If Variable Matches“: Tag activated if the variable matches the specified value (regular expressions allowed: * to match any character and ^ for “variable begins with”).

“If Variable Doesn’t Match“: Tag activated if the variable does not match the specified value (regular expressions allowed: * to match any character and ^ for “variable begins with”).

In which case using “external variables” for the mapping?

When you want to create a rule based on a tc_vars from the data layer implemented on your website.

Example: your technical team has implemented an env_country variable, and you want to create a rule based on it:

In which case using “internal variables” for the mapping?

When you want to create a rule based on a variable that you have created by yourself, from the internal variable interface.

In which case using “event variables” for the mapping?

When you want to create a rule based on a variable specific to an event.

Example: The following event is implemented in your site’s source code:

tC.event.add_to_cart(this, {"product_name":"iphone", "product_id":"1234"})

To call a tag only if the product name is “iphone”, you have to select the event variable named “product_name” and configure it in the following manner:

Cookie

The “Cookie” tab allows you to create rules based on cookies you have previously created in the Commanders Act interface or which are available for your site’s domain name (first-party cookies).

Condition and behavior

“If Cookie Equals“: Tag activated if the cookie’s value equals the specified value.

“If Cookie Is Not Equal“: Tag activated if the cookie’s value differs from the specified value.

“If Cookie Contains“: Tag activated if the cookie’s value contains the specified value. In case of multiple values : enter all the values in the field separated by a comma ",". Don't use space between.

“If Cookie Doesn’t Contain“: Tag activated if the cookie’s value does not contain the specified value. In case of multiple values : enter all the values in the field separated by a comma ",". don't use space between.

Example with multiple values: In order to call a tag when your “consent_status” cookie equals “exempt” or "optin", you must select the “If Cookie Equals” rule and configure it in the following manner:

URL

This tab allows you to create rules based on your site’s URLs (note: we recommend that you use rules based on variables instead of URLs since the rule will become obsolete if your URL changes in the future):

Condition and behavior

“If URL Equals“: Tag activated if the URL equals the specified value.

“If URL Contains“: Tag activated if the URL contains the specified value. In case of multiple values : enter all the values in the field separated by a comma ",". Don't use space between.

“If URL Doesn’t Contain“: Tag activated if the URL does not contain the specified value.

“If URL Matches“: Tag activated if the URL matches the specified value (regular expressions allowed: * to match any character and ^ for “variable begins with”).

“If URL Doesn’t Match“: Tag activated if the URL does not match the specified value (regular expressions allowed: * to match any character and ^ for “variable begins with”).

Example: to call a tag when your URL indicates that the user is on the product page (providing your product page URLs are all structured the same: https://www.site.com/$category$/$subcategory$/product_$product_ID$), you have to select the “If URL Matches” rule and configure it in the following manner:

Browser

This tab allows you to create rules based on browsers.

Condition and behavior

“If Browser Is“: Tag activated if the browser is (choose from the list).

“If Browser Is Not“: Tag activated if the browser is not (choose from the list).

Mobile

This tab allows you to create rules based on the type of device.

Condition and behavior

“If Device / OS Is“: Tag activated if the device is (choose from the list).

“If Device / OS Is Not“: Tag activated if the device is not (choose from the list).

“If Device / OS Is Android Tablet“: Tag activated if the device is an Android tablet.

“If Device / OS Is Android Mobile“: Tag activated if the device is an Android mobile device.

“If Device / OS Is Not Android Tablet“: Tag activated if the device is not an Android tablet.

“If Device / OS Is Not Android Mobile“: Tag activated if the device is not an Android mobile device.

Example: to prevent a tag from being called on an Android mobile device, you must select the “If Device Is Not Android Mobile” rule and configure it:

DataCommander

This tab allows you to create rules based on the type of audience segments created in DataCommander.

Condition and behavior

“DataCommander OR condition (up to six variables)“: Tag activated if at least one of the audiences equals the specified value.

“DataCommander AND condition (up to six variables)“: Tag activated if all the audiences equal all the specified values.

“DataCommander Event activation“: Tag activated on an event

Advanced rules

This tab allows you to create all types of advanced rules. For example, you can create sampling rules or even “Custom” rules:

Condition and behaviour

“Sampling (1/X) (Page Based)“: Tag activated in X% of page views.

“Sampling (1/X) (Session Based)” : Tag activated in X% of visits.

“Sampling (1/X) (Visitor Based)“: Tag activated for X% of visitors.

“(A or B or C or D or E) AND (F or G or H or I or J)“: Tag activated if at least one of the variables in the first group AND at least one of the variables in the second group equal the specified values.

“(A and B and C and D and E) AND (F or G or H or I or J)“: Tag activated if all the variables in the first group AND at least one of the variables in the second group equal the specified values.

“(A and B and C and D and E) OR (F and G and H and I and J)“: Tag activated if all the variables in the first group OR all the variables in the second group equal the specified values.

“(A and B and C and D and E) OR (F or G or H or I or J)“: Tag activated if all the variables in the first group OR at least one of the variables in the second group equal the specified values.

“(A different than VALUE1) OR (B different than VALUE2)“: Tag activated if the first variable is not equal to a value OR the second variable is not equal to a value.

“(A different than VALUE1) OR (B equals VALUE2)“: Tag activated if the first variable is not equal to a value OR the second variable is equal to a value.

“(A different than VALUE1) AND (B different than VALUE2)“: Tag activated if the first variable is not equal to a value AND the second variable is not equal to a value.

“(A different than VALUE1) AND (B equals VALUE2)“: Tag activated if the first variable is not equal to a value AND the second variable equals a value.

“In Array“: Tag activated if the variable is present in the variable array.

“In Sub Array“: Tag activated if the variable is present in a variable array key.

“Array Intersection”: Tag activated if two variables from two variable arrays are equal.

“Custom“: Custom rule (to define in JavaScript).

Example: In order to call a tag for 25% of site visitors, you must select the “Sampling (1/X) (Visitor Based)” and configure it in the following manner:

Event variables are the variables present in Commanders Act browser-side events. They are used primarily for tracking user actions (button clicks, links, etc.).

Event variables are useful if you want to send data specific to an event without having these data on your site pages as external variables.

Example: you wish to assign an event for the “Send” button on your form. The event variables could be the user’s last name, first name, email address and telephone number. These are data that are not available when the page is loaded; it only becomes available after the user has completed the fields on the form and clicked “Send”.

Event variables must be added in the Commanders Act interface before they can be used, and only for events, not tags.

Event variables must be created in the Commanders Act interface before they can be used in an event. See the “Adding event variables” article to find out how to create an event variable in the interface.

All event variables created can be used:

• To add information to the solutions embedded in Commanders Act (linking event variables and solutions is called mapping). See the “Mapping Tags’ Variables” article to find out how to map your variables in an event.

• To create activation rules for your events. See the “Adding Rules” section to find out how to create rules based on your event variables.

Additional information

Event variables must be implemented in the Commanders Act event function (tC.events).

Note: External variables that are already available on the page do not need to be implemented in your event. For example, you do not need to assign a “country” variable to an event if this information is already present in an external variable.

Here is an example of an event variable:

<a onclick="addtocart(0);{tC.event.addtocart(this, {'productID':123, 'user_email':'john@mail.com'})}">Add to cart</a>

When to add an event variable

There are two situations in which you may need to declare your variables in the event variable management interface:

• You want to implement Commanders Act events on a new site. The variables that your technical staff or technical provider implement in the site’s source code (in the tC.events function) must be declared in the interface first in order to be available to be added to your tags and rules.

• Variables are for your current event functions are missing or you want to add a new event to your site. Again, this variable must be declared in the interface first before it can be used in your tags and rules.

Adding event variables

To add an event variable, you must go to the "Data Management” > "Web Datalayer" > “Event Variables” and click “ADD VARIABLE”:

The “add” window consists of the following elements:

“Name“: the variable’s name (mandatory field)

“Type“: the variable’s type

“Description“: A description of the variable, to clarify its name (e.g. “Page template” can be the description of the variable named “env_template”)

“Detailed description“: A detailed description of the variable, to further clarify tits name (e.g. “possible values: homepage/category/product/funnel_confirmation” can be the detailed description of the “env_template” variable)

Editing or deleting variables

You can edit an internal variable by clicking the “Edit” icon and delete it by clicking the “X”:

A Website’s performance is key to SEO and user experience; however, the increasing amount of tags used on websites nowadays has an impact on loading times.

In this context, tags’ performance has become a strategic matter.

Commanders Act's “TagPerformance” module offers the possibility to measure your site’s performance based on the tags that are placed on it. It acts as a complementary tool to those used by IT departments to measure loading times of websites’ key elements (images, CSS …)

TagPerformance’s main features include:

• A measuring tag executed on the end client’s browser and not by a robot.

• Analysis of the START RENDER, DOM READY and DOM LOADED events to measure performance.

• The possibility to visualize significant variations in tags and page types, free from the noise resulting from the analysis of micro-variations.

• Information on loading times of partner solutions in relation with the average loading times of other solutions to ensure loading times are correct.

• Data segmentation to identify sources of problems, if any, or to focus on a particular segment: container, page type (product, home page), device (mobile, tablet, PC), OS and browser.

TagPerformance is one of the additional modules for the Commanders Act product: if you wish to use it on your website(s), please contact your account manager or reach out to our Support Department (support@commandersact.com)

Metrics

TagPerformance allows you to analyze three events:

• START RENDER or FIRST PAINT: This is when the first element is displayed on the page.

This metric is key to bounce rates (if initial visual elements take too long to load, users will most often leave a site) and SEO (“dwell time” metric).

• DOM READY: this is when a page’s structure is loaded and analyzed by the browser.

• PAGE LOADING TIME or ONLOAD or DOM LOADED: this is when the page’s content has finished loading. This metric is useful for SEO.

Loading order of a web page’s elements:

Example:

Page A and page B take both 12ms to load; DOM loaded is the same for both of them. However, Start Render and DOM Ready events are optimized for page A but not for page B.

How it works ?

• The page loads with the Commanders Act container.

• The Commanders Act container calls the tags placed on the page and loads the “Commanders Act – TagPerformance” tag two seconds after the DOM Loaded event.

• The “Commanders Act – TagPerformance” tag captures information provided by the browser thanks to the Navigation Timing API, which is compatible with 88% of existing browsers. The information that is captured includes:

• Generic information about the page: Start Render, DOM Ready and DOM Loaded

• Information about every tag that is executed on the page: hits’ aggregated loading time before Start Render, DOM Ready and DOM Loaded happen (separately).

Example:

This is the structure of a page from a website:

“Tag 1” sends 4 hits:

• One that loads before the Start Render event (300ms)

• One that loads before the DOM Ready event at (400ms)

• One that starts loading before DOM Ready and finishes loading during the DOM Loaded event (600ms)

• One that loads after the DOM Loaded event (100ms)

“Tag” 2 sends 2 hits:

• One that loads during the Start Render event (700ms)

• One that loads before the DOM Loaded event (200ms)

With the “TagPerformance” tag, Commanders Act will count the following loading times for tag 1:

• Hits’ aggregated loading time before the Start Render event (300ms).

• Hits’ aggregated loading time before the DOM Ready event: 1300ms (the first and second hit’s respective loading times of 300ms and 400ms are stored and added to the 600ms loading time of hit three, which is sent during the DOM Ready event).

• Hits’ aggregated time before the DOM Loaded event: 1300ms (all hits’ loading times are stored: 300ms, 600ms and 600ms for hits one, two and three, respectively).

• Total loading time of tag1 (1400ms)

The “TagPerformance” tag will count the following loading times for tag 2:

• Hits’ aggregated loading time before the Start Render event (700ms)

• Hits’ aggregated loading time before the DOM Ready event (700ms)

• Hit’s aggregated loading time before the DOM Loaded event (900ms)

• Total loading time of tag1 (900ms)

It will also count generic loading times on the page:

• Start Render (700 ms)

• DOM Ready (2000 ms)

• DOM Loaded (2800 ms)

All this data will populate TagPerformance’s reports.

Commanders Act provides a GTM template to connect your existing GTM implementation to our serverside endpoint, in a secured environment.

Setup

Summarizing all recommended steps:

1. Create a GTM source in Commanders Act

2. Add our template to your GTM implementation

3. Configure your tag

Create a source in Commanders Act

In your Commanders Act dashboard:

• In the left pane menu, click on Sources > Overview.

• Click on the Add source button.

• In the catalog, search for the Google Tag Manager source and click on it.

• Click on Configure and set its name, environment and bound destinations.

• Once you're done, click on the Create button at the bottom.

• The source key will then be displayed:

• Copy its value and keep it for later!

Add our template to GTM

First, access GTM and then add our template "Commanders Act | Serverside events bridge" from the Google "Community Template Gallery" in your workspace, then select (1) "Tags".

Click on (2) the "New" button.

Click on (3) the "Tag Configuration" area.

Click (4) the magnifying glass in the upper right corner.

Search for (5) the "Commanders Act | Serverside events bridge" custom template and click on it to start the configuration.

Configure your tag

Start by filling (6) a name for your tag in the upper left corner.

Input your (7) "Commanders Act Site ID" and (8) "Commanders Act Source Key" (refer to the first section on how to create a source and retrieve its key).

Select (9) the "Commanders Act Event" from the drop-down menu, which is the event you want to forward.

Depending on which event you select more (or less) fields will be presented. In case you don't input a mandatory field the template will highlight the missing entry so you can provide a proper mapping.

The "Event Fields" section contains fields that define the event itself and are mostly mandatory or highly recommended.

Events including the "Product Fields" section require an array structure for your product information. The first field will always be the (10) base array where the information is stored and all subsequent fields are the related properties - E.g. you can map the information about (11) the "Product Id" by filling the property name.

In the "User Fields" section you can set (12) the "User Id" and (13) "User Email" - Either one of them is required if you select the "Purchase" event. The (14) "User Consent Categories" is a mandatory field holding an array with the user's consent category identifiers.

It's important to define and map all category identifiers with their respective names. For example, you may have the following array: [1,2,4] and you defined the following relationship:

• 1 ➜ Advertising category

• 2 ➜ Analytics category

• 4 ➜ Functionality category

You also share with Commanders Act that the "Advertising category" must be enabled to activate the "Facebook CAPI." In this example, since the category identifier [1] is included in the array we can activate the bridge and forward the event to Facebook.