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.

tC.container.reload();

3. Execute Triggers

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

cact('emit', 'page_view', {});

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

<a href="/home" onclick="cact('emit', 'pageview', { from: this, some_data: 'some_value' })">Home</a>

Old Method

tC.event.pageview({}, {});

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.

<a href="/home" onclick="tC.event.pageview(event, {}))">Home</a>

Click Trigger

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

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

Scenarios

Click Navigates to an Internal Page

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

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

• The Tag delays page navigation until the Tag finishes execution

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

These options typically require configuration of the event Tag code.

Click Navigates to an External Page

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

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

Click Does Not Navigate to Another Page

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

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

Setup

With Commanders Act Interface

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.

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

<a href="..." class="btn btn--cta" data-tracking-action="click" data-tracking-label="My CTA" data-tracking-value="campaign-1234">Buy now!</a>

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:

(function(){

    if (!$) {
        console.log("Commanders Act | Error | jQuery not available in Commanders Act Click Trigger!");
        return;
    }

    var eventActionSelector = '[data-tracking-action="click"]';
    var eventLabelAttribute = 'data-tracking-label';
    var eventValueAttribute = 'data-tracking-value';

    var eventHandler = function(event) {

        var eventData = {};
        eventData.event_action = "click";
        eventData.event_label = $(this).attr("data-tracking-label");
        eventData.event_value = $(this).attr("data-tracking-value");

      	if (tC.event && typeof tC.event[triggerName] === "function"){
            // old method
            // tC.event["my_click_trigger"](event, eventData);

            eventData.from = event; // necessary to use event attributes inside the tag
            cact('emit', 'my_click_trigger', eventData);
      	}

    }

    // Setup event handler on body via event delegation to include asynchronous elements
    $("body").on("click", eventElementSelector, eventHandler);

}());

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

Reduce File Size of TagCommander

Remove unused Data Layer Properties

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

Remove Unused Internal Variables

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

Do Not Repeat Yourself

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

Split Large Container Files

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

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

Implement Hybrid TagCommander Setup

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

Make TagCommander asynchronous

Load Container Asynchronous

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

Load Tags Asynchronous

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

setTimeout(function() {
    // My Tag Code
}, 0);

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

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

Ecommerce

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

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

Publisher

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

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

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

“tC.” methods are namespaced* . They come in handy when needing to perform technically advanced actions such as printing the array of launched tags within a container into the browser’s console. Please note that these functions’ availability and behavior depend on several elements like your container configuration, among others. Simply type “tC.” into your browser’s console and the list of available functions on a given site and for a given container will appear.

* “namespacing is a technique employed to avoid collisions with other objects or variables in the global namespace. They’re also extremely useful for helping organize blocks of functionality in your application into easily manageable groups that can be uniquely identified.”

I cannot see my console.log, why ?

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

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

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

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)

Privacy ID & Privacy Version

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

tC.PrivacyID

tC.PrivacyVersion

Here above :

• Privacy ID : 12

• Privacy Version : 005

GET Tags List

Returns the tags list

Call URL

GET api.commander1.com/api/1.0/manage/container/tags/list?id_site=X&access_token=Y&id_container=Z

Call parameters

Return code:

Response format :

The response is in JSON format.

GET

Response example

Get Users

Get platform users.

Users

GET https://api.commander1.com/v2/{siteId}/users

Two usages : GET /users/ : Returns a list of user properties (depending on the parameters requested) linked to the users of a site. GET /users/123 : Return properties of one user (id 123) on one site. Click below to download complete API documentation

Query Parameters

Getting Started

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

How to use

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

Onsite API is included in each containers and privacy banners.

Send event

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

Example : to send a purchase event :

Get information

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

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

Error handling

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

API Stub (optional)

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

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