Overview of TagCommander Setup Guides per platform.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Installation Instructions for TagCommander on AMP.
Accelerated Mobile Pages (AMP) use the Server-Side version of TagCommander.
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/
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 (https://www.ampproject.org/docs/reference/components/amp-analytics) 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. To learn more about server-side set up please read the following article (https://community.commandersact.com/fr/introduction-au-tracking-server-side-avec-tagcommander/).
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
Installation Instructions for TagCommander for direct HTTP connections.
It is possible to communicate with TagCommander container via a HTTP API (e.g. for IOT and TV apps).
See "Serverside" setup guide for more details.
IOT & TV apps use the Serverside version of TagCommander.
Installation Instructions for TagCommander with AngularJS.
TagCommander 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.
AngularJS uses the Client-Side version of TagCommander.
Installation Instructions for TagCommander with Angular.
TagCommander 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 Angular.
Angular uses the Client-Side version of TagCommander.
How to condition tags to user consent
Commanders Act provides a Consent Management Platform (CMP) to easily manage the consent https://www.commandersact.com/en/solutions/trustcommander/ https://community.commandersact.com/trustcommander/
If you already use your own CMP, you can of course manage the way your tags will be triggered through your own CMP setup.
The recommended way is to attached a custom trigger to each of your tags and to manage this trigger inside your CMP to launch or not launch tags depending of the user's consent.
Warning : some part of TagCommander code is not inside tags, see below how to manage consent on custom code or core code
If you have written custom javascript code and/or internal variables that create cookies or send data, you'll have to link this code to your CMP. Of course it will depend of your CMP method, but the recommended way is to wrap your custom code with a conditional instruction (if) that will manage your CMP API or to embed it in a trigger that will be triggered by your CMP.
TagCommander contains also core code that is not accessible through the interface. There is one core feature that could put cookies and needs to be manage in your CMP through the management of one global variable : window.tc_disable_cookiesync
Usage : set this variable to true if the user doesn't give his consent
You have to set this variable to false or not set the variable when the user gives his consent
Installation Instructions for TagCommander on Android.
TagCommander offers dedicated Plug-Ins for all major native App platforms. Please refer to the SDK documentation on GitHub for detailed installation instructions for Android.
Android uses the Server-Side version of TagCommander.
TagCommander’s SDK allows you to trigger tags from a mobile application.
Commanders Act offers a so-called “super light” SDK you can include in your mobile app’s code; its purpose is to reduce calls to partner solutions as much as possible in order to improve your app’s performance and user experience. A unique call is issued to TagCommander’s servers the moment the app’s screen is displayed or than an element on the screen is clicked. Information related to the page browsed or the element that is clicked is then sent separately to partner solutions by TagCommander’s servers; this allows to prevent applications’ loading speed from slowing down.
Note: Not all solutions are compatible with this method. Since the light SDK sends app information to partner solutions’ servers, they cannot “go back” to the app. Adserving solutions (those displaying adverts) and push notification providers are thus not compatible with this method.
The basic operational principle of TagCommander’s light SDK is:
– Step 1: the mobile data layer and TagCommander’s SDK are called in the app’s source code every time the screen loads or that an element is clicked. (your IT staff should have implemented this at the start of the project).
– Step 2: TagCommander’s SDK issues calls to TagCommander’s servers and automatically sends the mobile data layer’s contents. This is the server-side hits’ structure:
https://serverside$siteID$.tagcommander.com/$containerID$/
$siteID$ and $containerID$ : TagCommander site and container ID. Variables in the mobile data layer are sent to TagCommander’s servers wit a POST method (i.e. in the https request’s head).
– Step 3: TagCommander’s servers send the received information to the different partner solutions. There are as many outgoing hits as there are partner solutions you wish to send information to.
Ex: if you wish to issue a call to both Criteo and Google, a hit will be sent to either solution’s servers.
Implementing TagCommander on a mobile application is a project that consists of the steps listed hereunder:
Definition of the mobile application’s tagging plan: selection and definition of internal and external variables.
Creation of a mobile container and configuration of tags within the TagCommander interface.
TagCommander SDK implementation in the app’s source code.
Acceptance testing of the implementation in a test environment.
Publishing (+ container updates)
The tagging plan corresponds to the list of variables that will populate the app. There are two types:
External variables, present within the app’s source code and programmed by technical staff.
Internal variables calculated within TagCommander’s SDK (mobile variables), or on TagCommander’s servers (server-side variables).
Both external and internal variables need to be declared in the interface beforehand (this is usually done by a Commanders Act consultant).
Mobile Data Layer: external variables
Mobile external variables are declared by your IT staff in the application’s source code and sent automatically to the servers by TagCommander’s SDK.
You can use these external variables to populate mobile tags or to create rules to execute them.
To learn more about external variables and steps to declare them in the interface please click here.
Mobile Data Layer: internal variables
Mobile internal variables are automatically calculated by TagCommander’s SDK or servers. You can use these variables to populate mobile tags or to create rules to execute them.
Mobile internal variables are reunited in the interface options’ “Server-side” > “Internal Variables” tab.
You will find, among the predefined internal variables, some that are calculated by TagCommander’s servers (“Server-side”) and designed for iOS (“iOS”), Android (“Android”) or both (“Mobile (iOS + Android)”). Click the blue “Add predefined variables” button (1) to access them and select a predefined universe (2):
Mobile (iOS + Android): internal variables that are automatically calculated by the SDK and designed for both systems.
TC_IP: the device’s IP address; it is only available if it is connected to the internet. (ex: “10.144.112.50”)
TC_LANGUAGE: the device’s language and location (ex: “fr_FR”)
TC_SYSNAME: the device’s operational system’s full name (ex: “Android-4.2.2” / “iPhone OS”)
TC_SYSVERSION: the device’s operational system’s version (ex : “4.2.2” / “8.4.1” for an iPhone 4s)
TC_MODEL: the device’s model (ex: “Nexus 7” for a Nexus 7; “A0001” for a OnePlus One, “GT-I9305” for a Galaxy S3, “iPhone” for an iPhone 4s)
TC_CONNEXION: connection type (ex : WIFI)
TC_DEVICE: name given to the device by the device’s owner (ex: “flo”)
TC_SCREEN: the device’s screen resolution (ex: “1920×1104” for a Galaxy Tab 3, “320×480” for an iPhone 4s)
TC_CHARSET: the device’s default character encoding method (“UTF-8” for a OnePlus One, “MacRoman” for an iPhone 5)
TC_CURRENCY_CODE: the device’s default currency code (ex: “EUR”, “CAD”)
TC_CURRENCY_SYMBOL: the device’s default currency symbol (ex: “&dollar”, “&euro”)
TC_APPLICATION_VERSION: the device’s application version allowing to run Commanders Act’s SDK (ex : “42.2.12”)
TC_APPLICATION_PREVIOUS_VERSION: The application’s previous version’s number whenever available (ex: “42.2.10”, blank otherwise)
TC_APPLICATION_BUILD: the application’s build number (ex: iPhone 5: 2.3 / Nexus 7: 1536)
TC_TAGCOMMANDER_VERSION: TagCommander’s SDK version in the following format: “version.release-date”
TC_MANUFACTURER: name of the device’s manufacturer (ex: “Apple”, “Samsung”)
TC_USER_AGENT: the device’s web browser’s user agent
TC_JAILBROKEN: jailbroken device (= “1”) or factory settings (= “0”)
TC_APPLICATION_STARTS: Number of the application’s cold starts. Cold starts correspond to the app’s first launch after a system reboot or whenever the app is closed and relaunched
TC_FOREGROUNDS: number of times the app is running in the foreground
TC_FOREGROUND_TIME: amount of time during which the app is open in the foreground (milliseconds)
TC_DELTA_FOREGROUND_TIME: time frame between the current time and date and the last time the app was opened in the foreground (milliseconds)
TC_BACKGROUND_TIME: amount of time during which the app runs in the background (milliseconds)
TC_DELTA_BACKGROUND_TIME: time frame between the current time and date ad the last time the app was running in the background (milliseconds)
TC_BACKGROUND_UX_TIME: amount of time during which the application runs in the background while interactive content is served to the user (milliseconds)
TC_DELTA_BACKGROUND_UX_TIME: time frame between the current hour and the last time the app ran in the background while interactive content was being served to the user (milliseconds)
TC_CURRENT_CALL_MS: time stamp of the hit’s generation (milliseconds)
TC_LAST_CALL_MS: time stamp of the previous hit’s generation (milliseconds)
TC_LAST_SESSION_LAST_HIT_MS: time stamp of the last hit registered during the last session (milliseconds)
TC_NOW_MS: Unix Time stamp (milliseconds)
TC_IDFA: Id of Google or Apple-served ads
TC_IS_TRACKING_ENABLED: indicates whether tracking is accepted on the device (YES/NO)
TC_LIMIT_USER_TRACKING_ENABLED: limited tracking on the device (YES/NO)
TC_LONGITUDE : user’s longitude if geolocation is authorized
TC_LATITUDE: user’s latitude if geolocation is authorized
TC_BUNDLE_IDENTIFIER: Id of the app’s batch allowing Commanders Act’s SDK to run
TC_APPLICATION_NAME: Name of the app allowing Commanders Act’s SDK to run
TC_RUNTIME_NAME: Device type (ex: Android / iOS)
TC_FIRST_VISIT_MS: time stamp of the app’s first launch (milliseconds)
TC_LAST_VISIT_MS: time stamp of the last visit’s start (milliseconds)
TC_CURRENT_SESSION_MS: time stamp of the current session (milliseconds)
TC_CURRENT_VISIT_MS: time stamp of the current visit (milliseconds)
TC_SESSION_DURATION_MS: current session’s length (milliseconds)
TC_VERSION_FIRST_VISIT_MS: for the app’s current version, it is the first time stamp of the first session following an app update (milliseconds)
TC_NUMBER_VISIT: number of times a user opened the app
TC_NUMBER_SESSION: number of sessions created in the app
TC_IS_FIRST_VISIT: whether it is the first time the app is launched (= “TRUE”) or not (= “FALSE”)
TC_FIRST_EXECUTE: the first time a developer executes the app with the execute() or SendData() functions after the latter is launched (= “TRUE” or “FALSE”). This variable can be combined with the TC_IS_FIRST_VISIT variable to retrieve the very first hit sent the first time the app was launched.
***
Android: internal variables calculated automatically by the SDK and specific to Android.
TC_UNIQUEID: random 64-bit number generated when the user sets-up the device for the first time. It remains the same throughout the device’s lifetime.
Creating a container for mobile applications
TagCommander’s SDK issues calls to TagCommander’s servers: you therefore have to create a “server-side” technology-based container for your mobile applications.
Please note: you can use a single server-side container for both the iOS and Android versions of your apps.
To learn more about how to create a server-side container, see serverside user manual.
Implementing tags on mobile apps
Implementing mobile tags is the same as implementing server-side tags (see serverside user manual)
The SDK implementation is performed by technical staff or IT departments.
These elements must be provided:
The app’s TagCommander tagging plan, which lets IT staff know which variables to declare and on which screens or elements.
Technical documentation referring to each and every app. It must contain elements that are key to setting up the SDK and screenshots of setup examples.
Click here to read the corresponding technical documentation for Android: https://github.com/TagCommander/Android/blob/master/TCSDK/README.md
The site’s ID (Commanders Act account number) and that of the server-side container, which are necessary to set-up the SDK. These two elements can be retrieved in the container’s options section: click the “container options” icon (1) and copy the site (2) or container ID (3)
TagCommander’s SDK can be tested with many different tools:
TagCommander’s SDK for iOS can be tested with developing software “Android Studio”: https://developer.android.com/studio/index.html
In order to test your app, connect your Android phone to your PC.
Open the “Android Studio” app > Click “Start a new Android Studio project”. Click “Next” while on the following screens until you reach the main one called “Android Monitor”.
Then select your Android device (1) and choose the app you wish to test from the list (2).
To speed up tests, type “TagCommander” into the search engine (3).
These elements will be displayed when you analyze mobile logs (4):
TagCommander SDK’s version number: “Commanders Act SDK init with version: VERSION_NUMBER”
TagCommander’s site and container number: “SDK init with siteID SITE_ID and CONTAINER_ID
A list of the external variables that were provided by technical staff and that are visible in Android Studio, thanks to this function “TCLogLevel_Debug”: “Tag Commander Executing with appVars : AppVars : {#VARIABLE#: VALUE}”
Server-side hit containing variables sent to TagCommander servers (POST method). You will see internal variables first, followed by external variables): “sending: http://serversideSITE_ID.tagcommander.com/CONTAINER_ID/ With POST data: VARIABLE=VALUE&VARIABLE=VALUE…”
***
TagCommander’s SDK for both iOS and Android operating systems can be tested with the “Charles Debugger” proxy, downloadable for free here: https://www.charlesproxy.com/
The first thing to do is to configure your phone so it can communicate with Charles.
In your phone’s settings, go to the Wi-fi configuration tab.
Select your network and proceed to the advanced options to edit Wi-fi settings.
Add a proxy manually:
Proxy’s name (server)(1): Computer’s IP (you can find it in the “Local IP address” tab from Charles’ options)
Port (2): 8888
Save.
Go to the Charles app and authorize it to connect to the phone.
Browse the web with your phone and in Charles (on your computer) apply a “TagCommander” filter to see server-side hits displayed in the “Overview” section. They look like this: http://serversideSITE_ID.tagcommander.com/CONTAINER_ID/
When you go to the “Request” area, you will be able to see all variables and the corresponding values that are sent through the TagCommander SDK.
HTTPS Protocol:
Most of the time, server-side calls are issued through an https protocol.
Seeing https hits with Charles requires a more complex configuration. You will need to open your phone’s browser while Charles runs on your computer and go to this URL on your phone http://www.charlesproxy.com/getssl/
Download the certificate and install it; you will need to enter its name for two applications “VPN and applications” and “Wi-fi”.
Go back to Charles > “SSL proxy settings” > “SSL Proxying” > check “Enable SSL Proxying” > Click “Add” and type “*” in the “Host” field (to authorize any given host).
Then proceed to running tests the same way you do for http hits.
When the implementation is ok on your testing environment, you need to submit your app to app stores (Apple Store or Android Market) and wait for them to approve changes and include the new version in their catalogues.
This is a one-time procedure you will not need to repeat. This is because TagCommander’s SDK is available on JCenter for Android and Cocoapods for iOS, allowing developers to include a link leading to the latest version of TagCommander’s SDK in the applications.
To learn more about JCenter and Cocoapod, please refer to this content:
JCenter for Android : https://github.com/TagCommander/Android
Cocoapods for iOS : https://github.com/TagCommander/pods
Installation Instructions for TagCommander with React.
React uses the Client-Side version of TagCommander.
Installation Instructions for TagCommander with React Native.
Our React Native plugin is currently deprecated. This page will be uploaded as soon as a new GitHub page will be released.
Server-side tracking allows triggering tags directly on your website(s) and calling them from your servers.
Main benefits of this type of tracking include:
Site performance improvement (tags are no longer called/triggered by the site itself)
Increased security (Commanders Act or partner solutions can no longer interact with the websites, drop cookies, etc…)
Possibility to monitor data collected by Commanders Act and sent to partners.
Server-side tracking operates as follows :
Step 1 : Your servers (clients’ servers) display the webpage a user is browsing and call Commanders Act’s servers simultaneously. Your IT department shares information of your choice with TagCommander through server-side variables (present in the server-side datalayer).
Server-side calls issued by your IT team to Commanders Act look like this :
http://serverside$siteID$.commandersact.com/$containerID$/?variable1=value1&variable2=value2…
$siteID$ and $containerID : Commanders Act site and container identifiers.
variable1, variable2: names of server-side data layer’s variables (ex: ProductID, UserID, Order Amount…)
They are called “incoming hits” or “input hits”.
Step 2: Commanders Act sends the received information to the partners’ servers. These hits are called “outgoing hits” or “output hits”. There are as many outgoing hits as there are partner solutions you wish to send the information to.
Ex: if you wish to call Criteo and Google; a hit will be sent to Criteo’s servers and another one to Google’s.
“Hybrid server-side” refers to an implementation method combining browser and server-side technologies.
It consists in retrieving web data (ex: cookies, variables …) and storing it on Commanders Act servers for 24 hours, in order to provide third-party solutions with information present in both the servers and the customer’s Website.
Main benefits:
Enhanced website performance (most tags are no longer called on web pages but on the server-side)
Data that can only be obtained on websites (cookies, certain variables) still can be collected and sent to partner solutions from the servers.
Hybrid server-side operates as follows:
Step 1: a Commanders Act tag present in the web container collects data on the website and stores it on TagCommander servers for 24 hours. A matching key allowing to associate information collected on the website with that present on the servers needs to be defined.
This key thus has to be retrievable both on the website and on the servers (example of reconciliation keys: User ID, Basket ID).
Example: you wish to obtain on your website the order ID and the cookie value of one your partner solutions. Your reconciliation key is the User ID. The Commanders Act tag will collect information in this way:
Step 2: Server-side hits sent to partner solutions will be enriched with information collected through web containers. Thank to this reconciliation key, data from the website and the servers correlates.
Installation Instructions for TagCommander on iOS.
iOS uses the Server-Side version of TagCommander.
TagCommander’s SDK allows you to trigger tags from a mobile application.
Commanders Act offers a so-called “super light” SDK you can include in your mobile app’s code; its purpose is to reduce calls to partner solutions as much as possible in order to improve your app’s performance and user experience. A unique call is issued to TagCommander’s servers the moment the app’s screen is displayed or than an element on the screen is clicked. Information related to the page browsed or the element that is clicked is then sent separately to partner solutions by TagCommander’s servers; this allows to prevent applications’ loading speed from slowing down.
Note: Not all solutions are compatible with this method. Since the light SDK sends app information to partner solutions’ servers, they cannot “go back” to the app. Adserving solutions (those displaying adverts) and push notification providers are thus not compatible with this method.
The basic operational principle of TagCommander’s light SDK is:
– Step 1: the mobile data layer and TagCommander’s SDK are called in the app’s source code every time the screen loads or that an element is clicked. (your IT staff should have implemented this at the start of the project).
– Step 2: TagCommander’s SDK issues calls to TagCommander’s servers and automatically sends the mobile data layer’s contents. This is the server-side hits’ structure:
https://serverside$siteID$.tagcommander.com/$containerID$/
$siteID$ and $containerID$ : TagCommander site and container ID. Variables in the mobile data layer are sent to TagCommander’s servers wit a POST method (i.e. in the https request’s head).
– Step 3: TagCommander’s servers send the received information to the different partner solutions. There are as many outgoing hits as there are partner solutions you wish to send information to.
Ex: if you wish to issue a call to both Criteo and Google, a hit will be sent to either solution’s servers.
Implementing TagCommander on a mobile application is a project that consists of the steps listed hereunder:
Definition of the mobile application’s tagging plan: selection and definition of internal and external variables.
Creation of a mobile container and configuration of tags within the TagCommander interface.
TagCommander SDK implementation in the app’s source code.
Acceptance testing of the implementation in a test environment.
Publishing (+ container updates)
The tagging plan corresponds to the list of variables that will populate the app. There are two types:
External variables, present within the app’s source code and programmed by technical staff.
Internal variables calculated within TagCommander’s SDK (mobile variables), or on TagCommander’s servers (server-side variables).
Both external and internal variables need to be declared in the interface beforehand (this is usually done by a Commanders Act consultant).
Mobile Data Layer: external variables
Mobile external variables are declared by your IT staff in the application’s source code and sent automatically to the servers by TagCommander’s SDK.
You can use these external variables to populate mobile tags or to create rules to execute them.
Mobile Data Layer: internal variables
Mobile internal variables are automatically calculated by TagCommander’s SDK or servers. You can use these variables to populate mobile tags or to create rules to execute them.
Mobile internal variables are reunited in the interface options’ “Server-side” > “Internal Variables” tab.
You will find, among the predefined internal variables, some that are calculated by TagCommander’s servers (“Server-side”) and designed for iOS (“iOS”), Android (“Android”) or both (“Mobile (iOS + Android)”). Click the blue “Add predefined variables” button (1) to access them and select a predefined universe (2):
Mobile (iOS + Android): internal variables that are automatically calculated by the SDK and designed for both systems.
TC_IP: the device’s IP address; it is only available if it is connected to the internet. (ex: “10.144.112.50”)
TC_LANGUAGE: the device’s language and location (ex: “fr_FR”)
TC_SYSNAME: the device’s operational system’s full name (ex: “Android-4.2.2” / “iPhone OS”)
TC_SYSVERSION: the device’s operational system’s version (ex : “4.2.2” / “8.4.1” for an iPhone 4s)
TC_MODEL: the device’s model (ex: “Nexus 7” for a Nexus 7; “A0001” for a OnePlus One, “GT-I9305” for a Galaxy S3, “iPhone” for an iPhone 4s)
TC_CONNEXION: connection type (ex : WIFI)
TC_DEVICE: name given to the device by the device’s owner (ex: “flo”)
TC_SCREEN: the device’s screen resolution (ex: “1920×1104” for a Galaxy Tab 3, “320×480” for an iPhone 4s)
TC_CHARSET: the device’s default character encoding method (“UTF-8” for a OnePlus One, “MacRoman” for an iPhone 5)
TC_CURRENCY_CODE: the device’s default currency code (ex: “EUR”, “CAD”)
TC_CURRENCY_SYMBOL: the device’s default currency symbol (ex: “&dollar”, “&euro”)
TC_APPLICATION_VERSION: the device’s application version allowing to run Commanders Act’s SDK (ex : “42.2.12”)
TC_APPLICATION_PREVIOUS_VERSION: The application’s previous version’s number whenever available (ex: “42.2.10”, blank otherwise)
TC_APPLICATION_BUILD: the application’s build number (ex: iPhone 5: 2.3 / Nexus 7: 1536)
TC_TAGCOMMANDER_VERSION: TagCommander’s SDK version in the following format: “version.release-date”
TC_MANUFACTURER: name of the device’s manufacturer (ex: “Apple”, “Samsung”)
TC_USER_AGENT: the device’s web browser’s user agent
TC_JAILBROKEN: jailbroken device (= “1”) or factory settings (= “0”)
TC_APPLICATION_STARTS: Number of the application’s cold starts. Cold starts correspond to the app’s first launch after a system reboot or whenever the app is closed and relaunched
TC_FOREGROUNDS: number of times the app is running in the foreground
TC_FOREGROUND_TIME: amount of time during which the app is open in the foreground (milliseconds)
TC_DELTA_FOREGROUND_TIME: time frame between the current time and date and the last time the app was opened in the foreground (milliseconds)
TC_BACKGROUND_TIME: amount of time during which the app runs in the background (milliseconds)
TC_DELTA_BACKGROUND_TIME: time frame between the current time and date ad the last time the app was running in the background (milliseconds)
TC_BACKGROUND_UX_TIME: amount of time during which the application runs in the background while interactive content is served to the user (milliseconds)
TC_DELTA_BACKGROUND_UX_TIME: time frame between the current hour and the last time the app ran in the background while interactive content was being served to the user (milliseconds)
TC_CURRENT_CALL_MS: time stamp of the hit’s generation (milliseconds)
TC_LAST_CALL_MS: time stamp of the previous hit’s generation (milliseconds)
TC_LAST_SESSION_LAST_HIT_MS: time stamp of the last hit registered during the last session (milliseconds)
TC_NOW_MS: Unix Time stamp (milliseconds)
TC_IDFA: Id of Google or Apple-served ads
TC_IS_TRACKING_ENABLED: indicates whether tracking is accepted on the device (YES/NO)
TC_LIMIT_USER_TRACKING_ENABLED: limited tracking on the device (YES/NO)
TC_LONGITUDE : user’s longitude if geolocation is authorized
TC_LATITUDE: user’s latitude if geolocation is authorized
TC_BUNDLE_IDENTIFIER: Id of the app’s batch allowing Commanders Act’s SDK to run
TC_APPLICATION_NAME: Name of the app allowing Commanders Act’s SDK to run
TC_RUNTIME_NAME: Device type (ex: Android / iOS)
TC_FIRST_VISIT_MS: time stamp of the app’s first launch (milliseconds)
TC_LAST_VISIT_MS: time stamp of the last visit’s start (milliseconds)
TC_CURRENT_SESSION_MS: time stamp of the current session (milliseconds)
TC_CURRENT_VISIT_MS: time stamp of the current visit (milliseconds)
TC_SESSION_DURATION_MS: current session’s length (milliseconds)
TC_VERSION_FIRST_VISIT_MS: for the app’s current version, it is the first time stamp of the first session following an app update (milliseconds)
TC_NUMBER_VISIT: number of times a user opened the app
TC_NUMBER_SESSION: number of sessions created in the app
TC_IS_FIRST_VISIT: whether it is the first time the app is launched (= “TRUE”) or not (= “FALSE”)
TC_FIRST_EXECUTE: the first time a developer executes the app with the execute() or SendData() functions after the latter is launched (= “TRUE” or “FALSE”). This variable can be combined with the TC_IS_FIRST_VISIT variable to retrieve the very first hit sent the first time the app was launched.
***
iOS: internal variables calculated automatically by the SDK and specific to the iOS.
TC_MODEL_AND_VERSION: Phone’s model and version depending on the device’s code.
TC_IDFV: Unique Id per solution
Creating a container for mobile applications
TagCommander’s SDK issues calls to TagCommander’s servers: you therefore have to create a “server-side” technology-based container for your mobile applications.
Please note: you can use a single server-side container for both the iOS and Android versions of your apps.
To learn more about how to create a server-side container, see serverside user manual.
Implementing tags on mobile apps
Implementing mobile tags is the same as implementing server-side tags (see serverside user manual)
The SDK implementation is performed by technical staff or IT departments.
These elements must be provided:
The app’s TagCommander tagging plan, which lets IT staff know which variables to declare and on which screens or elements.
Technical documentation referring to each and every app. It must contain elements that are key to setting up the SDK and screenshots of setup examples.
The site’s ID (Commanders Act account number) and that of the server-side container, which are necessary to set-up the SDK. These two elements can be retrieved in the container’s options section: click the “container options” icon (1) and copy the site (2) or container ID (3)
TagCommander’s SDK can be tested with many different tools:
TagCommander’s SDK for iOS can be tested with Apple’s developing software “XCode”:
You will need to connect your iPhone to your Mac.
Open XcOde, go to “Window” ), > “Devices” (2), then select ypur device in thecolumn to the left (3):
These elements will be displayed when you analyze mobile logs:
TagCommander SDK’s version number: “Commanders Act SDK init with version: VERSION_NUMBER”
TagCommander’s site and container number: “SDK init with siteID SITE_ID and CONTAINER_ID”
A list of the external variables that were provided by technical staff and that are visible in XCode, thanks to this function “TCLogLevel_Debug”: “Tag Commander Executing with appVars : AppVars : {#VARIABLE#: VALUE}”
***
The first thing to do is to configure your phone so it can communicate with Charles.
In your phone’s settings, go to the Wi-fi configuration tab.
Select your network and proceed to the advanced options to edit Wi-fi settings.
Add a proxy manually:
Proxy’s name (server)(1): Computer’s IP (you can find it in the “Local IP address” tab from Charles’ options)
Port (2): 8888
Save.
Go to the Charles app and authorize it to connect to the phone.
When you go to the “Request” area, you will be able to see all variables and the corresponding values that are sent through the TagCommander SDK.
HTTPS Protocol:
Most of the time, server-side calls are issued through an https protocol.
Download the certificate and install it; you will need to enter its name for two applications “VPN and applications” and “Wi-fi”.
Go back to Charles > “SSL proxy settings” > “SSL Proxying” > check “Enable SSL Proxying” > Click “Add” and type “*” in the “Host” field (to authorize any given host).
Then proceed to running tests the same way you do for http hits.
When the implementation is ok on your testing environment, you need to submit your app to app stores (Apple Store or Android Market) and wait for them to approve changes and include the new version in their catalogues.
This is a one-time procedure you will not need to repeat. This is because TagCommander’s SDK is available on JCenter for Android and Cocoapods for iOS, allowing developers to include a link leading to the latest version of TagCommander’s SDK in the applications.
To learn more about JCenter and Cocoapod, please refer to this content:
TagCommander offers dedicated Plug-Ins for all major Single Page Application (SPA) frameworks. Please refer to the Plug-In for detailed installation instructions for React.
If you need to do a setup urgently, you can use our & GitHub, the setup remains with the same approach, but you'll be must to change the languages of the code examples
TagCommander offers dedicated Plug-Ins for all major native App platforms. Please refer to the for detailed installation instructions for iOS.
To learn more about external variables and steps to declare them in the interface please click .
Click here to read the corresponding technical documentation for iOS:
Server-side hit containing variables sent to TagCommander servers (POST method). You will see internal variables first, followed by external variables): “sending: With POST data: VARIABLE=VALUE&VARIABLE=VALUE…”
TagCommander’s SDK for both iOS and Android operating systems can be tested with the “Charles Debugger” proxy, downloadable for free here:
Browse the web with your phone and in Charles (on your computer) apply a “TagCommander” filter to see server-side hits displayed in the “Overview” section. They look like this:
Seeing https hits with Charles requires a more complex configuration. You will need to open your phone’s browser while Charles runs on your computer and go to this URL on your phone
JCenter for Android :
Cocoapods for iOS :
Reconciliation key (user_id) | order_id | cookie_vendor1 |
123456 | 1234FR | A |
567489 | 34565FR | A |
346658 | 56456FR | B |
… | … | … |
Installation Instructions for TagCommander with VueJS.
TagCommander 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 VueJS.
VueJS uses the Client-Side version of TagCommander.
Installation Instructions for TagCommander on Websites.
It is necessary to implement one or multiple Container and optionally a Data Layer and event Trigger to install TagCommander on a website.
Websites use the Client-Side version of TagCommander.
A TagCommander Container is a version-controlled JavaScript file that bootstraps the tag management system functionality on a website. To implement and update Tags, users will generate new versions of the Container JavaScript file.
To implement TagCommander it is necessary to implement one or multiple TagCommander JavaScript Container files on the website. The URL of each JavaScript Container file will be provided alongside the Container IDs and Container Names by a Commanders Act Consultant during the setup process. Here you can find an overview of common Container setups.
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. TagCommander differentiates two types of Container to define whether the Container should be placed in the <head>
or in the <body>
section of the HTML document.
<head>
Container<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<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 implement JavaScript Container files with JavaScript loaders like RequireJS or HeadJS. On the opposite it is not possible to bundle the JavaScript Container files with bundlers like Webpack or ParcelJS to make sure that the Container files are dynamically loaded from the CDN or server on each page request. Otherwise users will not be able to manage TagCommander Container on their own.
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 TagCommander Container.
Following you will find an example object including its most relevant information:
The Commanders Act Assistant Chrome Extensions shows all loaded Container files on a page including their version and other information.
A TagCommander Data Layer is a JavaScript object that holds metadata of a website as properties to make it available to Tags. In TagCommander this Data Layer is named "External Variables" to distinguish it from scripted "Internal Variables" that are generated within the Container JavaScript.
To install a TagCommander 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 TagCommander setup process, but you can find a list of common properties here.
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 TagCommander 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.
Following example outlines how a Data Layer can be installed in case both a <head>
and a <body>
Container are used on a website.
As outlined in the example above the properties of the Data Layer are usually grouped with a prefix notation. E.g. env_
is used to group environment information and user_
is used to group user information.
In case a property is not relevant for a certain page (e.g. product_name
on the privacy policy page) it is recommended to fill it with an empty value (e.g. ""
, 0
, []
or {}
).
It is possible to investigate the Data Layer in the JavaScript console by logging tc_vars
.
Following you will find an example output of a tc_vars
Data Layer in the JavaScript Console.
The Tag template Commanders Act - Data Layer QA in the TagCommander Tag library automatically outputs Data Layer information to the JavaScript console on each page. This approach has the advantage that it logs a snapshot of the Data Layer at the exact time the Container JavaScript was executed. This allows to identify race conditions between the Data Layer properties and the Container JavaScript to make sure all necessary properties are available in time.
The Commanders Act Assistant Chrome Extensions shows the Data Layer properties of the currently visited page.
TagCommander Triggers are onsite events that are used by TagCommander users to dynamically execute Tags.
TagCommander allows to set up common Trigger automatically without the involvement of technical personnel (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 TagCommander setup process, but you can find a list of common Trigger here.
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:
A common approach for the Trigger Data Layer is to always use the same properties like event_label
, event_type
and event_value
—so in case of an add_to_basket
Trigger the event_value
would hold the product id of the selected product and in case of a video_play
event the event_value
would hold the current position within the video timeline. This allows to avoid to create multiple custom variable names for each individual event and therefore makes Trigger more generic.
In some situations it might happen, that a user interacts with a custom Trigger before the TagCommander JavaScript Container file was loaded. In this case using the Trigger function would cause a JavaScript ReferenceError
. Therefore it is recommended to check the availability of the Trigger function before using it.
The Tag template Commanders Act - Data Layer QA in the TagCommander Tag library automatically outputs 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.
Metric
Description
Container ID
Unique ID of the Container within your account. e.g. 21
Container Name
Label for the Container. Can be configured in the Options of TagCommander. e.g. "Header Container"
Container Filename
Name of the Container JavaScript file, can be configured in the Options of the TagCommander interface. e.g. "tc_header_21.js"
Container URL
Complete URL of the Container used for installation. Depends on the hosting method. e.g. "//cdn.tagcommander.com/1234/tc_footer_main_20.js"
Container Version
Snapshot of a Container JavaScript file.
Metric
Description
Trigger Label
Label for an event that is used by TagCommander users to execute Tags. e.g. add_to_basket
Trigger Data Layer
A JavaScript object that can be accessed by Tags that are executed on the related Trigger. e.g. product_id