JENTIS Tags - Server-, Client- and Hybrid-Modes

At heart JENTIS is a server side technology. From the beginning of the first prototypes back in 2016 we designed every component to enhance server side execution, be it a server runtime for pixels (TWIN browser) or the capacity to persist data server side per each user. Though that does not concludes that all of our components must run on server. Many roots of our framework are grounded in client side components, too. With many requirements that arise from frontend capacities we support most data schemes that are found in online marketing today. Lets look into the different runtimes JENTIS offers for your data flows.

Tag, Tool and Data Runtimes

To privacy, security and availability of data (ie. third party cookies) the runtime is key. If you execute the same data stream (HTTP based) from a server to server that will have different header and meta (user agent, IP address, etc) parameters than when the same request is send from the client to the receiving server. That impact is one of our backbones in data privacy and security architecture. At the same time it affects your data flows with JENTIS and your desired tools.

For that reason all data streams to all tools we have in our list (JTM Tools) support different schemes. In general we have three groups:

client side: tags are executed on the device (browser) of the website visitor - C2S (Client to Server) communication
server side: tags are executed on the server (JENTIS) - S2S (Server to Server) communication
hybrid: tags are build server side but executed on the device (browser) of the website visitor: C2S (Client to Server) communication

Not all tools support ALL three schemes - it is also bound to what a tool provider supports as a receiver. In some cases some tools are specifically designed not to receive data in S2S communication.

Here is a short summary of the benefits, strengths and drawbacks of each of this three modes:

Feature	Client Side	Server Side	Hybrid
Full Data Privacy and Security Control	❌	✅	❌
Control of Third Party Applications (loading external JS sources is restricted)	❌	✅	✅
Enhances Website Performance (Speed)	❌	✅	✅ (to a certain extent)
Server Side Data Persistence (all variables available)	❌	✅	✅
Server Side Functions (anonymization, pseudonymization of fields and values)	❌	✅	✅
Data Enrichment	✅	✅	✅
Third Party Data Exchange (ie. third party cookies)	✅	❌	✅

Here comes a short description of all three options with JENTIS.

Client Side Tags (C2S - Client to Server)

Those tags will execute frontend, on the clients (website visitors browser) device. Impacting the website performance and also possibly introducing third party libraries (JS files) to his sources on the website.

Additionally all communication of data (beacons and other signals) will use HTTP POST or GET to the third party. Exposing the IP address and other HTTP header fields of the client to the receiver (server) of the third party.

Some restrictions apply when it comes to availability of components when tags for client side are configured. For example you can not use server side variable values for those configurations, also the transformation functions (such as anonymization or pseudonymization) are not available.

Server Side Tags (S2S - Server to Server)

Those tags will be executed on the JENTIS server runtime. They fully profit of the data privacy and security of the JENTIS architecture. You are in full control of what data will be transmitted to the third party.

Additionally you can use all components in the JENTIS framework (server side variables, transformation functions for anonymization and pseudonymization, server side data persistence and enrichment).

Further two methods of S2S are available in individual tags with JENTIS:

Twin-Server Native Implementation: in this mode a third party library is executed on the JENTIS server and operation is mimicking the original execution same as it would on a client side (though, executed on a server and not on a users device).

Protocol Based Implementation: in this mode JENTIS will leverage a documented API from the provider (the receiver of the data) and send data accordingly, ie. following a Measurement Protocol with Google Universal Analytics.

Hybrid Tags

Those tags are similar to client side, but have all advantages of server side tags. Let's have a look at the process of the data flow here.

Data is first collected on the users device and send to the JENTIS server. There the final data stream is built (with all capabilities of JENTIS server, just as with Server Side Tags). After this computation the data to be sent to the receiver is again forwarded back to the client, which will execute the beacon call. Which in turn will now also activate the capabilities of client side executed data streams (ie. third party cookies).

However that also again has the drawback of client side tags: the stream is from client to server (third party). Which means that again the IP address and other HTTP header fields of the client will be exposed to the third party.

Some technical details on this communication to add:

The stream from client to server is asynchronous. So there is a constant pull from the client to the JENTIS server to get back new streams to execute. That is a /commands request you may note in the network protocol after installing JENTIS to your website. This constant pulling is enabled for the here described communication for hybrid tags.

This streams however will only be used when mandatory - as when a tag is to be executed in hybrid mode. If you do not implement any hybrid tags JENTIS will not install the according pulling service to save resources on your site.