JENTIS Tags: Server-side, Client-side and Hybrid
JENTIS is a server-side tracking platform with every component designed to enhance server-side execution. However, that does not mean all our components must run on the server. Many roots of our framework are also grounded in client-side components. With many requirements arising from front-end capacities, we support most data schemes found in online marketing today. However, JENTIS recognizes the need for client-side tracking in a few specific cases and allows maintaining client-side tags, supporting most data schemes from current online marketing practices. In this article, we will talk about the different tags available on the JENTIS Platform - server-side, client-side, and hybrid.
Tag, Tools, and Data Runtimes
JENTIS offers different runtimes for your data flows. A runtime is a framework or setup that defines where and how the data processing occurs and is key to privacy, security, and data availability (i.e., third-party cookies).
If you execute the same data stream (HTTP-based) from a server to a server, it will have different header and meta (user agent, IP address, etc.) parameters than when the same request is sent 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.
Therefore, all data streams to the tools we have in our list 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 built 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 these three options
Feature | Client Side | Server Side | Hybrid |
|---|---|---|---|
Full Data Privacy and Security Control | ❌ | ✅ | ❌ |
Control of Third-Party Applications | ❌ | ✅ | ✅ |
Enhances Website Performance (Speed) | ❌ | ✅ | ✅ (to a certain extent) |
Server-Side Data Persistence | ❌ | ✅ | ✅ |
Server-Side Functions | ❌ | ✅ | ✅ |
Data Enrichment | ✅ | ✅ | ✅ |
Third-Party Data Exchange | ✅ | ❌ | ✅ |
Here is a short description of all three options with JENTIS.
Client-Side Tags (C2S - Client to Server)
Those tags will execute on the front end of the client's (website visitor's browser) device, impacting the website performance and possibly introducing third-party libraries (JS files) to their sources on the website. Additionally, all data communication (beacons and other signals) will use HTTP POST or GET to the third party, exposing the client's IP address and other HTTP header fields to the third party's receiver (server).
Some restrictions apply to the availability of components when tags for the client side are configured. For example, you can not use server-side variable values for those configurations, and 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 from the data privacy and security of the JENTIS architecture. You completely control what data will be transmitted to the third party. Additionally, you can use all the 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 the operation mimics the original execution the same as it would on the client side (though executed on a server and not on a user's 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, i.e., following a Measurement Protocol with Google Universal Analytics.
Hybrid Tags
Those tags are similar to client-side tags but have all the advantages of server-side tags. Let's examine the data flow process here:
Data is first collected on the user's device and sent to the JENTIS server. There, the final data stream is built with all the capabilities of the 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. This will, in turn, activate the capabilities of client-side executed data streams (e.g., third-party cookies).
However, this also has the drawback of client-side tags: the stream is from the client to the server (third-party), which means that, again, the client's IP address and other HTTP header fields will be exposed to the third party.
Some technical details on this communication:
The stream from client to server (C2S) is asynchronous. So, there is a constant pull from the client to the JENTIS server to get new streams back to execute. That is a /commands request you may note in the network protocol after installing JENTIS on your website. This constant pulling is enabled for the previously described hybrid tags' communication.
These streams, however, will only be used when mandatory, such 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.
Read Next
If you have any questions or suggestions, contact us through our Helpdesk.