JENTIS Data Layer Fundamentals

There are two tag management integration principles: PUSH or PULL data. You have the option: do you want to make your website actively push data to your tag management system (JENTIS)? Or do you want to configure your JENTIS tag management to simply pull parameters from your website? To better understand the first option (PUSH) here you will find all you need to know. That is fundamental to get the integration started. Find more details on the push and pull principles here.

JENTIS will track a lot of data automatically (basic parameters and browser APIs are all there). Pushing data actively is only required when there is something dynamically coming from your Content Management System or any other information system (product data, user data, etc). Some of this additional data must be transferred manually. And you can always chose to enhance the push with more arguments and values, the objects and models are made to be extended.

Syntax

The basic syntax of pushing data to JENTIS is to submit an object of key:value pairs to a predefined global scope array: window._jts

JavaScript

window._jts = window._jts || []; // you can go ahead and create this safety call to instantiate an empty array, if JENTIS is not yet loaded

_jts.push({
    "track"  : "<trackcommand>",
    "prop-1" : "<prop-1-value>",
    "prop-2" : "<prop-2-value>",
    "prop-n" : "<prop-n-value>"
});

There are reserved names in that object, that are treated special in the JENTIS data model:

• track – this property must be set with each _jts.push call and have predefined value, however those can be extended by further customization.

• type – that is a pointer of a track properties value to a certain dependency; this will be described below in more detail “Tracking dependencies and properties”

The push function call will add data to the JENTIS data layer. The data layer is holding all data so it can be all submitted to the server when an event occurs (a click, pageview or any other interaction in a web browser).

JENTIS Data Layer and Interactions

Whenever a relevant event occurs all the data must be submitted to the server. Now what is “all the data” and how to determine the correct moment to submit?

The basic idea is that you can add as much data and objects (pushed to the _jts API via push function calls) as you feel like. All data can be submitted in one push, or multiple push calls happen asynchronously.

Only when a certain track value is submitted to that API it will be all send to the server. That moment is defined as a STATE. So when pushing data you can always define the ‘when’ to activate the data transmission to the server side, by sending a “submit” or an “event” call.

JavaScript

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

JavaScript

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

It is either track: "submit" or track: "event" that will always pack all data submitted and translate into a state. Where all further actions will take place: transmission of data to the server side, checking triggers conditions and actually activate tags.

If you feel like creating a custom state, you can go ahead and create those, too. Which is all customizable.

Tracking dependencies and properties

There are different dependencies on tracking commands. In the previous section we learned about the both reserved properties “track” and “type”. Now there are important dependencies that you must know when working with that API.

Queue Based Dependencies

When multiple push function calls are submitted all data becomes available in that state. Pushing a pageview interaction and next a product (in context of that page, ie. as a “product detail view”) will make both objects available to work with. Additionally we must define in what context that product was part. Its property “type” references this information, in our example that is “detailview”.

This is what our queue of commands looks like:

JavaScript

_jts.push({
    "track"  : "pageview",
    "title"  : "Detailpage"
});

_jts.push({
    "track"     : "product",
    "type"      : "detailview",
    "name"      : "T-Shirt"
});

_jts.push({
    "track"     : "detailview"
});

Now we have a page, where a product was submitted with the type “detailview” and we also submit a track command for that type: “detailview”. With this queue we define what happend (a pageview and a detailview) and part of that detailview was a product. Hence the “type” is the same as the “track” command.

Making the product part of that interaction. This we call a queue based dependency, as the data is all part of one single queue (until that data is submitted in a State).

Finally you just need to call _jts.push({"track":"submit"}); – and off it goes to the server to handle the rest.

Track Command Based Dependencies

When pushing a certain track-command (ie. “event”, “pageview”, “product”, etc.) all properties of that push are related to that object. This is the command based dependency that we will look into more deeply here.

Now lets see what that means in practice, looking at those both examples:

JavaScript

_jts.push({
    "track"     : "pageview",
    "title"     : "Homepage"
});


_jts.push({
    "track"     : "product",
    "type"      : "listview",
    "name"      : "T-Shirt"
});

_jts.push({
    "track"     : "product",
    "type"      : "listview",
    "name"      : "Jeans"
})

The track command is a special operation. It defines what kind of object is pushed with it. Thus making all properties part of exactly that pushed object. So each object that should be tracked must be pushed separately, not as an array or list. Multiple products are pushed each one by one. And all properties pushed in that call are the properties of that single property.

Data submit

We already touched the topic several times: when will be the data submitted to the server? It always depends on the States, a function that defines the moment to start the tracking. There are several ways to activate this process.

Auto Sending

There are two track commands which send directly all previously pushed data to the server.

• submit

• event

Both calls are directly connected to a default state (jts_push_submit) that exists in all JTM accounts, where all default triggers are connected to.

Use the submit command

Every time you are done with pushing data to the JENTIS API (_jts) you should call the command submit. With this command you create a state and thus start the http(s) network stream to transmit the data to the JENTIS system sitting server side.

All other tracking commands has to be executed before the submit command. Otherwise they will not be picked up with that state.

JavaScript

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

Usage of the pushs second parameter

By handover true as second parameter while pushing something to the array, all the data which was so far pushed will be send to the server immediately. Creating the same state as with submit or event calls.

JavaScript

_jts.push({
    "track"       :"addtocart",
    "productid"   :"1234",
},true);

Data Reset

If you like to reset the JENTIS Data Layer manually, you can use the following command. You can use this functionality to reset the Data Layer within a state. The JENTIS Data Layer SEND State integrates this by default.

window.jentis.tracker.resetDatalayer()