Container
Last updated
Last updated
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:
