Architecture Guideline - Push OR Pull

JENTIS has a unique approach to a new architecture that will soon be the standard best practice. We are talking about first-party tracking, also known as server-side tracking. In this quick guide, we show you the fundamental principles of how JENTIS elements work and what are the differences in approaches that share the same architecture but are different in the core.

The two main implementation basics are “push” and “pull”. You can provide data directly into your JENTIS Server from the frontend (PUSH). The other option is to access available data from your frontend elements (such as an existing Data Layer or other HTML elements, Browser APIs, etc.) (PULL).

Push Data

With this approach, you will be able to create a custom tracking map that meets your requirements. Based on your own requirements, all data is provided from your website application in a structured way.

We already covered the most basic and first call you might add: “track:pageview” and “track:submit” commands. See: JENTIS Code Snippet.

This approach is recommended for all JENTIS clients - because:

• it is more resilient on updates on your website, as the code is integrated natively, and updates will be picked up and not left behind on migration and updates

• all communication is orchestrated in a single point of control (following the MVC coding principle)

• no race conditions and less complexity in the tag management

Pull Data

Advanced tag manager users might decide to pull data from the website where JENTIS is embedded and running already.

Pulling data from a website refers to the configuration to read data from existing data layers or other structured objects on a website (HTML, JavaScript objects and properties, cookies, etc). This approach is an agile way to implement and get JENTIS dashing. You need fewer resources for your dev team - which is a short-term benefit. With implications on long-term maintenance, it has its downsides, too.

This approach should only be considered as a second option - because:

• it is an agile way to integrate but less resilient, as you create dependencies that are possibly not documented or unknown to developers on the website

• you must understand the core principles of JENTIS first: the JENTIS Data Layer, States, and all Tag Manager Elements (Tags, Triggers)

Websites can choose to directly communicate via _jts.push API or customize the JTM to directly map required variables/parameters to existing elements, such as a Data Layer object. Here are all elements of this graphic explained:

• _jts.push: This is the primary API to JENTIS. Simply push data following the JENTIS native data model (as in reference: JENTIS Data Layer Fundamentals). This way all tags and trigger will work automatically and out of the box for ALL tracking partners (Facebook, Google Analytics, etc.). JENTIS implements a tool and service agnostic approach, so you only use one single data syntax and JENTIS internally translates your products, enhanced eCommerce interactions, etc. directly into the syntax of the tools (such as Facebook Conversion API).

• JTS Data Layer: An internal data format of JENTIS that follows the basic principles of document objects (such as products, events, sessions, users, etc).

• Frontend Variables: Here all values are actually calculated and will be used with the tags, trigger, backend functions and variables later. The frontend variables are the user interface to conveniently access values that you may already have integrated and structured (such as in a dataLayer object or in HTML tags).

• JTS Native Data Model: This powerful data model is a single data stream approach that can be mapped to any tool and use case. It supports both, simple and complex objects (such as Arrays of Objects with individual properties). So there is no technical limitation to any use case you could have in mind.

The following concepts stand out with JENTIS when it comes to frontend (client side) implementation:

• JENTIS is a tool-agnostic single source of truth system, there is only one single data stream where all data is lined up, without specific business logic in the front end

  • benefit: less customization required as everything is tool-agnostic in the frontend

  • benefit: every tool on the server side will run plug&play without further customization

• JENTIS has a rich data model that caters all common use cases (ecommerce-, content-, custom-dimension- and event-tracking)

  • benefit: tool implementation concepts are cooked down to the essentials, with less ressources required from your internal IT to implement tool-specific requirements

• JENTIS has a direct communication interface, the _jts.push() API, as well as a tag management system for customization

Next Steps

Now that we have the JENTIS up and running and our tracking map lined up to cater our requirements. Let's further dive into PUSHing data: JENTIS Data Layer Fundamentals.

Or do you feel more agile and advanced? Then maybe the following guide is for you - to migrate from an existing Data Layer on your website and Listen to Datalayer Events.