Frontend Variables
  • 31 Mar 2022
  • 4 Minutes to read
  • Contributors
  • Dark

Frontend Variables

  • Dark

Values and properties that are accessed or received on the frontend (Website; Web browser environment scope) are considered Frontend Variables in JENTIS Tag Manager. So in that context the frontend is defined as the web application in the runtime of a clients (website visitors) web browser. With JTM you can access all those properties with frontend variables where each variable has an evaluated (static) value per state. This concept is described in more detail in this section. The first step is to define the type of variable and create that frontend variable.

Frontend Variable Types

JENTIS Tag Manager provides multiple types to select from. You can have a convenient form where you just define a parameter name to read the value from, or you can chose to write your own JavaScript function to return a certain value.

Currently supported frontend variable types:

  • 1st Party Cookie:
    Will read a value from a defined cookie name. Source is the document.cookie browser API.
  • JTM Data Layer Value:
    A value to be read from a certain document property that was pushed via _jts.push API function call. Following the general data schema of JENTIS Data Layer, a property is always to be read from a certain object (pageview, product, order, etc). Read more here: JENTIS Data Layer fundamentals reference.
  • GTM Data Layer Parameter:
    Read a value from the Data Layer that is defined in context of many Google Tag Manager implementations. Where the default is a global window.dataLayer object and a value can be read in that array.
  • JavaScript Function

More types will be defined in the future and thus the list may vary.

As those types have all individual configurations we will look in more details on how to configure the most common types individually in the creation process.

Use Cases of Frontend Variables

Frontend variables are a super capable functionality of JTM, here you can access anything frontend that is required for your tracking. This can be anything from clicked element, html attributes of tags or dataLayer parameter values. Some of this examples are described in detail here.

Frontend Variable Creation Process

Here is a short description on parameters and their meaning for the configuration. Only the most common ones are covered.

A frontend variable has the following generic properties:

  • Name: This is the value that will appear in the selection in a Tag configuration, here you should use a descriptive name.
  • ID: This is a technical reference that can be used to reference a trigger explicitly as this ID is unique per JTM account.
  • Description: Feel free to give a Frontend Variable a description to later better understand the motivation to this variable.
  • Scope: Any Fronend Variable will be accessible in the JENTIS Data Model (Document Objects). Here you can select which document object (based on JENTIS internal data model – please see: JENTIS Data Layer fundamentals reference) will be associated with this variable. It will affect the persistency of the value, as user and session values are persisted according to their name. Event scope will make the frontend variable value accessible only on its associated event and not available in later use.
All frontend variables share some common properties, like name, id, group, etc.

To create a Frontend Variable you will need to navigate in JTM to the Data Sources area. Here you can create a new frontend variable or edit an existing one.

Navigate to Data Sources > Variables and click the “+”-icon to create a new element.

JENTIS Data Layer Variable

Select this variable type to read a value that is supposed to be pushed via _jts.push API.

Following the fundamental JENTIS data model syntax you have a structure of a document (object) and its property (parameter key).

In example:

  "track"   : "product",
  "name"    : "product A",
  "my_prop" : 42
  "track"   : "product",
  "name"    : "product B",
  "my_prop" : 0

To read the value of my_prop as of this example the required configuration is:

  • Property key: “my_prop”
  • Document name: “product”
  • Occurrence pointer: first / last

To make the difference on “Occurrence pointer” clear we have chosen this example where the same document (“product”) has multiple entries (product A and product B by name). If you select “first” the Occurence pointer will control the return value to get the first instance pushed (returns 42). Contrary the occurrence pointer value “last” will result in a return value “0” in this example.

GTM Data Layer Parameter

The global dataLayer is a generic object structure that holds information on many websites. These you can access with a frontend variable of “GTM Data Layer Value”-type.

In example:

  "event"   : "a",
  "my_prop" : 42
  "event"   : "b",
  "my_prop" : 0

To read the value of my_prop in this example the required configuration is:

  • Parameter name: “my_prop”

Optional parameters:

  • Datalayer name: Default “dataLayer” but you can configure this to listen to a different Datalayer object (on window scope).
  • Event name: Empty on default but can be used to define a certain event value (ie. “gtm.init”) to only return the value from a certain event in dataLayer.
  • Occurrence pointer: Select if you would like to return the first or last occurrence of the parameter, if multiple parameters of that key are found. In the previous example “first” will return “42” and “last” will return “0”. The order is defined by the array (dataLayer) and order of events pushed. Where “last” is the most recent data pushed to the dataLayer.

Custom JavaScript Function Variable

With this template you can define a custom JS function that is executed in the frontend to resolve a value.

Make sure to always use this syntax:

  return "hello world!";

Do not use HTML text or tags in this field, as only JavaScript is allowed!

Was this article helpful?