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

• Complete closing of the platform: June 30

• Server-side v1 collection/processing end date: December 31

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

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

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

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

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.

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:

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

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.

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.

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.

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.

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.

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.

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

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.

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.

• Identity resolution

• Data Insights : Campaign analysis, Automatic Ads budget optimisation (Adloop), Customer analytics, Control group

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

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

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.

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

Real-time Commanders Act tracking

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

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

• and

• Custom storage universe

You can send your specific data through our .

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)

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

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

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

Commanders Act offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In 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 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 for more details

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 :

Documentation in progress

Documentation in progress

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

• API users

• Files importer (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 developper documentation on github to use the Flutter SDK and to APP "how to" :

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 developper documentation on github to use the iOS SDK and to APP "how to" :

You can send your product catalog data in 2 ways :

• Product API

• Files importer (FTP)

Documentation in progress

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.

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 developper documentation on github to use the Android SDK, and to the "how to":

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

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.

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.

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.

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.

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.

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.

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

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.

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

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 data quality indicator allows to quickly visualize the status of the source, if data are of good quality () or not () on the last hour.

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

• sunny if the percent of correct events is equal to 100%

• cloudy between 95% and 99.99%

• rainy between 90 and 95%

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:

– Data implemented by your IT department or your technical provider for all your web pages, based on the CSS, Backoffice and CRM. These data are called “external variables” and are displayed in your site’s source code as a JavaScript object containing all the variables used by your tags.

This is what the external variables look like in the source code:

– Data created in the interface by Commanders Act staff or Commanders Act users based on information available on the site’s pages (URL, cookies, HTML tags, external variables in the data layer, etc). They are called “internal variables” and are displayed in the Commanders Act web container’s code.

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.

It allows you to create rules to fire confirmation tags (mostly but not only) based on:

• A digital marketing channel (SEM, Display, Retargeting, Affiliation, etc).

• A traffic source linked to that channel (digital marketing solutions such as Criteo, Netaffiliation, Marin, Tradedoubler, etc).

• The position of the touchpoint throughout the customer journey

Note: Channel and source information is read and captured from the parameters in your tracking URLs if you use our “Commanders Act TMS” product only. However, if you have subscribed to other options of our platform (like “Enrichment”), you can use Commanders Act redirects, in which case there would be no URL parameter capture.

There are many benefits from activating the deduplication module:

• Preserving information confidentiality: by activating solely the tag of the partner responsible for a conversion, you limit information leakage about your sales, leads, order amounts, among others, to all your providers, and communicate only what pertains to a specific conversion generated by a specific solution to that very partner.

• Saving time: Commanders Act’s deduplication module allocates conversions to partners in real time, helping you save time and not having to allocate conversions manually afterwards from information obtained through reports generated by your analytics tools and your partners.

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

tC.containersLaunched

Here above :

• Site ID : 4505

• Containers IDs :

  • 20 (version 155.04)

  • 21 (version 32.01)

To be able to retrieve your Privacy ID & Privacy Version you need to open your DevTool on your navigator and enter

Here above :

• Privacy ID : 12

• Privacy Version : 005

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!

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

• Conversion API (online/offline conversions)

• Files importer (FTP) online/offline conversions

• (online/offlinepurchase event)

• Web Container (online purchase event)

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.

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.

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:

• Production: This is the live environment (on which to be very carreful)

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

• From a server, use our .

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 .

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.

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

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.

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:

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.

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.

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,

• One line per user

• Header on the file is needed for the matching

• Encoding: utf8

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

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;

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.

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.

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.

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.

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

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.

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.

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.

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

Definitions

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:

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.

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

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

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:

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

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

A Commanders Act Data Layer is a JavaScript object that holds metadata of a website as properties to make it available to Tags. In the platform this Data Layer is named "External Variables" to distinguish it from scripted "Internal Variables" that are generated within the Container JavaScript.

To install a Commanders Act Data Layer it is necessary to implement a global JavaScript object tc_vars that holds the meta data of the page as direct properties. The required Data Layer properties are defined during the Commanders Act setup process, but you can find a list of common properties on .

The approach to fill the Data Layer with properties depends on the technology framework that is used on the website and can reach from JavaScript web scraping to templating to hardcoding.

The Data Layer needs to be filled with information before the Web Container file is loaded—otherwise information might not be available at the time the Container JavaScript executes.

In case multiple Containers are used on the same page it is possible to fill the Data Layer in multiple steps. Global information like the page type should be made available before the first Container is loaded. Information that is only relevant for a certain Container (e.g. product information) can be appended prior to the respective Container.

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:

This trigger allows calling tags when the container is loaded on a page. It is the default trigger for all the tags you add to your container. This means that the tag will only be called when your JavaScript container loads on your site, but it will not be the case for other event types (such as a click, a page change within an “single page applications” environment, etc.). In order to trigger tags when a container loads on your page, all you need to do is selecting them from the list.

This trigger allows calling tags when the page’s structure is built (on the “DOM Ready” event). To launch tags on this event, all you need to do is selecting them. They will be called on the DOM Ready event when the page loads.

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.

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

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.

Sending an event from a web container is as easy as adding a tag : the OneTag.

1. Add the OneTag from the tag library

From your web container, add a tag from the tag library, searching Commanders Act OneTag

You will find 2 tags to choose from :

1. The OneTag - Builder: it will guide you without having to write code

2. The OneTag - Custom: for those who prefer to manually write complex event data using javascript

If you choose the builder version of the tag, you can go to the next step, you just have to follow the instructions. If you choose the custom one, here is how it works: The cact('trigger') function is what allows you to record any actions your users perform, along with any properties that describe the action. Each action is known as an .

Here’s the format of a typical trigger call:

Each event has a name, like page_view, and properties. For example, a page_view event might have properties like page_name or page_type.

Here is an example

You can implement two types of events:

• Recommended are events that you implement yourself, but that have Commanders Act-predefined names and parameters.

• Custom events are events that you name and implement yourself. Before implementing a custom event, check that there is not a that already provides what you need. With custom events, best practice is to use recommended properties that you can find in our (ex: revenue, currency, ...) beside your custom properties.

If you use Commanders Act CMP, the user consent is automatically retrieved and put inside all events in the user property.

If you use another CMP, you will have to add manually a property consent_categories inside a user property, following this example :

consent_categories is the user's consents list and is mandatory to manage consents in each destinations (aka server-side consent) See .

There are 3 default parameters that you can override if needed:

• collectionDomain: if not set, the default value correspond to your first party domain (if you setup one) or collect.commander1.com

• sourceKey: if not set, the default value is the of the currently running web container.

To override a parameter, you can add a config object to your cact('trigger') function (4th parameter) like this:

You can also set globally these parameters for all triggered events with the cact('config') method. See the for more information.

After configuring your OneTag (at lease one event triggered) and deploying your web container, you can refer to the tab for the Source to verify that it generates the expected event data.

The Source Event Inspector serves as a live tool that aids in validating the arrival of events originating from your website, mobile application, or servers to your Commanders Act Source. This enables you to promptly examine the reception of calls by your source and troubleshoot without the need to await data processing.

Once you have verified the inflow of data from your fresh source, it's the perfect moment to create your first destination:

• Navigate to your Commanders Act platform, click on Destinations-> Overview, and select 'Add Destination' to list all the available destinations in the catalog.

• Look for the destination of your preference. For example Facebook Conversion API.

• Click on the card representing the destination to obtain more information about it.

When you add a destination (aka serverside tag), you manage the user consent by selecting the appropriate consent categories for that destination (for example "Advertising" category for Facebook CAPI). As a result, since each event entering the platform contains information about the user's consent, the event will only be sent to the destination if there is a match between the categories consented by the user and the consent's category associated to the destination.

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.

Download it now in the Chrome Extension 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)

Inside the plugin

You can select the version you need to test directly in the drop down on the right side

You haven't seen your latest version? Use the refrseh buttons to update the dropdown with the latest version

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.

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

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. Simply unfold the "web containers" section to see the list

Use the icon aside the Site Name - Container Name to reach in just one click your Web Container on our Platform

On every new page load, you can see the state of the Data Layer!

Simply unfold "External variables" or "Internal variables" to see it.

Open the tab "Events" to see your tags triggered on events. The Data Layer state is also visible on this tab. If some "event variables" are fed up, you will see them as well

Customs Events are also visibles, with the proper name of each custom event.

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

To preserve confidentiality, our plugin requires to be logged on our platform.

It's also compatible with SSO

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

• 🌍 Consistent Web Container URLs: The Web Containers 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 "custom event" hit collected by the plugin. On each page change, the tags are added to the list*. The Data Layer is updated on each new "page load" *This behavior will be improved in an upcoming update, so stay tuned!

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

• Improved SPA website management (for custom events "page load")

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.

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:

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

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

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

Data storage that you create in the interface are first-party cookies, which are cookies set for your site’s domain name.

You can use the function below to see the content of data storage created for one of your site’s pages:

tC.getCookie('cookie_name')

You can use the following function to create custom data storage: tC.setCookie('cookie_name', 'value', 'expiration')

To add data storage, you must go to the “Options” tab > “Data layer” > “Data Storage” and click “ADD DATA STORAGE”:

The “add” window consists of the following fields:

Name: Name of the Data Storage Container(s) to link:A menu that unfolds and shows all available containers Lifetime: A menu to select the cookie’s lifetime Type: the type of cookie/what it is used for Value: the values the cookie will take (a and b for ab testing, many more for n testing …)

Generates a unique ID for each visitor.

Example: Commanders Act can become your visitors’ unique reference ID to replace or enrich the ID generated by your partner solutions.

The “Do you want lifetime to be refreshed at each page view?” option changes the data storage’s lifetime based on the frequency of visits to the site. This option refreshes the data storage lifetime with each page view.

Example: you have set the data storage lifetime to 30 days and checked this option. If a user visits the page at 12 p.m. on 05/01/2015, the cookie will remain on the visitor’s computer until 12 p.m. on 05/31/2015, i.e. 30 days later. The cookie’s lifetime will refresh with each page view.

Saves the value of a URL parameter.

Example: if you want to save the value of the “utm_source” parameter, i.e. “google” in the URL https://www.site.com/landing?utm_source=google&utm_medium=cpc, you must enter the name of the parameter to save, which in this case would be “utm_source”

Assigns a score based on the number of page views.

Example: if you want to assign the score of “A” to visitors visiting 1 to 3 pages, a “B” to visitors visiting 4 to 7 pages and a “C” to visitors visiting 8 to 11 pages, you must enter the different ranges of page views and indicate each range’s score. The data storage value will be the score (A, B or C).

Saves the number of page views for a given visitor.

Example: you can use this data storage type if you want to save and send the user’s number of page views to one of your solutions or define a tag’s activation on the number of page views. Just select the “page views counter” data storage type, and the cookie’s value will increase automatically with each page view (1 page view: cookie value = “1”, 2 page views: cookie value = “2”, etc.)

Creating two visitor populations split 50/50.

Example: if you want to activate solution A for 50% of your visitors and solution B for the remaining 50%, all you need to do is indicate the data storage values for population A, “vendor_A” for example, and population B, “vendor_B”.

You will then be able to create a rule during the deployment process in the “Rules” section that activates solution A’s tags when the data storage value is “vendor_A”, and solution B’s tags when the value is “vendor_B”.

Note: this method is used regularly for A/B tests of two competing retargeting solutions.

Creating N visitor populations of equal size.

Example: if you want to launch an N test for 3 competing solutions, each solution will be assigned 33.3% of the traffic (100%/3); for 4 solutions, each solution will be assigned 25% of the traffic (100%/4), and so forth.

If you decide to activate solution A for 33.3% of your visitors, solution B for another 33.3% and solution C for the remaining 33.3%, you must enter the data storage value in each case. For example, “vendor_A” for solution A, “vendor_B” for solution B and “vendor_C” for solution C (1). Each value must be separated by a comma in order to be processed.

Saves a variable’s value.

Example: if at some point you want to save a Commanders Act data layer variable or any other JavaScript variable present on the page, you must enter the name of the variable to save.

For example, data storage allows you to save visitors’ user_id variables in order to recognize them if they return several days after leaving your site. To save the user_id variable value, you must enter “tc_vars[“user_id”]” or “tc_vars.user_id” (both formats are accepted) in the “Variable to save” field (1). If you want to save the value of an internal variable, you must enter the value using the following format: tC.internalvars.variable_name.

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.

Interface Description

Calendar

The calendar allows you to select a period of time to display deduplicated tag calls. There are eight predefined periods (Yesterday, Last Week, Last 30 days, Last Month, Last Quarter, Month-to-Date, Quarter-to-Date, Year-To-Date) and you can customize the period you wish to see tag calls for. You also have the possibility to compare periods to have a clearer vision of the way tags’ performance has evolved from one period to another.

“Report by Conversion” Table

This table displays the number of tag calls for every conversion:

• “Conversion ID”column: displays your conversions’ IDs.

• “Date”column: displays a conversions’ time and date.

• “Revenue”column: displays the conversions’ amounts (including or excluding taxes, depending on the amount you chose to collect with the “Commanders Act – Reporting Deduplication v1.2” tag).

1. Position: displays, in descending order, the position of every touch point within the customer journey associated to the conversion.

2. Type: displays the touchpoint’s type (click or impression).

3. Channel/Source: displays the channel (lever) and source (solution) corresponding to every touch point.

The search engine above the table allows you to easily and quickly find a conversion simply by typing its ID.

The “Advanced Filtering” button lets you filter results by tag to find a conversion faster.

Exporting the “Report by Conversion” table

The “export” icon on top of the table allows you to export the “Report by Conversion” report:

• If you click “CSV” you will receive the CSV report directly in your mailbox.

• If you click “Email”, you will be able to enter the email addresses of people you wish to send the CSV report to.

The “Report by Tag” report allows you to see, over a specific period of time, the number and evolution of calls to the tags that were placed on your confirmation page(s), more specifically those of deduplicated tags. Data is collected by the “Commanders Act – Reporting Deduplication v1.2” tag.

Access

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

Interface Description

Calendar

The calendar allows you to select a period of time to display deduplicated tag calls. There are eight predefined periods (Yesterday, Last Week, Last 30 days, Last Month, Last Quarter, Month-to-Date, Quarter-to-Date, Year-To-Date) and you can customize the period you wish to see tag calls for. You also have the possibility to compare periods to have a clearer vision of the way tags’ performance has evolved from one period to another.

“Tag calls’ evolution” graph

The “Tag calls’ evolution” graph displays calls to the tags checked in the “Tag Calls Detailed” table. If you wish to display data for other tags, simply check the corresponding box and click the table’s refresh icon. A curve with a specific color is associated to every tag. When you click the tag’s name in the graph’s legend, the curve corresponding to the tag whose name you clicked will disappear or reappear.

The arrow in the graph’s upper right-hand corner allows you to unfold or collapse the latter.

The button in the graph’s bottom right-hand corner lets you see calls to deduplicated tags on a daily or weekly basis.

“Tag Calls Detailed” table

Tags listed in the “Tag Calls Detailed” table are tags placed on pages where the “Commanders Act – Reporting Deduplication v1.2” tag was included too.

The table displays the number of calls that were issued:

• The “Conversions” column indicates the number of times a tag was called over a given period of time. This number considers deduplication and other rules placed on your tags.

• The “Conversion Share” column displays the percentage of conversions a given tag participated in, according to the exact same rules as those considered in the “Conversions”

• The “Detail” column allows you to see the IDs of conversions a tag was called for, as well as the corresponding time, date and amount (including or excluding taxes, depending on the amount you chose to collect with the “Commanders Act –Reporting Deduplication v1.2” tag.

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.

Implementation of the containers on the page

Web container are usually installed by implementing a <script> html node on every page of your website that holds a src attribute that points to the Container URL.

The containers can be placed in different locations in the page source’s code depending on their use and your type of business.

Here’s a common example with 3 containers:

<head> container's location is usually used for AB test and should be load synchronously, to prevent flickering effect.

We recommended to implement all <body> containers asynchronously. Simply use the async attribute in the <script> element.

<head> Container are used to implement A/B-testing and personalisation Tags that usually impact the visual content of a website before it is presented to the user. Therefore it is important to place them as high as possible in the <head> section of your website.

Please ensure that the <head> Container file is loaded synchronously to avoid potential content flickering effects.

<body> Container are used to implement Tags that measure information. These Containers are therefore placed at the end of the <body> section to make sure they have minimal impact on the loading time of the content of the website.

In contrast to the <head> Container it is possible to implement <body> Container asynchronously. For example it is possible to load them via JavaScript on the onload event of the page or it is possible to use the async attribute in the <script> element.

It is possible to log all loaded Container files on a site via the JavaScript console of the browser. The JavaScript object tC.containersLaunched provides information of each loaded Web Container.

Following you will find an example object including its most relevant information:

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:

cact(command, [options,] [callback])

Onsite API is included in each containers and privacy banners.

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

Example : to send a purchase event :

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:

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

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.

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

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)

To send a basic event call using pixel tracking, construct a GET request to the tracking endpoint URL with the necessary query parameters. The following example demonstrates a basic event call for tracking a page view:

In the above example, replace {siteId} with the ID of your site (aka workspace), {yourSourceKey} with your specific source key, and value1 with the desired value for prop1. Remember to URL encode the string values, especially if they contain special characters or spaces.

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] https://www.ampproject.org/fr/learn/about-amp/

[EN] https://www.ampproject.org/learn/about-amp/

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.

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.

window.tc_vars = {
    env_template: "homepage",
    env_work: "prod",
    page_name: "Homepage",
    page_keywords: ["homepage", "home", "entrypage", "index"],
    product_name: "",
    (…)
};

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

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.

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.

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.

Commanders Act users can setup common click Triggers with minimal effort via the Web Containers interface by selecting them with a CSS selector path.

This Trigger works in many scenarios but has two downsides:

1. Using a generic CSS selector path to setup a Trigger is unstable and can break on future releases of the website code when the CSS is updated.

2. Commanders Act can only identify elements that are loaded synchronously on the website. Elements that are loaded asynchronously cannot be watched by the predefined Commanders Act Trigger.

Good scenarios for setting up Commanders ActTriggers with the Interface are:

1. Onsite campaign that has to be measured for a short time period (couple of weeks)

2. General click tracking until the web development team can implement a custom Trigger.

Technical personnel can implement custom Triggers to track clicks on a website. This approach is more stable compared to setting up a click Trigger with the interface, but usually requires some time until the web development team can implement them. Therefore it is recommended to implement intermediary Triggers with the interface until they are implemented in the site.

Custom Triggers should not be implemented for short term campaigns, but should be favoured for business critical functionalities like Add to basket or Successful Registration.

A common way to setup click Trigger is done by setting up data-attributes on all elements where clicks should be tracked. These attributes could then be filled by the website CMS with values, so e.g. the marketing team can setup a "Click Trigger" for a new Teaser on their own. In HTML this might look like this:

Inside of Commanders Act Platform it is then possible to catch clicks on these elements to execute a custom Trigger. With jQuery this might look like this:

Commanders Act provides a GTM template to connect your existing GTM implementation to our serverside endpoint, in a secured environment.

Setup

Summarizing all recommended steps:

1. Create a GTM source in Commanders Act

2. Add our template to your GTM implementation

3. Configure your tag

In your Commanders Act dashboard:

• In the left pane menu, click on Sources > Overview.

• Click on the Add source button.

• In the catalog, search for the Google Tag Manager source and click on it.

• Copy its value and keep it for later!

First, access and then add our template "Commanders Act | Serverside events bridge" from the Google "" in your workspace, then select (1) "Tags".

Click on (2) the "New" button.

Click on (3) the "Tag Configuration" area.

Click (4) the magnifying glass in the upper right corner.

Search for (5) the "Commanders Act | Serverside events bridge" custom template and click on it to start the configuration.

Start by filling (6) a name for your tag in the upper left corner.

Input your (7) "Commanders Act Site ID" and (8) "Commanders Act Source Key" (refer to the first section on how to create a source and retrieve its key).

Select (9) the "Commanders Act Event" from the drop-down menu, which is the event you want to forward.

Depending on which event you select more (or less) fields will be presented. In case you don't input a mandatory field the template will highlight the missing entry so you can provide a proper mapping.

The "Event Fields" section contains fields that define the event itself and are mostly mandatory or highly recommended.

Events including the "Product Fields" section require . The first field will always be the (10) base array where the information is stored and all subsequent fields are the related properties - E.g. you can map the information about (11) the "Product Id" by filling the property name.

In the "User Fields" section you can set (12) the "User Id" and (13) "User Email" - Either one of them is required if you select the "Purchase" event. The (14) "User Consent Categories" is a mandatory field holding an array with the user's consent category identifiers.

It's important to define and map all category identifiers with their respective names. For example, you may have the following array: [1,2,4] and you defined the following relationship:

• 1 ➜ Advertising category

• 2 ➜ Analytics category

• 4 ➜ Functionality category