Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Container strategies for common setups.
A Container Strategy is the layout of the TagCommander 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.
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
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.
Container
Type
Placement
Tags
Body Container
<body>
All pages or catalog pages
Analytics and tracking
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. For AMP versions of the website it is possible to implement a Server-Side TagCommander.
In case A/B-testing and personalization Tags are used, the additional implementation of a <head> Container is recommended.
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 :
Data Layer strategies for common setups.
Following you will find common TagCommander Trigger setups.
In most cases page view events are covered by the inbuilt Container loaded and DOM ready Trigger within TagCommander. 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.
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.
TagCommander users can setup common click Triggers with minimal effort via the TagCommander 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.
TagCommander can only identify elements that are loaded synchronously on the website. Elements that are loaded asynchronously cannot be watched by the predefined TagCommander Trigger.
Good scenarios for setting up TagCommander Triggers 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 TagCommander 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 TagCommander. The website is responsible to provide tracking data and mark which elements should be trackable. TagCommander is responsible in bootstrapping the click tracking code and executing the related Tags.
Coming soon...
“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.”
tC. Function
Behavior
tC._R
Internal object used for statistics
tC.ams
Internal object used for the Measure product
tC.array_launched_tags
Displays a list of tags within the container version that is published. If you use one of our testing tools (Bookmarklet or TagAssistant Chrome extension) and simulate the presence of a different container version, the function will display the tags within the container version that is being tested
tC.array_launched_tags_keys
Displays a list of tag identifiers corresponding to the tags within the container version that is published or being tested
tC.call
Internal function used for callbacks
tC.containerVersion
Displays the version number of the container that is published or being tested
tC.containersLaunched
Displays a JavaScript object containing other objects. The latter correspond to the containers launched on a given page and provide information about them and the tags within (id, name)
tC.dedup
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays a JavaScript object containing all defined channels and sources and showing whether they are active or not
tC.dedup_done
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays whether the deduplication module is on or off on a given site
tC.dedup.cj
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last 10 touchpoints in a user’s customer journey. They are collected with customer journey (CJ) cookies. You can adjust the number of touchpoints in the interface. To do so, please go to the Options > Channel and sources definition tab
tC.dedup.LeA
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last recognized channel in the customer journey
tC.dedup.LeAD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the last recognized channel in the customer journey cookie
tC.dedup.LeC
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last recognized channel – related to clicks – in the customer journey cookie
tC.dedup.LeCD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the last recognized channel – associated to clicks – in the customer journey cookie
tC.dedup.LeV
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the last recognized channel – related to views – in the customer journey cookie
tC.dedup.LeVD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the last recognized channel – related to views – in the customer journey cookie
tC.dedup.FeC
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the first recognized channel – related to clicks – in the customer journey
tC.dedup.FeCD
DEDUPLICATION HAS TO BE ACTIVE FOR THIS FUNCTION TO WORK
Displays the source associated to the first recognized channel – related to clicks – in the customer journey cookie
tC.dedup.FeV
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the first recognized channel – related to views – in the customer journey cookie
tC.dedup.FeVD
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays the source associated to the first recognized channel –related to views – in the customer journey cookie
tC.dedup.AeA
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays channels recognized halfway through the customer journey
tC.dedup.AeC
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays channels recognized halfway through the customer journey (for clicks)
tC.dedup.AeV
DEDUPLICATION HAS TO BE ENABLED FOR THIS FUNCTION TO WORK
Displays channels recognized halfway through the customer journey (for views)
tC.domReady
Displays whether all the content from the Document Object Model (DOM) has finished loading or not (i.e. the containers)
tC.domain
Returns the page’s domain (.tagcommander.com for instance)
tC.each
Internal iterator
tC.generatorVersion
Displays the container generation engine’s version
tC.getCookie
Displays the value of a given cookie. You need to write the function and the cookie’s name next to it between parentheses and quotes: tC.getCookie(“cookie’s name”).
tC.getParamURL
Displays a given parameter from the page’s URL
tC.hitCounter
Internal function used to obtain statistics related to invoicing hits
tC.id_container
Displays the container ID
tC.id_site
Displays the TagCommander site ID
tC.inArray
Internal function to check if an element is placed inside an array
tC.inclusion_oct_1
Specific to each container (JS inclusion)
tC.internalFunctions
Namespace for TagCommander’s internal functions
tC.internalvars
Namespace for TagCommander’s internal variables
tC.isArray
Method to verify whether a variable is placed inside an array
tC.isCurrentVersion
Confirms whether the currently deployed version in the interface is the current version on the site
tC.isDOMReady
Confirms if the Document Object Model (DOM) is ready
tC.isFunction
Method to verify whether the type of a variable is a function
tC.isNumeric
Method to verify whether a variable’s value is a number
tC.isPrototypeOf
Method to verify whether a variable is prototype
tC.isWindow
Method to verify whether a variable is window
tC.launchTag
Internal method used for TagCommander’s Google Chrome extension
tC.length
Internal variable
tC.log
Method replacing the console.log() command
tC.maindomain
Displays the main domain containers are deployed on
tC.name
Displays a “c” for container
tC.nodeNames
Displays the list of the Document Object Model’s (DOM) elements
tC.onDomReady
Method to execute code on the Dom Ready event
tC.pixelTrack
Internal Method injecting pixels
tC.privacy
Namespace for variables related to the Privacy module
tC.privacyVersion
Displays the version number of the Privacy banner and settings that are published
tC.rchecked
Internal Variable storing a regexp
tC.removeCookie
This function lets you remove a cookie. You need to write the function and the cookie’s name next to it between parentheses and quotes: tC.removeCookie(“cookie’s name”)
tC.script
Returns a JavaScript object that you can “unfold” to find the location of the container (link to the script)
tC.setCookie
This function lets you create a cookie. Here is the function interface: tC.setCookie(name, value, lifetime, path, domain, secure, sameSite). Ex: tC.setCookie(“My_cookie”, “1”, 365,”/”,”.mysite.com”, true, "Lax")
tC.ssl
Displays the SSL certificate: indicates whether the page’s protocol is https or http
tC.tagPatterns
Internal variable containing the regex (patterns) to detect tags’ hits for the TagPerformance module
tC.tagPerf
Internal variable for the TagPerformance module
tC.tagPerfAnalyzer
Internal function that analyzes a page to calculate tags’ response time (for the TagPerformance module)
tC.tagPerfE
Yet unused variable that controls sampling rates of TagPerformance’s calls
tC.script.add(location.protocol + “//manager.tagcommander.com/utils/IP/”);
This function allows you to recover the IP address
Data Layer properties for common setups.
Following you will find a collection of important Data Layer properties. These should be seen as a framework that can be adjusted to the needs of each individual site.
Base Data Layer Properties are recommended for all TagCommander implementations. They are the minimum amount of properties to allow a straightforward handling of common Tags.
Property
Description
Example
env_template
Page type identifier—most important property that allow users to play out Tags only on relevant pages.
"homepage", "product_detail", "funnel_confirmation"
env_work
Environment identifier
"prod", "stage", "dev"
env_country
Site country code (ISO_3166-1_alpha-2)
"DE", "EN", "FR"
env_language
Site language code (ISO 639-1)
"DE", "EN", "FR"
page_name
Name of the page.
"Our new phone!"
page_cat1_name
Page top category name
"smartphones"
page_cat2_name
Page category name
"apple"
page_cat3_name
Page sub category name
"iphones"
page_cat1_id
Page top category id
"1234"
page_cat2_id
Page category id
"2345"
page_cat3_id
Page sub category id
"3456"
page_search_keywords
Search keywords on search or product finder pages
"new iphone"
page_search_filters
Array of search filters on search or product finder pages
["price", "rating"]
User ids and properties are important for advertising and personalisation services.
Property
Description
Example
user_id
User ID
"12345"
user_email_hash
Hashed user email
"kGghdg62173fh1123ff667128g"
user_newcustomer
New customer flag
true for new customer, false for known customer
It is recommended to extend the base Data Layer properties with following variables for ecommerce sites. These enable users to successfully track product and order information:
Property
Description
Example
env_currency
Currency code (ISO code 4217)
"EUR"
product_array
An array of product objects that holds products information of currently viewed products on a page—product list pages usually hold several products (e.g. top 5 products of the page), product detail pages only one product
Described in section Data Layer Product Array
basket_id
Unique basket ID
"B12345"
basket_products
An array of product objects that holds product information of current products in the basket
Described in section Data Layer Product Array
order_id
Unique order ID
"O12345"
order_amount
Total value of the order, without tax and without shipping fee
123.45
order_amount_ati
Total value of the order, all tax included and without shipping fee
234.56
order_amount_ati_with_sf
Total value of the order, all tax included and with shipping fee.
345.67
order_discount
Total discount of the order without tax
12.34
order_discount_ati
Total discount of the order with tax
23.45
order_discount_code
Order discount or voucher code
"AB16887CDV883"
order_products
An array of product objects that holds product information of all ordered products on the product confirmation page
Described in section Data Layer Product Array
TagCommander recommends to structure lists of products (product_array, basket_products and order_products) via an array of JavaScript product objects:
Following you will find a list of recommended properties of each product entry:
Property
Description
Example
product_id
Product ID—usually internal ID
"12345"
product_id_variation
Product ID variation—usually SKU
"2345"
product_name
Product name
"My product"
product_name_variation
Product name variation
"My other product name"
product_unitprice
Product unit price without tax
12.34
product_unitprice_ati
Product unit price with tax
23.45
product_discount
Discount amount without tax
1.23
product_discount_ati
Discount amount with tax
2.34
product_cat1_name
Product top category name
"smartphones"
product_cat2_name
Product category name
"apple"
product_cat3_name
Product sub category name
"iphone"
product_cat1_id
Product top category id
"1234"
product_cat2_id
Product category id
"2345"
product_cat3_id
Product sub category id
"3456"
product_qty
Product quantity
5
Coming soon ...
