Check out the Sources catalog if you merely want to look at the Commanders Act sources and how each is implemented.

Sources vs Destinations

The platform has Sources and Destinations. Sources send data into the platform, while Destinations receive data from the platform.

Source key

The source key is a unique identifier for each Source. It allows Commanders Act to identify which Source is transmitting the data and which destinations should be the recipients of that data. It is also employed to deactivate a source when necessary.

To locate a source key, you initially need to have or create a source like a website, server, or mobile source.

Next, within the Source, navigate to “Settings", and then proceed to “source key".

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

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

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

Connect serverside destinations to a web container

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

To start sending data, there is only one easy step to follow : adding the Commanders Act One Tag.

The last tag that you will ever setup.

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

Recommandations for setup

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

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

Extensions

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

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:

What is a source ?

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

Source list

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

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

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

Trend and data quality

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

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

From the select step

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. Each block represents one tag: 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 or by searching for the tag name via the search box:

Click the blue “ADD TAG(S)” button 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:

“Search a tag“: Search box for finding a tag in the library by its name

“All vendors“: Filter for finding tags by solution name

Search by letter: Tags in the library are sorted in alphabetical order (by tag name)

Tag library: All the tags in the library (click the tag(s) you want to add to your container)

“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.

From the edit step

Go to the “EDITION” section. Follow the same steps then from the "SELECT" page

The blue ADD TAGS buttons will open the Commanders Act tag library.

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 (basic 'custom event' Commanders Act OneTag):

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.