Loading...
Overview of TagCommander Setup Guides per platform.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
How to condition tags to user consent
Commanders Act provides a Consent Management Platform (CMP) to easily manage the consent https://www.commandersact.com/en/solutions/trustcommander/ https://community.commandersact.com/trustcommander/
If you already use your own CMP, you can of course manage the way your tags will be triggered through your own CMP setup.
The recommended way is to attached a custom trigger to each of your tags and to manage this trigger inside your CMP to launch or not launch tags depending of the user's consent.
Warning : some part of TagCommander code is not inside tags, see below how to manage consent on custom code or core code
If you have written custom javascript code and/or internal variables that create cookies or send data, you'll have to link this code to your CMP. Of course it will depend of your CMP method, but the recommended way is to wrap your custom code with a conditional instruction (if) that will manage your CMP API or to embed it in a trigger that will be triggered by your CMP.
TagCommander contains also core code that is not accessible through the interface. There is one core feature that could put cookies and needs to be manage in your CMP through the management of one global variable : window.tc_disable_cookiesync
Usage : set this variable to true if the user doesn't give his consent
You have to set this variable to false or not set the variable when the user gives his consent
Installation Instructions for TagCommander on AMP.
Accelerated Mobile Pages (AMP) use the Server-Side version of TagCommander.
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/
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. To learn more about server-side set up please read the following article (https://community.commandersact.com/fr/introduction-au-tracking-server-side-avec-tagcommander/).
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
Installation Instructions for TagCommander for direct HTTP connections.
It is possible to communicate with TagCommander container via a HTTP API (e.g. for IOT and TV apps).
See "Serverside" setup guide for more details.
IOT & TV apps use the Serverside version of TagCommander.
TagCommander is a tag management system (TMS) that allows to dynamically implement services like analytics or personalization on a website or app.
The exponential growth in the number of tag-based marketing solutions has created the need to centralize the data they collect and ensure it is properly governed. Additionally, consumer privacy laws like the General Data Protection Regulation (GDPR) have provided the added push marketers needed to put consumers first from a personal data standpoint.
Business-friendly enterprise tag management solutions like TagCommander let marketers deploy new technologies faster and take action against the data they’re collecting, while respecting users’ privacy requests. Additionally, built-in safeguards like audit trails, tag rollback, customizable user permissions, and black- / white-listing functionality help reduce the likelihood of costly mistakes.
This documentation will provide you with an overview of the components of TagCommander, its installation process per platform and provides a knowledge base for its features.
Depending on the technical capabilities of a platform TagCommander can be installed in two versions—Client-Side TagCommander and Server-Side TagCommander.
Client-Side TagCommander is used for environments that support JavaScript. It works by dynamically installing JavaScript Tags on a site. It is for example used to implement TagCommander on static websites or React apps.
Client-Side TagCommander consists of following components:
Part
Description
Tags
JavaScript snippets that are used to implement services on a website or webapp. e.g. the JavaScript snippet of an analytics service
Rules
Conditions under which a Tag is executed. e.g. "If on Homepage", "If on Chinese Country Site"
Trigger
Events on a website or webapp that execute a Tag. e.g. "Site loaded", "Button Clicked"
Container
Version-controlled JavaScript files that include Tags, Triggers and Rules.
Data Layer
Metadata of each page of a website or webapp that can be accessed by Tags.
Server-Side TagCommander is used for environments that have no support for JavaScript. It therefore offers an API that allows to dynamically dispatch onsite data to multiple vendor servers. It is for example used to implement TagCommander on TV, native Android or iOS Apps.
Server-Side TagCommander consists of following components:
Part
Description
Tags
API Endpoints of vendors TagCommander should dispatch data to.
Rules
Conditions under which a Tag is executed. e.g. "If on Homepage", "If on Chinese Country Site"
Container
API Endpoint where you can send data that should be dispatched to Tags.
Data Layer
Data that is sent to the Container to be dispatched to vendor Tags.
It is possible to extend TagCommander with additional modules:
Module
Description
Type
TagPerformance
A tool to measure onsite performance of Tags.
Client-Side
Deduplication
A tool to selectively attribute conversions to marketing channels.
Client-Side
TagFirewall
A tool to black- or whitelist Tags.
Client-Side
These modules are set up and configured by a Commanders Act consultant.
Please refer to the Setup Guides section for detailed installation instructions of TagCommander per platform. In case your platform is not listed you can reach out to a Commanders Act consultant for a custom implementation.
Installation Instructions for TagCommander with Angular.
TagCommander offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In for detailed installation instructions for Angular.
Angular uses the Client-Side version of TagCommander.
Installation Instructions for TagCommander with AngularJS.
TagCommander offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In for detailed installation instructions for AngularJS.
AngularJS uses the Client-Side version of TagCommander.
Installation Instructions for TagCommander with React Native.
Our React Native plugin is currently deprecated. This page will be uploaded as soon as a new GitHub page will be released.
To begin working with your container you will need:
– A site available in the Commanders Act interface (this is set-up either by a Commanders Act consultant or a support agent).
– “Administrator” or “Technical” rights to access the TagCommander interface.
– A TagCommander data layer implemented in your site’s source code.
Should you need more detailed information on the steps in this quick setup guide, please refer to the desired section in the menu to the left or use the search engine.
Once your technical account manager grants you access to the Commanders Act interface, go to our website www.commandersact.com and click “LOGIN” (1):
Click the “TAG” icon to access the TMS’ dashboard (2).
The first thing to do is to declare in our interface the data layer variables that are implemented in your site’s source code. Variables to declare are indicated in the Commanders Act tagging plan that you receive at the beginning of the project.
Declaring these variables will later allow tag mapping to be performed between the information expected by your solutions and the information available in your data layer.
To declare variables in the interface, click “Options” (1) > “External Variables” (2) > “ADD VARIABLE” (3):
A configuration window will appear: make sure to complete the following fields: “Name“(1) (variable’s name, as per the designation used by your team or technical provider in the source code) and “Description” (2) (variable’s description):
Repeat this step as many times as there are variables available in the data layer in your site’s source code.
The next step consists of adding a new container to your site.
To create a new container, go to the “DASHBOARD” (1) and click “ADD CONTAINER” (2)
A configuration window will appear: enter the name of your container in the “Name” field (1) and click “ADD” (2):
There are different possibilities to add tags to your container ; once it is created, you are automatically directed to the “EDIT” (2) step, where you have the possibility to add tags. When you are there, click the “Add tag(s)” button (3).
Another option is to add tags from the “SELECT” step (1). Simply click the “Add tags” (2) button when you are there.
Here you can look for tags present in your container (3), apply filters (4) to display only active or inactive tags (5), or filter by vendor (6).
In both cases, after you have clicked the “Add tag(s)” button, a window will appear containing the list of all the tag templates available in TagCommander and ordered by solution name.
There are various filters you can use to search for the tag you need (sort by alphabetical order or solution name, or use the search engine).
Select the tag(s) you want (1) and click “ADD TAGS” (2):
Note: if the tag you want to add is not on the list, you have two options:
– Sending an email to either the Commanders Act support department or your Commanders Act consultant requesting that your partner solution be listed in the interface ( this takes close to 3 weeks);
– Adding a “Custom” tag into which you can copy and paste the code sent by the solution.
The tags you just added must now be populated with data required by your partner solutions.
Within the TagCommander interface, you must create the link between the information requested by the different tags in the container and data available in the data layer. Establishing this connexion is called “Mapping“.
Overview of mapping in TagCommander
Every variable slot (or nearly, depending on your needs) present in a tag (displayed in between pound signs/hashtags in the interface (3)) must be linked to a variable (external or internal, previously declared in the interface (see Step 1 – declaring TagCommander variables ), or to a static value*).
*values that do not change, like your account ID (5).
In the image below you see :
1) The list of tags, and the one you are currently mapping highlighted in pink.
2) The tag’s name (which you can edit).
3) The available variable #slots# that will host values collected by the variables from the datalayer.
4) The list of variables that were declared in the options section, by category (displayed when the drop down menus are unfolded)
5) The option to enter static values.
The “EDIT” step (1) allows you to perform the mapping (above) between the tag variables and data layer variables.
To map variables, click the arrows in the same row as slots are (1 & 2). When you click the arrow, a menu will unfold with the list of declared and available variables (3) and a pencil icon to write custom values. You can also use the search engine (4) to find the variable you are looking for much faster.
In the tag’s code, the slots that hold the dynamic variables’ values appear in blue boldface as shown above.
In the image below, on the left-hand side of the interface (1), you can see a list of tags that have been added to the container. A “warning” icon appearing before the tags’ names indicates that they have not yet been completely configured and validated.
When you are done, click “Save” (2)
The “RULES” step (1) allows you to manage built-in and customized tag activation rules. By default, your tags are set to be executed on all the pages of your site, as indicated in the “Summary” table (2).
You can add two types of rules:
– “Perimeters“: perimeters are the page types on which you wish to activate your tags, for example: the homepage, “my account” page, product page, etc.
– “Constraints“: constraints are rules based on criteria other than the page type, for example:visitor status, the type of browser or device, etc.
To create a new perimeter, click “Perimeters” (1) > “ADD PERIMETER” (2):
To create a new constraint, click “Constraints” (1) > “ADD CONSTRAINT” (2):
By clicking “Add perimeter” or “Add constraint“, a rule creation interface will appear (the perimeter and constraint creation interfaces offer the same options). This interface can be seen as a “tool box” that allows you to create rules based on various elements that act as triggers: variable(s) value(s), cookie values, specific URLs or specific words in the URLs, etc.
The available trigger types can be selected at the top of the rules creation interface (1). You can select the most appropriate type of trigger and choose among its different triggering condition(s) (2) to set up a rule on one or more of your tags. For each new rule created, make sure to complete the “Name” field (rule name) and check the box(es) of the tag(s) you wish to execute with the rule (3).
The perimeters you created are displayed by column in the “Summary” tab (1). Your constraints are displayed in the rows corresponding to each tag they act upon(2):
Proceed to the “GENERATE” (1) step to generate a new container version and save all the work done in the preceding steps.
Click the green “GENERATE” button, enter a comment describing the changes you made (2) and click the blue generate button in the pop-in:
You will then be automatically directed to the “TEST” step, and the container tests will begin.
The “TEST” step allows you to test your container before it goes online. This stage is important to guarantee the quality of the tags present in the container and preventing errors from appearing on the site in production.
If your container contains an error, its status will appear as “NOT DEPLOYABLE” (1); you will need go back and correct the error before it can be deployed. Click the red “X” displayed in the relevant browser column (2) to see details on the error(s) found.
Tests are performed on a selection of operating systems and browsers. If no errors are detected, the container will be “DEPLOYABLE” and all check marks will be green (1). There is also a list of versions indicating whether a given version of a container can be deployed or not (2).
If your container’s status is “DEPLOYABLE” in the “TEST” step, you can continue to the “DEPLOY” step (1) to put your container online.
You must first choose the version to deploy (2) and then the deployment method (3) before clicking “DEPLOY” (4) to deploy your version:
Note: When you host your container on Commanders Act’s servers, the default deployment method to select is:
“Set as deployed and send to FTP (CDN)” if you wish to deploy on your published site.
“Set as deployed and send to FTP (CDN UAT)” if you wish to deploy on a site in a UAT environment.
Installation Instructions for TagCommander on Websites.
It is necessary to implement one or multiple Container and optionally a Data Layer and event Trigger to install TagCommander on a website.
Websites use the Client-Side version of TagCommander.
A TagCommander Container is a version-controlled JavaScript file that bootstraps the tag management system functionality on a website. To implement and update Tags, users will generate new versions of the Container JavaScript file.
To implement TagCommander it is necessary to implement one or multiple TagCommander JavaScript Container files on the website. The URL of each JavaScript Container file will be provided alongside the Container IDs and Container Names by a Commanders Act Consultant during the setup process. you can find an overview of common Container setups.
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. TagCommander differentiates two types of Container to define whether the Container should be placed in the <head> or in the <body> section of the HTML document.
<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.
Please ensure that the <head> Container file is loaded synchronously to avoid potential content flickering effects.
<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.
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.
It is possible to implement JavaScript Container files with JavaScript loaders like RequireJS or HeadJS. On the opposite it is not possible to bundle the JavaScript Container files with bundlers like Webpack or ParcelJS to make sure that the Container files are dynamically loaded from the CDN or server on each page request. Otherwise users will not be able to manage TagCommander Container on their own.
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 TagCommander Container.
Following you will find an example object including its most relevant information:
A TagCommander Data Layer is a JavaScript object that holds metadata of a website as properties to make it available to Tags. In TagCommander this Data Layer is named "External Variables" to distinguish it from scripted "Internal Variables" that are generated within the Container JavaScript.
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.
The Data Layer needs to be filled with information before the TagCommander 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.
As outlined in the example above the properties of the Data Layer are usually grouped with a prefix notation. E.g. env_ is used to group environment information and user_ is used to group user information.
In case a property is not relevant for a certain page (e.g. product_name on the privacy policy page) it is recommended to fill it with an empty value (e.g. "", 0, [] or {}).
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.
The Tag template Commanders Act - Data Layer QA in the TagCommander 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.
TagCommander Triggers are onsite events that are used by TagCommander users to dynamically execute Tags.
To install a custom Trigger on the website it is necessary to call a JavaScript function with the following pattern:
A typical example is an Add to basket event where the product id of the selected product is sent with the event:
A common approach for the Trigger Data Layer is to always use the same properties like event_label, event_type and event_value—so in case of an add_to_basket Trigger the event_value would hold the product id of the selected product and in case of a video_play event the event_value would hold the current position within the video timeline. This allows to avoid to create multiple custom variable names for each individual event and therefore makes Trigger more generic.
In some situations it might happen, that a user interacts with a custom Trigger before the TagCommander JavaScript Container file was loaded. In this case using the Trigger function would cause a JavaScript ReferenceError. Therefore it is recommended to check the availability of the Trigger function before using it.
The Tag template Commanders Act - Data Layer QA in the TagCommander Tag library automatically outputs 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.
The shows all loaded Container files on a page including their version and other information.
To install a TagCommander 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 TagCommander setup process, but you can find a list of common properties .
The shows the Data Layer properties of the currently visited page.
TagCommander allows to set up common Trigger automatically without the involvement of technical personnel (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 TagCommander setup process, but you can find a list of common Trigger .
Metric
Description
Trigger Label
Label for an event that is used by TagCommander users to execute Tags. e.g. add_to_basket
Trigger Data Layer
A JavaScript object that can be accessed by Tags that are executed on the related Trigger. e.g. product_id
Metric
Description
Container ID
Unique ID of the Container within your account. e.g. 21
Container Name
Label for the Container. Can be configured in the Options of TagCommander. e.g. "Header Container"
Container Filename
Name of the Container JavaScript file, can be configured in the Options of the TagCommander interface. e.g. "tc_header_21.js"
Container URL
Complete URL of the Container used for installation. Depends on the hosting method. e.g. "//cdn.tagcommander.com/1234/tc_footer_main_20.js"
Container Version
Snapshot of a Container JavaScript file.
Installation Instructions for TagCommander with React.
TagCommander 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.
React uses the Client-Side version of TagCommander.
Installation Instructions for TagCommander with VueJS.
TagCommander 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.
VueJS uses the Client-Side version of TagCommander.
An event (HTML event) is an action that can be performed either by a web browser or a user.
An event may be:
An HTML page that has finished loading.
A field that has been modified within an HTML page.
Scrolling on an HTML page.
Clicking a button or any other HTML element on a website, for example, an “add to cart” button.
They are mostly used to send information when a user performs any of the aforementioned actions.
An event listener lets you identify user actions on your page. TagCommander’s event listener allows you to track these actions:
Clicks on the pages’ elements,
Form submissions,
Vertical and/or horizontal scrolling on the page,
“Custom” events (when a TagCommander event function is identified on the page, ex: tC.event.xxx)
To use TagCommander’s event listener (currently only available for Chrome), please launch the Chrome extension.
Then press the F12 key: your browser’s console will open.
(1) Click the “TagCommander events” tab to open the Commanders Act console.
(2) You will get to the “Event listener” feature, which lets you listen to actions users perform on your site.
(3) Logged actions will appear on the list to the left as users continue browsing. They are stored even if you change pages.
(4) You can delete this list anytime by clicking the “clear all” button above the events list.
“Custom” is checked by default: this means that tC.event.xxx functions identified on the page will appear on the list.
“Click” is checked by default: every time a click occurs on the page, an event will appear on the list of events being listened to. If you uncheck this option, clicks will no longer appear on the list.
“Form submission” is also checked by default: form submissions are detected and displayed on the list of events being listened to.
“Show only events with tags associated”: by clicking this option, only events upon which tags are called will appear on the list to the left.
This feature is not yet available.
It will allow you to target an element (button, link …) and to visualize its properties.
Technical staff can implement these functions on your site during the tagging phase:
tC.event.label() label: specify the name you wish to call your function. This function allows tagging an event directly form your site’s source code. It will let you load selected tags on it. Ex: you can ask your technical staff to implement the tC.event.add_to_cart function on the add to cart button if you wish to track this action.
Steps to add a tag that is called on an event are exactly the same as those followed to add a tag that is called when a container is loaded.
The first thing to do is selecting the desired tag in the tag library, or selecting a custom tag:
Then map your tag’s variable with those from the data layer, as you would do for any regular tag. All variable types are at your disposal: external variables, internal variables, event attributes and event variables:
In order to call a tag on an event, go to the Rules area, “triggers” section.
Click the “ADD A TRIGGER” button to have your tag called on an event.
There are many triggers available:
1) Two triggers allowing our TMS to automatically call tags on tracked events: “container loaded” and “DOM Ready”:
Container loaded: This trigger allows calling tags when the container is loaded on a page. It is the default trigger for all the tags you add to your container. This means that the tag will only be called when your JavaScript container loads on your site, but it will not be the case for other event types (such as a click, a page change within an “single page applications” environment, etc.). In order to trigger tags when a container loads on your page, all you need to do is selecting them from the list.
DOM Ready: This trigger allows calling tags when the page’s structure is built (on the “DOM Ready” event). To launch tags on this event, all you need to do is selecting them. They will be called on the DOM Ready event when the page loads.
2) Four triggers allowing to call tags on user actions (click, form submission, scrolling or any other event tracked with the tC.event function):
Click: This trigger allows calling tags whenever elements of the page are clicked. Example: if you would like to call a tag when a user clicks a button (ex: “add to cart” button), select the desired tag(s) and enter the code allowing to target the button or the link on your page in the “CSS Selector” field.
Must know:
To retrieve the CSS selector, open your browser’s console and use its targeting tool (1) to target one of your page’s elements (2). Then right-click, the code appearing in your console (3), click “Copy” and “Copy selector” (4). All you have to do next is pasting this code in the interface.
You can enter many selectors in the interface; you will have to separate them with commas.
Form submission: This trigger allows calling tags when a user submits a form. Example: when they click the “submit” button or press the Enter key. To call a tag when a form is submitted, follow the same steps you followed to call a tag upon a click. Indicate your trigger’s name (ex: “account creation confirmation”), select the desired tag(s) and enter the code allowing targeting the form submission button on your page in the “CSS Selector” field.
Scroll: This trigger allows calling tags when a user scrolls the page vertically or horizontally. In order to execute a tag on scrolling, you will need to enter your trigger’s name (ex: “30% vertical scrolling”), select the desired tag(s), choose the scrolling type (horizontal/vertical) from the dropdown menu, the expected scrolling and measuring unit (page percentage or pixels).
Custom: This trigger allows calling tags whenever a TagCommander event function (tC.event.xxx) is identified on the page. If you wish to execute a tag on a custom eventm, please indicate your trigger’s name (ex: “add to cart click”), select the desired tag(s) and enter the implemented event function’s name (ex : “tC.event.add_to_cart”).
In addition to these triggers, you can add perimeters and constraints to your tags.
Please note: constraints now have to be systematically associated to a trigger. They are linked to the “container loaded” trigger by default.
You can visualize all the rules associated to your tags anytime in the “Rules Summary” section. In addition to seeing the perimeters and constraints associated to your tags, you can see which triggers were selected.
Finally, generate and deploy your container so that your tags are called on you site according to the rules you configured.
The data layer represents all your available data. It consists of information about your site (e.g. page name, product ID) and your visitors (e.g. user ID, customer status) in the form of JavaScript variables.
These variables have two uses:
– To populate the tags present in your container;
– To create activation rules for your tags.
Additional information:
The data layer can consist of two types of data:
– Data implemented by your IT department or your technical provider for all your web pages, based on the CSS, Backoffice and CRM. These data are called “external variables” and are displayed in your site’s source code as a JavaScript object containing all the variables used by your tags.
This is what the external variables look like in the source code:
– Data created in the interface by Commanders Act staff or TagCommander users based on information available on the site’s pages (URL, cookies, HTML tags, external variables in the data layer, etc). They are called “internal variables” and are displayed in the TagCommander container’s code.
Installation Instructions for TagCommander on iOS.
TagCommander offers dedicated Plug-Ins for all major native App platforms. Please refer to the SDK documentation on GitHub for detailed installation instructions for iOS.
iOS uses the Server-Side version of TagCommander.
TagCommander’s SDK allows you to trigger tags from a mobile application.
Commanders Act offers a so-called “super light” SDK you can include in your mobile app’s code; its purpose is to reduce calls to partner solutions as much as possible in order to improve your app’s performance and user experience. A unique call is issued to TagCommander’s servers the moment the app’s screen is displayed or than an element on the screen is clicked. Information related to the page browsed or the element that is clicked is then sent separately to partner solutions by TagCommander’s servers; this allows to prevent applications’ loading speed from slowing down.
Note: Not all solutions are compatible with this method. Since the light SDK sends app information to partner solutions’ servers, they cannot “go back” to the app. Adserving solutions (those displaying adverts) and push notification providers are thus not compatible with this method.
The basic operational principle of TagCommander’s light SDK is:
– Step 1: the mobile data layer and TagCommander’s SDK are called in the app’s source code every time the screen loads or that an element is clicked. (your IT staff should have implemented this at the start of the project).
– Step 2: TagCommander’s SDK issues calls to TagCommander’s servers and automatically sends the mobile data layer’s contents. This is the server-side hits’ structure:
https://serverside$siteID$.tagcommander.com/$containerID$/
$siteID$ and $containerID$ : TagCommander site and container ID. Variables in the mobile data layer are sent to TagCommander’s servers wit a POST method (i.e. in the https request’s head).
– Step 3: TagCommander’s servers send the received information to the different partner solutions. There are as many outgoing hits as there are partner solutions you wish to send information to.
Ex: if you wish to issue a call to both Criteo and Google, a hit will be sent to either solution’s servers.
Implementing TagCommander on a mobile application is a project that consists of the steps listed hereunder:
Definition of the mobile application’s tagging plan: selection and definition of internal and external variables.
Creation of a mobile container and configuration of tags within the TagCommander interface.
TagCommander SDK implementation in the app’s source code.
Acceptance testing of the implementation in a test environment.
Publishing (+ container updates)
The tagging plan corresponds to the list of variables that will populate the app. There are two types:
External variables, present within the app’s source code and programmed by technical staff.
Internal variables calculated within TagCommander’s SDK (mobile variables), or on TagCommander’s servers (server-side variables).
Both external and internal variables need to be declared in the interface beforehand (this is usually done by a Commanders Act consultant).
Mobile Data Layer: external variables
Mobile external variables are declared by your IT staff in the application’s source code and sent automatically to the servers by TagCommander’s SDK.
You can use these external variables to populate mobile tags or to create rules to execute them.
To learn more about external variables and steps to declare them in the interface please click here.
Mobile Data Layer: internal variables
Mobile internal variables are automatically calculated by TagCommander’s SDK or servers. You can use these variables to populate mobile tags or to create rules to execute them.
Mobile internal variables are reunited in the interface options’ “Server-side” > “Internal Variables” tab.
You will find, among the predefined internal variables, some that are calculated by TagCommander’s servers (“Server-side”) and designed for iOS (“iOS”), Android (“Android”) or both (“Mobile (iOS + Android)”). Click the blue “Add predefined variables” button (1) to access them and select a predefined universe (2):
Mobile (iOS + Android): internal variables that are automatically calculated by the SDK and designed for both systems.
TC_IP: the device’s IP address; it is only available if it is connected to the internet. (ex: “10.144.112.50”)
TC_LANGUAGE: the device’s language and location (ex: “fr_FR”)
TC_SYSNAME: the device’s operational system’s full name (ex: “Android-4.2.2” / “iPhone OS”)
TC_SYSVERSION: the device’s operational system’s version (ex : “4.2.2” / “8.4.1” for an iPhone 4s)
TC_MODEL: the device’s model (ex: “Nexus 7” for a Nexus 7; “A0001” for a OnePlus One, “GT-I9305” for a Galaxy S3, “iPhone” for an iPhone 4s)
TC_CONNEXION: connection type (ex : WIFI)
TC_DEVICE: name given to the device by the device’s owner (ex: “flo”)
TC_SCREEN: the device’s screen resolution (ex: “1920×1104” for a Galaxy Tab 3, “320×480” for an iPhone 4s)
TC_CHARSET: the device’s default character encoding method (“UTF-8” for a OnePlus One, “MacRoman” for an iPhone 5)
TC_CURRENCY_CODE: the device’s default currency code (ex: “EUR”, “CAD”)
TC_CURRENCY_SYMBOL: the device’s default currency symbol (ex: “&dollar”, “&euro”)
TC_APPLICATION_VERSION: the device’s application version allowing to run Commanders Act’s SDK (ex : “42.2.12”)
TC_APPLICATION_PREVIOUS_VERSION: The application’s previous version’s number whenever available (ex: “42.2.10”, blank otherwise)
TC_APPLICATION_BUILD: the application’s build number (ex: iPhone 5: 2.3 / Nexus 7: 1536)
TC_TAGCOMMANDER_VERSION: TagCommander’s SDK version in the following format: “version.release-date”
TC_MANUFACTURER: name of the device’s manufacturer (ex: “Apple”, “Samsung”)
TC_USER_AGENT: the device’s web browser’s user agent
TC_JAILBROKEN: jailbroken device (= “1”) or factory settings (= “0”)
TC_APPLICATION_STARTS: Number of the application’s cold starts. Cold starts correspond to the app’s first launch after a system reboot or whenever the app is closed and relaunched
TC_FOREGROUNDS: number of times the app is running in the foreground
TC_FOREGROUND_TIME: amount of time during which the app is open in the foreground (milliseconds)
TC_DELTA_FOREGROUND_TIME: time frame between the current time and date and the last time the app was opened in the foreground (milliseconds)
TC_BACKGROUND_TIME: amount of time during which the app runs in the background (milliseconds)
TC_DELTA_BACKGROUND_TIME: time frame between the current time and date ad the last time the app was running in the background (milliseconds)
TC_BACKGROUND_UX_TIME: amount of time during which the application runs in the background while interactive content is served to the user (milliseconds)
TC_DELTA_BACKGROUND_UX_TIME: time frame between the current hour and the last time the app ran in the background while interactive content was being served to the user (milliseconds)
TC_CURRENT_CALL_MS: time stamp of the hit’s generation (milliseconds)
TC_LAST_CALL_MS: time stamp of the previous hit’s generation (milliseconds)
TC_LAST_SESSION_LAST_HIT_MS: time stamp of the last hit registered during the last session (milliseconds)
TC_NOW_MS: Unix Time stamp (milliseconds)
TC_IDFA: Id of Google or Apple-served ads
TC_IS_TRACKING_ENABLED: indicates whether tracking is accepted on the device (YES/NO)
TC_LIMIT_USER_TRACKING_ENABLED: limited tracking on the device (YES/NO)
TC_LONGITUDE : user’s longitude if geolocation is authorized
TC_LATITUDE: user’s latitude if geolocation is authorized
TC_BUNDLE_IDENTIFIER: Id of the app’s batch allowing Commanders Act’s SDK to run
TC_APPLICATION_NAME: Name of the app allowing Commanders Act’s SDK to run
TC_RUNTIME_NAME: Device type (ex: Android / iOS)
TC_FIRST_VISIT_MS: time stamp of the app’s first launch (milliseconds)
TC_LAST_VISIT_MS: time stamp of the last visit’s start (milliseconds)
TC_CURRENT_SESSION_MS: time stamp of the current session (milliseconds)
TC_CURRENT_VISIT_MS: time stamp of the current visit (milliseconds)
TC_SESSION_DURATION_MS: current session’s length (milliseconds)
TC_VERSION_FIRST_VISIT_MS: for the app’s current version, it is the first time stamp of the first session following an app update (milliseconds)
TC_NUMBER_VISIT: number of times a user opened the app
TC_NUMBER_SESSION: number of sessions created in the app
TC_IS_FIRST_VISIT: whether it is the first time the app is launched (= “TRUE”) or not (= “FALSE”)
TC_FIRST_EXECUTE: the first time a developer executes the app with the execute() or SendData() functions after the latter is launched (= “TRUE” or “FALSE”). This variable can be combined with the TC_IS_FIRST_VISIT variable to retrieve the very first hit sent the first time the app was launched.
***
iOS: internal variables calculated automatically by the SDK and specific to the iOS.
TC_MODEL_AND_VERSION: Phone’s model and version depending on the device’s code.
TC_IDFV: Unique Id per solution
Creating a container for mobile applications
TagCommander’s SDK issues calls to TagCommander’s servers: you therefore have to create a “server-side” technology-based container for your mobile applications.
Please note: you can use a single server-side container for both the iOS and Android versions of your apps.
To learn more about how to create a server-side container, see serverside user manual.
Implementing tags on mobile apps
Implementing mobile tags is the same as implementing server-side tags (see serverside user manual)
The SDK implementation is performed by technical staff or IT departments.
These elements must be provided:
The app’s TagCommander tagging plan, which lets IT staff know which variables to declare and on which screens or elements.
Technical documentation referring to each and every app. It must contain elements that are key to setting up the SDK and screenshots of setup examples.
Click here to read the corresponding technical documentation for iOS: https://github.com/TagCommander/pods/blob/master/TCSDK/README.md
The site’s ID (Commanders Act account number) and that of the server-side container, which are necessary to set-up the SDK. These two elements can be retrieved in the container’s options section: click the “container options” icon (1) and copy the site (2) or container ID (3)
TagCommander’s SDK can be tested with many different tools:
TagCommander’s SDK for iOS can be tested with Apple’s developing software “XCode”:
https://itunes.apple.com/fr/app/xcode/id497799835
You will need to connect your iPhone to your Mac.
Open XcOde, go to “Window” ), > “Devices” (2), then select ypur device in thecolumn to the left (3):
These elements will be displayed when you analyze mobile logs:
TagCommander SDK’s version number: “Commanders Act SDK init with version: VERSION_NUMBER”
TagCommander’s site and container number: “SDK init with siteID SITE_ID and CONTAINER_ID”
A list of the external variables that were provided by technical staff and that are visible in XCode, thanks to this function “TCLogLevel_Debug”: “Tag Commander Executing with appVars : AppVars : {#VARIABLE#: VALUE}”
Server-side hit containing variables sent to TagCommander servers (POST method). You will see internal variables first, followed by external variables): “sending: http://serversideSITE_ID.tagcommander.com/CONTAINER_ID/ With POST data: VARIABLE=VALUE&VARIABLE=VALUE…”
***
TagCommander’s SDK for both iOS and Android operating systems can be tested with the “Charles Debugger” proxy, downloadable for free here: https://www.charlesproxy.com/
The first thing to do is to configure your phone so it can communicate with Charles.
In your phone’s settings, go to the Wi-fi configuration tab.
Select your network and proceed to the advanced options to edit Wi-fi settings.
Add a proxy manually:
Proxy’s name (server)(1): Computer’s IP (you can find it in the “Local IP address” tab from Charles’ options)
Port (2): 8888
Save.
Go to the Charles app and authorize it to connect to the phone.
Browse the web with your phone and in Charles (on your computer) apply a “TagCommander” filter to see server-side hits displayed in the “Overview” section. They look like this: http://serversideSITE_ID.tagcommander.com/CONTAINER_ID/
When you go to the “Request” area, you will be able to see all variables and the corresponding values that are sent through the TagCommander SDK.
HTTPS Protocol:
Most of the time, server-side calls are issued through an https protocol.
Seeing https hits with Charles requires a more complex configuration. You will need to open your phone’s browser while Charles runs on your computer and go to this URL on your phone http://www.charlesproxy.com/getssl/
Download the certificate and install it; you will need to enter its name for two applications “VPN and applications” and “Wi-fi”.
Go back to Charles > “SSL proxy settings” > “SSL Proxying” > check “Enable SSL Proxying” > Click “Add” and type “*” in the “Host” field (to authorize any given host).
Then proceed to running tests the same way you do for http hits.
When the implementation is ok on your testing environment, you need to submit your app to app stores (Apple Store or Android Market) and wait for them to approve changes and include the new version in their catalogues.
This is a one-time procedure you will not need to repeat. This is because TagCommander’s SDK is available on JCenter for Android and Cocoapods for iOS, allowing developers to include a link leading to the latest version of TagCommander’s SDK in the applications.
To learn more about JCenter and Cocoapod, please refer to this content:
JCenter for Android : https://github.com/TagCommander/Android
Cocoapods for iOS : https://github.com/TagCommander/pods
Event variables are the variables present in TagCommander 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 TagCommander interface before they can be used, and only for events, not tags.
Event variables must be created in the TagCommander 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 TagCommander (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 TagCommander 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:
There are two situations in which you may need to declare your variables in the event variable management interface:
You want to implement TagCommander 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.
The “add” window consists of the following elements:
(1) “Name“: the variable’s name (mandatory field)
(2) “Type“: the variable’s type
(3) “Description“: A description of the variable, to clarify its name (e.g. “Page template” can be the description of the variable named “env_template”)
(4) “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)
You can edit an internal variable by clicking the “Edit” icon (1) and delete it by clicking the “X” (2):
The “RULES” step allows you to create your tag activation rules.
You can manage how your tags and events are called by using the four tabs displayed in the left menu (1):
The “Summary” tab provides you with an overview of the created rules per tag and event.
The “Triggers” tab allow you to create triggers for your tags. Triggers are rules allowing to execute tags on different conditions: container loaded, DOM Ready, clicks, form submissions, scroll and custom events.
The “Perimeters” tab allows you to create perimeters for your tags. Perimeters are the page types for which you want to activate your tags (for example: the homepage, “my account” page, product page, etc.).
The “Constraints” tab allows you to create constraints for your tags and events. Constraints are rules based on criteria other than the page type (for example: rules based on visitor status, the type of browser or device, etc.) Note: You must use constraints if you want to create a rule for an event.
The “Deduplication” tab allows you to implement deduplication rules for your tags.
These variables are called external variables because they are outside the TagCommander 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 TagCommander 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 TagCommander 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 TagCommander 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:
There are two situations in which you may need to declare your variables in the external variable management interface:
1) You wish to install TagCommander 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 TagCommander 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.
Clicking “Download” will open a window containing the JavaScript code (1) to insert in the site’s source code:
(1) “Name“: the variable’s name (mandatory field).
(2) “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.
(3) “Type“: The type of variable. See the “Managing Variable Types” article in this section.
(4) “Use in noscript“: Check the box so that the variable is present in the tag’s noscript code.
(5) “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”).
(6) “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).
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 green “ADD VARIABLE” button:
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).
Once you have mapped your variable, click the symbol:
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 (1) 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 “order_product”, 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 edit an external variable by clicking the “Edit” icon (1) and delete it by clicking the trash can. The flag next to the variable’s name (2) will tell you if it is mapped and the tag(s) it is mapped with:
(5) In the table to the left, you can see the properties of events that are being listened to. Properties’ values can be sent within tags called on these events; they can also be used to condition tag calls. Please note: the list of attributes (properties) listened on all events is available in the TagCommander interface: follow this path “Options”> “Event Attributes”.
Click “options” to select elements to display on the list of events that are listened to:
“Vertical scrolling” and “horizontal scrolling”: by default scrolling is not displayed on the list in order not to overload it. If you wish to listen to these actions, all you need to do is to provide the value of the scrolling you wish to listen to in terms of screen percentage or pixels. You can provide several values and separate them with commas: In the example above, we scrolled the screen by 10% and 30%, originating two events that are displayed on the list.
tC.event.label(this, {“page_name”:””, “product_id”:””}) This function allows tracking events directly from your site’s source code and sending specific variables to it. You will then have to declare these variables from the “Options”> “Event variables” tab in order to be able to map your tags or to use them to create rules for the latter (). Ex: ask your technical staff to implement the function below on the add to cart button if you wish to know the precise product that was added to the cart, in case different products are present on the page: tC.event.add_to_cart(this, {“product_name”:”product_v2″, “product_id”:”12324″}).
To add an event variable, you must go to the “Options” tab > “Event Variables” and click “ADD VARIABLE” (1):
Note: If necessary, you can click “Download“, (1) 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:
To add an external variable, you must go to the “TagCommander” interface, “Options” tab > “External Variables” and click “ADD VARIABLE” (1):
The “add variable” window contains various fields:
Once the variable is added, it will appear on the variables list:
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 green plus button :
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):
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 “_”) (1) and click “SAVE” (2):
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.
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:
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 TagCommander 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 “TagCommander” product only. However, if you have subscribed to other products in our suite (“MixCommander”), 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.
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.
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_template 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:
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:
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.
“If Cookie Doesn’t Contain“: Tag activated if the cookie’s value does not contain the specified value.
Example: In order to call a tag when your “user_logged” cookie equals “1”, you must select the “If Cookie Equals” rule and configure it in the following manner:
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.
“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: http://www.site.com/$category$/$subcategory$/product_$product_ID$), you have to select the “If URL Matches” rule and configure it in the following manner:
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).
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 in the following manner:
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
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:
A tag is a piece of code executed on your site that allows information regarding the site or its visitors to be sent to a digital marketing solution.
Example: Digital analytics tags collect information on site page views, visitors, and conversions in order to propose analysis of your site’s performance. Retargeting tags collect information on products viewed or added to the cart by visitors in order to retarget them to other sites via banners that highlight the products they browsed.
Additional information
Here is an example of a tag (Commanders Act Attribution tag):
The first step of the deployment process “SELECT” displays the tags present in your container and allows you to add new ones.
The main area of the “SELECT” interface displays all the tags already present in your container (1). Each block represents one tag (2): You can edit or delete your tag by clicking on the respective icons in the block.
You can search for a previously added tag by solution name using the “All vendors” filter in the drop-down menu (3) or by searching for the tag name via the search box (4):
Click the green “ADD TAG(S)” button (1) to add a new tag to your tag list:
The Commanders Act tag library window will appear displaying the pre-configured tags in the interface. The tag library is composed of the following elements:
(1) “Search a tag“: Search box for finding a tag in the library by its name
(2) “All vendors“: Filter for finding tags by solution name
(3) Search by letter: Tags in the library are sorted in alphabetical order (by tag name)
(4) Tag library: All the tags in the library (click the tag(s) you want to add to your container)
(5) “Add tag(s)“: Click this button to add the selected tag(s) to the container
To add one or more tags to your container, check the desired tags and click the green “ADD TAG(S)” button. Your new tags will appear in the list of tags present in the container.
To start adding one or more tags you will need to access your container. You can do this while on the “TagCommander” Dashboard (1) by clicking:
The container’s name (2)
The “EDIT” button (3)
After clicking either of those buttons, you will be taken to the “EDITION” section. Tags can be added while on the “SELECT” or “EDIT” step within said section. In both steps, there are green “Add Tag” buttons.
EDIT
SELECT
The green ADD TAGS buttons will open the Commanders Act tag library.
Once a tag is added, you can configure it in the “EDIT” step.
A list of your tags is displayed in the left menu of the “EDIT” interface (1). Tags that need to be configured or validated are listed in the “To Validate” category (2) and have a warning (/!\) sign before their name.
Note: Tags that have already been validated are sorted by category. You can find a tag on the list by using the search box (3):
For each tag selected, a configuration window will appear in the center of the interface containing the following elements:
(2) “Expiration“: An expiration date can be applied to the tag
(3) Tag variable(s): Tag variables that need data layer data or static information linked to them
(4) Data layer data: Your data layer variables. They have to be linked to the tag variables
(5) Tag code: The selected tag’s code
(6) “Use Tag Cleaner“: JavaScript correction tool and preview button to see the tag’s code once its variables have been mapped with variables from the datalayer
(7) “Previous version(s)“: The tag’s version history; “delete” and “save” buttons
(8) “Rules“: Shortcut to the tag’s rules configuration
You can apply a custom expiration date to each tag (1). Check the box to activate this function (2) and then select a date on the calendar or type it in the blank field (3).
When you activate the expiration function, it automatically deactivates the tag into the container on the expiration date selected.
This function is useful if you have added a tag for a specific campaign and you want it to be deactivated once it ends, so that your container is not needlessly overloaded with tags.
Additional information
You can be notified of a tag’s upcoming expiration by receiving an email 2 weeks and 1 week before its expiration. To activate this feature, you need to go to the container Options (1), click the “Advanced” tab (2) and select the recipients from the list of people with access to the container (3).
You can also apply a default expiration date to all the tags present in your container (3 months, 6 months or 1 year) (4):
You can set expiration dates for the tags in your container so that they are automatically deactivated when you have no more use for them.
To display a summary of the different tag expiration dates, go to the “REPORTS” tab > “Tag Expiration Summary“.
This interface displays the list of tags present in your container along with their expiration dates if they have one. You can modify your tags’ expiration dates directly in this interface by clicking the box and selecting a date on the calendar (1).
You can also filter the containers (2) or tags (3) that you want to analyze:
Important reminder: You must create a link between the information requested by the different tags in the container and the data available in the data layer. Adding data layer variables to tag variables is called “mapping“.
The tag variables to map are called “dynamic variables“, and they are designated in the following manner: #variable#.
They appear in the tag’s code, in blue boldface, (1) as well as above the tag’s code (2).
You must map these dynamic variables with the data layer variables available in the drop down menus (example: page name, user ID) or a static value (example: a URL or account ID) (3):
Additional information
If the tag’s code does not meet your needs, you can customize it directly in the “JAVASCRIPT CODE” section (1) as well as the “NOSCRIPT CODE” (2) section for browsers without JavaScript activated (this function will only work if you call the NOSCRIPT version of the container in your site’s source code):
You can modify your tag directly by transforming the dynamic variables within the code into data of your choice.
Example:
If you wish to hard code the ORDER ID, just replace #TCIORDER# (1) with the ID (2):
You can also customize your tag’s code by changing the static elements into dynamic variables.
Example:
If you want to make all the values to be collected in a tag dynamically, simply leave them in between pound signs. Then save the tag after making this change (1) and you will be able to map your variable with your data layer data:
Note: you can modify your tag anytime you want. However, please pay attention to its JavaScript structure: Dynamic elements must be placed between the ## and followed or preceded by a “+” if they are joined with static elements. The colored syntax in the tag code allows you to verify that there are no errors:
A TagCommander “Free input (custom)” tag can be used to add a tag to your container even if it is not listed in the tag library.
To configure your custom tag, just replace the default code in the “JAVASCRIPT CODE” (1) with the code supplied by your partner solution and click “SAVE”.
In the vast majority of cases, you will see that your tag is rewritten so that its structure is compatible with that of the container and is called asynchronously. This is also done to prevent errors linked to certain JavaScript data structures such as “document.write”.
Tags are corrected by using the “Use Tag Cleaner” feature:
Uncheck the “Use Tag Cleaner” box if you do not want your tag to be rewritten.
Each time a container is generated, Commanders Act saves the tags present in the container, thus allowing you to return to an old tag configuration if necessary.
You can display previous versions of a particular tag by clicking “PREVIOUS VERSION(S)” (1):
The “PREVIOUS VERSION(S)” window contains all the saved versions of your tag. The version displayed by default is the previous version of the tag.
(1) Tag version: number of the last tag version saved, name of the user who generated the version, and the date and time it was generated
(2) “Rollback“: button allowing you to return to the tag version displayed
(3) “JavaScript code/NoScript“: buttons to select the tag’s JavaScript or NoScript code
(4) Tag code: selected tag code (JavaScript or NoScript code depending on the option selected in (3))
(5) Tag versions: previous versions of the tag
To return to a previous tag version, select the version you want and click “ROLLBACK“.
You can add a tag activation rule directly in the “EDIT” step.
You have two options:
You can select a previously created perimeter or constraint by clicking the drop-down menu (1):
You can create a new perimeter or constraint by clicking “+” (2)
The rule creation window will appear so that you can create your rules in the same way as in the “RULES” step.
For more information on creating rules, please refer to the “Rules” section.
To display a summary of all the tags present on your site along with their rules, go to the “REPORTS” tab > “Tags’ Summary“.
You can display the code (1), rules (2) and expiration date (3) for each tag.
You can also filter the containers or tags that you want to analyze (drop down menus above 3 ):
This report can be useful for displaying which tags are present on your site at a given time and for sharing this information with others internally. It can also help you find a tag from the list of tags present on your site.
Once you have finished configuring your tag, click “SAVE” (1) to save your modifications.
You can also delete a tag you do not need any more by clicking “DELETE” (2).
Caution: a deleted tag cannot be recovered.
To activate or deactivate tags in the “GENERATE” step, just check or uncheck each tag in the “ACTIVATION” column (1) and generate a new container version (green button in the upper right-hand side of the screen):
All checked tags are active and all unchecked tags are inactive. The advantage of deactivating a tag rather than permanently deleting it is that you can keep all the tag parameters (mapping, rules) and reactivate them at a later date without having to reconfigure everything.
Note: Since a deactivated tag will be visible in the interface but not in the container called for your site, your container will not become needlessly cluttered.
To modify the order in which tags are executed in a container in the “GENERATE” step, just drag and drop each tag in the “RANK” column (1) and place them in the order in which you want them to execute on your site’s pages, and then generate a new container version (green button in the upper-right hand side of the screen):
We recommend that you place the most important tags at the top of the container so that they have the best chance of executing if your visitors change pages quickly without waiting for them to fully load.
To improve your site’s performance, Commanders Act suggests that you deactivate a tag if it takes too long to load. You can enter a maximum duration, in milliseconds, for a tag to execute. If the tag takes longer than this time to execute, it will be deactivated.
To add a timeout to tags in the “GENERATE” step, just enter a duration in milliseconds in the “TIMEOUT MS” column (1) and generate a new container version (2):
You can customize the tag library by restricting the number of tag templates available in the tag addition popin from the “Select” and “Edit” steps.
This “tags whitelist” feature is useful if you wish to limit access to the solutions in the library and only make some of them available to your staff. This aims at preventing users from placing tags you did not authorize into your containers.
The “Library management” interface is accessible to administrators and to custom users this interface was granted access to. The tags whitelist is managed from the “Admin” > “Library management” (1) interface:
All tags will be selected by default.
You can click the “Unselect all” (1) option and then choose the tags you wish to make available in your library.
1/ Select the site you wish to set up the tags white list for from the drop down menu.
2/ Check/Uncheck relevant tags.
3/ The “Select all” and “Unselect all” buttons allow you to check or uncheck many tags simultaneously.
4/ You have the possibility to filter tags by name or alphabetical order.
5/ Click the “SAVE” button to save your settings.
Must know:
When a new tag is added to the tag library by Commanders Act’s staff, it is automatically unchecked if you have created at least one tag whitelist for your site.
You can copy a tags whitelist from one site to another from the “Admin” > “Copy management” menu. To learn more, please click here.
A Custom user can be given access to this feature. To grant this access, click “YES” in the custom user options for the “Admin” > “Library management category”.
Server-side tracking allows triggering tags directly on your website(s) and calling them from your servers.
Main benefits of this type of tracking include:
Site performance improvement (tags are no longer called/triggered by the site itself)
Increased security (Commanders Act or partner solutions can no longer interact with the websites, drop cookies, etc…)
Possibility to monitor data collected by Commanders Act and sent to partners.
Server-side tracking operates as follows :
Step 1 : Your servers (clients’ servers) display the webpage a user is browsing and call Commanders Act’s servers simultaneously. Your IT department shares information of your choice with TagCommander through server-side variables (present in the server-side datalayer).
Server-side calls issued by your IT team to Commanders Act look like this :
http://serverside$siteID$.commandersact.com/$containerID$/?variable1=value1&variable2=value2…
$siteID$ and $containerID : Commanders Act site and container identifiers.
variable1, variable2: names of server-side data layer’s variables (ex: ProductID, UserID, Order Amount…)
They are called “incoming hits” or “input hits”.
Step 2: Commanders Act sends the received information to the partners’ servers. These hits are called “outgoing hits” or “output hits”. There are as many outgoing hits as there are partner solutions you wish to send the information to.
Ex: if you wish to call Criteo and Google; a hit will be sent to Criteo’s servers and another one to Google’s.
“Hybrid server-side” refers to an implementation method combining browser and server-side technologies.
It consists in retrieving web data (ex: cookies, variables …) and storing it on Commanders Act servers for 24 hours, in order to provide third-party solutions with information present in both the servers and the customer’s Website.
Main benefits:
Enhanced website performance (most tags are no longer called on web pages but on the server-side)
Data that can only be obtained on websites (cookies, certain variables) still can be collected and sent to partner solutions from the servers.
Hybrid server-side operates as follows:
Step 1: a Commanders Act tag present in the web container collects data on the website and stores it on TagCommander servers for 24 hours. A matching key allowing to associate information collected on the website with that present on the servers needs to be defined.
This key thus has to be retrievable both on the website and on the servers (example of reconciliation keys: User ID, Basket ID).
Example: you wish to obtain on your website the order ID and the cookie value of one your partner solutions. Your reconciliation key is the User ID. The Commanders Act tag will collect information in this way:
Reconciliation key (user_id)
order_id
cookie_vendor1
123456
1234FR
A
567489
34565FR
A
346658
56456FR
B
…
…
…
Step 2: Server-side hits sent to partner solutions will be enriched with information collected through web containers. Thank to this reconciliation key, data from the website and the servers correlates.
TagCommanders Data Storage is a cookie stored on the user’s browser.
When you create data storage in the TagCommander interface, a cookie with the same name is stored on the visitor’s browser. Data storage allows you to make use of the data it contains. Its use is described in the next articles in this section.
Data storage is useful for continually storing data about a visitor from one page to the next, from one visit to the next or for a defined period of time up to one year.
It is a cookie that stores data and allows to use it afterwards in many ways. Its uses are detailed in other articles in this section.
Additional information
Data storage that you create in the interface are first-party cookies, which are cookies set for your site’s domain name.
You can use the function below to see the content of data storage created for one of your site’s pages:
You can use the following function to create custom data storage:
To add data storage, you must go to the “Options” tab > “Data layer” > “Data Storage” and click “ADD DATA STORAGE” (1):
The “add” window consists of the following fields:
Name: Name of the Data Storage
Container(s) to link:A menu that unfolds and shows all available containers
Lifetime: A menu to select the cookie’s lifetime
Type: the type of cookie/what it is used for
Value: the values the cookie will take (a and b for ab testing, many more for n testing …)
Generates a unique ID for each visitor.
Example: TagCommander can become your visitors’ unique reference ID to replace or enrich the ID generated by your partner solutions.
The “Do you want lifetime to be refreshed at each page view?” option (1) changes the data storage’s lifetime based on the frequency of visits to the site. This option refreshes the data storage lifetime with each page view.
Example: you have set the data storage lifetime to 30 days and checked this option. If a user visits the page at 12 p.m. on 05/01/2015, the cookie will remain on the visitor’s computer until 12 p.m. on 05/31/2015, i.e. 30 days later. The cookie’s lifetime will refresh with each page view.
Saves the value of a URL parameter.
Example: if you want to save the value of the “utm_source” parameter, i.e. “google” in the URL https://www.site.com/landing?utm_source=google&utm_medium=cpc, you must enter the name of the parameter to save, which in this case would be “utm_source” (1)
Assigns a score based on the number of page views.
Example: if you want to assign the score of “A” to visitors visiting 1 to 3 pages (1), a “B” to visitors visiting 4 to 7 pages (2) and a “C” to visitors visiting 8 to 11 pages (3), you must enter the different ranges of page views and indicate each range’s score. The data storage value will be the score (A, B or C).
Saves the number of page views for a given visitor.
Example: you can use this data storage type if you want to save and send the user’s number of page views to one of your solutions or define a tag’s activation on the number of page views. Just select the “page views counter” data storage type, and the cookie’s value will increase automatically with each page view (1 page view: cookie value = “1”, 2 page views: cookie value = “2”, etc.)
Creating two visitor populations split 50/50.
Example: if you want to activate solution A for 50% of your visitors and solution B for the remaining 50%, all you need to do is indicate the data storage values for population A, “vendor_A” for example, (1) and population B, “vendor_B” (2).
You will then be able to create a rule during the deployment process in the “Rules” section that activates solution A’s tags when the data storage value is “vendor_A”, and solution B’s tags when the value is “vendor_B”.
Note: this method is used regularly for A/B tests of two competing retargeting solutions.
Creating N visitor populations of equal size.
Example: if you want to launch an N test for 3 competing solutions, each solution will be assigned 33.3% of the traffic (100%/3); for 4 solutions, each solution will be assigned 25% of the traffic (100%/4), and so forth.
If you decide to activate solution A for 33.3% of your visitors, solution B for another 33.3% and solution C for the remaining 33.3%, you must enter the data storage value in each case. For example, “vendor_A” for solution A, “vendor_B” for solution B and “vendor_C” for solution C (1). Each value must be separated by a comma in order to be processed.
Saves a variable’s value.
Example: if at some point you want to save a TagCommander data layer variable or any other JavaScript variable present on the page, you must enter the name of the variable to save.
For example, data storage allows you to save visitors’ user_id variables in order to recognize them if they return several days after leaving your site. To save the user_id variable value, you must enter “tc_vars[“user_id”]” or “tc_vars.user_id” (both formats are accepted) in the “Variable to save” field (1). If you want to save the value of an internal variable, you must enter the value using the following format: tC.internalvars.variable_name.
A test environment is useful for making the container test step more “realistic” and more reliable.
The purpose is to simulate the production environment by assigning values to all the external variables as they would be on your site’s pages in the production environment.
Thus, real values from your data layer are added to the tags tested in the “TEST” step.
The test environment allows you to detect as many errors as possible in said step.
Go to the “TEST” step of the tag deployment process.
You will see tabs for all the test environments created and linked to the container (1):
The test environments will be tested along with the default environment (the default environment is a test environment available for all containers and all customers in which the external variables’ values are empty).
If the test environment returns an error, it will be displayed in the environment tab (NO). If an environment returns an error, the container will not be shown in the “DEPLOY” step.
To add a test environment, you must go to the “OPTIONS” tab > “Test Environments” and click “ADD TEST ENVIRONMENT” (1):
The “add” window consists of the following elements:
(1) “Name“: The test environment’s name (mandatory)
(2) “Environment JavaScript code“: The field to write the environment’s JavaScript code
(3) “Linked container(s)“: The containers you wish to link the test environment to
Once the test environment is added, it will appear in the list of test environments (1), click the pencil to edit them or the cross to delete them (2):
TagCommander allows you to include “free” JavaScript in the tag container, with no character limit, in two places named “Static JavaScript Code”.
The “Static JS codes” allow you to perform different types of actions, notably:
– Fixing data layer issues.
E.g. If your external variable “page_name” contains values with special characters, you can delete or replace them in the Static JavaScript code (e.g. change “&” into “and” as follows:
Thus, you can continue to use your external variable “page_name” in tags by removing its special characters via the Static JS code.
– Recovering data absent in the data layer from the site pages’ source code.
E.g. You can recover JQuery form fields in your Static JS block in the following manner:
The “Static JS codes” appear in two places in the left menu of the “EDIT” step interface:
– The first Static JS code is placed before the declaration of internal variables in the order that elements in your site’s container are executed (1).
– The second Static JS code is placed after the declaration of the internal variables (you can thus reuse previously declared internal variables in this position) (2):
The same user interface is used for the Static JavaScript code regardless of whether it executes before or after the internal variables. Just enter the JavaScript code you desire (1) and click “SAVE” (2):
agCommander allows dynamic JavaScript file(s) to be included in a tag container, in two places named “Dynamic JavaScript File(s)“.
Unlike “Static JavaScript codes“, “Dynamic JavaScript Files” are JavaScript files outside TagCommander that are downloaded and then added or updated in the container each time it is generated.
The “Dynamic JavaScript File(s)” allow you to perform different types of actions.
For example, you can use them to import a JavaScript file containing a JQuery library (if it is not already called on your site) or a JavaScript currency converter file into your container. By importing these files into TagCommander, you can add them to your solutions or use them to create new variables (for example, you can automatically update currencies in your solutions’ tags).
“Dynamic JavaScript File(s)” appear in two places in the left menu of the “EDIT” step:
The first Dynamic JavaScript File(s) is placed before the declaration of the internal variables, in the order that the elements of the container on your site are executed (1).
The second Dynamic JavaScript File(s) is placed after the declaration of the internal variables (you can thus reuse previously declared internal variables in this position) (2):
The same user interface is used for the Dynamic JavaScript File(s) regardless of whether they execute before or after the internal variables. Just enter the URL of your JavaScript file (1) and click “SAVE” (2):
You can perform this operation again for all the JavaScript files to be included in your tag container.
Caution: adding JavaScript files to the container will increase its size and thus increase the time for the pages to load.
You can update your dynamic file manually (by clicking “Refresh”), display its contents (“View”) or delete it (“Remove”) (1):
Installation Instructions for TagCommander on Android.
TagCommander offers dedicated Plug-Ins for all major native App platforms. Please refer to the for detailed installation instructions for Android.
Android uses the Server-Side version of TagCommander.
TagCommander’s SDK allows you to trigger tags from a mobile application.
Commanders Act offers a so-called “super light” SDK you can include in your mobile app’s code; its purpose is to reduce calls to partner solutions as much as possible in order to improve your app’s performance and user experience. A unique call is issued to TagCommander’s servers the moment the app’s screen is displayed or than an element on the screen is clicked. Information related to the page browsed or the element that is clicked is then sent separately to partner solutions by TagCommander’s servers; this allows to prevent applications’ loading speed from slowing down.
Note: Not all solutions are compatible with this method. Since the light SDK sends app information to partner solutions’ servers, they cannot “go back” to the app. Adserving solutions (those displaying adverts) and push notification providers are thus not compatible with this method.
The basic operational principle of TagCommander’s light SDK is:
– Step 1: the mobile data layer and TagCommander’s SDK are called in the app’s source code every time the screen loads or that an element is clicked. (your IT staff should have implemented this at the start of the project).
– Step 2: TagCommander’s SDK issues calls to TagCommander’s servers and automatically sends the mobile data layer’s contents. This is the server-side hits’ structure:
https://serverside$siteID$.tagcommander.com/$containerID$/
$siteID$ and $containerID$ : TagCommander site and container ID. Variables in the mobile data layer are sent to TagCommander’s servers wit a POST method (i.e. in the https request’s head).
– Step 3: TagCommander’s servers send the received information to the different partner solutions. There are as many outgoing hits as there are partner solutions you wish to send information to.
Ex: if you wish to issue a call to both Criteo and Google, a hit will be sent to either solution’s servers.
Implementing TagCommander on a mobile application is a project that consists of the steps listed hereunder:
Definition of the mobile application’s tagging plan: selection and definition of internal and external variables.
Creation of a mobile container and configuration of tags within the TagCommander interface.
TagCommander SDK implementation in the app’s source code.
Acceptance testing of the implementation in a test environment.
Publishing (+ container updates)
The tagging plan corresponds to the list of variables that will populate the app. There are two types:
External variables, present within the app’s source code and programmed by technical staff.
Internal variables calculated within TagCommander’s SDK (mobile variables), or on TagCommander’s servers (server-side variables).
Both external and internal variables need to be declared in the interface beforehand (this is usually done by a Commanders Act consultant).
Mobile Data Layer: external variables
Mobile external variables are declared by your IT staff in the application’s source code and sent automatically to the servers by TagCommander’s SDK.
You can use these external variables to populate mobile tags or to create rules to execute them.
Mobile Data Layer: internal variables
Mobile internal variables are automatically calculated by TagCommander’s SDK or servers. You can use these variables to populate mobile tags or to create rules to execute them.
Mobile internal variables are reunited in the interface options’ “Server-side” > “Internal Variables” tab.
You will find, among the predefined internal variables, some that are calculated by TagCommander’s servers (“Server-side”) and designed for iOS (“iOS”), Android (“Android”) or both (“Mobile (iOS + Android)”). Click the blue “Add predefined variables” button (1) to access them and select a predefined universe (2):
Mobile (iOS + Android): internal variables that are automatically calculated by the SDK and designed for both systems.
TC_IP: the device’s IP address; it is only available if it is connected to the internet. (ex: “10.144.112.50”)
TC_LANGUAGE: the device’s language and location (ex: “fr_FR”)
TC_SYSNAME: the device’s operational system’s full name (ex: “Android-4.2.2” / “iPhone OS”)
TC_SYSVERSION: the device’s operational system’s version (ex : “4.2.2” / “8.4.1” for an iPhone 4s)
TC_MODEL: the device’s model (ex: “Nexus 7” for a Nexus 7; “A0001” for a OnePlus One, “GT-I9305” for a Galaxy S3, “iPhone” for an iPhone 4s)
TC_CONNEXION: connection type (ex : WIFI)
TC_DEVICE: name given to the device by the device’s owner (ex: “flo”)
TC_SCREEN: the device’s screen resolution (ex: “1920×1104” for a Galaxy Tab 3, “320×480” for an iPhone 4s)
TC_CHARSET: the device’s default character encoding method (“UTF-8” for a OnePlus One, “MacRoman” for an iPhone 5)
TC_CURRENCY_CODE: the device’s default currency code (ex: “EUR”, “CAD”)
TC_CURRENCY_SYMBOL: the device’s default currency symbol (ex: “&dollar”, “&euro”)
TC_APPLICATION_VERSION: the device’s application version allowing to run Commanders Act’s SDK (ex : “42.2.12”)
TC_APPLICATION_PREVIOUS_VERSION: The application’s previous version’s number whenever available (ex: “42.2.10”, blank otherwise)
TC_APPLICATION_BUILD: the application’s build number (ex: iPhone 5: 2.3 / Nexus 7: 1536)
TC_TAGCOMMANDER_VERSION: TagCommander’s SDK version in the following format: “version.release-date”
TC_MANUFACTURER: name of the device’s manufacturer (ex: “Apple”, “Samsung”)
TC_USER_AGENT: the device’s web browser’s user agent
TC_JAILBROKEN: jailbroken device (= “1”) or factory settings (= “0”)
TC_APPLICATION_STARTS: Number of the application’s cold starts. Cold starts correspond to the app’s first launch after a system reboot or whenever the app is closed and relaunched
TC_FOREGROUNDS: number of times the app is running in the foreground
TC_FOREGROUND_TIME: amount of time during which the app is open in the foreground (milliseconds)
TC_DELTA_FOREGROUND_TIME: time frame between the current time and date and the last time the app was opened in the foreground (milliseconds)
TC_BACKGROUND_TIME: amount of time during which the app runs in the background (milliseconds)
TC_DELTA_BACKGROUND_TIME: time frame between the current time and date ad the last time the app was running in the background (milliseconds)
TC_BACKGROUND_UX_TIME: amount of time during which the application runs in the background while interactive content is served to the user (milliseconds)
TC_DELTA_BACKGROUND_UX_TIME: time frame between the current hour and the last time the app ran in the background while interactive content was being served to the user (milliseconds)
TC_CURRENT_CALL_MS: time stamp of the hit’s generation (milliseconds)
TC_LAST_CALL_MS: time stamp of the previous hit’s generation (milliseconds)
TC_LAST_SESSION_LAST_HIT_MS: time stamp of the last hit registered during the last session (milliseconds)
TC_NOW_MS: Unix Time stamp (milliseconds)
TC_IDFA: Id of Google or Apple-served ads
TC_IS_TRACKING_ENABLED: indicates whether tracking is accepted on the device (YES/NO)
TC_LIMIT_USER_TRACKING_ENABLED: limited tracking on the device (YES/NO)
TC_LONGITUDE : user’s longitude if geolocation is authorized
TC_LATITUDE: user’s latitude if geolocation is authorized
TC_BUNDLE_IDENTIFIER: Id of the app’s batch allowing Commanders Act’s SDK to run
TC_APPLICATION_NAME: Name of the app allowing Commanders Act’s SDK to run
TC_RUNTIME_NAME: Device type (ex: Android / iOS)
TC_FIRST_VISIT_MS: time stamp of the app’s first launch (milliseconds)
TC_LAST_VISIT_MS: time stamp of the last visit’s start (milliseconds)
TC_CURRENT_SESSION_MS: time stamp of the current session (milliseconds)
TC_CURRENT_VISIT_MS: time stamp of the current visit (milliseconds)
TC_SESSION_DURATION_MS: current session’s length (milliseconds)
TC_VERSION_FIRST_VISIT_MS: for the app’s current version, it is the first time stamp of the first session following an app update (milliseconds)
TC_NUMBER_VISIT: number of times a user opened the app
TC_NUMBER_SESSION: number of sessions created in the app
TC_IS_FIRST_VISIT: whether it is the first time the app is launched (= “TRUE”) or not (= “FALSE”)
TC_FIRST_EXECUTE: the first time a developer executes the app with the execute() or SendData() functions after the latter is launched (= “TRUE” or “FALSE”). This variable can be combined with the TC_IS_FIRST_VISIT variable to retrieve the very first hit sent the first time the app was launched.
***
Android: internal variables calculated automatically by the SDK and specific to Android.
TC_UNIQUEID: random 64-bit number generated when the user sets-up the device for the first time. It remains the same throughout the device’s lifetime.
Creating a container for mobile applications
TagCommander’s SDK issues calls to TagCommander’s servers: you therefore have to create a “server-side” technology-based container for your mobile applications.
Please note: you can use a single server-side container for both the iOS and Android versions of your apps.
To learn more about how to create a server-side container, see serverside user manual.
Implementing tags on mobile apps
Implementing mobile tags is the same as implementing server-side tags (see serverside user manual)
The SDK implementation is performed by technical staff or IT departments.
These elements must be provided:
The app’s TagCommander tagging plan, which lets IT staff know which variables to declare and on which screens or elements.
Technical documentation referring to each and every app. It must contain elements that are key to setting up the SDK and screenshots of setup examples.
The site’s ID (Commanders Act account number) and that of the server-side container, which are necessary to set-up the SDK. These two elements can be retrieved in the container’s options section: click the “container options” icon (1) and copy the site (2) or container ID (3)
TagCommander’s SDK can be tested with many different tools:
In order to test your app, connect your Android phone to your PC.
Open the “Android Studio” app > Click “Start a new Android Studio project”. Click “Next” while on the following screens until you reach the main one called “Android Monitor”.
Then select your Android device (1) and choose the app you wish to test from the list (2).
To speed up tests, type “TagCommander” into the search engine (3).
These elements will be displayed when you analyze mobile logs (4):
TagCommander SDK’s version number: “Commanders Act SDK init with version: VERSION_NUMBER”
TagCommander’s site and container number: “SDK init with siteID SITE_ID and CONTAINER_ID
A list of the external variables that were provided by technical staff and that are visible in Android Studio, thanks to this function “TCLogLevel_Debug”: “Tag Commander Executing with appVars : AppVars : {#VARIABLE#: VALUE}”
***
The first thing to do is to configure your phone so it can communicate with Charles.
In your phone’s settings, go to the Wi-fi configuration tab.
Select your network and proceed to the advanced options to edit Wi-fi settings.
Add a proxy manually:
Proxy’s name (server)(1): Computer’s IP (you can find it in the “Local IP address” tab from Charles’ options)
Port (2): 8888
Save.
Go to the Charles app and authorize it to connect to the phone.
When you go to the “Request” area, you will be able to see all variables and the corresponding values that are sent through the TagCommander SDK.
HTTPS Protocol:
Most of the time, server-side calls are issued through an https protocol.
Download the certificate and install it; you will need to enter its name for two applications “VPN and applications” and “Wi-fi”.
Go back to Charles > “SSL proxy settings” > “SSL Proxying” > check “Enable SSL Proxying” > Click “Add” and type “*” in the “Host” field (to authorize any given host).
Then proceed to running tests the same way you do for http hits.
When the implementation is ok on your testing environment, you need to submit your app to app stores (Apple Store or Android Market) and wait for them to approve changes and include the new version in their catalogues.
This is a one-time procedure you will not need to repeat. This is because TagCommander’s SDK is available on JCenter for Android and Cocoapods for iOS, allowing developers to include a link leading to the latest version of TagCommander’s SDK in the applications.
To learn more about JCenter and Cocoapod, please refer to this content:
TAG > Tag Manager > Edition
The 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.
For example, a container in the <head> for your AB Testing solutions and another one in the <body> for the remaining solutions; or a container for the navigation pages and a container for the conversion funnel.
In this case, the data layer must always be located above all the containers so that the variables can be added to the tags.
Additional information:
Technically, the container is a JavaScript file containing the code of the tags to execute: this file must be called on all the pages that you wish to track.
We offer two ways to host your container:
Via our CDN (Content Delivery Network): we currently work with two select service providers, Edgecast and Akamai (100% 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.
The container is structured as follows:
To add a container, go to the “Dashboard” interface (1) and click “ADD CONTAINER” (2):
A configuration window will appear with 3 main tabs:
“General“: to manage basic container options (1)
“Synchronization“: to manage container updating options (2)
“Advanced“: to manage advanced container options (3)
After configuring the various container options, click “Add” (4):
“Name“: Container’s name
“Support“: Type of container
There are 2 container types:
HTML: For a container present on a web site or mobile site
Server-side: For a container containing server-side tags or for mobile applications.
Regardless of the type selected, the container will appear on the “Dashboard” once it is created.
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 “Options” > “Connector management“). By clicking this option, the “Set as deployed and send to FTP” 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 “Options” > “Connector management“). 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.).
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).
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 9 browsers/OS are tested (1):
The latest version of Edge
The latest version of Chrome
The latest version of Firefox
The two latest versions of Internet Explorer
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 (2):
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” (3):
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) (1); it will also appear on the Container line (2).
In this case, your container version is “NOT DEPLOYABLE” (3) 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” (4).
(1) Error message details returned by the tested browser
(2) 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.
(3) Clicking this button opens a new tab in your browser that displays the error it sent with the help of your console (only works if the browser currently being used is the same as that for which the error was detected):
(4 in the third image above) The tag’s code, for easily detecting the error in the example shown (open string).
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.
A container is deployed in the “DEPLOY” step (highlighted in pink below) :
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 its 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) (1), the name of the person who generated the version, a comment, and the container’s size (2). You will also be able to load your selected container version directly from the interface (3) or via a permanent link (4):
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 (1).
Note: to roll back the container, just select a previous container version.
Choose the deployment method (2).
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” (1) 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” (1):
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 in pink (2). To delete it click the red “Delete” button to the right.
A confirmation message will appear , please note that this operation cannot be undone.
To display container statistics, go to the “REPORTS” section > “Container firing“.
These statistics allow you to monitor container calls, view important information and make sure they continue to be called on your site.
You can find your container list on the left side of the “Container firing” interface (highlighted in pink below).
Click a container’s name to see its statistics: the deployed version number, the live version number, the last modification date and the tags’ default expiration period (2).
You can also display each container’s call statistics (3). These statistics are divided into four time periods: last day, last 7 days, last 30 days, and last year. Pass the pointer along the curve to see display detailed statistics.
The “Container firing” interface also allows you to modify one of your containers by clicking “EDIT” (you will be taken to the tag deployment process) (4), or delete a container by clicking “DELETE” (5).
modification date, average number of modifications per week) as well as access to all the technical logs, ordered by date and user.
You can also filter the list by user or date (4) and see details about the operations performed:
You can select a default trigger in the container options.
This means that each time you will add a tag to your container, the default trigger(s) will apply on this tag.
To select your default trigger(s), go in the container options (1), “advanced” part (2):
This trigger allows calling tags when the container is loaded on a page. It is the default trigger for all the tags you add to your container. This means that the tag will only be called when your JavaScript container loads on your site, but it will not be the case for other event types (such as a click, a page change within an “single page applications” environment, etc.). In order to trigger tags when a container loads on your page, all you need to do is selecting them from the list.
This trigger allows calling tags when the page’s structure is built (on the “DOM Ready” event). To launch tags on this event, all you need to do is selecting them. They will be called on the DOM Ready event when the page loads.
This trigger allows calling tags whenever elements of the page are clicked. Example: if you would like to call a tag when a user clicks a button (ex: “add to cart” button), select the desired tag(s) and enter the code allowing to target the button or the link on your page in the “CSS Selector” field.
Must know:
To retrieve the CSS selector, open your browser’s console and use its targeting tool (1) to target one of your page’s elements (2). Then right-click, the code appearing in your console (3), click “Copy” and “Copy selector” (4). All you have to do next is pasting this code in the interface.
You can enter many selectors in the interface; you will have to separate them with commas.
This trigger allows calling tags when a user submits a form. Example: when they click the “submit” button or press the Enter key. To call a tag when a form is submitted, follow the same steps you followed to call a tag upon a click. Indicate your trigger’s name (ex: “account creation confirmation”), select the desired tag(s) and enter the code allowing targeting the form submission button on your page in the “CSS Selector” field.
This trigger allows calling tags when a user scrolls the page vertically or horizontally. In order to execute a tag on scrolling, you will need to enter your trigger’s name (ex: “30% vertical scrolling”), select the desired tag(s), choose the scrolling type (horizontal/vertical) from the dropdown menu, the expected scrolling and measuring unit (page percentage or pixels).
This trigger allows calling tags whenever a TagCommander event function (tC.event.xxx) is identified on the page. If you wish to execute a tag on a custom eventm, please indicate your trigger’s name (ex: “add to cart click”), select the desired tag(s) and enter the implemented event function’s name (ex : “tC.event.add_to_cart”).
You can use the “Summary” interface to assign previously created rules directly to the new tags you want to add to the container:
By default, a newly added tag is called on the container loaded trigger, on all pages, with no constraints.
You can use this interface to add perimeters and constraints alerady created to tags or events added afterwards or modify them from the “Summary” interface:
To add a perimeter to a tag, you must check the box where the tag line and the perimeter column intersect (1). You can also delete a tag’s perimeter(s) by checking the green “All pages” column. The tag will now activate on all pages (2).
To add a constraint to a tag, click edit button close to the triggers and use the existing constraints list to select those you wish to add to your tag (3).
Additional information:
You can add multiple triggers, perimeters and constraints to the same tag:
The “OR” logic operates when multiple triggers are added to a tag. For example, if you check the “Container loaded” and “add to cart button” triggers, your tag will activate in one case OR the other, i.e. on the container loaded and at the click on the button.
The “OR” logic operates when multiple perimeters are added to a tag. For example, if you check the “homepage” and “account creation page” perimeters, your tag will activate in one case OR the other, i.e. for the homepage and the account creation page.
The “AND” logic operates when multiple constraints are added to a tag. For example, if you check the “logged user” and “mobile exclusion” constraints, your tag will activate only if the two conditions are met, i.e. only for logged users AND everything except a mobile device.
The “AND” logic operates when a trigger, a perimeter and a constraint are added to the same tag. For example, if you check the “container loaded” trigger, the “homepage” perimeter and the “logged user” constraint, your tag will activate only if the three rules are valid, i.e. only at the container loaded AND on the homepage AND logged visitors.
You can add 3 types of rules: constraint, perimeters and triggers.
Perimeters are the page types you want to activate your tags for (example: the homepage, “my account” page, product page, etc.).
Constraints are rules based on criteria other than the page type (example: rules based on visitor status, the type of browser or device, etc.).
Triggers are rules allowing to execute tags on different conditions: container loaded, DOM Ready, clicks, form submissions, scroll and custom events.
To create a new trigger, click “Trigger” (1) > “ADD TRIGGER” (2):
To create a new perimeter, click “Perimeters” (1) > “ADD PERIMETER” (2):
To create a new constraint, click “Constraints” (1) > “ADD TAG CONSTRAINT” (2):
By clicking “Add trigger” a rule creation interface will appear. This interface allows you to create a trigger of your choice: container loaded, DOM ready, click, form submission, scroll and custom.
By clicking “Add perimeter” or “Add tag constraint“, a rule creation interface will appear. This interface can be seen as a “tool box” that allows you to create rules based on various elements: cookies, data layer variables, URLs, etc.
The “tools” available to you can be selected at the top of the rules creation interface (1), and various options allow you to create the most appropriate rule for your tag (2). For each new rule created, make sure to complete the “Name” field (rule name), check the boxes of the tags to which the rule applies and configure the rule (3).
Note: The perimeter and constraint creation interfaces offer the same options, but in the constraint creation interface you need to link the constraint to a specific trigger:
To modify a rule, click the “edit” icon (1).
Note: you can modify the rule’s name and value. However, you must create a new rule if you wish to change its type: if you want to replace the “If Variable Equals” rule with “If Variable Is not Equal”.
To delete a rule, click the “trash” icon (1):
Note: your rule will be saved in the trash (2), where you can recover or permanently delete it at any time (3):
To learn more about external variables and steps to declare them in the interface please click .
Click here to read the corresponding technical documentation for Android:
TagCommander’s SDK for iOS can be tested with developing software “Android Studio”:
Server-side hit containing variables sent to TagCommander servers (POST method). You will see internal variables first, followed by external variables): “sending: With POST data: VARIABLE=VALUE&VARIABLE=VALUE…”
TagCommander’s SDK for both iOS and Android operating systems can be tested with the “Charles Debugger” proxy, downloadable for free here:
Browse the web with your phone and in Charles (on your computer) apply a “TagCommander” filter to see server-side hits displayed in the “Overview” section. They look like this:
Seeing https hits with Charles requires a more complex configuration. You will need to open your phone’s browser while Charles runs on your computer and go to this URL on your phone
JCenter for Android :
Cocoapods for iOS :
To edit a container, go to the “EDITION” tab from the “TagCommander” menu. Then click the gear next to the name of the container you want to edit (1):
A window will appear displaying the test error details. Below is an example of a possible tag 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:
This documentation is out of date ! Please refer to our latest documentation instead https://doc.commandersact.com/getting-started/concepts
Serverside version 2 refers to our new technical brick to perform advanced serverside activation use cases. It will replace the current Serverside v1 feature.
Serverside v2 is only available through our new platform. Please contact our support team if you are interested in using this feature.
This feature is also available from a Google Tag Manager container. Please refer to the Facebook CAPI GTM setup to explore the setup documentation.
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.
TagCommander’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 TagCommander 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)
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.
The following diagram explains how TagPerformance works, technically speaking:
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.
These variables are called internal variables because they are created inside the TagCommanders 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 TagCommander 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 TagCommander. 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:
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.
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 “Options” > “Internal Variables” > “ADD PREDEFINED VARIABLE” (1):
You will then be prompted to select a predefined variable universe.
The “add variable” window contains various fields:
(1) “Predefined universe“: Selection of predefined internal variable categories
(2) “Name“: Variable’s name
(3) “Description“: Variable’s description
(4) “Code“: Variable’s code
(5) 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 TagCommander 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.
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.
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”.
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 TagCommander consultant or support team can create custom variables for you if necessary).
To create your own internal variable, click “Options” > “Internal Variables” > “ADD VARIABLE” (1):
The “add variable” window contains various fields:
(1) “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.
(2) “Builder“/”Custom“: Select “Builder” or “Custom” creation mode
(3) Area to create the variable (see details below for the Builder and Custom modes)
(4) “Type“: The type of variable. Please refer to the article “Managing Variable Types“.
(5) “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”)
(6) “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”)
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”.
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 (1) and then enter and add your separator in the “add separator” field (2) in order to finish the “order_amount” variable in the “External variables” tab (1).
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 “order_products” variable) (1), then the “price” variable (here the “order_product_price” key) (2) and the separator “|” (3). For example, the value obtained might be: “22.50|33.98|94.30”.
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”) (1) and then add the output account IDs of your analytics solution in the “OUTPUT” field (2). You can also add a default value if none of the values entered in the “INPUT” field have been found (3).
This operation allows you to automatically send the correct account ID to your analytics solution depending on the work environment.
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:
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.mycustomvar):
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.
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 (1):
Once you have mapped your variable, click the symbol:
A window will appear with a list of different operations corresponding to the type chosen. Check the operation you want (for example, use only 2 decimal places in the amount) (1) and click “SAVE” (2))
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 (1):
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).
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 (1):
To realize a bulk action on multiple variables, check the variables of your choice (1), then choose the container(s) in the list (2):
Before you begin creating deduplication rules in the interface, you should define the following things and inform your Commanders Act consultant:
The digital marketing channels you wish to include in the configuration of the deduplication interface. Commanders Act allows you to configure natural and paid channels to take into account for the deduplication rules.
The “cookie window” (lookback window) settings you wish to configure for every channel: information on the channels that drove a user to your site are stored in a cookie whose lifetime usually is of 30 days. You can, for example, set it to 15 days for channel A and 30 days for channel B.
Setting deduplication rules is a two-step procedure:
Defining and configuring channel and sources recognition in the interface.
Applying deduplication and other rules to activate tags according to your needs.
/!\ If you wish to track impressions, you need to make sure a Commanders Act subdomain has been created for you and have your account manager confirm that the feature is enabled. Please note that setting up the subdomain and tracking impressions with our pixel is a paid service.
Click the Deduplication link in the TAG menu from the home logo
The Channel Identification menu will open, then
Click the ADD CHANNEL button.
Your channel will be displayed afterwards in the channels list.
When you click “ADD CHANNEL”, a new window will be displayed to allow you to configure a new paid channel (natural channels are set-up by default).
You can configure channels with one or more “channel” parameters and one or more “source” parameters (or no “source” parameters at all).
In the window that opens after you click “ADD CHANNEL”, enter your new channel’s name (Display, Affiliation, Retargeting, etc) – this is only a label to identify it in the Channel’s list in the interface – and click “ADD CONDITION”.
In the menu that appears (see below)(2), select the parameter that will store the information defining the channel (there are default parameters such as those used by Google Analytics, AT Internet as well as the possibility to add custom parameters)(2).
Select the condition (whether the value of the parameter matches or doesn’t match the value you are about to enter)(3).
Enter the value that will identify the channel (4). /!\ If a parameter’s value is made of more elements than the one you require, you need to use a star (*) to indicate what chunk is to be considered. For example, let’s say you only need “Retargeting” in this parameter: utm_medium=Retargeting-A1B3C3-crt. You need to write “Retargeting*” (values are case sensitive):
Click ADD (5) on the line of the channel declaration to confirm the creation of the condition.
Click SAVE (6) at the bottom, right-hand corner of the window.
In the window that opens after you click “ADD CHANNEL”, enter your new channel’s name (Display, Affiliation, Retargeting, etc) – this is only a label to identify it in the Channel’s list in the interface – and click “ADD CONDITION”.
In the menu that appears, select the parameter that will store the information defining the channel (there are default parameters such as those used by Google Analytics, AT Internet as well as the possibility to add custom parameters).
Select the condition (whether the value of the parameter matches or doesn’t match the value you are about to enter).
Enter the value that will identify the channel.
/!\ If a parameter’s value is made of more elements than the one you require, you need to use a star (*) to indicate what chunk is to be considered. For example, let’s say you only need “Retargeting” in this parameter:
utm_medium=Retargeting-A1B3C3-crt
You need to write “Retargeting*” (values are case sensitive):
Click ADD on the line of the channel declaration to confirm the creation of the condition.
Click the pencil icon next to “Source: Will not be captured” to modify settings for the source to be captured.
Select the capture method:
Taking all: the entire value of the URL parameter containing the source will be captured. For example, if the parameter in the URL is: “?utm_source=criteo” and you use “Taking all”, all the parameter’s value will be taken. In this case, “criteo”.
Splitting: splits the parameter’s value and takes the block you want. For example, if the parameter in the URL is: “?utm_source=retargeting|criteo|123456&(…)” and you use the setting depicted in the image below, you will obtain “criteo”.
Cutting: cuts a part of the parameter’s value and returns it. For example, if the parameter in the URL is: “?utm_source=criteo&”, you will obtain “cri” with the setting below.
Select the parameter containing the source that will be captured.
Save
Add the channel
This will allow you to have the tag fire depending on the value of the channel AND the value of the source.
In the window that opens after you click “ADD CHANNEL”, enter your new channel’s name (Display, Affiliation, Retargeting, etc) – this is only a label to identify it in the Channel’s list in the interface – and click “ADD CONDITION”.
In the menu that appears, select the parameter that will store the information defining the channel (there are default parameters such as those used by Google Analytics, AT Internet as well as the possibility to add custom parameters).
Select the condition (whether the value of the parameter matches or doesn’t match the value you are about to enter).
Enter the value that will identify the channel. Repeat these steps for as many possible combinations of parameters/values that could identify a channel. In the example below, if the utm_medium parameter in the URL takes the values “Retargeting”, “rtg”, “RTG”, or “retargeting”, the channel called/labeled “Retargeting” (1) will be recognized.
/!\ If a parameter’s value is made of more elements than the one you require, you need to use a star (*) to indicate what chunk is to be considered. For example, let’s say you only need “Retargeting” in this parameter:
utm_medium=Retargeting-A1B3C3-crt
You need to write “Retargeting*” (values are case sensitive):
You can also create conditions based on the “AND” operator. For example: if the UTM_MEDIUM parameter’s values are “Retargeting” or “rtg” AND the UTM_CONTENT’s parameter’s value is “email”, then, the Retargeting channel will be recognized (see second screenshot below).
If you wish to base your conditions on sources too (B), for every condition defining a channel, you will need to select a source.
When everything is setup, click ADD in the bottom, right-hand corner of the window.
In order to create groups of conditions combining “blocks” made of multiple channel+source parameters, follow the steps in C) (above), according to your needs. When you have created your first “block”, click the “ADD CONDITION GROUP” button to create a new set of parameters to be configured (1).
In the example below, the Retargeting channel will be recognized by the interface when either of the two conditions* is met.
*Condition 1: if utm_medium = “retargeting” or “rtg” and the source is captured and matches the configured value (said value is configured in the rules step).
OR
*Condition 2: if utm_medium = retargeting and utm_medium = email and the source matches the configured (said value is configured in the rules step).
Note:
You can select the default parameters (below) but also enter custom parameters or use the “Advanced” option to add custom JavaScript.
Example of custom parameter: “gclid” (SEM)
When you connect Google Adwords and Google Analytics, Google allows you to automatically link your two accounts by adding the “gclid” tracking parameter in your URL. This parameter replaces “utm_source = SEM” and indicates that traffic is SEM-originated. You can use a custom parameter to set this up.
When your channels and source-capturing methods are defined, you will return to the channel list and options.
You just need to write the iD values available on Mixcommander side. For each value you have to declare a channel. For example for the channel AFFILIATION, you have to create as many channels as IDs available on the mapping table ("Affiliation", "aff", "affiliate"). That's why it's very important when you create a campaign to use always the same id. Example : chn=affiliation.
Channel prioritization
You can change the order of paid channels and move them up and down according to the priority you want to give to each one of them. Channels are detected in the exact same order they are listed in the interface and do not exclude each other. So, in the event in which two or more conditions are true, the last condition will be taken into account.
For example, if you have two channels (Email Retargeting and Retargeting) configured as below.
Email Retargeting
Retargeting
The interface will only pay attention to the last condition (if utm_medium = retargeting) and will ignore the rest.
So if you have channels sharing one or more conditions, it is necessary that you place the channels with the least conditions first and those with the most conditions at the bottom of the queue so that all conditions are taken into consideration.
To reorder the channels, please use the handles to the left of the channel’s label.
Cookie Window Configuration
You can change the order of paid channels and move them up and down according to the priority you want to give to each one of them.
Check this box if the channel considers clicks.
Define the lifetime to the cookie storing click information (in number of days).
Check this box if the channel considers views.
Define the lifetime to the cookie storing views information (in number of days).
Define the number of touch points you want to store in the deduplication cookie. You can store no less than ten and no more than 50. The larger the amount of touchpoints, the heavier the cookie’s weight.
Enter the keywords for SEO brand identification, the full word or part of if (you can choose between “contains” or Regex). Declaring keywords is useful to differentiate branded and unbranded SEO in case one of both should be taken into consideration in the deduplication rules. Since some browsers, such as Google, have ceased to provide keywords – this is referred to as “not provided”-, the branded and unbranded SEO distinction is less complete than it used to be.
Add more keywords if necessary.
See the list of your keywords and how they are captured.
Configure your impression tracking pixel’s URL by replacing Channel with one of the channels you created and source with the desired parameter value.
/!\ If you wish to track impressions, you need to make sure a Commanders Act subdomain has been created for you and have your account manager confirm that the feature is enabled. Please note that setting up the subdomain and tracking impressions with our pixel is a paid service.
For more information on these fees please contact your account manager. For more information about Commanders Act’s view pixel, please refer to the “Tracking impressions” and “Structure of TagCommander’s impression pixel” articles.
When your channels are defined in the interface and you have specified whether the parameter storing the source of traffic will be considered or not to launch a tag, you will need to go to the “RULES” step in the TagCommander interface.
Set-up your deduplication rules by following these steps:
1.When on the RULES step, click the “Deduplication” button on the menu to the left.
2.In the new window, click “ADD DEDUPLICATION RULE” to open the rule configuration window. If you click “MANAGE CHANNEL(S)” you will be taken to the Channel Identification interface again
3.When the window opens, select the tag on which you wish to apply a rule from the dropdown menu.Please note: Deduplication is used on confirmation tags only.
4.Select the touchpoint’s position in the customer journey (beginning, end, anywhere).
First refers to the first touchpoint at the beginning of the customer journey (SEM/Google in the illustration below). A rule based on this position would call Google’s tag on the confirmation page and allocate the conversion to it.
Last refers to the last touchpoint before the conversion, at the end of the customer journey (if we consider paid traffic, it would be RETARGETING/Criteo in the image below, and Direct Access overall). A rule based on this position, would call Criteo’s tag on the confirmation page and allocate the conversion to it.
Any refers to any place throughout the customer journey (in the example below, all paid traffic solutions contributing to the conversion would be called on the confirmation page. That is Google, Tradedoubler and Criteo).
5. Select the nature of the touchpoint (click, view or both) you wish to include in your conversion attribution rules. For example, if you wish to consider only clicks, check that box and leave the view box unchecked. If you wish to consider them both, you should check both boxes.
6. Select your channel(s) (you must declare them first in the Channel Identification section; you can select more than one channel).
7. Select whether it corresponds or not to your channel.
8.State whether the source is ignored or (if you configured it to be captured in the channel identification interface) not. If not, define if all or only a part of it will be captured and if it has to match or not a certain value.
9.Enter the value of the parameter that will be compared to what was set in the interface, during the channel identification step, when you chose to capture the source.
10. Click “ADD” to add the rule.
After you create your rules, they will appear in the rules summary.
If your wish to edit a rule, click the pencil icon to the right on the line of each rule. If you wish to delete it, click the trash can.
The rules summary interface has a Deduplication column. A check mark will indicate what tags are deduplicated.
In order to enable the deduplication module, you will need to place the “Commanders Act – Get dedup cookie” and “Commanders Act– Reporting Deduplication v1.2” tags inside your container.
The “Commanders Act – Reporting Deduplication v1.2” tag
The “Commanders Act – Reporting Deduplication v1.2” tag allows you to collect conversion-related data (order ID and amount) and display it in the “By Tag” and “By Conversion” deduplication reports explained here.
You will then need to go to the tag library and add the tag to the container you placed in the confirmation page(s).
In the “Edit” section, map the “Commanders Act – Reporting Deduplication v1.2” tag with the corresponding variables from your data layer:
#TCIDORDER# (mandatory field) must be mapped with the data layer variable that collects the conversion ID (ex: tc_vars[“order_id”]).
#TCAMOUNTORDER# (optional field) must be mapped with the data layer variable that collects the conversion amount (ex: tc_vars[“order_amount”]). Whether you collect the order amounts excluding taxes or all taxes included is your choice.
In the “Rules” section, add a condition to your “Commanders Act – Reporting Deduplication v1.2” tag to call it only on your website’s confirmation page(s) (“confirmation page” perimeter).
The “Commanders Act – Get dedup cookie” tag
Important note: Before adding this tag, you need to make sure that a “commander1.com” subdomain has been added to your account from the “Admin”>”Domain management” interface (only administrators have access to this area). If the subdomain has not yet been created, please contact our support department (support@tagcommander.com).
The “Commanders Act – Get dedup cookie” tag lets you retrieve all the touch points from a user’s customer journey. These touch points are collected on the “commander1.com” subdomain that is associated to your account. This tag is indispensable if you track impressions for your deduplication rules.
Go to the tag library and add the tag to the container you placed in the confirmation page(s).
In the “Edit” section, make sure that the tag does indeed call your “commander1.com” subdomain (scriptElt1.src = “//domain.commander1.com/dg3/”). If it is not the case, please contact our support department (support@commandersact.com). No additional configuration is required for this tag.
In the “Rules” section, add a condition to your “Commanders Act– Get dedup cookie” tag to call it on all but the conversion page among the conversion funnel pages. This will allow you to retrieve all information stored in the “commander1.com” subdomain (especially impressions) when a user engages in the purchase process. Your tags will thus be called depending on the user touch points that are identified.
If you notice that a tag is slowing down your pages, please try the following:
Have the tag load after the DOM Loaded event. Caution: not all tags are compatible with this method and the more you delay a tag’s execution the more you loose data in your reports.
This code block allows calling a tag during the DOM Loaded event:
tC_ready = function(){
// Code du tag
}
if (window.addEventListener)
window.addEventListener(‘load’, tC_ready, false)
else if (window.attachEvent)
window.attachEvent(‘onload’, tC_ready)
Get in touch with the tag’s editor and request they improve their tag in terms of size or server response. Note: it is possible to include the tag’s JavaScript file in the Commanders Act container while on the “EDIT” tab from the TagCommander interface.
Sample the tag from the “RULES” tab from the TagCommander interface. This will improve the average loading time of your site’s pages.
Shifting the tag’s execution order from the “GENERATION” (1) tab from the TagCommander interface (place the one taking longer to load at the end of the queue).
Use a timeout on your tags from the “GENERATION” (1) tab from the TagCommander interface. This feature interrupts the tag’s execution if it takes too long to load.
Deactivate the tag from the “GENERATION” (1) tab from the TagCommander interface (1)
Use your tag in a serverside configuration (this entails activating an additional module from the TagCommander product, please contact your account manager or our Support Department for further information). Caution: not all tags are compatible with this method.
For more detailed information on how to set up these methods, please contact our Support Department (support@commandersact.com).
The “Report by Conversion” report provides information pertaining to the tags that were called for every conversion on your site, according to the rules you defined in the rules section, more specifically deduplication rules. Data is collected by the “Commanders Act – Reporting Deduplication v1.2” tag.
Access
To access the report, please click the “Deduplication” entry from the main menu.
Then click the “Report by Conversion” tab (1).
Interface Description
Calendar
The calendar allows you to select a period of time to display deduplicated tag calls. There are eight predefined periods (Yesterday, Last Week, Last 30 days, Last Month, Last Quarter, Month-to-Date, Quarter-to-Date, Year-To-Date) and you can customize the period you wish to see tag calls for. You also have the possibility to compare periods to have a clearer vision of the way tags’ performance has evolved from one period to another.
“Report by Conversion” Table
This table displays the number of tag calls for every conversion:
“Conversion ID”column: displays your conversions’ IDs.
“Date”column: displays a conversions’ time and date.
“Revenue”column: displays the conversions’ amounts (including or excluding taxes, depending on the amount you chose to collect with the “TagCommander – Reporting Deduplication v1.2” tag).
“Tags” column: lists all tags that were called per conversion. Rules affecting tags are all considered, especially deduplication rules.
“Detail”column: it displays a popin with the detailed customer journey per conversion. The popin is made of four columns.
Position: displays, in descending order, the position of every touch point within the customer journey associated to the conversion.
Type: displays the touchpoint’s type (click or impression).
Channel/Source: displays the channel (lever) and source (solution) corresponding to every touch point.
Date: displays every touch point’s time and date.
The search engine above the table allows you to easily and quickly find a conversion simply by typing its ID.
The “Advanced Filtering” button lets you filter results by tag to find a conversion faster.
Exporting the “Report by Conversion” table
The “export” icon on top of the table allows you to export the “Report by Conversion” report:
If you click “CSV” you will receive the CSV report directly in your mailbox.
If you click “Email”, you will be able to enter the email addresses of people you wish to send the CSV report to.
The “Report by Tag” report allows you to see, over a specific period of time, the number and evolution of calls to the tags that were placed on your confirmation page(s), more specifically those of deduplicated tags. Data is collected by the “Commanders Act – Reporting Deduplication v1.2” tag.
Access
To access the report, please click the “Deduplication” entry fromthe main menu.
Then click the “Report by Tag” tab (1).
Interface Description
Calendar
The calendar allows you to select a period of time to display deduplicated tag calls. There are eight predefined periods (Yesterday, Last Week, Last 30 days, Last Month, Last Quarter, Month-to-Date, Quarter-to-Date, Year-To-Date) and you can customize the period you wish to see tag calls for. You also have the possibility to compare periods to have a clearer vision of the way tags’ performance has evolved from one period to another.
“Tag calls’ evolution” graph
The “Tag calls’ evolution” graph displays calls to the tags checked in the “Tag Calls Detailed” table. If you wish to display data for other tags, simply check the corresponding box and click the table’s refresh icon. A curve with a specific color is associated to every tag. When you click the tag’s name in the graph’s legend, the curve corresponding to the tag whose name you clicked will disappear or reappear.
The arrow in the graph’s upper right-hand corner allows you to unfold or collapse the latter.
The button in the graph’s bottom right-hand corner lets you see calls to deduplicated tags on a daily or weekly basis.
“Tag Calls Detailed” table
Tags listed in the “Tag Calls Detailed” table are tags placed on pages where the “Commanders Act – Reporting Deduplication v1.2” tag was included too.
The table displays the number of calls that were issued:
The “Conversions” column indicates the number of times a tag was called over a given period of time. This number considers deduplication and other rules placed on your tags.
The “Conversion Share” column displays the percentage of conversions a given tag participated in, according to the exact same rules as those considered in the “Conversions”
The “Detail” column allows you to see the IDs of conversions a tag was called for, as well as the corresponding time, date and amount (including or excluding taxes, depending on the amount you chose to collect with the “TagCommander – Reporting Deduplication v1.2” tag.
You work with Retargeting solutions and your tracking URLs look like:
mysite.com?utm_medium=RETARGETING&utm_source=Criteo
mysite.com?utm_medium=RETARGETING&utm_source=MyThings
Where the utm_medium parameter stores the channel and utm_source stores the source (namely your partners).
In order to fire only the tag of the partner to whom the sale is attributed, you would need to follow these steps:
Defining Channels and Sources
Adding a Channel: click “Add Channel” (1)
Name the channel and add the parameter that will store the value defining Retargeting (Add Condition)
Define the condition (Parameter Match or Not and the comparison value) and specify whether or not the value of the parameter containing the source will be captured (pencil icon).
Select the capture mode of the parameter containing the source (the whole value, or parts of it), then confirm the channel identification condition by clicking ADD.
Save the source-capturing settings and save the Channel configuration (Click “SAVE”).
Now that you have defined the retargeting channel, you can define firing rules for your retargeting tags Criteo and MyThings.
Click the edition tab and go to the Rules step. Once there, click “Deduplication” on the menu to the left (1).
In the new window, click “ADD DEDUPLICATION RULE” to open the rule configuration window.
When the window opens, select the Criteo OneTag Conversion tag from the dropdown menu (3).
Select “Last” among the options relating to the touch point’s position in the customer journey. This will fire the tag if it is the last paid solution in the customer journey, now you need to define if it is the last paid click, impression or both (4).
Let’s say you want to launch the Criteo OneTag Conversion tag only if it is the last paid click. Select “click” from the options (5).
Select whether it corresponds or not to your channel (6).
Select “RETARGETING” from the dropdown menu. All channels that you have defined will become available in this menu (7).
Select “EQUALS” for the source. When you configured the channel you indicated that the source of traffic (partner) would be captured by “taking all” the value of the “utm_source” URL parameter. Since your tracking URL for Criteo looks like this:
www.mysite.com?utm_medium=RETARGETING&utm_source=Criteo
You will need to select “EQUALS”.
Enter the value of the parameter that will be compared to what was set in the interface (“Criteo”) (9)
Click “ADD” to add the rule (10).
Repeat these steps for your MyThings Conversion tag.
When both your rules are created, they will appear in the rule summary.
If your wish to edit any of them, click the pencil icon to the right on the line of each rule. If you wish to delete it, click the trash can.
The rules summary interface has a Deduplication column. A check mark will indicate that your two tags are deduplicated.
To add a new container, go to the “Dashboard” interface (1) and click “ADD CONTAINER” (2):
In the configuration window, select “Serverside” (1) and click the “Add” button (2):
Your server-side container is ready to be configured.
The “SELECT” step (1) is the first phase of the tag configuration process: it allows you to select tags to add to your container from a tag library. To add one or more tags, click “ADD SERVER-SIDE TAG(S)” (2):
A window containing the list of tag templates ordered by publisher name will appear. There are different filters to look for the tag(s) you need (sorted by alphabetical order or by solution name), as well as a search engine. Select the tag(s) you need (1) and click the “ADD SERVER-SIDE TAGS” button (2).
NB: if you do not find the tag you wish to add among those listed, you have two choices:
Sending an email to Commanders Act support department or to your Consultant to request a partner solution be listed in our library (this takes about three weeks to do).
Adding a “Free input (custom)” tag where you can copy and paste the code your partner solution provides you with:
Tags you just added now have to be populated with information required by your partner solutions.
The “EDIT” (1) step is where you “map” tags with variables needed by them and which are present in the Data Layer:
You can see in the left-hand side of the interface (1) the list of tags you just added. A “warning” icon displayed in front of tags’ names indicates that they have not yet been configured and validated.
You can begin by naming your tag (2) and defining a delay (3) defined in seconds. This allows calling it asynchronously on Commanders Act’s servers. We recommend a delay of 1 second or higher.
When this is done, you can start configuring your tag.
There are two areas available to do this:
A “URL (GET)” section (mandatory): it is the server-side URL’s visible part when calling a partner solution.
“HEADER (POST)” (optional): it contains information sent in the server-side’s query header (2).
You can send POST information in two formats: key=value combinations within an associative array (“Standard” tab (3)) or JSON (4).
Configuring the “URL (GET)” part:
URL (GET) corresponds to the visible part of the server-side URL.
Important:
Do not forget to systematically add a URL in the “GET” part even if you wish to send parameters in “POST”.
The expected format of the “GET” block is a URL. You should never add JavaScript code in this block (JavaScript tags are only compatible with Web containers).
Parameters that are sent to partner solutions in “GET” format must be included in the query string (after the question mark in the URL “?”) in a key=#value# format as shown in the following example: http://logc8.xiti.com/hit.xiti?s=#s#&s2=#s2#&idtransact=#transactid#
The #value# nomenclature represents your URL’s dynamic variables (i.e. parameters expected by the solutions that need to be populated). They are visible both in the URL’s code, in bold and blue characters (1), and underneath the tag’s code (2). You have to map these dynamic variables with those present in your server-side Data Layer, available from the dropdown menus, or with static values (example: an account ID) (3):
Configuring the “URL (POST)” part:
HEADER (POST) corresponds to the server-side Header’s query.
The Header’s code must not exceed 65,000 characters.
Two different formats can be used in the POST section:
An associative array with key=#value# combinations available from the “Standard” tab (1)
A JSON structure (“JSON” tab) (2). Important :
Your JSON code must begin and end with curly brackets {}.
Use commas as separators but omit that which should be placed right before de closing bracket (}).
“String” values (strings) you will send your partners have to be written as follow: “key”:“#value#“. (Most common).
It is also possible to send your partners “integers” or “Booleans. In this case, they should be sent in this format: “key”:#value#. It will only work if “input hits’” values’ types are “integer” or “Boolean”.
Warning signs to the left of the code block will remind you that the standard “string” format is not “key”=#value# as in Web containers, but rather “key”=“#value#“.
Please note: it is possible that certain solutions ask you to send information in a key={JSON} format. Go to the “STANDARD” section to configure this format. Rules applicable to JSON are exactly the same as those mentioned above (even if syntax color codes do not work the same).
Here again, the #value# nomenclature represents your URL’s dynamic variables. They are visible both in the URL’s code, in bold and blue characters (1), and underneath de tag’s code (2).
You have to map these dynamic variables with those present in your server-side Data Layer, available from the dropdown menus, or with static values (example: an account ID) (3):
The “RULES” section is where you create firing rules for your server-side tags.
The two tabs in the left-hand side menu let you manage tag activation:
The “Summary” tab displays a summary of all the rules created for each tag (1)
The “Constraints” tab allows you to create rules for your tags (2)
To create a server-side rule, click the “Constraints” tab, then the “Add tag constraint” button (1):
A new window opens : this is where you add the rules. This interface can be considered as a toolbox allowing you to create rules based on two elements: data layer variables (“Variables”) or mobile OS (“Mobile”)(1).
Select the corresponding rule (2) and then:
Enter the it’s name in the corresponding field (“Name”)(3)
Check the tags you wish to apply the rule to (4)
Configure the rule (5)
Rules based on variables
The “ Variables” menu lets you create rules based on variables from your data layer (external or internal):
“If variable equals (GET and POST)”: Tags execute if the variable equals the specified value.
“If variable is not equal (GET)”: Tags execute if the variable (present in the query string of the incoming server-side hit, i.e. in “GET” format) is different from the specified value. This is the rule that will need to be used in most cases, rather than “If variable is not equal (POST)”.
“If variable is not equal (POST)”: Tags execute if the variable (present in the header of the incoming server-side hit, i.e. in “POST” format) is different from the specified value.
“If variable equals (based on saved Data)”: Tags execute if the “data storage”-type variable equals the specified value.
“If variable is not equal (based on saved Data)”: Tags execute if the “data storage”-type variable is different from the specified value.
“OR condition (one variable)”: Tags execute if the variable equals at least one of the specified values (the variable must be present in the query string of the incoming server-side hit, i.e. in “GET” format).
“NAND condition (one variable)”: Tags execute if the variable is different from the specified values (variable in “GET” format).
“OR condition (up to six possible variables)”: Tags execute if at least one of the variables equals the specified value (variable in “GET” format).
“AND condition (up to six possible variables)”: Tags execute if all variables equal the specified values (variable in “GET” format).
“If variable contains”: Tags execute if the variable contains the specified value (variable in “GET” format).
“If variable doesn’t contain”: Tags execute if the variable does not contain the specified value (variable in “GET” format).
“If variable exists”: Tags execute if the variable exists (variable in “GET” format).
“If variable doesn’t exist”: Tags execute if the variable does not exist (variable in “GET” format).
“Greater than condition”: Tags execute if the variable is greater than the specified value (variable in “GET”).
“Less than condition”: Tags execute if the variable is lesser than the specified value (variable au format GET).
Rules based on mobile OS
The “Mobile” menu lets you create mobile OS-based rules:
“Android”: Tags execute if the mobile OS is “Android”.
“iOS”: Tags execute if the mobile OS is “iOS”.
“Not Android”: Tags execute if the mobile OS is not “Android”.
“Not iOS”: Tags execute if the mobile OS is not “iOS”.
If you wish to modify (1) or delete a variable (2), click the corresponding icons in the rules summary page:
To generate a new container version and save all your work, please move forward to the “GENERATE” step (1).
Enter a comment (entering a comment is mandatory in order to keep good logs about the different container versions) (2) and click the blue “Generate” button (3).
Before generating your container, you can define the execution order of all your tags by clicking the handle (lines) and dragging and dropping each tag in the desired order (“RANK” column) (1). You can also activate or deactivate a tag by checking or unchecking the boxes (“ACTIVATION” column) (2).
Go to the “TEST” step to test your server-side container and verify outgoing hits’ structure.
Select the container version you wish to run tests on from the dropdown menu (1). Parameters sent with both GET (2) and POST (3) methods will be tested. Click the “Test” button (4) and make sure, by looking at the generated code, that outgoing hits are correctly structured (5):
Note: if you have already deployed your container, you still can test the live version (1) or an older/newer version in this section (2).
is the server-side incoming hit’s structure, which you need to provide your technical staff with for calls to Commanders Act servers from your servers occur.
In this section you can also consult the deployed versions’ history (1) and retrieve the server-side URL’s structure once your container is deployed (2): it is the server-side incoming hit’s structure, which you need to provide your technical staff with for calls to Commanders Act servers from your servers occur.
Server-side external variables consist of all the information sent by your IT staff to Commanders Act through server-side hits (input hits).
Reminder of server-side incoming hits’ structure:
http://serverside$siteID$.commandersact.com/$containerID$/?variable1=value1&variable2=value2…
$siteID$ and $containerID$: Commanders Act site and container identifier
variable1, variable2: server-side data layer’s variables (ex: ProductID, UserID, Order Amount…)
You can use these external variables to populate server-side tags or to create firing rules to execute them.
Server-side external variables have to be declared in the “Options” tab from the “Commanders Act” interface at the beginning of the project (or later on if the data layer changes). To add a new variable, click the “ADD VARIABLE” (1) button in the “Server-Side” section from the “External Variables” menu.
The variable creation window contains different fields:
(1) “Name”: variable’s name (mandatory field).
(2) “Parameter label”: parameter name within the incoming server-side hit (ex: order_id in this hit http://serverside123.tagcommander.com/1/?order_id=1234).
(3) “Data storage”: do not check this box in a classic server-side implementation. This option is used in hybrid server-side configurations. (Please refer to the corresponding article).
(4) “Category”: variable’s category. It allows you to classify variables according to their use (ex: variables pertaining to users, product pages, confirmation pages, etc.). Variables’ categories are added by clicking the “Manage categories” button next to the “ADD VARIABLE” button.
(5) “Description”: Variable description; it needs to be provided to simplify understanding of the variable’s name. (ex: “Page template” could be the description associated to the “env_template” variable).
(6) “Detailed description”: Detailed description of the variable; it needs to be provided to simplify understanding of the variable’s name (ex: “possible values: homepage/category/product/funnel_confirmation could be the detailed description associated to the “env_template” variable).
When the variable is added, it appears in the variable’s list.
When a flag is displayed next to it, it means that it is currently being used in a tag or a rule. Click the flag to learn more (1).
There are two types of internal variables:
Predefined internal variables, which are variables that are calculated automatically by Commanders Act servers
Custom variables, which allow you to reformat server-side variables’ values with a correspondence table (equivalent to internal variables mapped within Web containers)
1)-Predefined variables
To add a new predefined server-side internal variable, click “Server-Side” > “Internal variables” > “Add predefined variables” (1).
Select “server-side” (2) from the dropdown menu in the popin window and choose the variable(s), among those listed, you wish to add to your account. (Please note: the tick mark atop the column allows you to check/uncheck al variables) (3):
There are six default internal variables in your server-side container:
TC_UNIQ_ID: Commanders Act user ID
IP: Visitor IP
TC_REFERER: User referrer
RANDOM: Random number between one and one billion
TC_TIMESTAMP: Time and date of the server-side hit
USERAGENT: Server’s User Agent (IP, browser, etc. combination)
You can use these internal variables to populate server-side tags or to create firing rules to execute them.
2)-Custom Variables – Correspondence Table
To add a new mapped internal variable, click “Server-Side” > “Internal variables” > “Add variable” (1).
Enter your new variable’s name (2)
Select the server-side variable you will use as reference to create your correspondence/matching table (3)
In the “INPUT” column of the correspondence table, enter your reference server-side variable’s values (4)
In the “OUTPUT” column, enter the values you wish to populate your new variable with (5)
You can also add default values in case none of those present in the “INPUT” column are found (6)
Click “SAVE” (7):
Manage consents in Serverside context
If you setup a serverside tag from your web container, one way to manage consents is to fire or not your serverside tag depending of your CMP signal. Commanders Act offers with TrustCommander an integrated way to manage the firing of your tags depending of consent categories by a simple mapping beetween your tags and your categories.
Nevertheless, for a more precise management, even in hybrid setup we recommand to manage consent in serverside constraints.
We recommand to manage your serverside's tags through constraints, using a variable containing the list of optin categories.
Create an external variable consent_categories and feed it with the user's consent from your CMP. We recommand that consent_categories is feeded by a list of categorie's ids.
(You can also create one variable per category of course if needed)
2. Create a constraint in your serverside container that rely on consent_categories
3. Attach the constraint to your tags
With TrustCommander, you can get your consent categories easily inside your client container using our Javascript APIcact('consent.get') and put the result inside a variable that will be send through your serverside tag.
See documentation here : https://community.commandersact.com/trustcommander/onsite-api/consent.get
The TagPerformance tag must be included in each and every one of your containers.
If you have many containers on a given page and as many TagPerformance tags, only one hit containing information about your tags will be sent.
It is not necessary to place it in a particular order within your containers, as it will automatically execute two seconds after the DOM Loaded event, that is to say, after all the other tags have loaded.
In the tag library, select the “Commanders Act – TagPerformance” tag.
There is nothing to configure in the “EDIT” step: Generate a new container version and deploy it.
Advanced – Customizing the “TagPerformance” tag:
It is possible to force-measure a tag’s performance (for example, that of a tag outside the container, that of a custom tag whose URL paths are not recognized by TagCommander or that of a tag that is not present in the TagCommander tag library). If you wish to measure a new tag’s performance, place the following code block in the commented line (4 (1) tC.tagPerf.customPatterns.push({label:’Solution A’,p:’domain\.com.*js\.js’})
Example:
tC.tagPerf.customPatterns.push({label:’exelate’,p:’loadm.exelator.com’});
You can also add additional filters (in addition to default filters page type, container, device, OS and browser). If you wish to add a custom filter, place the following code block in the commented line (4): tc_vars[“custom_segment”] = #custom_segment#;
Note: You can only add one additional filter.
Example: to add a “page category” filter (tc_vars[“page_cat1”]) :
tc_vars[“custom_segment”] = tc_vars[“page_cat1”];
Finally, you can change the capturing method of the “Page Type” filter, which is available in the reports. This filter is based on the tc_vars[“env_template”] variable by default. If this variable is not available on your site, you can rely on a different variable by adding the following code block in the commented line (4) tc_vars[“env_template”] = #page_type#;
Example: if you wish to replace tc_vars[“env_template”] with tc_vars[“page_type”] :
tc_vars[“env_template”] = tc_vars[“page_type”] ;
In order to be able to visualize TagPerformance reports, you have to request the activation of this module, not included in the basic TagCommander offer. If you are interested in using TagPerformance, please get in touch with your account manager or our Support Department (support@commandersact.com).
To access the reports,
Log in to the TagCommander Interface and click the TagPerformance menu
You will be taken to the dashboard where three reports are available: “Dashboard”, “Report by Tag” and “Tags Hierarchy“.
The “Dashboard” report provides an overview of tags’ performance on your site:
You will find below a detailed explanation of the report’s analysis windows.
1)-The three main indicators (Start Render, DOM Ready, DOM Loaded):
Average Start Render (First Paint): average loading time on site of the Start Render event.
Average DOM Ready: average loading time on site of the DOM Ready event.
Average Page loading time (on load): average loading time on site of the DOM Loaded event.
Note: These three metrics consider the following filters “page type”, “container”, “device”, “OS” or “browser”.
Example: These three pages are loaded on your site:
Les 3 pages suivantes sont chargées sur votre site :
The three metrics would take the following values:
“Average Start Render (First Paint)”: 5 sec (700ms, 500ms and 300ms on average)
“Average DOM Ready”: 8 sec (2000ms, 2200ms and 1100ms on average)
“Average Page loading time (on load)”: 6 sec (2800ms, 2800ms and 2100ms on average)
2)-The Pie Chart:
The pie chart highlights tags that take longer to load in terms of the selected level of analysis in the available filters: Start Render, DOM Ready, DOM Loaded or Cumulated loading time.
Example: the pie chart above appears once the “Tags impacting start render (First Paint)” level of analysis is selected. It shows that the “Lengow lead validation” tag is the tag that delays the most the Start Render event, because it takes about 17% of total time preceding the Start Render event.
By clicking the “Others” part, you will be able to obtain more details about the remaining tags affecting your site’s loading time.
Note: the pie chart that appears next provides the proportion of each tag in relation with the “Other”’s total.
Example: Here below, the “Effiliation” tag takes about 14% of the “Other”’s total loading time (14% of the 21% of global loading time, which “Others” account for).
3)-Main Tag Variations:
The “Main Tag Variations” graphs allow you to identify tags whose loading time has varied (+/-10%) over a selected period of time in terms of the selected level of analysis in the available filters: Start Render, DOM Ready, DOM Loaded or Cumulated loading time.
The tag’s variation measures gaps in tags’ loading times in relation with the median (and not the average, in order for it to be less sensitive to extreme values). Calculation is based on the six previous identical periods.
Example:
We wish to analyze the variation of tags affecting the Start Render event on May 22nd.
In the screenshot below, we can see a 65% increase in AB Tasty’s loading time for that day. The tag does indeed take 61.96ms to load, whereas the median for the six previous days was of 37.65ms. (May 16th: 48.05ms /May 17th: 30.30ms / May 18th: 35.77ms / May 19th: 27.44ms / May 20th: 64.11 ms / May 21st: 39.53ms).
4)-Main Page Type Variations:
The “Main Page Type Variations” graphs allow you to identify the page types whose loading time has varied (+/-10%) over a selected period of time in terms of the DOM Loaded event only (the page’s loading time is defined with the arrival of the DOM Loaded event).
Note: The page type corresponds to the default “page type” filter available on the interface.
The page type variation measures gaps in pages’ loading times depending on their type and in relation with the median (and not the average). Calculation is based on the six previous identical periods.
Example:
We wish to analyze variations in types on May 2nd.
In the screenshot below, we see a 31% reduction in loading times for the “newsletter” page type on that day. It takes 5.23ms to load whereas the median in the six preceding days was of 7.6ms (April 26th: 7.58 ms / April 27th: 5.31 ms / April 28th: 8.16 ms /April 29th: 7.62 ms / April 30th: 7.84 ms / May 1st: 6.02 ms).
1)-The four main metrics
Average page loading time: average loading time of your website’s pages (= DOM Loaded). This loading time is compared to that of the previous period (ex: the previous day or week according to the selected period).
Average tag loading time: average loading time of the tags on your website according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time). This loading time is compared to that of the previous period (ex: the previous day or week according to the selected period).
Lowest impact tag: tag that takes the least time to load according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time).
Highest impact tag: tag that takes the most time to load according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time).
Note: These four metrics consider the selected filters among “page type”, “container”, “device”, “OS” or “browser”.
2)-TagPerformance by tags
The graph shows information about tags’ loading time on your website.
To select tags to analyze with the graph (1), check the corresponding tag in the “Tags” report (2) and reload (3).
You can compare this data to generic information about the page’s context. To do so, select the indicators you are interested in from the dropdown menu above the graph.
Metrics related to the analyzed tags:
Tag Loading time: tags’ loading time according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time).
Tag firing: number of times tags are loaded on the site (this metric is independent from the filters).
Metrics related to the page’s context:
Tag number: number of tags present in the last generated version(s) of a container.
Average start render (First paint): average loading time of the tart Render on the site.
Average page structure building (DOM Ready): average loading time of the DOM Ready on the site.
Average page loading time (OnLoad): average loading time of the DOM Loaded on the site.
Note: These six metrics consider the selected filters among “page type”, “container”, “device”, “OS” or “browser”.
Example:
You wish to know if a tag loading during the Start Render event has an impact on the site’s global Start Render.
Use the “Tags impacting Start Render (First Paint)” filter on your report:
Select the tag to analyze:
Select the following metrics from your graph: “Tag Loading Time” (the tag’s loading time) and “Average Start Render (First Paint)” (average loading time of the Start Render):
The result below shows that the selected tag has little impact on the site’s Start Render, as the increase in the tag’s loading time at 13h (1) did not cause the Start Render’s average loading time to increase as well at that very moment.
3)-Tags
The “Tags” section of the report provides deeper insight about the tags that are loaded on your site, according to the level of analysis you selected from the filters on the top left-hand side (Start Render, DOM Ready, DOM Loaded, Cumulated loading time) and top right-hand side of the page (“page type”, “container”, “device”, “OS” and “browser”).
You can analyze the following elements for each tag:
“Tag loading time” (ms): Loading time in milliseconds
“Tag firing”: Number of times a tag is loaded
If you click a tag’s name, a graph appears showing these items:
The tag’s loading time compared to the previous period (ex: previous day if the analysis is done by day).
The tags’ average loading time compared to the previous period.
The number of times a tag is loaded compared to the previous period (ex: previous day if the analysis is done by day).
The number of times tags are loaded on the site compared to the previous period.
Note: The current period is always displayed in green and the period of comparison in blue.
“Piggybacking”, consisting in triggering a tag with another, has widespread exponentially with the appearance of programmatic. The subsequent data leakage has generated legal issues and financial losses for companies.
Amid this context, the “Tag Hierarchy” report provides a global insight of requests happening while your website and its content load. You can thus better control calls issued from your website and exchanged data.
Report Structure:
1/Page type filter:
This report is filtered by page type (“page_type” option on the segmentation menu). The default selected page type is the first one appearing on the list (1) and is displayed on the top, left-hand side of the report (2):
You can at all times apply filters on different page types or deselect enabled filters to have an overview of your site (please note that in this case, the report might take a little longer to load, as it will combine all domains called on your website).
2/Request type (script/iframe/pixel)
The report highlights the request’s nature/type:
Script (URL called with <script> tag)
Iframe (URL called with an <iframe> tag)
Pixel (URL called with an <img> tag)
“Other” (in case the request type is not identified)
3/Request Detail
The “Tag Hierarchy” report allows you to visualize all domains called from your main domain and all other domains they call on different levels:
On the diagram above, sub-domain 2 (“sub-domain 2”) is called from your site’s main domain. It is a JavaScript file (blue circle) that in turn calls two pixels (green circles) and a JavaScript file. Waterfall calls stop here for this request, but this is not the case for sub- domain 1 (“Sub-domain 1”), which calls JavaScript files which in turn issue new requests.
In order to provide you with better readability, same-type “childless” requests (script/iframe/pixel) coming from the same domain are gathered under the same domain name, and a number between brackets next to the domain’s name indicates how many calls were issued from it:
By hovering over any of these domains (ex: ) you will see, with greater detail, which URLs are called by them:
You will also be able to see the URL structure and its parameters for certain requests, hence all the information sent to solutions called on your website:
4/Report dates
Displayed data is collected over the past 24 rolling hours.
This export is currently unavailable.
1)-Select your level of analysis:
“Tags impacting start render (First Paint)”: This corresponds to the aggregated loading time of hits that are sent prior to the Start Render event.
“Tags impacting page structure building (DomReady)”: This corresponds to the aggregated loading time of hits that are sent prior to the DOM Ready event.
“Tags impacting page loading time (Onload)”: This corresponds to the aggregated loading time of hits that are sent before the DOM Loaded event.
“Cumulated tag loading time”: corresponds to the aggregated loading time of all hits (including those sent after the DOM Loaded event).
Example: The following diagram shows an extract of tags present on the site:
These are the results you will obtain when you select the following levels of analysis:
“Tags impacting start render (First Paint)”: TAG1 (HIT1) + TAG2 (HIT1)
“Tags impacting page structure building (DomReady)”: TAG1 (HIT1) + TAG2 (HIT1) + TAG1 (HIT2) + TAG1 (HIT3)
“Tags impacting page loading time (Onload)”: TAG1 (HIT1) + TAG2 (HIT1) + TAG1 (HIT2) + TAG1 (HIT3) + TAG2 (HIT2)
“Cumulated tag loading time”: TAG1 (HIT1) + TAG2 (HIT1) + TAG1 (HIT2) + TAG1 (HIT3) + TAG2 (HIT2) + TAG1 (HIT4)
If you wish to know more about the “Start Render”, “DOM Ready” and “DOM Loaded” concepts please refer to the Definition of TagPerformance Metrics article.
If you wish to know more about the technical elements that are captured by TagPerformance, please refer to the Advanced: Technical functioning of TagPerformance article.
2)-Select, if need be, one of the default filters from the interface should you require a more detailed analysis of your site’s performance.
The page type: This filter allows you to display your tags’ performance in terms of the page template. It is based on the “env_template” variable’s values, which are automatically captured by TagPerformance.
Note: If you do not have an env_template variable on your site, you still can capture the values of other variables. Please refer to the Adding the TagPerformance Tag article.
The container name: This filter allows you to display how tags within one or more specific containers are performing.
The device: This filter allows you to display your tags’ performance in terms of the devices your visitors are using. The “device” metric is calculated automatically by our servers, based on the user agent.
OS: This filter allows you to display your tags’ performance in terms of the devices your visitors are using. The “OS” metric is calculated automatically by our servers based on the user agent.
The Bowser: This filter allows you to display your tags’ performance in terms of the browsers your visitors are using. The “browser” metric is calculated automatically by our servers based on the user agent.
Note: if you wish to add an additional filter, please refer to the Adding the TagPerformance Tag article.
3)-Click “Apply” to obtain filtered results and a different level of analysis.
The first step consists in collecting the necessary information through the web container.
To do this, you will need to add the “Commanders Act – Data Saver 1.0” tag to your container, it will collect the information you need and store it for 24 hours on Commanders Act servers.
1)-In the Select step, select the “Commanders Act – Data Saver 1.0” tag and add it to your container:
2)-Configure your tag in the “Edit” step:
#STORAGE_KEY# corresponds to the reconciliation key to match data collected through the web container and that collected on the server-side (ex: user ID, basket ID…)
#DATA_KEYN# corresponds to the names of the variables that will collect and store information on the Website (ex: “order_id”, “cookie_vendor”…)
#DATA_VALUEN# corresponds to the variables’ value, e. information that was collected (ex: tc_vars[“order_id”]; a cookie’s value retrieved with and internal variable, etc…). In the following example, we wish to obtain the Order ID and the value of a cookie that was dropped by a partner solution. The reconciliation key that will allow to link Web data to that of the server side is the User ID. This is how you need to configure your tag:
#STORAGE_KEY# = tc_vars[“user_id”] (data layer variable)
#DATA_KEYN# = “order_id” or “cookie_vendor1” (needs to be typed because it is the variable’s name)
#DATA_VALUEN# = tc_vars[“order_id”] or the partner solution’s cookie’s name, collected with the tC.internalvars.get_cookie_vendor1
Note: The name of the partner solution’s cookie can be retrieved prior to this configuration (Options > Internal Variables):
Information collected by the tag will be stored on Commanders Act’s servers for 24h hours with this structure:
3) – Add, if need be, firing rules in the Rules step, then generate and deploy your web container.
The second step consists in declaring variables retrieved with the “Commanders Act – Data Saver 1.0” tag in the “Server-side external variables” section. You will thus be able to map them with your server-side tags and send your partners values collected with your Web container.
1)- Go to the “Options” > “Server-side” > “External Variables” and click “Add variable” to add your data storage variables.
“Name” and “Parameter label” correspond to the name of the variable present in the #DATA_KEYN# field in the “Commanders Act – Data Saver 1.0 ” tag.
Remember to check the “data storage” box to specify that the variable retrieved from the Web database:
You will find the variable among those in the external variables list:
2)- Lastly, make sure that the variable serving as reconciliation key is indeed present amid your server-side variables. The “Reconciliation key” box must be checked:
The third step consists in mapping variables from the data storage within the server-side tag in the edit step, just as you would map a server-side variable. These variables’ names will be preceded by the “External Variables (data storage)” specification :
The fourth step (optional) consists in creating rules in terms of data saver variables. To do this, go to the Rules section. Two rule types can be defined based on data saver variables:
“If variable equals (based on saved Data)”: A tag executes if the “data storage” variable equals the specified valyue.
“If variable is not equal (based on saved Data)”: A tag executes if the “data storage” variable is different from the specified value.
When you are finished configuring the aforementioned elements, you can generate, test and deploying your server-side container.
Phoenix reduce the impact of Safari ITP on your cookies.
The Intelligent Tracking Protection (ITP) feature of Safari browsers reduces the duration of most 1st party cookies to one day. ITP was initially implemented to reduce the effectiveness of cross domain visitor tracking—unfortunately it also has a strong impact on the user experience of website users. 1st party cookies are often used to store user settings of important features of a website.
e.g. cookie banner use 1st party cookies to store consent settings of a website visitor. On Safari these cookies might only last for one day. Thus cookie banner show up on almost any consecutive website visit, asking the visitor for his privacy settings again and again.
Phoenix enables you to persist 1st party cookies for longer durations to reduce the impact of ITP on your website and business.
To understand how Phoenix works it is important to understand following cookie concepts.
Phoenix allows to persist 1st party cookies without a Secure and HttpOnly flag.
After Phoenix is set up on a website domain it will backup selected 1st party cookies that are affected by ITP by storing them in Secure Http cookies that are not affected by ITP.
Phoenix will check if a 1st party cookie was deleted and recreate it from its backup on further website visits. Therefore the 1st party cookie is not anymore affected by ITP.
Phoenix setup consists of following steps. A Commanders Act consultant will support you during setup.
Phoenix has to run on your website domain to be able to create Secure Http cookies. Therefore you will need to assign a subdomain of your domain (e.g. phoenix.mydomain.com) to Phoenix.
In case you want to activate Phoenix for multiple domains (e.g. two domains, one .com for an English site and .fr for a French site.) you need to create one subdomain per domain.
Your administrator can configure your Phoenix subdomains in your Commanders Act interface under Admin > Domain Management.
Browsers, like Safari, can usually store a maximum of 8 kB of cookie data per domain. Web servers also have a cookie data limit, often matching the 8 kB of browsers.
Your administrator can configure how much cookie space he wants to make available for Phoenix in your Commanders Act interface under Admin > Domain Management. It is recommended to not exceed 2 kB, and we suggest a limit below 0.5 kB during initial setup.
Exceeding cookie storage limit can make your website inaccessible. Please consult with your technical teams during setup to define an optimal storage quota for Phoenix.
You will then need to connect your Phoenix subdomains with the Phoenix service. Your domain administrator needs to therefore configure CNAME entries that point your Phoenix subdomains (e.g. phoenix.mydomain.com) to the Phoenix service domain (e.g. sitexxx.commander5.com).
Your administrator can find the Phoenix service domain in your Commanders Act interface under Admin > Domain Management.
You have to re-generate your TagCommander containers after enabling Phoenix.
Commanders Act cookies are automatically managed by Phoenix. Cookies of other vendors have to be configured manually.
In TagCommander cookies are usually set by your vendor tags. You can enable Phoenix for selected tags in the "Deployment" step of your TagCommander container by enabling the ITP BYPASS option. This will automatically persist all cookies of this tag with Phoenix. A progress bar will show the remaining cookie space made available by your administrator.
Please contact the Commanders Act support or your Commanders Act consultant in case the ITP BYPASS option is not available for a tag or cookie you would like to persist.
Please contact your Commanders Act consultant in case you would like to persist cookies outside of TagCommander or in case you would like to install Phoenix without TagCommander.
Through serverside v2
This documentation is out of date ! Please refer to our latest documentation instead
This connector allows you to push every kind of events directly to Facebook through API. Online conversions, offline conversions... send it to Facebook and it will help you to increase the reach and accuracy of your campaigns.
Currently this destination is open only through our consultings services, please contact our support team or sales.
This connector is compatible with different sources, here is the documentation for each:
(web tag, offline conversions, ...)
This documentation is out of date ! Please refer to our latest documentation instead
This connector allows you to push every kind of events directly to Facebook through API. Online conversions, add to cart... send it to Facebook and it will help you to increase the reach and accuracy of your campaigns.
You can, for example, not send campaigns related to a specific product to users who already bought it, or you can also send campaigns to users who bought a specific product in cross-sell logic.
Facebook developed an API called 'Facebook Conversions API'
You need a Facebook Business Manager account
Then on the menu, click on 'Events Manager':
Here, you have to create a new Web Pixel:
Select Conversions API and give a name to your connection:
Now your pixel is created and you will have access to the IDs needed on our connector (send it to our consultants).
Our consultants need to fill the pixel ID on our connector, it is the ID of the pixel you just created on steps above.
You can find this ID when you click on the pixel's name and on the right of the graph activities. You can find it also on the settings tab.
Please send this Pixel ID to our consultants (+ access token).
Then you need the Access Token
Click on the settings tab.
Scroll until the section 'Conversions API'
Click on the button 'Create Access Token':
If you are not able to click on the button 'Create access token', that mean you don't have enough rights to do it. You should be administrator on your Facebook Business account to create it.
Please send this access token to our consultants (+ pixel ID).
Only events with a consent will be sent to Facebook
Only conversions with personal information (email and/or phone number...) will be sent to Facebook
On the connector, the consent is managed with the field 'User Consent Category'. You should enter a category ID, the one corresponding to Facebook (advertising) on Trust consent categories.
We should distinguish 3 cases:
Your online events are collected through our Commanders Act event's tag: You have to provide, in the event tags, the list of category ids consented by the user, through the consent_categories property.
You are pushing your events to us through API or CSV file: a field consent_categories must be added on the JSON or CSV to precise the consent category IDs of the user. Then inside the connector setting, use the field 'User Consent Category' to enter a category ID, the one corresponding to Facebook (advertising)
You already manage consents on your side and you only send us, from your server,
events that obtained the consent for the category advertising. In this case, do not fill the field ‘User Consent Category’ in the connector.
Using both the pixel and server is recommended per Facebook as it could avoid losing data.
To make it works, you should have the same configuration for both the pixel and server, using same Facebook parameters.
event_id should be the same
On the pixel, event_id is automatically generated by our Commanders Act Tag and we retrieve the same value for the server on_integrations.facebook.event_id_. As a result, these 2 values should be the same.
Event_name should be the same also.
Fbp parameter is automatically retrieved to keep the same value between pixel and server.
Deduplication works when the same event is sent first from the browser and then from the server, otherwise it creates a duplicate. Events are pushed in real-time.
On pixel:
eventID: tc.uniqueEventId is automatically generated.
On server:
integrations.facebook.event_id automatically retrieves the eventID value coming from the pixel (eventID: tc.uniqueEventId) for standard events.
To send any of your Commanders Act events (that are not listed in the table above) to Facebook custom events, you don't have anything to do. By default, your unmapped events are automatically sent as a Facebook custom events with the name of your Commanders Act events.
If you want to change the name of the custom event that will receive Facebook, you can overwrite the event_name property using integrations.facebook.event_name:'yourCustomEventName'
Every property can be overridden using integrations.facebook.user_data.<property> (for standard data) or integrations.facebook.custom_data.<property> (for custom data).
Events can only be used if there is enough information to match a user. Facebook expects at least one user_data property, but strongly advises sending as many properties as possible.
Here are our conditions to send the events :
at least 1 of those fields: em, ph, external_id, fbp, fbc
at least 3 of the other fields
Note : external_id, fbp, fbc will allow matching event with other events. But to match a user, one of those events shall contain additional information (em and ph are best suited for matching)
Custom Facebook parameters could be added.
Facebook allows you to send any data you want in custom data parameters. By default, we fill generic fields when possible (like value, currency, contents...). You can specify in the tag your own parameters in integrations.facebook.custom_data.
The server-side monitoring interface lets you visualize “incoming hits” to Commanders Act servers (calls issued from your servers to Commanders Act’s) and “outgoing hits” (calls issued by Commanders Act’s servers to your partner solutions’).
Please note the following elements before using the server-side hit monitoring interface :
If you have already subscribed to our server-side tracking service and wish to make use of the monitoring interface, you need to regenerate and deploy the server-side containers you wish to monitor hits for. Information collection will start as soon as the containers are deployed.
Data is stored one day only (24 hours) and updated in real time.
Please do the following to access the reports:
1) – Click the TagCommander icon
2) – Click “Reports”
3) – Select “Server-side Monitoring”
4) – Select the container whose tags you wish to monitor hits for (in case you have more than one container).
5) – Select the type of hits you wish to monitor from the dropdown menu:
*Incoming hits: input hits or hits sent from the client’s server to Commanders Act’s.
*Outgoing hits: output hits or hits sent from Commanders Act’s servers to the client’s.
Default settings will display outgoing hits for all your partners (“all tags”), but you can display a specific partner’s tags by selecting their name from the list.
6) – Click this tab to see hits hourly or every 15 minutes.
7) – The table under the graph contains four default columns for incoming hits and three for outgoing hits. They correspond to server-side hits’ default parameters:
ID: Id of the server-side hit (it is generated automatically by Commanders Act’s servers).
Timestamp: Time and date of the server-side hit (it is generated automatically by Commanders Act’s servers).
User agent: server’s user agent (it is generated automatically by TagCommander’s servers).
Method: It is the method used to send hits to Commanders Act’s servers, meaning “POST”, “GET”, and/or “GET and POST” methods, (the latter is displayed for incoming hits only).
8) – The remaining columns correspond to custom parameters sent in the incoming or outgoing server-side hits. It is data sent by your servers to Commanders Act or by the latter to your partners’ servers.
Example – An incoming hit has the following structure: http://serverside$siteID$.commandersact.com/$containerID$/?order_id=value&order_amount=value
The default columns (ID, Timestamp, User Agent, IP) will be displayed, as well as two additional columns: one labeled “order_id” (corresponding to the order information included in the hit) and another one labeled “order_amount” (order amounts sent through the hits).
9) – Click this icon to display a dropdown menu that will allow you hide or display columns from the table.
10) – You can search for information contained in the hits with this search engine.
11) – Click this icon to export data contained in the table as a .CSV file. You will receive the report by email.
Container strategies for common setups.
A Container Strategy is the layout of the TagCommander Container of a site. Following you will find recommended Container Strategies for common types of websites and businesses.
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 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. For AMP versions of the website it is possible to implement a Server-Side TagCommander.
In case A/B-testing and personalization Tags are used, the additional implementation of a <head> Container is recommended.
Bridge your events in a seamless way.
This documentation is out of date ! Please refer to our latest documentation instead
Commanders Act provides a GTM template to connect your existing GTM implementation to our serverside endpoint, enabling "Facebook CAPI" in a secured environment.
Summarizing all recommended steps:
Add our template
Configure your tag
Update your Facebook tags
First, access and then add our template "Commanders Act | Serverside events bridge" from the Google "" 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.
Start by filling (6) a name for your tag in the upper left corner.
Hint: you may want to name your tag adding the event name you're going to implement in the end. (E.g. "Commanders Act | Serverside events bridge - Purchase")
Input your (7) "Commanders Act Site ID" and select (8) 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.
In the "User Fields" section you can set (11) the "User Id" and (12) "User Email" - Either one of them is required if you select the "Purchase" event. The (13) "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.
Ensure your category relationships are shared with Commanders Act.
Only with the agreed consent settings, we're allowed to bridge both the "Purchase" and "Refund" events to the "Facebook CAPI".
Complete your configuration by selecting the proper activation in the "Triggering" area / "Firing Triggers".
If you're planning to keep running your existing Facebook pixels while using "Facebook CAPI" through GTM, it's really important that you update them following these guidelines. This will allow to deduplicate and keep consistent measurements of your events.
The process is straightforward as for every event you're sending via pixel tags you just need to add the event identifier - On GTM, open your "Facebook Pixel" tag and expand (14) "More Settings" to locate the "Event ID" and click (15) its icon on the right.
A new window will slide-in. Click on (16) the plus on the top right.
Click on (17) the "Variable Configuration".
Click (18) the "JavaScript Variable".
Rename your (19) variable as window.tC.uniqueEventId and set the same name in (20) the "Global Variable Name" then click (21) the "Save" button.
Back on the tag configuration, expand (22) "Advanced Settings" and (23) "Tag Sequencing" to check (24) the option "Fire a tag before Facebook Pixel fires". In "Set-up Tag", select (25) "Commanders Act | Serverside events bridge" and save your tag.
Repeat this configuration for each active "Facebook Pixel" in GTM.
Some answers from your questions
When you write a console.log within a tag to check if a tag is correctly triggered of to check a value, for example like this :
when a new container version is generated, it re-writes the console.log as tC.log
To be able to read these tC.log you need to add this cookie within you browser :
TRUST Commander is our Consent Management Platform. (More information: )
The following mappings are fully automated and do not require any additional configuration. Any of the Commanders Act Standard Events in the table below will be sent as the corresponding Facebook Standard Event. The Facebook pixel has more information on these.
Official documentation
Events including the "Product Fields" section require . The first field will always be the (9) base array where the information is stored and all subsequent fields are the related properties - E.g. you can map the information about (10) the "Product Id" by filling the property name.
See Facebook documentation for more details:
Contact your reference consultant or our in case you need assistance.
Reconciliation Key (user_id)
order_id
cookie_vendor1
123456
1234FR
A
567489
34565FR
A
346658
56456FR
B
…
…
…
begin_checkout
InitiateCheckout
purchase
Purchase
add_to_cart
AddToCart
view_item
ViewContent
view_item_list
ViewContent
search
Search
add_payment_info
AddPaymentInfo
add_to_wishlist
AddToWishlist
generate_lead
Lead
page_view
PageView
complete_registration
CompleteRegistration
contact
Contact
customize_product
CustomizeProduct
donate
Donate
find_location
FindLocation
schedule
Schedule
search
Search
start_trial
StartTrial
submit_application
SubmitApplication
subscribe
Subscribe
user.id (hashed)
user_data.external_id
user.email
user_data.em (email, hashed)
user.phone
user_data.ph (phone, hashed)
user.gender
user_data.ge (gender, hashed)
user.birthdate
user_data.db (birthdate, hashed)
user.lastname
user_data.ln (last name, hashed)
user.firstname
user_data.fn (first name, hashed)
user.city
user_data.ct (city, hashed)
user.state
user_data.st (state, hashed)
user.zipcode
user_data.zp (zip code, hashed)
user.country
user_data.country (hashed)
browser.ip
Automatically set if generated from Commanders Act OneTag
user_data.client_ip_address
browser.user_agent
Automatically set if generated from Commanders Act OneTag
user_data.client_user_agent
integrations.facebook.fbc
Automatically set if generated from Commanders Act OneTag
user_data.fbc (Click ID)
integrations.facebook.fbp
Automatically set if generated from Commanders Act OneTag
user_data.fbp (Browser ID)
amount
custom_data.value
currency
custom_data.currency
items
custom_data.contents
name
OR first items[i].product.name found
custom_data.content_name
category
OR first items[i].product.category_N found (N ∈ [1, 5])
custom_data.content_category
default value : 'product'
custom_data.content_type
status
custom_data.status
Container
Type
Placement
Tags
Head Container
<head>
All pages
A/B-testing and personalization
Body Container
<body>
All pages or catalog pages
Analytics and tracking
Funnel Container
<body>
Funnel pages
Conversion
Container
Type
Placement
Tags
Body Container
<body>
All pages or catalog pages
Analytics and tracking
Strategies to improve the onsite performance of TagCommander.
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.
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).
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.
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.
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.
A hybrid setup allows to move onsite performance impact into the Server-Side TagCommander infrastructure.
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.
Tags in asynchronous <body> Container that use synchronous document.write (e.g. some advertising solutions) will break the website in case the Container is loaded asynchronously. These Tags need to be avoided in case a Container is installed asynchronously.
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.
This needs to be tested with each individual Tag as some might not be compatible with this approach.
Data Layer strategies for common setups.
Following you will find common TagCommander Trigger setups.
In most cases page view events are covered by the inbuilt Container loaded and DOM ready Trigger within TagCommander. 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.
tc_vars Data LayerThe Data Layer should be updated with the new metadata of the subsequent virtual page view.
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.
3. Execute Triggers
After these steps it is then necessary to signal a custom Trigger to execute the related Tags.
Steps 2. and 3. are often used in conjunction therefore it is possible to combine them in one call. e.g. tC.container.reload({ events: { pageview: [{}, {}] } });
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.
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.
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.
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.
TagCommander users can setup common click Triggers with minimal effort via the TagCommander interface by selecting them with a CSS selector path.
This Trigger works in many scenarios but has two downsides:
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.
TagCommander can only identify elements that are loaded synchronously on the website. Elements that are loaded asynchronously cannot be watched by the predefined TagCommander Trigger.
Good scenarios for setting up TagCommander Triggers with the Interface are:
Onsite campaign that has to be measured for a short time period (couple of weeks)
General click tracking until the web development team can implement a 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:
Inside of TagCommander it is then possible to catch clicks on these elements to execute a custom Trigger. With jQuery this might look like this:
This approach results in a nice separation of concerns between website code and TagCommander. The website is responsible to provide tracking data and mark which elements should be trackable. TagCommander is responsible in bootstrapping the click tracking code and executing the related Tags.
Coming soon...
Returns the tags list
GET api.commander1.com/api/1.0/manage/container/tags/list?id_site=X&access_token=Y&id_container=Z
URL PARAMETER
TYPE
MANDATORY
DESCRIPTION
id_site
Integer
Yes
Client site identifier
access_token
Alphanum
Yes
Caller’s security identifier
id_container
Integer
No
Container identifier
HTTP CODE
MESSAGE
DESCRIPTION
200
OK
The request went through, the result is in the answer’s body
400
Bad Request
The parameters are not ok or mandatory parameters are missing
401
Unauthorized
The security token does not match the site_id or the container_id
404
Not Found
A container identifier for the site_id parameter was not found
500
Internal Server Error
Internal server error
The response is in JSON format.
FIELD
TYPE
ALWAYS PRESENT ?
DESCRIPTION
idSite
Integer
Yes
Site identifier
containers
Array
Yes
Array containing the container list and their label
containers/id
Integer
Yes
Container identifier
containers/label
String
Yes
Container label
containers/is_active
Boolean
Yes
Container status (active=true, deleted=false)
tags
Array
Yes
Array containing the tag list and container label
tags/id
Integer
No
Tag identifier
tags/label
String
No
Tag label
GET
Data Layer properties for common setups.
Following you will find a collection of important Data Layer properties. These should be seen as a framework that can be adjusted to the needs of each individual site.
Base Data Layer Properties are recommended for all TagCommander implementations. They are the minimum amount of properties to allow a straightforward handling of common Tags.
Property
Description
Example
env_template
Page type identifier—most important property that allow users to play out Tags only on relevant pages.
"homepage", "product_detail", "funnel_confirmation"
env_work
Environment identifier
"prod", "stage", "dev"
env_country
Site country code (ISO_3166-1_alpha-2)
"DE", "EN", "FR"
env_language
Site language code (ISO 639-1)
"DE", "EN", "FR"
page_name
Name of the page.
"Our new phone!"
page_cat1_name
Page top category name
"smartphones"
page_cat2_name
Page category name
"apple"
page_cat3_name
Page sub category name
"iphones"
page_cat1_id
Page top category id
"1234"
page_cat2_id
Page category id
"2345"
page_cat3_id
Page sub category id
"3456"
page_search_keywords
Search keywords on search or product finder pages
"new iphone"
page_search_filters
Array of search filters on search or product finder pages
["price", "rating"]
User ids and properties are important for advertising and personalisation services.
Property
Description
Example
user_id
User ID
"12345"
user_email_hash
Hashed user email
"kGghdg62173fh1123ff667128g"
user_newcustomer
New customer flag
true for new customer, false for known customer
It is recommended to extend the base Data Layer properties with following variables for ecommerce sites. These enable users to successfully track product and order information:
Property
Description
Example
env_currency
Currency code (ISO code 4217)
"EUR"
product_array
An array of product objects that holds products information of currently viewed products on a page—product list pages usually hold several products (e.g. top 5 products of the page), product detail pages only one product
Described in section Data Layer Product Array
basket_id
Unique basket ID
"B12345"
basket_products
An array of product objects that holds product information of current products in the basket
Described in section Data Layer Product Array
order_id
Unique order ID
"O12345"
order_amount
Total value of the order, without tax and without shipping fee
123.45
order_amount_ati
Total value of the order, all tax included and without shipping fee
234.56
order_amount_ati_with_sf
Total value of the order, all tax included and with shipping fee.
345.67
order_discount
Total discount of the order without tax
12.34
order_discount_ati
Total discount of the order with tax
23.45
order_discount_code
Order discount or voucher code
"AB16887CDV883"
order_products
An array of product objects that holds product information of all ordered products on the product confirmation page
Described in section Data Layer Product Array
TagCommander recommends to structure lists of products (product_array, basket_products and order_products) via an array of JavaScript product objects:
Following you will find a list of recommended properties of each product entry:
Property
Description
Example
product_id
Product ID—usually internal ID
"12345"
product_id_variation
Product ID variation—usually SKU
"2345"
product_name
Product name
"My product"
product_name_variation
Product name variation
"My other product name"
product_unitprice
Product unit price without tax
12.34
product_unitprice_ati
Product unit price with tax
23.45
product_discount
Discount amount without tax
1.23
product_discount_ati
Discount amount with tax
2.34
product_cat1_name
Product top category name
"smartphones"
product_cat2_name
Product category name
"apple"
product_cat3_name
Product sub category name
"iphone"
product_cat1_id
Product top category id
"1234"
product_cat2_id
Product category id
"2345"
product_cat3_id
Product sub category id
"3456"
product_qty
Product quantity
5
Coming soon ...
“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.”
tC. Function
Behavior
tC._R
Internal object used for statistics
tC.ams
Internal object used for the Measure product
tC.array_launched_tags
Displays a list of tags within the container version that is published. If you use one of our testing tools (Bookmarklet or TagAssistant Chrome extension) and simulate the presence of a different container version, the function will display the tags within the container version that is being tested
tC.array_launched_tags_keys
Displays a list of tag identifiers corresponding to the tags within the container version that is published or being tested
tC.call
Internal function used for callbacks
tC.containerVersion
Displays the version number of the container that is published or being tested
tC.containersLaunched
Displays a JavaScript object containing other objects. The latter correspond to the containers launched on a given page and provide information about them and the tags within (id, name)
tC.dedup
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays a JavaScript object containing all defined channels and sources and showing whether they are active or not
tC.dedup_done
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays whether the deduplication module is on or off on a given site
tC.dedup.cj
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last 10 touchpoints in a user’s customer journey. They are collected with customer journey (CJ) cookies. You can adjust the number of touchpoints in the interface. To do so, please go to the Options > Channel and sources definition tab
tC.dedup.LeA
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last recognized channel in the customer journey
tC.dedup.LeAD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the last recognized channel in the customer journey cookie
tC.dedup.LeC
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last recognized channel – related to clicks – in the customer journey cookie
tC.dedup.LeCD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the last recognized channel – associated to clicks – in the customer journey cookie
tC.dedup.LeV
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last recognized channel – related to views – in the customer journey cookie
tC.dedup.LeVD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the last recognized channel – related to views – in the customer journey cookie
tC.dedup.FeC
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the first recognized channel – related to clicks – in the customer journey
tC.dedup.FeCD
DEDUPLICATION HAS TO BE ACTIVE FOR THIS FUNCTION TO WORK
Displays the source associated to the first recognized channel – related to clicks – in the customer journey cookie
tC.dedup.FeV
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the first recognized channel – related to views – in the customer journey cookie
tC.dedup.FeVD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the first recognized channel –related to views – in the customer journey cookie
tC.dedup.AeA
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays channels recognized halfway through the customer journey
tC.dedup.AeC
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays channels recognized halfway through the customer journey (for clicks)
tC.dedup.AeV
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays channels recognized halfway through the customer journey (for views)
tC.domReady
Displays whether all the content from the Document Object Model (DOM) has finished loading or not (i.e. the containers)
tC.domain
Returns the page’s domain (.tagcommander.com for instance)
tC.each
Internal iterator
tC.generatorVersion
Displays the container generation engine’s version
tC.getCookie
Displays the value of a given cookie. You need to write the function and the cookie’s name next to it between parentheses and quotes: tC.getCookie(“cookie’s name”).
tC.getParamURL
Displays a given parameter from the page’s URL
tC.hitCounter
Internal function used to obtain statistics related to invoicing hits
tC.id_container
Displays the container ID
tC.id_site
Displays the TagCommander site ID
tC.inArray
Internal function to check if an element is placed inside an array
tC.inclusion_oct_1
Specific to each container (JS inclusion)
tC.internalFunctions
Namespace for TagCommander’s internal functions
tC.internalvars
Namespace for TagCommander’s internal variables
tC.isArray
Method to verify whether a variable is placed inside an array
tC.isCurrentVersion
Confirms whether the currently deployed version in the interface is the current version on the site
tC.isDOMReady
Confirms if the Document Object Model (DOM) is ready
tC.isFunction
Method to verify whether the type of a variable is a function
tC.isNumeric
Method to verify whether a variable’s value is a number
tC.isPrototypeOf
Method to verify whether a variable is prototype
tC.isWindow
Method to verify whether a variable is window
tC.launchTag
Internal method used for TagCommander’s Google Chrome extension
tC.length
Internal variable
tC.log
Method replacing the console.log() command
tC.maindomain
Displays the main domain containers are deployed on
tC.name
Displays a “c” for container
tC.nodeNames
Displays the list of the Document Object Model’s (DOM) elements
tC.onDomReady
Method to execute code on the Dom Ready event
tC.pixelTrack
Internal Method injecting pixels
tC.privacy
Namespace for variables related to the Privacy module
tC.privacyVersion
Displays the version number of the Privacy banner and settings that are published
tC.rchecked
Internal Variable storing a regexp
tC.removeCookie
This function lets you remove a cookie. You need to write the function and the cookie’s name next to it between parentheses and quotes: tC.removeCookie(“cookie’s name”)
tC.script
Returns a JavaScript object that you can “unfold” to find the location of the container (link to the script)
tC.setCookie
This function lets you create a cookie. Here is the function interface: tC.setCookie(name, value, lifetime, path, domain, secure, sameSite). Ex: tC.setCookie(“My_cookie”, “1”, 365,”/”,”.mysite.com”, true, "Lax")
tC.ssl
Displays the SSL certificate: indicates whether the page’s protocol is https or http
tC.tagPatterns
Internal variable containing the regex (patterns) to detect tags’ hits for the TagPerformance module
tC.tagPerf
Internal variable for the TagPerformance module
tC.tagPerfAnalyzer
Internal function that analyzes a page to calculate tags’ response time (for the TagPerformance module)
tC.tagPerfE
Yet unused variable that controls sampling rates of TagPerformance’s calls
tC.script.add(location.protocol + “//manager.tagcommander.com/utils/IP/”);
This function allows you to recover the IP address
You can download it in your account section (bottom left menu):
And then in the "advanced" section:
The Bookmarklet is a widget that allows you to:
*Test container versions on your sites before deploying them by simulating their presence on the sites.
*Verify tags are being called.
*Verify the variables from the data layer and the values that populate them.
*List the cookies present on the site.
*To See the Customer Journey.
*Implement events.
Click Events (1) and then Implement (2)
Select the element/event you wish to set up (3) [It will be highlighted in pink]
Fill in the form with the required information.
To install the Bookmarklet, follow these steps:
1) Click the Admin tab.
2) Drag and drop the button to your favorites’ bar.
3) Go to the site you wish to use the Bookmarklet on.
4) Click the corresponding bookmark and log in (with the same credentials you log in with to the commanders act interface).
Note: the extension is compatible with all browsers (most up to date versions).
You can now see all users that are connected to your TagCommander account pages when you are.
A tab in the bottom, right-hand corner of the screen indicates the number of connected users. By clicking their name, you can see which areas of the interface they are looking at.
This feature will prevent you from making changes on your containers when other users are doing the same.
TagCommander's Chrome Extension is available at the Google Chrome web store.
Shortcut to the Chrome extension :
It allows you to:
Test container versions on your sites before deploying them by simulating their presence on the sites.
Verify tags are being called.
Verify the variables from the data layer and the values that populate them.
List the cookies present on the site.
To see sent hits and their loading time.
To install it, follow these steps:
Click "add to Chrome"
Go to the site you wish to launch it on
Click the pink Rocket ship Icon in the extensions bar.
The “Copy Management” user interface is available to administrators only, from the “Admin” menu:
It allows duplicating sites, containers, variables, deduplication settings and tags.
Note: only the site copy feature is available at present; container, variables, deduplication settings and tag copy features are currently under development.
Follow these steps to copy an existing site and its contents:
1/ “Element to copy”: select “Site” from the drop down menu to duplicate a site.
2/ “Site to copy”: select the site you wish to duplicate.
3/ “Add several new sites based on the site to copy”: If you wish to copy the content of a given site to another one and only, select “No”. If you wish to copy that site’s content to more than one site, select “Yes”.
4/ “Site name”: enter the name(s) of your new site(s). The “+” and “–“icons allow adding or deleting sites.
5/ “Grant same rights to the same user(s) on the new site(s)”: If you wish to duplicate user access from one site to another click “Yes”, otherwise click “No” (should you click “No”, no one else but you will have access to the duplicated site).
6/Click the “COPY” button to validate your settings.
What elements are duplicated with the “Site Copy” feature?
The “Site Copy” feature duplicates the following elements and creates one or more new sites with the exact same settings as the source site:
TagCommander product:
Containers
Tags
Events
“Static JavaScript Code” and “Dynamic JavaScript code” files
Rules
Data layer (external, internal and event variables)
Deduplication settings
Privacy settings (if the module is activated)
MixCommander product:
Attribution models
Segments
Excluded IPs
Channel identification
Dimensions (conversion/traffic)
Currencies
Costs
DataCommander product:
Segments
Streams
Cross-product options: connectors
The “Site Copy” feature does not duplicate these items:
TagCommander product:
Generated container versions
MixCommmander product:
Custom reports
Raw data
DataCommander product:
Raw data
Note: only administrators and technical users can copy sites
Follow these steps to copy an existing container and its contents:
1) – Click the “Admin” tab
2) – Click the “Copy Management” tab
3) – Select “Container” from the dropdown menu
4) – Select the site the container you want to duplicate belongs to
5) – Select the container to copy
6) – Select the site to host the duplicated container (among the sites you manage)
7) – Choose whether you want to create a new container or replace an existing container with the duplicate
8) – Name the copy
9) – Click “Copy”
Note: only administrators and technical users can copy tags
The copy tag functionality is also available on the deploy step of containers for admin users (can be added to custom profiles with Profile Management).
Follow these steps to copy tags from a given container:
1) – Click the “Admin” tab
2) – Click the “Copy Management” tab
3) – Select “Tag” from the dropdown menu
4) -Select the site containing the tags you wish to copy
5) – Select the container the tags are in
6) – Select the tag(s) to copy
7) – Select the destination site
8) – Select the destination container
9) – Click the “+” button to add more destination sites and containers
10) – Click copy
Note: only administrators and technical users can copy variables
Follow these steps to copy existing variables:
1) – Click the “Admin” tab
2) – Click the “Copy Management” tab
3) – Select “Variables” from the dropdown menu
4) – Sélectionnez le site qui contient les variables que vous souhaitez copier
5) – Sélectionnez les variables à copier
6) – Vous verrez affiché le nombre de variables qui ont été sélectionnées
7) – Ajoutez le site dans le menu déroulant
8) – Ajoutez plus de sites de destination pour les variables sélectionnées si besoin est
9) – Click “copy”
Follow these steps to copy tag librairies:
1) – Click the “Admin” tab
2) – Click the “Copy Management” tab
3) – Select “Tags Library” from the dropdown menu
4) – Choose the site containing the tag whitelist to copy
5) – Select one or more destination sites
6) – Click “Copy”
Note: only administrators and technical users can copy deduplication settings
Follow these steps to copy existing deduplication rules:
1) – Click the “Admin” tab
2) – Click the “Copy Management” tab
3) – Select “Deduplication Configuration” from the dropdown menu
4) – Choose the site containing the deduplication configuration to copy
5) – Select on or more destination sites
6) – Click “Copy”
Follow these steps to copy rules from one container to another (or within the same container):
1) Click the “Admin” tab
2) Click the “Copy Management” tab
3) Select “Rules” from the dropdown menu displaying all the possible elements to copy:
4) Select the site and the container you wish to copy rules from:
5) Select the rules you wish to duplicate from the “perimeter” or “constraint” sections:
6) Select the target site and container from the dropdown menu:
7) Click copy
Go here
Note: only administrators and technical users can copy tag librairies (to learn more about the libraries’ customization options, please click )
