Free Tag Commander training course – 2026

Why should you rethink your tag management?

In the age of dynamic websites, single-page apps, GDPR consent and multiple tracking tools, tag management has become a key issue. Whether you’re sending data to Google Ads, Facebook CAPI, your web analytics tool or your CRM, everything depends on a robust, centralised, testable… and scalable implementation.

This is exactly what a TMS (Tag Management System) such as TagCommander, offered by Commanders Act, enables. With it, tags are no longer scattered throughout the source code, but grouped within a single container, which can be managed via a single interface.

In this guide, we’ll explore together all the key steps for making the most of TagCommander in a structured and professional manner: from initial configuration to rule management, not forgetting testing, versioning and best practices for deployment.

1. Laying the foundations: understanding the role of the TagCo container

1.1. The container: your command centre

The TagCommander container is a JavaScript file that you will embed on every page of your website. It contains all the tags required for your various marketing and analytics tools.

💡 No more tags scattered throughout the HTML – you centralise everything here.

Once configured, this container is generated by the Commanders Act interface and hosted:

• either via their CDN (Content Delivery Network) with a guaranteed level of availability (100% SLA),
• or locally on your servers, if you have the technical resources to manage it.

In either case, this file must be called on all pages to be tracked, with one crucial timing requirement: the dataLayer(called tc_vars in Tag Commander) must be inserted before the container, so that the tags can use its variables.

1.2. Organising your account and containers

Each organisation has a Commanders Act account, within which one or more containers can be created. This structure allows you to segment your tracking by domain, subdomain or purpose (e.g. main container + A/B testing container).

Each container is identified by:

• a descriptive name (often linked to the project or domain),
• a numerical ID, visible both within the platform, in the interface URL, and via the browser console using the methodtC.containersLaunched.

You can have several active containers on the same page, for example:

• one in the <head>for critical tools (A/B testing, performance),
• one in the <body>for more secondary tracking tools.

1.3. The (dataLayeror tc_vars): the foundation of your strategy

The isdataLayer a JavaScript object referred to here as tc_vars, which contains all the page’s contextual data: page type, user ID, basket total, product category, etc.

It is through this that the tags will be populated.

A few key points:

• It must be declared before any other container in the HTML page.
• It takes the form of a key/value object: tc_vars['page_type'] = 'product';
• Its structure must be stable, documented and shared with the developers.

This becomesdataLayer the interface for communication between your site and TagCommander. It is what prevents hard-coding in the tags.

2. The types of variables you need to know about

Once your container is set up, variables form the core of the control system. They are what enable you to feed data into your tags, trigger events or condition the display of a tag. TagCommander distinguishes between several types of variables, each with a clearly defined role.

2.1. External variables

External variables come directly from your dataLayer, i.e. the object tc_varsthat you place in your website’s code. They are available as soon as the page loads, and are used to:

• Populate the content of tags (e.g. user ID, basket value, etc.)
• Define trigger rules
• Create scopes or constraints

They are used in the following format: tc_vars['nom_de_la_variable'].

2.2. Internal variables

Internal variables are generated directly by TagCommander, either from elements present on the page or by combining data. They are not defined in the dataLayerbut calculated on the fly, for example:

• Extract a value from a URL or a cookie
• Convert an external variable (e.g. amount including VAT → excluding VAT)
• Creating an automatic mapping table

They can be accessed using the prefix tC.internalvars.followed by the name, e.g.: tC.internalvars.page_type. This prefix prevents any conflicts with other types of variables.

2.3. Event variables

These event variables are used to send information during a user interaction, without reloading the page. For example: clicking a button, opening a pop-up, progressing through a conversion funnel, etc.

They take the form: tc_array_events['nom_de_la_variable'], and are generally triggered via JavaScript functions called:

• tc_events (version 1, older but still used by some users – ignore this method as it is completely deprecated)
• tC.event (version 2, modern and absolutely mandatory by 2025)

Event variables are essential for tracking user behaviour in real time within SPAs or dynamic interfaces.

2.4. Data Storage

TagCommander also allows you to use a data storage system via cookies, known as Data Storage. You can temporarily store certain key pieces of information there, such as:

• An audience segment (e.g. A/B test)
• A user ID or preference
• The value of a variable for reuse on another page

This mechanism is useful for improving personalisation, tracking user journeys or ensuring consistency in tag firing.

2.5 Initialise correctly tc_varsbefore each page load

The object playstc_vars a central role in the TagCommander ecosystem: it is the container for contextual data that feeds tags, triggers and scopes. It must always be initialised or updated before the container loads, and whenever the page context changes (for example, in a SPA).

When should be triggered?tc_vars

• 📍 Before calling the file tc_XXXX_XX.js
• 🔁 On every page change in a SPA

Here is a generic example of an object tc_varsto include in your HTML code:

<script>  
window.tc_vars = {
  env_work: "prod",
  lang: "fr",
  profil: "particulier",
  page_title: "Transmettre un capital",
  page_referrer: "https://www.exemple.fr",
  page_url: "https://www.xxx.fr/xxxx",    
  content_type: "Solution",
  rubrique: "Nos solutions"
};
</script>

💡 Important: if you trigger a custom event such as (tC.container.reload()SPA), you must ensure that tc_varshas been updated immediately beforehand. Otherwise, the event will be triggered, but the data sent will be incorrect or missing.

🚫 Common error observed: the event is triggered correctlytC.container.reload(), but the tags do not receive the correct data because it hastc_vars not been reset properly.

3. Implementing event functions

On a modern website, not everything happens when the page loads. Many interactions take place afterwards: clicking a button, displaying a pop-up, navigation without reloading (SPA), etc. To track this type of behaviour, TagCommander offers two event tracking mechanisms, in the form of JavaScript functions.

3.1. (tc_eventsversion 1) – OBSOLETE: DO NOT READ UNLESS THIS APPLIES TO YOU

Historically, the first events were defined using the functiontc_events. This version 1 is still supported, but is now obsolete. Each function is directly attached to a specific container.

The syntax is as follows:

tc_events_X(this, "ID", {
  'Variable1' : 'Valeur1',
  'Variable2' : 'Valeur2'
});

• X represents the container ID
• ID is the event identifier
• Each variable is passed in key/value format

These events are useful for sending specific information at a given moment, such as a click or a form submission, but their scope remains limited to a single container.

3.2. tC.event(version 2, recommended)

Version 2 introduces a more modern and flexible feature: tC.event. It allows you to define global events that can be reused across all containers in your account, without having to link them individually.

Here is an example of the syntax for V2:

tC.event.monEvenement(this, {
  'click_type' : 'CTA',
  'page_path' : document.location.pathname
});

This method is now the most widely used. It facilitates maintenance, code readability and the reuse of an event in multiple contexts.

Good to know: simply creating a custom trigger intC.event.monEvenement the TagCommander interface is enough to ‘declare’ this event, without the need for an additional block of code in the container.

Further relevant information: if you do not declare the event in the TagCommander interface but call the function tC.event.myEvent, you will get an error in the console because the event has not been declared in the container.

3.3. JavaScript API (cact()version 3, the latest – 2025)

TagCommander offers a unified JavaScript API called cact()to interact dynamically with containers, send events, manage configuration, and listen for consent changes. It is a modern and flexible alternative to tC.event, compatible with the SDK or web containers.

Initialise global configuration (siteId, sourceKey, etc.)

Before sending an event or interacting with Commanders Act’s services, you can initialise the settings with:

cact('config', {
  siteId: 1234,
  sourceKey: 'ABCD-1234',
  collectionDomain: 'my.customdomain.com'
});

All parameters are optional if a TagCommander container is already loaded on the page.

Fire a client-side event (JavaScript) using emit– as a replacement for tC.event (v2)

Ideal for triggering custom tags, tracking a click, or simulating a page view:

cact('emit', 'page_view', { page_type: 'homepage' });

💡 isemit more secure than :tC.event it does not generate an error if the event has not yet been declared.

Send a server-side event via trigger– SERVER SIDE ONLY

Allows you to send server-side data to Commanders Act. Each call to also triggerstrigger a event that can be usedtrack_* as a trigger in the TMS.

cact('trigger', 'purchase', {
  id: 'cmd-001',
  amount: 99.99,
  currency: 'EUR'
});

Retrieve consent status

To integrate or synchronise with TrustCommander:

cact('consent.get', function(result) {
  if (result.consent.status === "all-on") {
    console.log("Consentement total accepté");
  } else if (result.error) {
    console.warn("Erreur dans la récupération du consentement");
  }
});

Practical example: triggering a script after consent is updated

cact('on', 'consent_updated', function(event) {
  console.log("Consentement mis à jour !");
  // relancer le suivi ou mettre à jour les scripts
});

This unified API allows you to centralise all your events, custom triggers and interactions with the Commanders Act platform, without relying on the DOM or obsolete methods.

In summary:

• Use this primarilytC.event as it is well documented
• Onlytc_events keep for existing integrations that need to be maintained

4. Creating and configuring your tags

Once your variables are in place and your events have been defined, the next step is to create the tags that will transmit data to your partner tools: analytics, marketing, A/B testing, etc. TagCommander allows you to manage them from a centralised interface, whether using pre-existing templates or custom code.

4.1. Available tag types

When creating a tag, you can choose between:

• A** library tag**: a template provided for common solutions (Google Ads, Meta, AT Internet, etc.)
• A custom tag: if you need to inject a bespoke script

The process is simple:

1. Click on ‘Add a tag’
2. Choose from the library or opt for a custom tag
3. Name the tag
4. Enter its content (script or HTML code)
5. Define the triggers, privacy category, etc.

4.2. Mapping variables in a tag

Once your tag has been created, it must be populated with the correct data. This is where variable mapping comes in, allowing you to dynamically link information from the event(dataLayers) to your code.

Here’s how to do it:

1. In your script, enclose the variables in hash symbols #ma_variable#
2. Save: TagCommander will automatically detect the variables to be mapped
3. Select their type (external, internal, event, data storage)

💡 Tip: use lower-case names with underscores to maintain a clear naming convention (e.g. #user_id#rather than #UserID#).

4.3. Advanced customisation

Custom tags offer you a great deal of freedom: you can write conditional JavaScript, use loops, check values, and so on. Here are some best practices:

• Enclose your code in a block try / catch
• Add toconsole.log() log the execution
• Clearly define the triggering rules to avoid conflicts

Example of customisation:

var montant = #amount#;
if (montant > 100) {
  console.log("Tag déclenché pour un panier élevé");
  // ici votre code de tag
}

This flexibility allows you to tailor each tag to your business context, without overburdening developers.

🧩 Best practice for integrating TagCommander into your website

Here are the steps to follow to integrate TagCommander correctly into your web environment, whether in a test or production environment. These steps ensure reliable and structured data collection.

1. Integrate the TagCommander container Add the main<script> tag generated by the TagCommander interface to all pages of the site. ⚠️ The container URL must be adapted to the environment:
   • Test environment: dedicated container or unpublished version
   • Production environment: validated and deployed live container

🔧 Integrating the TagCommander container according to the environment

To ensure TagCommander works correctly in all your environments (production, testing, pre-production, staging, etc.), you must call the correct version of the JavaScript container depending on the context.

📌 Where should this script be included? Place it as high up as possible within the tag <head>on all your pages. This ensures that the tags can run quickly and correctly.

Example of a script to integrate:

<!-- Environnement de PRODUCTION -->
<script src="https://cdn.tagcommander.com/xxxx/tc_xxxx_xx.js"></script>

<!-- Environnement de RECETTE / PREPROD / STAGING -->
<script src="https://cdn.tagcommander.com/xxxx/uat/tc_xxxx_xx.js"></script>

🚫 Warning: Failure to follow this environment-specific rule may block or distort data collection. Common mistake: calling the production version even/tc_xxxx_xx.js during acceptance testing, or omitting the script in/uat/ test environments.

1. Initialise the beforetc_vars the container dataLayerThe TagCommander must be declared above the container script. It must contain the variables required for the tagging plan (e.g. page type, user ID, basket total, etc.). Example: window.tc_vars = { page_type: "homepage", user_id: "123456", cart_value: "89.99" };
2. Handling “virtual” views in an SPA For pages displayed dynamically without reloading (Single Page Applications), it is necessary to force TagCommander to trigger a “page view” each time the page state changes. In practice: e.g. pageview: This mechanism allows you to accurately track user interactions on dynamic pages such as.
   • Resetting variables tc_vars
   • Trigger a new virtual event via tC.event

Forcing a virtual page view in an SPA

In web flows operating in Single Page Application (SPA) mode, page changes do not trigger a full browser reload. As a result, TagCommander does not automatically detect that a “new page” has just been displayed.

To rectify this, you need to:

1. Reset / update **tc_vars**with the new values (page_type, page ID, etc.)
2. Manually trigger a virtual page view by calling:

tC.container.reload({ events: { pageview: [{}, {}] } });

This line simulates a new page view and re-triggers the tags that depend on the page loading.

🚫 Warning: You must refresh beforetc_vars calling tC.container.reload().

In some cases observed in a test environment, the event is triggered correctly, but the data sent is out of date or empty, as hastc_vars not been updated correctly.

1. Implementing custom events & attributes Depending on the business rules in your tagging plan, you must integrate: These elements must be implemented conditionally depending on the pages, user journeys or specific actions defined in the tagging plan.
   • Custom events via tC.event.nom
   • HTML attributes used as triggers or variables (via the DOM)

5. Define trigger rules

A tag must not fire at random. To avoid tracking errors or excessive resource usage, TagCommander allows you to define precisely when, where and under what conditions a tag should be activated. This is achieved through three key elements: triggers, scopes and constraints.

5.1. Triggers

A trigger is the** basic** event that activates a tag. It may be:

• The container loading
• DOM ready (HTML structure complete)
• A click on a button (via a CSS selector)
• A form submission
• Scrolling the page
• A custom event (tC.event.nom)

You can associate several of these with a single tag. In this case, the logic is OR: if any one of them is triggered, the tag is executed.

5.2. Scopes

The scope allows you to define the context in which a tag can be executed. It is an additional filtering layer to the triggers. There are various options:

• URL (fixed or with a pattern)
• Variable value (external, internal, event)
• Specific cookie
• Browser or device type
• Audience from DataCommander
• Advanced conditions via the ‘Advanced’ menu

💡 For example, you can trigger a tag only on product pages, or only on mobile devices.

Here too, multiple criteria = OR logic.

5.3. Constraints

Constraints allow you to add an extra level of condition… but with an AND logic. This means that all constraints must be true for the tag to be allowed to fire.

Constraints use the same types of conditions as scopes (URL, cookie, device, variable, etc.), but serve to further refine execution.

Combined example: A tag triggered both:

• when a button is clicked (trigger)
• only if the URL contains /checkout(scope)
• and if tracking consent has been given (constraint on a Privacy variable)

Best practice

• Check whether a trigger or scope already exists before creating a new one (to avoid duplicates)
• Give each element descriptive names to make maintenance easier
• Test your rules in a staging environment before moving to production

6. Generating and organising versions

In TagCommander, any change (adding a tag, changing a variable, creating a new rule, etc.) requires a key step: generating a version. This is what enables you to produce an updated container file, ready to be tested and then deployed. This version management is essential to ensure the traceability, stability and reversibility of your changes.

6.1. Generating a version

To generate a new version, you must first validate the changes made in the interface. During generation, several options are available:

• Reorder the tags (some must load before others)
• Enable or disable tags without deleting them
• Set a timeout for tags that are too slow (to improve performance)
• Enable/disable privacy management for the version

💡 Tip: place critical tags (such as those related to conversion or consent) at the top of the list.

6.2. Version history and organisation

Each version created is saved with:

• Its version number
• Its creation date
• Its status (deployed or not / in production or not)
• The name of the person who generated it
• A descriptive label (to be filled in carefully!)

The description is very important: it must enable the content of the version to be understood quickly, especially in the event of a rollback.

6.3. Best practices for versioning

• Use a clear naming convention for your version names: Tag name – Action – Scope – Description
• Specify the type of change: Create, Modify, Delete
• Avoid grouping too many critical changes into a single version
• If there is a risk, include the word NE PAS DÉPLOYERin the version label to alert other users

This versioning system is also useful in the event of a problem: you can revert to a previous, already tested and validated version at any time.

7. Test before going live

A good tagging plan doesn’t stop at configuration. Before deploying to production, it is essential to validate every element: tags, variables, triggers, scripts… An error that goes undetected during acceptance testing can skew your data or even block certain site features. TagCommander offers a comprehensive testing interface to ensure your deployments are secure.

7.1. The 5 levels of testing

Each version can (and must) be tested at several levels:

• Container: verification of the global JavaScript file
• Data Layer: checking variables (external, internal, events, etc.)
• Static/dynamic JavaScript: validation of custom blocks
• Tags: individual testing of each embedded tag
• Events: verification of events tc_eventsand tC.event

Each test results in a pass (✅), a failure (❌) or no test run (–). A blocking error renders the version undeployable.

7.2. Using test environments

TagCommander allows you to configure test environments, simulating production conditions (same variables, same tags, same values). This enables you to:

• Test without affecting live data
• Reproduce user behaviour with realistic values
• Identify anomalies more easily

Each environment can be linked to one or more containers and populated with specific sets of external variables.

7.3. Resolving errors effectively

When an error is detected, it is advisable to follow a structured approach:

1. Start with errors related to variables (dataLayer)
2. Then check the JavaScript scripts (custom or dynamic)
3. Continue with tags, then events
4. Finish with the global container

🛠️ Help with testing the Tag Commander tag plan: log events easily

To make it easier to validate events triggered via tC.event(V2), you can use the following script directly in your browser’s console (the Console tab in DevTools). It will allow you to view events as they are triggered in real time, along with the data associated with them:

(function monitorTCEEvents() {
  const interval = setInterval(() => {
    if (typeof tC !== "undefined" && typeof tC.event === "object") {
      Object.keys(tC.event).forEach(eventName => {
        const originalHandler = tC.event[eventName];
        if (typeof originalHandler === "function") {
          const backup = `__originalHandler_${eventName}`;
          window[backup] = originalHandler;

          tC.event[eventName] = function (...args) {
            window[backup](...args);
            console.group("📊 Custom Event Triggered");
            console.log(`%ctC.event.${eventName}`, "background: #3A86FF; color: #fff; padding: 2px 6px; border-radius: 3px;", "fired");
            if (args[1]) {
              console.table(args[1]);
            } else {
              console.log("No data passed to event.");
            }
            console.groupEnd();
          };
        }
      });

      clearInterval(interval);
    }
  }, 100);
})();

How to use it:

1. Open the console (F12 or right-click → “Inspect”)
2. Paste the script above into the Console tab
3. Interact with the site (clicks, pop-ups, etc.) to see the events displayed

This is a very useful tool for checking that your event triggers tC.eventare being correctly handled by the interface.

You can’t see your console.log messages in the console – why is that?

When you add a console.log inside a tag to check whether it’s firing correctly or to inspect a value

When a new version of the container is generated, the console.log is automatically rewritten as tC.log.

To be able to read these tC.logs in your browser, you need to add a specific cookie:

tC.setCookie("tCdebugLib", 1, 30);

Best practices

• Never deploy a version containing a red cross ❌ in the test table
• Use inconsole.log() your custom tags to identify errors quickly
• Always test on different browsers and devices if your site is responsive or multi-device

8. Deploying cleanly to production

Once your tests have been validated, it’s time for the big moment: deployment. In TagCommander, deployment involves making a version ‘live’ on your site, i.e. delivering the new container to end users. This is a critical stage: an error could affect the data collected or the site’s performance. Hence the importance of following a rigorous process.

8.1. Pre-production checklist

Before clicking ‘Deploy’, check the following points:

• All tests are green ✅ (no red crosses in the acceptance test table)
• Version labels are clear and documented
• Critical tags are correctly positioned at the top of the container
• Triggers, scopes and constraints are correctly configured
• Privacy is enabled where necessary
• If Privacy is enabled, the tags are conditional on the desired consent categories

8.2. Deployment and rollback methods

TagCommander allows you to:

• Deploy the latest generated version
• Roll back to a previous version
• View the changes made since the last deployment

💡 Tip: always test in a staging environment before switching to production. And, where possible, avoid deploying to production at the end of the day or the day before a public holiday.

9. Maintain a clean installation

Once your container is in production, the work isn’t over yet. Like any technical system, a TagCommander configuration requires regular maintenance. Without it, duplicates accumulate, rules become unreadable, and the container’s size skyrockets… to the detriment of performance and data quality.

9.1. Tracking changes

TagCommander provides a complete history of actions carried out on each container. This allows you to find out:

• Who changed what and when
• How many times an item has been modified
• What types of actions were carried out (additions, deletions, updates, etc.)

💡 Use keyword filters (e.g. added, updated) to easily find a specific operation.