Skip to main content
Skip table of contents

Architecture Guideline: Push or Pull Data

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 front end (PUSH) or access available data from your front-end elements, such as an existing Data Layer or other HTML elements, Browser APIs, etc. (PULL).

Push Data

This approach allows you to create a custom tracking map that meets your requirements. Based on your own requirements, all data from your website application is provided 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 to 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).

  • It avoids race conditions—when two operations are done simultaneously when they should be done in sequence—and reduces the complexity of 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. However, 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 before doing this: the JENTIS Data Layer, States, and all Tag Manager Elements (Tags, Triggers).

JENTIS_Docs_PoP (1).jpg

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

  • _jts.push(): This is the primary API to JENTIS. Simply push data following the JENTIS native data model - see the reference in JENTIS Data Layer: Push Data. This way, all tags and triggers will work automatically and out of the box for all tracking partners, like 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, and others, 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 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 you may already have integrated and structured, such as in a dataLayer object or 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 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 front-end (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. This means:

    • Less customization is required as everything is tool-agnostic in the front end;

    • Every tool on the server side will run plug-and-play without further customization.

  • JENTIS has a rich data model that caters to all common use cases (e-commerce, content, custom dimensions, and event tracking). This means tool implementation concepts are cooked down to the essentials, and fewer resources are required from your internal IT to implement tool-specific requirements.

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

Read next

For more information about Push Data, read JENTIS Data Layer: Push Data.

For a more advanced topic, learn how to migrate from an existing Data Layer on your website: Listen to Datalayer Events.


If you have any questions or suggestions, contact us through our Helpdesk.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.