JENTIS States Framework

Events and data interweave like bread and butter. One can not go without the other. Every data point that describes an observation must be logically linked to some interaction (or: observation of such). In this article we will look deeper into what and why events are so important in tracking. And how JENTIS has internal concepts like JENTIS States to give you all the options to connect to your individual environment on a website.

Page Lifecycle, Events and JENTIS Data Layer

JENTIS State is an event-driven data model architecture. Hence why often JENTIS States and events are used synonymously. But there are also very important differences which we must cover in this in depth article.

Browsing a website is a concept we all can relate to - but what does that technically mean exactly? There is a thing often described as the page lifecycle in the web developer community. Events that mark this life of a page often referenced are such as "DOMready" or "on page load" (more on that on MDN: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/Events ).

With JENTIS you can connect to any event or simply talk to an API to give instructions. Those are two completely different concepts. Let's have a closer look into what both mean.

The most resilient way to connect JENTIS to your data is to actively push data to the JENTIS Data Layer (more on that topic: JENTIS Data Layer Fundamentals). With that approach you will not only push descriptive data (product name, page title, etc.) but also commands (events, tracking signals to invoke a State like pageview, virtual pageview, productview, etc). We highly recommend to implement JENTIS using this approach with an aligned up tracking map, that displays all requirements and parameters. However that is not the only option in practice.

As we already covered in the first paragraphs, there are also signals and data that can be picked up on the fly. Meaning during the lifecycle and on certain events. Those can be any interactions of the user or other applications submitting data to a generic (non JENTIS flavor) data layer.

In the following articles we have covered popular examples and use cases for events translated into JENTIS States:

• Listen to (Google Tag Manager) Data Layer Events: Listen to Datalayer Events

• Clicks, Form Submits and Scroll Tracking: Form Submit, Click and Other Actions

• History Change States (Virtual Pageviews): History Change State and Virtual Pageviews

JENTIS States Architecture

Now that we better understand the both options: push actively data AND/OR listen to page lifecycle events. We can now again zoom out on the topic and have a little bird view on the architecture.

Both implementation types (pushing or listening) will create a JENTIS State. Yes - the default push of events, pageviews, etc. is just the same in the internal framework. We will treat both options equally in the architecture.

Following up on the JENTIS States are the triggers. As a JENTIS State is activated (as the event is called or the push submitted) all variables and triggers will be evaluated. And this is where the tags can now be activated - so it is a logical chain of events. As in the following diagram:

So on each JENTIS State all variables and triggers are evaluated, meaning each variable can have only one static value on a single JENTIS State (that will not change as all triggers and tags are activated accordingly in that moment). Which will make sure all tags that are activated on that JENTIS State will actually have the same parameter value. And on a different moment (ie. when a button is clicked on that same page that was loaded seconds ago) the variables will again be evaluated, but could have a different value (as it might get updated, as the presentation on the website changes during loading).

For better understanding here is a table that should present the situation:

What this table displays is that a value of any variable is dynamically calculated in context of a JENTIS State. In that example a web application submits data before the DOM ready signal. At that moment the "Price Tag" is not rendered yet and has no value (undefined). A couple of milliseconds later the price appears on the screen and is available on the following moments (DOM ready, Button Click). So if you'd want to track the price tags value, you must configure your tags to activate on a JENTIS State and according trigger.

JENTIS States, Variables and Scopes of Data

This final chapter is about individual data that you are accessing on operation of a JENTIS State: JENTIS Tag Manger Variables. Which are elements describing an individual dimension of data (ie. "Page Title", "Product Name" or "Event Category").

A variable returns a value of a given property. Following the previous example the "Page Title" variable value of this article is "JENTIS States Framework". Easy, right? But what about the scope of this data, what can I access and at which time and/or event (JENTIS State)?

There are two types of variables that are very different when it comes to JENTIS States: actively pushed values (JENTIS Data Layer values) that are event driven and pulled values (that are accessed from a global scope, ie. document.title).

Pushed variables

All data that is bound to a context (the actual event) is available as it occurs with the event. Here are the most common types of variables that are context-based:

• JENTIS Data Layer variables:
  This values are provided in a _jts.push function call when submitted (via _jts.push track:submit call or whenever a track:event is automatically submitted)

• Click Variables:
  This values are only available when an according click happened (ie. clicked elements class, click text, etc), as those values only exist in context of that action.

• GTM Data Layer values:
  This variable is a hybrid, it can either access the dataLayer and simply point to the earliest/latest observed value (at the moment a JENTIS State was submitted or the according action happened), which works then works like a pull-variable; but you can also examine a dataLayers event object as it is pushed (object by object) and not iterate it to find a value, read more on the topic of contextual JENTIS State objects. (currently the contextual-dataLayer option is not implemented yet but in beta testing)

Pulled variables

• Custom JavaScript Variables:
  Every variable of this type will be computed at the given JENTIS State.

• URL Parameter-, Cookie-, JavaScript Variable-value (and all other):
  Every time you reference a global property in the frontend of a browser it will be accessed on the moment of the JENTIS State. If a value changes or is updated between two states always the currently available value will be used. 

• Constants:
  All constants are treated the same way as all the other pulled variables, as their values are always available to be pulled in a JENTIS State.

• GTM Data Layer values:
  Just as mentioned in push-variables, this variable can access the dataLayer by pulling values that were available at the moment of a given JENTIS State. If a value is not pushed yet when the event occurred you might run into data inconsistencies, read here more on the race condition phenomenon: https://jsremote.jobs/tutorials/race-condition/

Server-side variables

All variable values that are computed on the server side are treated same as pulled variables. They must not be explicitly pushed, but they have one special property.

Server-side variables are computed for each tools tag execution customly. So even when executed on the same JENTIS State a single server-side variable can have a different value than when examined in context of a different tool. This is because the read and write operation with server-side local storage (see: Serverside Functions Reference) is persisting values in context of the tool. Data is by default not shared between tools on the server.

Examples of State and Variable Combinations

Now lets put all into practice one more last time. To see what and how variable values might differ on possible JENTIS States.

All events appear on the same page (website) with no reloads and navigation, all in the same scope.

dataLayer = [{
  event:"gtm.init",
},{
  event:"pageload"
}]

_jts.push({
  track:"pageview"
});
_jts.push({
  track:"submit"
});

dataLayer = [{
  event:"gtm.init",
},{
  event:"pageload"
}]

dataLayer = [{
  event:"gtm.init",
},{
  event:"pageload"
},{
  event:"gtm.click"
}]

_jts.push({
  track:"event",
  name:"my event"
});

dataLayer = [{
  event:"gtm.init",
},{
  event:"pageload"
},{
  event:"gtm.click"
}]