Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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).
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):
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).
A window will appear displaying the test error details. Below is an example of a possible tag error:
(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.
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:
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:
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.
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):
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.
(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:
“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.
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 (click here to learn more). 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″}).
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.
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”.
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.
(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):
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:
“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.
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: