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

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

Hosting types

We offer two ways for your container's hosting:

• Via our CDN (Content Delivery Network): provides you a total autonomous deployment. Our CDN is having a 99.9% of SLA It's compatible with First Party hosting, please read this page for further info!

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

FTP connector configuration

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

CDN connector configuration

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

URL connector configuration

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

Amazon S3 connector configuration

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

Google Cloud Storage connector configuration

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

//example for the private key:

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

Bing Ads connector configuration

Simply follow the step by step guide provided by Bing:

Facebook Ads connector configuration

Simply follow the step by step guide provided by Facebook:

Criteo connector configuration

Simply follow the step by step guide provided by Criteo:

Google Ads connector configuration

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

Snapchat connector configuration

Simply follow the step by step guide provided by Snapchat:

Adobe Analytics connector configuration

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

Equativ connector configuration

Simply follow the step by step guide provided by Equativ:

Test & Debug

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

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

A configuration window will appear with 3 main tabs:

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

• “Synchronization“: to manage container updating options

• “Advanced“: to manage advanced container options

After configuring the various container options, click “Add”

General

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

Synchronization

Mode: Synchronization modes for the container:

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

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

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

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

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

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

Recurring synchronization:

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

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

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

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

Advanced

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A total of 8 browsers/OS are tested:

• The latest version of Edge

• The latest version of Chrome

• The latest version of Firefox

• The latest version of Opera

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

• The latest version of Safari (for tablets)

• The latest version of Android (for tablets)

Tests are performed on five levels:

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

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

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

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

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

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

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

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

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

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

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

Error message details returned by the tested browser

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

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

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

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

Before deploying a container version, you can:

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

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

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

Additional information:

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

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

• Tags: Tags’ weight

• Events: Events’ weight

• Rules: Rules’ weight

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

• Internal variables: Internal variables’ weight

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

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

• Choose the version to deploy.

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

• Choose the deployment method.

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

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

Additional information

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

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

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

A confirmation message will appear

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

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.

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.

You can also display each container’s call statistics. 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.

All modifications done on the containers in the last 36 months are recorded on the Modification History page You can access to this menu by the tab Administration => Modification History

Adding static JavaScript code

Commanders Act 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.

– 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):

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 and click “SAVE”.

Adding dynamic JavaScript files

Commanders Act 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 Commanders Act 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 Commanders Act, 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.

• 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):

  

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 and click “SAVE”.

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”):

Introducing the new "Branches" feature

Are you ready to take your TMS experience to the next level? We are thrilled to introduce our latest feature: Branches. This powerful tool is designed to elevate your team’s efficiency, allowing multiple users to work simultaneously on the same project without stepping on each other's toes. Imagine a workspace where you can confidently make changes, test them in isolation, and merge them seamlessly—all while keeping your Main project intact. Let’s dive into what makes this feature a game-changer.

What is "Branches"?

Branches allow you to create a separate, partitioned work environment—a safe space where your work is your own. You can make changes without worrying about interrupting your colleagues’ progress. When you're ready, simply merge your work back into the Main project with confidence, knowing that everything aligns perfectly.

Key Benefits

• Work independently: No more waiting for colleagues to finish their tasks. With Branches, everyone can contribute simultaneously without conflicts.

• Reduce errors: By isolating changes, you can avoid the dreaded “unfinished work” being deployed to production. Test and validate your changes in a secure environment before merging.

• Streamlined merging: Our intuitive interface makes merging a breeze. View changes side-by-side with our diff checker, ensuring nothing slips through the cracks.

❤️ Why you’ll love Branches ❤️

Say goodbye to workflow interruptions!

Previously, if two users worked on the same account, their changes would overlap, leading to potential conflicts during container generation. This often resulted in errors that stalled the deployment process, or worse—unfinished work going live. With Branches, you’ll experience a smoother, more controlled workflow. Your team can now focus on what they do best, without the hassle of managing conflicting changes.

A seamless User Experience

• Visual indicators: It’s easy to know where you are. When you’re working on the Main (your actual web container), all menu elements are cherry red. Switch to a Branch, and everything turns blue, signaling that you’re in a safe zone to make changes.

• Effortless Branch creation: Whether you’re starting a new project, creating a new Branch is just a click away. Our intuitive panel guides you through the process, from naming your Branch to diving straight into editing.

• Real-time notifications: Stay updated with any changes made into the Main while you’re working on a Branch. You’ll receive a prompt with options to update your Branch or continue working—keeping you in control at all times.

Glossary

• Main: your usual container, considered as "parent" in a Branch context

• Branch: a duplication of your Main to work without impacting your Main configuration

• Merge: action to bring the modifications from your Branch live in your Main container

How it works ?

Branch Creation

To open the Branch creation UI use the button in the breadcrumb menu (identified as "Main" when you are on your regular container, or by the Branch name if your are in Branch context). The list of your branches will appears. Click on "Create new branch". Just define a Branch name, you can also add a description if needed, You can create up to 5 Branches for each container!

On save, you will redirected in your new Branch environment

Once your Branch is created, all changes you make are isolated to this environment. The blue color of the navigation elements shows you are in a Branch.

You can edit or modify any of the elements as if you were in a normal container.

Branch Comparison with the Main

At any time you can have clear view of the work done on each Branch. Simply click on the link "See changes"

The "Comparison" pop in will appears:

You can unfold elements to get details

Existing Branch Edition

To access an existing Branch, click on "pen" icon. This pop in is also useful to go back to your Main container.

Edit/modify any elements as if you where in a regular container.

Branch Update

If your Branch is not up to date with the newest Main changes, you will see this warning message, inviting you to update your Branch

On click, the pop in "Update" will be displayed, a diff checker. You are allowed to keep or discard the changes. The checked items will be bring into your Branch. If you don't wish to update your Branch now, then click on cancel.

Branch QA & Test

You can generate your Branch as a regular container.

Once your Branch has been merged, you can do your Quality Assurance by 2 different ways: Deploy your Branch in your UAT environment, or use our Chrome Plugin "Commanders Act Tag Assistant"

Test on your UAT environment

When you’re ready, deploy your changes in your UAT environment, ensuring everything works flawlessly before merging.

There's a main difference for Branches containers at the deloy step: deployment on Production environment isn't allowed. That's why the deploy step has been renamed as "QA - Merge" in Branch context!

The UAT deployment option will push your Branch version on the UAT URL of the Main container.

It means that you can test your Branch directly on your UAT site without IT intervention.

Test with our plugin

Our Commanders Act Assistant is compatible with Branches!

Download it from Chrome Extension Store, once it is installed on your browser, you can use the button "preview" to test your Branch on your website.

For a detailed documentation about our plugin, pease read the following page

Merge Branch

Ready to bring your changes from Branch into the Main? Use our “Merge” feature, where you can review the differences, see a detailed comparison, and complete the merge effortlessly.

Take the time to update your Branch now with the latest Main changes!

After merge

Once you merged your Branch, the Branch will be deleted and you will be redirected to your Main

All modifications from Branches are now logged in your Main with [Branch*] prefix

At any time after merge, you can view all modifications logs from the merged Branch on your Main Modification History.

Custom User Rights

The native roles 'Administrator', 'Technical' and 'Marketing' are allowed to create, edit and merge branches.

If you want to manage these access rights more closely, you can use the dedicated rights in Profile Management, Custom Profile.

Looking ahead

Future-Proof Your Workflow

Although direct production deployment from a Branch is not available, our new QA plugin (currently under development), will offer you another way of testing your Branches, even in a production environment.

Introduction

We are excited to introduce the latest version of our browser plugin, Commanders Act Assistant (CAA)! Designed to streamline your testing and debugging processes, CAA is fully compatible with Google Chrome and Microsoft Edge, offering seamless integration into your workflow.

Download it now in the Chrome Store

*Availability in the Microsoft Edge Store is coming soon!

Key Features

Replace Web Containers easily

With CAA, you can effortlessly switch between Web Containers versions without a container deployment. You can test directly on your production website, allowing for quality assurance without disrupting your live environment. ❤️ It's also compatible with Branches feature! ❤️

How to replace your(s) Web Container(s)

You can test directly using the dedicated buttons visible on the steps "Generate," "Test," and "Deploy" within the Commanders Act platform, making it easier to validate your configurations.

On click, you will be invited to enter the expected landing page for your test session, then click 'OK' to be redirected to your site.

Stop Web Container(s) replacement

To turn off the override, simply click the button "stop override" on the plugin.

Monitor Tags in Action

Easily view the list of triggered tags as they fire on your website, giving you a clear overview of your tracking implementation in real time.

Keep a History Across Pages

CAA records events across multiple pages, ensuring you have a complete history of tag activations for a comprehensive debugging experience.

Limitations

While CAA is a powerful tool, here are some current limitations to keep in mind:

• 🌍 Consistent Web Container URLs: The WebContainer URLs must remain the same across all pages for the plugin to function correctly.

• ⚡ SPA Compatibility: On Single Page Applications (SPA), the list of triggered tags is only filled on the first hit collected by the plugin. On each page change, the tags are added to the list. *This will behavior will be improved in an upcoming update, so stay tuned!

Future Enhancements

CAA is continuously evolving, with new features and improvements planned to further enhance your testing experience. Keep an eye out for future updates that will make debugging and optimization even easier!

Coming soon

• Events tracking

• Web Datalayer tab

• Site and Web container(s) names visible