Learn how to use the platform to collect, enrich, validate and integrate your customer data with hundreeds of solutions.

16/12/2022 - End of life of Platform version 7

Dear Customer,

As you know, we have created the new Platform X, which was launched in May 2022 to provide you with a range of new and improved features, including a higher-performance architecture, modern, fast and user-friendly interfaces, and enhanced functionalities to make your daily life easier.

In light of this, we will be closing the old platform (version 7) on June 30th 2023.

Here are the closing steps on the v7 in 2023:

• End date for adding new containers: April 30

• Maintenance end date: June 30

• Support end date: June 30

Many of you have already switched to the platform X and are already enjoying its benefits. If you have not yet had the chance to explore the new platform, we invite you to come and discover it for yourself. We would be happy to provide you with a presentation and show you all that it has to offer. We are very proud of our new platform and are delighted with the positive feedbacks we have received so far. This reinforces our choice to provide you this new unified platform, ready for the future !

Thank you for your continued support.

Sincerely, The Commanders Act Team

Our market and solution use many technical concepts, but our goal is also to democratize and explicate these notions to all.

Cookie first

A first-party cookie is a cookie managed by the website owner to track users' activities and remember preferences. It is opposed to third-party cookies which are not owned by the website but partners (advertising partners, for example). Ad blockers and browsers are blocking more and more third-party cookies, that's why first-party cookie is a great workaround to keep a continuity on tracking users.

A-record

It indicates the IP address of a given domain. 'A' for address, it is the most fundamental DNS record type (Domain Name System = website domain). By adding Commanders Act on your A-record, it allows Commanders Act to launch tags as first-party cookies, avoiding ad blockers and limitations regarding third-party cookies.

Cookie client-side

A client-side cookie (HTTP cookie, browser cookie) is a small piece of data that a server sends to a user's web browser. These cookies are stored on the browser.

Cookie server-side

A server-side cookie (session) is a unique Session Identifier stored on the browser and cookie information are stored on the server. The Session Identifier is used to match the request with the data stored on the server.

ITP

Intelligent Tracking Prevention is a feature on browser Safari (Apple) to restrict the use of cookies to track consumers.

Public cloud

With public cloud, companies don't have to purchase, manage and maintain heavy and expensive infrastructures. All of this is managed by third-party providers, and companies only pay for what they consume.

ETL capabilities

An ETL (Extract - Transform - Load) is a system that can extract the data from a source, transform the data (normalization, cleaning...) and load, insert the data to a destination.

Normalized data layer

A normalized data layer refers to ready-to-use data: after collection and normalization, the data quality is ensured, data is clean and ready to be sent to destinations.

Augmented data layer

From collected data, it is possible to enrich the data layer with computed data: create new properties from existing properties to create a sum, count, average, ratio... This allows to create high value properties to send to destinations for a better segmentation or personalization. For example, it is possible to count the total value of purchases per user or the average basket value per user.

Enrichment

When an event is collected, it is possible to enrich it from stored data to add more information on the event before to send it to destinations. For example, a purchase event can be enriched with data coming from CRM, like hashed email address or any other relevant information. It can also be enriched with information coming from the product catalog, from the product ID we can add product details, color, weight, materials...

Identity resolution

The goal of Identity resolution is to create a unified customer profile, whatever devices (desktop, mobile) or channels used (online and offline). To achieve this goal, we built a real-time proprietary reconciliation algorithm to create the complete view of customers.

1. How to send data from my web container ?

2. How to migrate from the serverside v1 (server to server) ?

3. How to migrate my mobile app data collection ?

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

Commanders Act TMS offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for Angular.

Commanders Act TMS offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for AngularJS.

Commanders Act offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for React.

Commanders Act offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In documentation on GitHub for detailed installation instructions for VueJS.

It is possible to send server-side events Commanders Act TMS container via a HTTP tracking API Source (e.g. for IOT and TV apps). Please refer to this page for more details

Documentation in progress

Documentation in progress

Commanders Act is a cookieless platform that allows you to collect, normalize/fix, enrich, check and send in real time your first-party customer data.

Basically, the platform libraries/API (Source) collects user actions (Event) on your website/app/etc. These events are sent to the platform servers and are then (in this order) fixed, normalized, enriched, checked, filtered and translated in each tool (Destination) format, so that they can be sent to your chosen destinations.

Platform servers can also store events, users and custom data in the Commanders Act database (Data store) and send this data to your storage system (by FTP, email, S3, ...), BI system, etc. The user storage is based on a realtime identity resolution system that give you a cross-device single view of your users (profiles), allowing you to build segments and use audience-based destination.

Event

An represents an action made by a user on your website or application. To track that action, you send an event that contains the data and will be received by Commanders Act.

Source

A is an emitter of events. It can represents your website, your mobile app, a point of sale (POS) etc. Defining your sources allow you to easily manage and monitor where your events are coming from. See more on:

Destination

are the partners/tools where you eventually want the collected data to go. Commanders Act provide a library of many destinations ready to be used, like GA4, Facebook CAPI or Google Enhanced Conversion. See our .

Data store

Data store is the name of Commanders Act BigData database. You can store here your events and your (product catalog, etc.) Storing data inside the Data store allows you then to your events by retrieving additional data in any storage universe. It also allows you to create user and to benefit from analysis and insights.

Data layer

A data layer is a specification of your data for tracking customer interactions. This can include data from websites, mobile apps, connected devices, and offline sources. The data layer enables your third-party vendor solutions and serves as the basis for your data-focused initiatives.

CAX Platform : Features and Functions

Commanders Act: Cookieless platform for first-party customer data collection, normalization, enrichment, and real-time transmission.

Components:

• Source: Libraries/APIs collect user actions (events) from various platforms (websites, apps, POS).

• Event: User actions tracked from sources and sent to CAX.

• Destination: Tools/partners receiving the collected data in suitable format. Examples include GA4, Facebook CAPI, Google Enhanced Conversion.

• Data store: Commanders Act's BigData database for storing events and imported data. Enables event or user enrichment, user segmentation, and data analysis.

Data Integration:

• Real-time tracking: Via OneTag, Javascript SDK, Google Tag Manager, Mobile SDKs, Rest API.

• Third-party tools: Connectors catalog, destination builder, webhook.

• Imports: Regular automated file imports (csv) for CRM users, offline conversions, product catalog, custom storage universe.

Data Quality:

• Confidence: In-app reporting and daily email digests for invalid event action.

• Normalized Datalayer UI: Interface for data schema definition and validation rule creation (event specs).

• QA automation: Event specification writing for QA process automation and real-time alert definition.

OneTag

1. Add OneTag from tag library in web container. Options: Builder (no code) and Custom (manual code).

2. Setup tag. Use cact('trigger') to record user actions. Format: cact('trigger', '<event_name>', {<event_data>}, [config], [callback]);. Events have names, properties. Example:

3. Event types: standard (recommended, predefined names, parameters) and custom (user-defined). Use standard properties in custom events.

Discover the synopsis concept behind the platform and explore our features below.

Serverside v1 to Serverside v2

Severside v1 (aka SSv1) is the serverside tag management feature of the old platform (v7). It is now deprecated. In this section, we'll see how to migrate from a SSv1 setup to the new platform (aka SSv2)

Tree steps to migrate

1. (aka Platform X)

Find on this page a full list of sources you can use to gather infomation on your traffic. Sources are sorted per categories (Web, Mobile, Push notification, CRM, etc).

You can use the search bar to find the source you are looking for. Cannot find the source you want? Fill our request form to ask our team to add a new source to the list.

All requested sources are viewable by clicking the “Request” tab on the left.

To have more information on a source simply click on it and you'll get all details to use and install the souce.

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.

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 and privacy banners in the last 36 months are recorded on the Modification History page You can access to this menu by the tab Administration => Modification History

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

I cannot see my console.log, why ?

When you write a console.log within a tag to check if a tag is correctly triggered of to check a value, for example like this :

When a new container version is generated, it re-writes the console.log as tC.log

To be able to read these tC.log you need to add this cookie within you browser :

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

Sources vs Destinations

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

What is a source ?

A source is an emitter of events, more information .

Source list

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:

The “RULES” step allows you to create your tag activation rules.

You can manage how your tags and events are called by using the tabs displayed in the left menu:

• 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

The data layer represents all your available data. It consists of information about your site (e.g. page name, product ID) and your visitors (e.g. user ID, customer status) in the form of JavaScript variables.

These variables have two uses:

– To populate the tags present in your container;

– To create activation rules for your tags.

Additional information:

The data layer can consist of two types of data:

Deduplication is the conditional activation on the confirmation page of a website, of the tag(s) responsible for the conversion.

This activation is possible by capturing and reading the parameters of your tracking URLs through TagCommander.

Within our interface, tags can be deduplicated with configurable rules depending on their position throughout the customer journey: at the beginning, at the end, or anywhere.

For example, if before converting on your site a user saw and clicked a banner served by your retargeting partner, you can set up a rule to call only that partner’s confirmation tag on the confirmation page.

The deduplication module in Commanders Act is included in your Commanders Act offer.

Site & Containers IDs / Versions

To be able to retrieve your site ID & containers IDs you need to open your DevTool on your navigator and enter

Here above :

The iOS SDK allows you to send data to analytics or marketing tools without having to learn, test, or implement a new API with each update or addition.

Please refer to our on github to use the iOS SDK and to APP "how to" :

You can send us your users' data in 2 ways :

• (Get in touch with your Account Manager)

The Flutter SDK allows you to send data to analytics or marketing tools without having to learn, test, or implement a new API with each update or addition.

Please refer to our on github to use the Flutter SDK and to APP "how to" :

You can send your product catalog data in 2 ways :

• Product API

• Files importer (FTP)

Documentation in progress

Example of event triggered from a browser-side user interraction

Example use case : trigger a view_content event when the user scroll to 80% of the page.

import React, { useEffect } from 'react';

const MyPage = () => {
  useEffect(() => {
    let eventTriggered = false; // Flag to track if the event has been triggered

    function handleScroll() {
      if (eventTriggered) return; // If the event has already been triggered, do nothing

      const { scrollTop, scrollHeight, clientHeight } = document.documentElement;
      if (scrollTop + clientHeight >= scrollHeight * 0.8) {
        if (window.cact) {
          window.cact('trigger', 'my_event_name', {
            myprop1: '1234',
            myprop2: 'abcd',
          }, {
            collectionDomain: "my.firstdomain.com",
            siteId: "1234", 
            sourceKey: "abcd1234",
          });
          eventTriggered = true; // Update the flag to avoid triggering the event again
        }
      }
    }

    window.addEventListener('scroll', handleScroll);

    return () => {
      window.removeEventListener('scroll', handleScroll);
    };
  }, []);

  return (
    <div>
      {/* Your server-side rendered content here */}
      <script
        dangerouslySetInnerHTML={{
          __html: `
            (function() {
              var tc = document.createElement('script');
              tc.type = 'text/javascript';
              tc.async = true;
              tc.src = 'https://cdn.tagcommander.com/events/sdk.js';
              var s = document.getElementsByTagName('script')[0];
              s.parentNode.insertBefore(tc, s);
            })();
          `
        }}
      />
    </div>
  );
};

export default MyPage;

There are several ways how to get your data into Commanders Act platform.

Real-time Commanders Act tracking

Third party tools

Commanders Act also offers connectors to third party tools, visit the to explore the full list.

Imports

It is possible to import data to Commanders Act through regular automated file imports (csv), such as:

• and

• Custom storage universe

Data API

You can send your specific data through our .

1. New concepts

On the new platform (aka Platform X), everything is Source/Event/Destination. Sources (your website, app or server) collect your user actions by sending events. These events are sent to the platform servers and are then enriched, normalized and translated in each tool (Destination) format, so that they can be sent to your chosen destinations. You can learn more in the Concepts section.

2.How to send events (standard / custom)

• From a server, use our .

• From a mobile application, you can either use one of our SDK (, , ...) or use our if you don't want to use a SDK.

3. Format events

• Events are the new format of your data. As explain in the , common events have to be sent in the standard format (name and properties) to benefit from plug&play features.

• Standard event format can be found in our

• Go through this based on the ssv1 format :

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

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 on every page of your website.

Moreover, the 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:

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

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 ([email protected]) 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

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

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

Event variables are the variables present in Commanders Act browser-side events. They are used primarily for tracking user actions (button clicks, links, etc.).

Event variables are useful if you want to send data specific to an event without having these data on your site pages as external variables.

Example: you wish to assign an event for the “Send” button on your form. The event variables could be the user’s last name, first name, email address and telephone number. These are data that are not available when the page is loaded; it only becomes available after the user has completed the fields on the form and clicked “Send”.

Event variables must be added in the Commanders Act interface before they can be used, and only for events, not tags.

Event variables must be created in the Commanders Act interface before they can be used in an event. See the “Adding event variables” article to find out how to create an event variable in the interface.

All event variables created can be used:

• To add information to the solutions embedded in Commanders Act (linking event variables and solutions is called mapping). See the “Mapping Tags’ Variables” article to find out how to map your variables in an event.

• To create activation rules for your events. See the “Adding Rules” section to find out how to create rules based on your event variables.

Additional information

Event variables must be implemented in the Commanders Act event function (tC.events).

Note: External variables that are already available on the page do not need to be implemented in your event. For example, you do not need to assign a “country” variable to an event if this information is already present in an external variable.

Here is an example of an event variable:

When to add an event variable

There are two situations in which you may need to declare your variables in the event variable management interface:

• You want to implement Commanders Act events on a new site. The variables that your technical staff or technical provider implement in the site’s source code (in the tC.events function) must be declared in the interface first in order to be available to be added to your tags and rules.

• Variables are for your current event functions are missing or you want to add a new event to your site. Again, this variable must be declared in the interface first before it can be used in your tags and rules.

Adding event variables

To add an event variable, you must go to the "Data Management” > "Web Datalayer" > “Event Variables” and click “ADD VARIABLE”:

The “add” window consists of the following elements:

“Name“: the variable’s name (mandatory field)

“Type“: the variable’s type

“Description“: A description of the variable, to clarify its name (e.g. “Page template” can be the description of the variable named “env_template”)

“Detailed description“: A detailed description of the variable, to further clarify tits name (e.g. “possible values: homepage/category/product/funnel_confirmation” can be the detailed description of the “env_template” variable)

Editing or deleting variables

You can edit an internal variable by clicking the “Edit” icon and delete it by clicking the “X”:

Commanders Act Events Triggers are onsite events that are used by Commanders Act users to dynamically execute Tags.

Definitions

Installation

Commanders Act allows to set up common Trigger automatically without the involvement of technical team (e.g. Container loaded, DOM ready or Vertical Scroll 25%). In cases where the default Triggers are not sufficient it is possible for technical personnel to implement custom Triggers. The necessary Trigger are defined during the Commanders Act setup process, but you can find a list of native Trigger on .

To install a custom Trigger on the website it is necessary to call a JavaScript function with the following pattern:

A typical example is an Add to basket event where the product id of the selected product is sent with the event:

Testing

Via Quality Assurance Tag

The Tag template Commanders Act - Event QA in the Commanders Act Tag library automatically outputs event Data Layer information to the JavaScript console when executed. Assigning this Tag with the Trigger allows to log a snapshot of the Data Layer when the respective Trigger is executed. Another way, more technical: you can type in your console tc_arrray_events when the event is executed. The Data Layer of the event variables will be displayed.

A Container Strategy is the layout of the Web Container of a site. Following you will find recommended Container Strategies for common types of websites and businesses.

Ecommerce

Ecommerce websites require a mix of personalization, analytics and conversion Tags. To optimise website performance it is recommended to use three Containers.

With this setup it is possible to avoid conversion Tag JavaScript snippets on catalog pages—this results in smaller Container file sizes and therefore quicker loading times for SEO relevant catalog pages.

Publisher

Publisher websites primarily require analytics Tags. Therefore it is recommended to only use one Container.

Using one <body> Container helps to have minimal impact on the page loading time, which is crucial for SEO of Content pages like news articles.

In case A/B-testing and personalization Tags are used, the additional implementation of a <head> Container is recommended.

Onsite performance of a website is one of the most important KPIs for SEO. Therefore more and more businesses are interested in optimizing onsite performance via TagCommander. This post collects topics to make TagCommander itself more performant.

Reduce File Size of Web Containers Commanders Act

Remove unused Data Layer Properties

Each Data Layer property that is configured in the options in the interface creates a bit of JavaScript code in the Container to initialise the variable in case it was not present in the onsite Data Layer tc_vars. Removing unused/old variables will therefore make the Container file a bit smaller (and as a side effect also improve transparency of the Container setup).

Remove Unused Internal Variables

Each internal variable that is configured in the options in the interface is a JavaScript snippet, so removing internal variables allows to make a Container file smaller. This can be done by removing unused internal variables and also by specifying which variables are used in which Container. This is especially important for clients with a <head> and <body> Container and clients that have multiple Containers for different websites.

Do Not Repeat Yourself

Sometimes the same functionality of a Tag is duplicated in multiple Tags. In these cases it is possible to save a good amount of JavaScript code and Container file size by refactoring the common functionality into an internal variable or into a common Tag. For example many Tags exist of two parts. One part loads an external JavaScript library of the vendor and one part sends the actual event to the vendor. Per default the code that loads the JavaScript library is often duplicated in every event. So extracting the first part into a base Tag allows to remove the duplicated JavaScript.

Split Large Container Files

Many Tags are deployed on every page of a website even so they are not triggered. For example many vendors have separate Tags for collecting information and only one Tag that is played out on the confirmation page. Therefore it might make sense to split the Container in two parts—one for catalogue pages and one for funnel pages. Therefore both Containers have a smaller size as they only include Tags that are relevant for their part of the website.

Also make sure to only implement Tags in <head> Container if necessary as those Tags usually have a greater impact on onpage performance than Tags in `<body>` Container.

Implement Hybrid Web Container Setup

A hybrid setup allows to move onsite performance impact into the Server-Side Commanders Act infrastructure.

Make Commanders Act asynchronous

Load Container Asynchronous

Many onsite page speed crawlers measure the time until the browser event onload. So in case the IT team loads the Web Container asynchronous on the onload event it is possible to make the Web Container file invisible for some page speed metrics. This is usually only possible for <body> Containers as <head> Containers need to be executed synchronously for A/B testing and personalization Tags that have an impact on the visual content of the website.

Load Tags Asynchronous

JavaScript is for the most part a single thread language, this means that long running JavaScript (like a long process in a loop) can block other parts of the JavaScript that should be executed right away. It is possible to put long running JavaScript on an execute later with a lower priority stack by wrapping it inside of a setTimeout with a delay of 0 ms.

This needs to be tested with each individual Tag as some might not be compatible with this approach.

Overview

The Geoloc API allows you to enrich your website’s traffic data with geographic information about your visitors — without needing support from your technical team. This service provides precise location attributes such as:

• Continent code

• Country code

• Region

• City

• Postal code

• Latitude & longitude

Note: Geoloc is an optional, billable feature. Please contact your Commanders Act Sales representative for pricing details.

How It Works

To retrieve geoloc data, our system sends a request to the following endpoint:

Parameters:

The API returns a JSON object containing the visitor’s geographic details.

Example Response

Using Geoloca in your JavaScript custom block

Below is a simple example showing how to call the API and store the result in tC.internalvars for use within TMS. You can use this code inside your custom javascript block.

Example Script

Once assigned, you can use any field directly via internalvars

These variables can now be used to create your own custom rules, such as display a privacy banner for different countries.

React native

We currently offer a bridge for ReactNative! It's compatible with iOS & Android.

Mobile developpers can follow our dedicated documentation

https://github.com/CommandersAct/TCDemoReactNative

Send Server -Side events:

To send events to Commanders Act you need a Source Key. To get it, you can use the dedicated Source on our platform.

Once your Source is called in your mobile app, you will obtain information about what is collected and the health of the implementation.

This should be quite easy and straightforward now!

Default triggers

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, “advanced” part:

File structure

• One line per user

The Android SDK allows you to send data to analytics or marketing tools without having to learn, test, or implement a new API with each update or addition.

Please refer to our on github to use the Android SDK, and to the "how to":

You can send us your conversion's data in 4 ways :

• (online/offline conversions)

• (FTP) online/offline conversions

This guide shows you how to quickly set up server-side event forwarding for GA4 in Google Tag Manager (GTM) using Commanders Act. With this setup, your GA4 events can be routed to multiple destinations like Facebook CAPI, Google Enhanced Conversions, and others.

1. Create a GTM Source in Commanders Act.

2. Update the GA4 URL in GTM.

3. Set Up Domain Delegation for first-party data collection (strongly recommended).

Step 1: Create a GTM Source in Commanders Act

1. Log in to Commanders Act.

2. Go to the Sources section and create a new Google Tag Manager source.

3. Copy the Source Token displayed.

Step 2: Update GA4 in Google Tag Manager

1. Open your GTM workspace.

2. Find your GA4 Configuration Tag.

3. In the Tag Configuration window, under Fields to Set, add a new field with the following values:

Note: This URL uses Commanders Act’s default domain (commander1.com) to get you up and running quickly. For better data quality, it’s strongly recommended to use your own custom domain (see Step 3).

1. Save and Publish your changes in GTM.

Step 3: Set Up Domain Delegation for First-Party Data Collection

For enhanced data accuracy and first-party tracking, we recommend setting up a custom domain through domain delegation. This ensures the data is collected and processed as first-party, improving tracking reliability and compliance with privacy regulations.

How to Set Up Domain Delegation:

1. Go to the Domain Management section of Commanders Act (find detailed instructions ) and follow the steps to configure a custom subdomain such as https://collect.yourdomain.com

2. In GTM, update server_container_urlwith your subdomain url such as:

   Replace collect.yourdomain.com with your own subdomain.

Using a custom domain not only improves tracking precision but also helps ensure better compliance with browser and privacy policies.

Step 4: Event Forwarding to Multiple Destinations

Once GA4 events are sent to Commanders Act, they can be forwarded to various destinations, such as: Facebook CAPI, Google Enhanced Conversion, Bing Ads, TikTok, Awin, ... And many more through the Commanders Act plug&play destinations catalog.

Going Further: Bypassing Ad-Blockers with GTM Script Proxification

For users looking to optimize server-side tracking, Commanders Act provides also an option to proxify the GTM JavaScript file to bypass ad-blockers. This solution ensures that consented data can still flow to your analytics tools or partners without being unfairly blocked by ad-blockers that might indiscriminately block GTM scripts, even when used responsibly.

How It Works:

• Instead of using the default GTM URL (e.g., https://www.googletagmanager.com/gtm.js?id=XXX), the script is served from your own domain (e.g., https://track.yourdomain.com/custompath.js) with a unique path modifier to avoid detection by ad-blockers.

• This process helps ensure that only user-consented data is collected and forwarded, in strict compliance with privacy regulations such as GDPR.

A Privacy-Respectful Approach:

Our server-side infrastructure is designed with privacy, consent, and user control at its core. By proxifying the GTM script, you're simply ensuring that consented data can be processed and sent to trusted tools and partners, in line with the user’s preferences. This aligns with best practices in privacy and GDPR compliance, ensuring that ad-blockers do not unfairly interrupt responsible data flows.

If you're interested in setting this up, please contact your account manager for more information.

Here are an example of a serverside v1 hit : Booking Confirmation :

{
    "method": "GET",
    "event_page_name_detailed": "page.Checkout.Confirmation",
    "booking_order_number": 9179124954957,
    "product_list_pricing_price_base_amount": 295.82,
    "product_list_pricing_currency_displayed": "USD",
    "event_page_funnel_location": 70,
    "point_of_sale_eg_brand_name": "magicOne",
    "event_page_p_line": "F",
    "privacy_ccpa_consent": true,
    "privacy_gdpr_consent": true,
    "product_list_product_id_1": 4521812,
    "product_list_product_name_1": "Luggage compartment",
    "product_list_product_id_2": 5721913,
    "product_list_product_name_1": "Lifeline",
    "request_request_url": "https://www.domain.com/Checkout/V1/MultiItemBookingConfirmation",
    "user_sha256_email_address": "4a0a303e33c11f496a9312a77309133325af1527a26d9d95cf74b81feba9c955",
    "facebook_fbp":"fb.1.1596403881668.1116446470",
    "device_information_user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36 Edg/96.0.1054.62",
    "timestamp": "11/01/2022 14:32",
 
}

It should be sent to the serverside v2 in this format (adding maximum of recommanded properties) :

{
    "event_name": "purchase",
    "properties": {
        "id": 9179124954957,
        "revenue":295.82,
        "value": 300.00,
        "currency": "USD",
        "point_of_sale_eg_brand_name": "magicOne",
        "p_line": "F",
        "items": [
            { 
             "discount":1.99,
             "quantity": 2,
             "product":{ "id":"4521812", "name":"Luggage compartment"}
            },
            {
             "discount":1.99,
             "quantity": 1, 
             "product":{ "id":"5721913", "name":"Lifeline"}
             }
        ],
        "user": {
            "id": "61be2261-8701-4b4d-af97-60ea4329c7aa",
            "email_sha256": "4a0a303e33c11f496a9312a77309133325af1527a26d9d95cf74b81feba9c955",
            "consent_categories": [
                1,
                2,
                3
            ]
        }
    },
    "page": {
        "location": "https://www.domain.com/Checkout/V1/MultiItemBookingConfirmation",
        "title" : "page.Hotels.Checkout.Confirmation",
    },
    "device": {
        "user_agent": "Mozilla/5.0 (X11; CrOS x86_64 14268.67.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.111 Safari/537.36",
        "cookie": "_fbp=fb.1.1596403881668.1116446470;_fbc=fb.1.233356.5656565;"
    },
    "event_timestamp": 1641907920000
}

Standard parameters :

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

• ““: to manage container updating options

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

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

Summary of rules for tags and events

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. You can also delete a tag’s perimeter(s) by checking the green “All pages” column. The tag will now activate on all pages.

• To add a constraint to a tag, click edit button (pencil icon) close to the triggers and use the existing constraints list to select those you wish to add to your tag.

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.

Adding rules

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” > “ADD TRIGGER”:

To create a new perimeter, click “Perimeters” > “ADD PERIMETER”:

To create a new constraint, click “Constraints”> “ADD TAG CONSTRAINT”:

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, and various options allow you to create the most appropriate rule for your tag. 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.

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:

Modifying a rule

To modify a rule, click the “edit” icon (pencil icon).

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

Deleting a rule

To delete a rule, click the “trash” icon (garbage bin icon):

Note: your rule will be saved in the trash, where you can recover or permanently delete it at any time:\

Defining channels and sources

You work with Retargeting solutions and your tracking URLs look like:

• mysite.com?utm_medium=RETARGETING&utm_source=Criteo

• mysite.com?utm_medium=RETARGETING&utm_source=MyThings

Where the utm_medium parameter stores the channel and utm_source stores the source (namely your partners).

In order to fire only the tag of the partner to whom the sale is attributed, you would need to follow these steps:

Defining Channels and Sources

Adding a Channel: click “Add Channel”

Name the channel and add the parameter that will store the value defining Retargeting (Add Condition)

Define the condition (Parameter Match or Not and the comparison value) and specify whether or not the value of the parameter containing the source will be captured (pencil icon).

Select the capture mode of the parameter containing the source (the whole value, or parts of it), then confirm the channel identification condition by clicking ADD.

Save the source-capturing settings and save the Channel configuration (Click “SAVE”).

Setting up deduplication rules

Now that you have defined the retargeting channel, you can define firing rules for your retargeting tags Criteo and MyThings.

Click the edition tab and go to the Rules step. Once there, click “Deduplication” on the menu to the left.

In the new window, click “ADD DEDUPLICATION RULE” to open the rule configuration window.

When the window opens, select the Criteo OneTag Conversion tag from the dropdown menu (3).

Select “Last” among the options relating to the touch point’s position in the customer journey. This will fire the tag if it is the last paid solution in the customer journey, now you need to define if it is the last paid click, impression or both (4).

Let’s say you want to launch the Criteo OneTag Conversion tag only if it is the last paid click. Select “click” from the options (5).

Select whether it corresponds or not to your channel (6).

Select “RETARGETING” from the dropdown menu. All channels that you have defined will become available in this menu (7).

Select “EQUALS” for the source. When you configured the channel you indicated that the source of traffic (partner) would be captured by “taking all” the value of the “utm_source” URL parameter. Since your tracking URL for Criteo looks like this:

www.mysite.com?utm_medium=RETARGETING&utm_source=Criteo

You will need to select “EQUALS”.

Enter the value of the parameter that will be compared to what was set in the interface (“Criteo”) (9)

Click “ADD” to add the rule (10).

Repeat these steps for your MyThings Conversion tag.

When both your rules are created, they will appear in the rule summary.

If your wish to edit any of them, click the pencil icon to the right on the line of each rule. If you wish to delete it, click the trash can.

The rules summary interface has a Deduplication column. A check mark will indicate that your two tags are deduplicated.

Getting Started

The onsite API is used to interact with Commanders Act features with JavaScript.

How to use

The onsite API consists of a single function, cact(), with the following strict signature:

Onsite API is included in each containers and privacy banners.

Send event

To send event data to the serverside Commanders Act platform, use this command:

Example : to send a purchase event :

Get information

To get various values from Commanders Act, use this command:

Example : to get consent from TrustCommander, you can call the consent.get API like this:

Error handling

You can handle errors through error property in the callback object. Example:

API Stub (optional)

For advance usage, we provide also an API stub that can be added when you need to interact with the API before containers or banners have loaded. This stub is already included in containers and privacy banners, so you do not have to add in most use cases. The stub is used to buffer all methods in a JavaScript array until Commanders Act JavaScript is loaded and ready to process the methods. This allows for example to use the onsite API before TrustCommander JavaScript was loaded.

window.caReady is a JavaScript array that buffers the interactions with the API. window.cact is a JavaScript function used to interact with the onsite API.

Realytics helps you measuring the impact of TV/radio campaigns on digital conversions. Using this source, you can add TV touch points to customer journeys being able to to measure the contribution of TV to their conversions from within MixCommander.

Setup

1. Access your Commanders Act account.

2. Add Realytics "Default tag".

3. Configure your tag.

4. Test and deploy your container.

Add Realytics "Default tag"

From the "INTEGRATIONS" side menu, expand(1)"Sources" and select (2)"Web containers".

Select a "Web" container and, from the step (3)"SELECT" (or "EDIT"), click on (4)"Add Tag(s)".

Search for the tag "Realytics V2 - Default Tag" and add it to your container. You can now proceed with its configuration.

Configure your tag

Start by adding (5) "Customer Key" which is your unique identifier as provided by Realytics. Set the (6) "Sync User" with your desired value: this can be either "true" or "false" (without quotes) and input the (7) "Metric Name" (also know as "Conversion Action") that you want to track. Lastly, fill two specific fields related to your entered metric: (8) "Transaction Amount" and (9) "Transaction Order Id".

Under "RULES", select (10) a "Privacy Category". This will link your tag with the explicit user consent for the selected category.

This completes your configuration. You can now start the testing phase, leading to the final deployment in production.

If you wish to share your data via flat file feed integration, please use a CSV feed format, following the structure below.

Files can be uploaded to the Commandersact FTP or downloaded from your own FTP by CommandersAct. Get in touch with your Account Manager to agree the integration method that is best for you.

Use our CSV conversion importer connector to configure the FTP import.

Structure of the file:

1 file with 1 line per product (conversion item)

Each line in the file should be a distinct product (conversion item) with their unit price and quantity. Transactions that include several products should be split into multiple lines, sharing the same conversion_id.

Example: conversion_ID_1, conversion_item_1, conversion_ID_1, conversion_item_2, conversion_ID_1, conversion_item_3,

The Commanders Act platform allows you to manage data sources, destinations, transformations across different environments. These environments—namely Production, Staging, and Development—help you organize and control your data flow more efficiently.

What Are Environments?

Environments are labels can be applied to sources, destinations, and transformations. These labels help you categorize and manage how data flows and is processed within the system. By selecting an environment, you can specify the context in which a particular source, destination, or transformation should operate. The default three primary environments are:

Introduction

We are excited to introduce the latest version of our browser extension, 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.

*Availability in the Microsoft Edge Store is coming soon!

Commanders Act Data Storage is a cookie stored on the user’s browser.

When you create data storage in the Commanders Act interface, a cookie with the same name is stored on the visitor’s browser. Data storage allows you to make use of the data it contains. Its use is described in the next articles in this section.

Data storage is useful for continually storing data about a visitor from one page to the next, from one visit to the next or for a defined period of time up to one year.

It is a cookie that stores data and allows to use it afterwards in many ways. Its uses are detailed in other articles in this section.

Additional information

Report by conversion

The “Report by Conversion” report provides information pertaining to the tags that were called for every conversion on your site, according to the rules you defined in the rules section, more specifically deduplication rules. Data is collected by the “Commanders Act – Reporting Deduplication v1.2” tag.

Access

To access the report, please click the “Deduplication by conversions” entry from the Health > Website Monitoring menu.

A web container is a JavaScript file which has two purposes:

· To be able to use native functions & methods of the TMS

· To execute the partners solutions (tags) contained inside

It is possible, as it is often the case, to have several containers for the same site or even the same page.

The URL of each JavaScript Web Container file will be provided alongside the Container IDs and Container Names by a Commanders Act Consultant during the setup process.

Pixel Tracking, also known as 1x1 gifs, or clear gifs, lets you record data from any website (or application) where JavaScript or POST requests are not allowed, but where you can insert an image (aka GET hit)

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\

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

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:

AMP Definition

AMP, which stands for Accelerated Mobile Pages, is a technology issued from the open source Digital News Initiative (DNI) between Google and European publishers. AMP is a format allowing the creation of optimized mobile content in a bid to improve user experience.

If you wish to learn more about AMPs, click the following links:

[FR]

[EN]

Implementing Commanders Act on AMPs

AMP blocks synchronous JavaScript files called on your websites in order to increase mobile pages’ loading speed. For your Commanders Act container to be compatible, you need to adapt the way you set it up to be compliant with AMP’s requirements.

Below, you will find an example showing how to set up a Commanders Act container on your AMP pages. We recommend using the <amp-analytics> tag () to define your data layer and the container.

Important: This operation calls for Commanders Act’s API and thus requires that a server-side container be setup in Commanders Act’s user interface.

Setup example with analytics tag

AMPs also allow you to set up your tag management tool through an iframe. Please note that if the iframe has not loaded within 5 seconds, it will not be called. You will find below an a setup example through an iframe:

Setup example with iframe

Following you will find common Commanders Act Trigger setups.

Page View Trigger

In most cases page view events are covered by the inbuilt Container loaded and DOM ready Trigger within Commanders Act. Therefore it is only necessary to setup the Data Layer and the Container to execute Tags on page views. In case of JavaScript driven webpages it is sometimes necessary to further track "virtual page views", e.g. in case the process steps of a sales funnel (log-in, enter shipping details, enter payment details, confirm order, order success) are implemented via JavaScript functionally and not via individual pages with distinct URLs.

In this case it is common to track the initial page view with the Container loaded or DOM ready Trigger and subsequent virtual page views via a custom Trigger. For this scenario it would be necessary to follow these steps on each subsequent virtual page view.

1. Update tc_vars Data Layer

The Data Layer should be updated with the new metadata of the subsequent virtual page view.

2. Reload the Container

Some internal functionality of the Container (e.g. Internal Variables) are only calculated when the Container was initially loaded. To reload these with the updated Data Layer it is necessary to reload the Container via a JavaScript function.

3. Execute Triggers

After these steps it is then necessary to signal a custom Trigger to execute the related Tags.

To use event attributes, you can specify the event or the element as first argument.

Old Method

To use event attributes, you need to specify the event or the element as argument. event is a special variable that is always available inside of onclick and on* attributes.

Click Trigger

Click Trigger implementation depends on the scenario. e.g. Is the user navigated to another site when he clicks an element? and Does the following page open in a new tab?.

Following you will find a list of common scenarios for click Trigger.

Scenarios

Click Navigates to an Internal Page

Links or interactions that navigate the user to another internal page are difficult to track. The reason for this is that Tags usually need more time to execute than the browser needs to navigate to the next page. This might accidentally cancel Tags execution and therefore its related tracking capabilities.

To successfully track these kind of scenarios it is important to align with the Tag vendor for a solutions. Typical solutions are:

• The Tag delays page navigation until the Tag finishes execution

• The Tag uses the Beacon Browser API, which sends tracking calls in the background

These options typically require configuration of the event Tag code.

Click Navigates to an External Page

External links are best opened in another browser tab by using the target="_blank" option on anchor links. This allows Tags to finish their work on the old tab, while users can already navigate the new external page in a new tab.

In case external links can not be opened in a new tab this scenario should follow the same advice than the prior scenario.

Click Does Not Navigate to Another Page

Some click events do not redirect to a new page. Typical examples are video transport controls or interactions with image carousels.

These click events can usually be tracked with less rissk due to Tags having enough time to execute on the same page.

Setup