An overview of the

Tracking code Manager is a code management system that can easily update code and code snippets on mobile applications when they are triggered, and complete “dynamic” management of third-party SDK code or custom code logic in the case of pre-buried points.

For example, add and update third-party SDK code or custom code such as Google Analytics through TagManager without modifying the application code. This reduces errors and eliminates the need to ask developers for help when configuring your code.

The basic concept

Basic concepts that a TagManager must understand, such as containers, code, data layers, triggers, and variables.

To put it simply, a company can create multiple containers by registering an account. For example, an Android application corresponds to a container, which mainly contains codes (tags), triggers, macro variables, etc.

The container

For Android, the container is a binary configuration file provided to the SDK (with an exported JSON file), which the SDK can use to process. The SDK can also get the latest configuration file from the server to replace the current local file.

By getting containers, developers can get the value of the macro variable that dynamically gets the set value type, process the parameters that replace some of the preset macro variables, such as app ID, and also get container-related information.

code

Code refers to a piece of code that sends information to a third-party SDK. If you are not using a code management solution such as a trace code manager, you need to add these code snippets directly to the files of your mobile application. With TagManager, instead of maintaining each code snippet in the source code file, you can specify the code you want to fire, and when you want it to fire, in the trace code manager interface.

For The Android end, the code is to specify the information of calling the third-party SDK. For example, when the tag product can be set as Google Analytics, the Tracking ID and Tracking type (equivalent to the event type triggered by the SDK) need to be configured for the third-party SDK. For example, specify the app View event.

The code effect is to transfer the events that we need to do after embedding the third-party SDK to the TagManager, without explicitly calling the third-party SDK code. The advantages of this are as follows:

  • The tagManager only needs to implement a trigger action, which reduces the code implementation of calling multiple SDKS. It is equivalent to unified code management and avoids repeating multiple SDK calls.

  • The background can dynamically configure the code. After obtaining the new container configuration, the client will parse the configuration file according to the new code and rules, change the timing of the action and the specific parameters of the method to call the third-party SDK, and realize the “dynamic” configuration (on the basis of burying points first).

  • When it is convenient to replace the supported third-party SDK later, the project code can not be changed (in the third-party SDK supported by TagManager, there is no need to explicitly call the third-party SDK trigger code), of course, all the premise is to bury the point.

The trigger

First, to be clear again: The TagManager does not reduce the number of buried points, the buried location is still the same, but the original method of calling the third party SDK trigger events is transferred to the TagManager, which is equivalent to the third party SDK proxy (in fact, the later data layer implements the data mapping).

A trigger, simply speaking, is a set of condition rules that trigger behavior, and the behavior that meets the condition will be triggered. This is also one of the “dynamic” aspects of a TagManager. That is, before the user action can fire the code, it must meet the condition rules set by the trigger, which are contained in the container configuration file retrieved from the back end.

A “trigger” is a condition that evaluates to “true” or “false” at run time. It is evaluated by comparing the value of a “variable” with the value specified when defining triggers that are attached to code to control when the code fires or does not fire.

Tagmanager variables are configured name-value pairs whose values are populated at run time. Tagmanager has many built-in variables, and you can also configure custom variables.

For example, the predefined variable “URL” always contains the URL of the currently loaded web page. If you want to only for web example.com/purchase/receipt.html trigger code, so you need to define the rules:

Event: Web browsing

Trigger type: Web browsing

Trigger condition: some web browsing

Trigger code when the result of the following condition is “true” :

Url contains example.com/purchase/receipt.html

You can define variables (multiple macro type variables) according to your needs, each containing some information that needs to be used at run time. You can then use these variables in trigger conditions or pass information to code through them.

Common trigger conditions:

| | conditions

| : — — — — — – : |

Contains | |

| to |

| to | endings

| | matches a regular expression

| match the regular expression (case) |

Less than | |

| less than or equal to |

| greater than |

| is not equal to |

| does not contain |

The beginning is not | |

Not | | end

| | regular expressions don’t match

| with regular expressions don’t match (case) |

Macro variables

Variables in tagManager have fixed type matches.

  • AD tracking enabled: For Android, this variable returns true if AD tracking is enabled, or false if the user chooses to disable ads targeted to the user’s interests. Learn more in the Android Developer Center. SDK versions prior to V4 will always return false. For iOS 6 and higher, the value is set to advertisingTrackingEnabled properties. Otherwise, the value is set to true. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Application ID: This value is set to the package name (Android) or bundle ID (iOS). Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Application Name: This value is set to the name of the currently running application. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Application Version: This value is set to the version of the currently running application. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Constant: This value is set to the supplied string.

  • Container ID: The value is the container’s public ID (such as GTM-ABC42). Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Container version number: When the container is in preview mode, this variable value is the preview version number of the container. In other cases, this variable value is the actual version number of the container. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Device ID: For Android, set this value to the device ID. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Device Name: This value is set to the device name of the currently running application (for example, Samsung Android, Android SDK Built for x86). Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Event name: This value is set to “eventNameXYZ” when executing the following code in the application:

Android:

FirebaseAnalytics.getInstance(mContext).logEvent("eventNameXYZ", null);

Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Event parameter: This value is set to the Firebase Analytics event parameter value recorded for the given key.

  • Firebase User Properties: This value is set to the Firebase Analytics user properties value for the given key.

  • Function call: This value is set to the value returned by calling pre-registered functions. Refer to the SDK documentation (Android or iOS) for details.

  • ID for ads: For Android, this value is set to the AD ID. Learn more in the Android Developer Center. SDK versions prior to V4 will always return “(empty string).

  • Language: This value is set to a two-letter language code that represents the device language set by the user. A predefined variable of this type is provided in the mobile application container; there is no need to define a new variable of this type.

  • Comparison table: This value is set according to the description in the comparison table. The comparison table contains two columns (the table below does not contain any data, and the usage of data is described below) :

Operating system version: Set this value to the operating system version on which the application is installed. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Platform: This value is set to the platform (for example, Android) on which the currently running application belongs. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Random number: This value is set to a random number between 0 and 2147483647. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Screen resolution: Set this value to the screen resolution of the device on which the application is currently running. The format is < width > X < height >, for example, 1024×768. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • SDK version: Set this value to the SDK version of the operating system on which the application is installed. Built-in variables of this type are provided in the mobile application container; there is no need to define new variables of this type.

  • Operating system version: Set this value to the operating system version on which the application is installed.

  • Platform: This value is set to the platform (Android or iOS) on which the application is currently running. A predefined variable of this type is provided in the mobile application container; there is no need to define a new variable of this type.

  • Random number: This value is set to a random number between 0 and 2147483647.

  • Screen resolution: Set this value to the screen resolution of the device on which the application is currently running. The value is in the width x height format, for example, 1024×768. A predefined variable of this type is provided in the mobile application container; there is no need to define a new variable of this type.

  • SDK version: Set this value to the SDK version of the operating system on which the application is installed. A predefined variable of this type is provided in the mobile application container; there is no need to define a new variable of this type.

Data layer mapping

The data layer is an object that configures the information you want to pass to the TagManager. This requires configuring data layer variables to capture these values for later use. To have the TagManager evaluate the values of the data layer variables, the system must also push events, using push to do this.

In Android, the data layer maintains an event queue. Developers push a map object containing key-value to add it to the queue. When push receives an object with key=event, the event content in the queue will be extracted and match the trigger rule conditions in the container. The two correspond to trigger the corresponding code logic. Therefore, the data layer contains the event map objects pushed by the developer, the data layer variable information configured in the container, and so on.

Google TagManager example in action

Get the data layer object in the project code with getDataLayer(). You can use push or pushEvent methods to pass data to the data layer

As shown in the figure above, using pushEvent(object) is equivalent to pushing (“event”,object), which means that a key = “event” is pushed to the data layer. Value = “openScreen” and a map object set with key = “screen-name” and value = “test Page”. These data layer variables are mapped to Google Analytiecs as triggered parameters.

Let’s take a look at how Google Tagmanager works

Create a variable

Create a data layer variable screen-name as the key passed into the data layer map. The name must be consistent with the project code. Note that screen name2 is only used to manage interface operations.

Create a variable of type constant to hold the Tracking ID of Google Analytiecs

Create trigger

  1. Trigger openScreen: Triggered when the Event value of the data layer variable in Event of the management interface equals openScreen

  1. Trigger TestScrenn: Triggered when the value of the data layer variable screen-name in the management interface variable Screen name2 is equal to test Page

Create code Tag

Take a look at the overall effect of the configuration

Select the product type of the management code, Google Analytiecs is selected here, and then configure tag related information, such as tracking ID required by GA, and the event type triggered is App View. The screenName argument passed when the GA statistics method is triggered is replaced with the value of the data layer variable Screen name2. That is, the values of data layer variables are mapped to GA method parameters.

With automatic event tracking in TagManager, you can create event code directly in the TagManager interface instead of hard-coding each click action in the SEND (“event”, “category”, “action”, “label”) call ga. This code is then triggered using triggers based on predefined variables or custom variables that can be created in the TagManager interface.

Configure the code triggers by selecting the two previously configured triggers.

After all configurations are complete, click Save and click Publish to generate a new release.

Overall relationship renderings

The final data is mapped to Google Analytiecs by calling the data layer variables and methods configured by The TagManager. This process does not explicitly call the GA statistics code in the project code, but the data is still transferred to the GA.

Check the data at Google Analytiecs