Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Container strategies for common setups.
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 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.
Container
Type
Placement
Tags
Head Container
<head>
All pages
A/B-testing and personalization
Body Container
<body>
All pages or catalog pages
Analytics and tracking
Funnel Container
<body>
Funnel pages
Conversion
Container
Type
Placement
Tags
Body Container
<body>
All pages or catalog pages
Analytics and tracking
Returns the tags list
GET api.commander1.com/api/1.0/manage/container/tags/list?id_site=X&access_token=Y&id_container=Z
The response is in JSON format.
GET
Get platform 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
Name | Type | Description |
---|---|---|
URL PARAMETER
TYPE
MANDATORY
DESCRIPTION
id_site
Integer
Yes
Client site identifier
access_token
Alphanum
Yes
Caller’s security identifier
id_container
Integer
No
Container identifier
HTTP CODE
MESSAGE
DESCRIPTION
200
OK
The request went through, the result is in the answer’s body
400
Bad Request
The parameters are not ok or mandatory parameters are missing
401
Unauthorized
The security token does not match the site_id or the container_id
404
Not Found
A container identifier for the site_id parameter was not found
500
Internal Server Error
Internal server error
FIELD
TYPE
ALWAYS PRESENT ?
DESCRIPTION
idSite
Integer
Yes
Site identifier
containers
Array
Yes
Array containing the container list and their label
containers/id
Integer
Yes
Container identifier
containers/label
String
Yes
Container label
containers/is_active
Boolean
Yes
Container status (active=true, deleted=false)
tags
Array
Yes
Array containing the tag list and container label
tags/id
Integer
No
Tag identifier
tags/label
String
No
Tag label
id
integer
The user id
include
string
permissions
or roles
or both separated by a comma
Data Layer strategies for common setups.
Following you will find common Commanders Act Trigger setups.
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.
tc_vars
Data LayerThe Data Layer should be updated with the new metadata of the subsequent virtual page view.
2. Reload the Container
Some internal functionality of the Container (e.g. Internal Variables) are only calculated when the Container was initially loaded. To reload these with the updated Data Layer it is necessary to reload the Container via a JavaScript function.
3. Execute Triggers
After these steps it is then necessary to signal a custom Trigger to execute the related Tags.
To use event attributes, you can specify the event or the element as first argument.
Old Method
To use event attributes, you need to specify the event or the element as argument. event
is a special variable that is always available inside of onclick
and on*
attributes.
Steps 2. and 3. are often used in conjunction therefore it is possible to combine them in one call. e.g. tC.container.reload({ events: { pageview: [{}, {}] } });
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:
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.
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:
Onsite campaign that has to be measured for a short time period (couple of weeks)
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:
This approach results in a nice separation of concerns between website code and Commanders Act. The website is responsible to provide tracking data and mark which elements should be trackable. Commanders Act is responsible in bootstrapping the click tracking code and executing the related Tags.
Strategies to improve the onsite performance of TagCommander.
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.
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.
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.
A hybrid setup allows to move onsite performance impact into the Server-Side TagCommander infrastructure.
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.
Tags in asynchronous <body>
Container that use synchronous document.write
(e.g. some advertising solutions) will break the website in case the Container is loaded asynchronously. These Tags need to be avoided in case a Container is installed asynchronously.
JavaScript is for the most part a single thread language, this means that long running JavaScript (like a long process in a loop) can block other parts of the JavaScript that should be executed right away. It is possible to put long running JavaScript on an execute later with a lower priority stack by wrapping it inside of a setTimeout with a delay of 0 ms.
This needs to be tested with each individual Tag as some might not be compatible with this approach.
Some answers from your questions
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 :
This is how you can retrieve IDs of sites, containers, privacy.
To be able to retrieve your site ID & containers IDs you need to open your DevTool on your navigator and enter
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
The onsite API is used to interact with Commanders Act features with JavaScript.
The onsite API consists of a single function, cact()
, with the following strict signature:
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:
The onsite API methods are called asynchronously. In case e.g. you need information synchronous in the <head>
of the document it is recommended to cache and retrieve the result of the API in localStorage
.
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.
In case you work in a big team and are unsure the stub was already installed it is ok to install the JavaScript stub multiple times.
“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.”