# JENTIS Documentation JENTIS is the leading server-side tracking solution built for marketers, analysts, and data professionals who demand both performance and compliance. This documentation is your go-to resource for unlocking the full potential of the JENTIS platform—from powerful data collection capabilities to seamless integrations and privacy-first tracking. Let’s turn your data into a competitive advantage. Contact Us Quickstart ## Discover JENTIS


Resources & Product Updates	Find out more about recent Releases, Helpdesk and FAQ	/files/ryFI5Kjlicohg3WTRwsk	https://github.com/JENTISDev/publicDocs/blob/master/broken-reference/README.md	/pages/oveS31IwwNmBGTLosRaI
Introduction & Core Concepts	Get to know JENTIS, why and how to use it!	/files/YtZd3EVYiAPqNAWE1t5A		/pages/IEOzV1zllLvKQEpun5X3
Data Capture	Read more about: - Web Tracking Setups - Shop System Setups - App Tracking Setups	/files/I9689CREF6Uyf84vy5kB		/pages/9Vycma0dS2bQlgw8sFLz
Data Control	Read more about Data Enrichment, Privacy Features & Data Transformation	/files/bRpih0BRoVtlHgJJ4f3d		/pages/ffZgndYO50O7CwN1rrO3
Data Activation & Connectors	Find supported Connectors & Raw Data information	/files/4sGqHJvCOTWilC8hicai		/pages/iarRhq3ygI8TzsFAqGFY
Developer Guide	Technical implemenation guides for JENTIS	/files/C6BJPzV8sKKLTTleEiJZ		/pages/CodwtGRl48aW7MnfG2Wo
Consent Center	How does JENTIS handle consent on a technical level? Find our here!	/files/cmNnkCO1HzJyeSb78uRz		/pages/pWsvtL8NwzH2Qpq9hjaZ
Use Cases & Tutorials	Common use cases in the configuration of JENTIS.	/files/4KqpOHv4iz681idGURRU		/pages/GwLR3fZR38ip3QXek72J
Troubleshooting	Most common errors and how to fix them.	/files/HCWAhzyoeBnYXcGBQxu7		/pages/IXAxdRgacAzuat1cKNNh
Privacy Documentation	Read more about the legal aspects of JENTIS here.	/files/7T6U2z8fvSXP23vysIkB		/pages/vuLnsulDl8pGFkG23NSu

# Quickstart ## Getting Started with JENTIS: What You Need for a Successful Setup At JENTIS, we’re all about empowering your data strategy with next-generation server-side tracking. To ensure a smooth and effective onboarding, there are a few key steps required from your team. Don’t worry – we’ve made the process as streamlined as possible, and our experts are here to support you every step of the way. ### From Your IT Department To activate the full potential of JENTIS, your IT department will need to implement a few technical components. These are quick to set up and form the foundation of your JENTIS environment: **1.** [**JENTIS Snippet Implementation (Mandatory) \[max. 1-2h\]**](/data-capture/web-tracking-setup/install-the-jentis-web-tag)\ Our lightweight script needs to be embedded into your website to initiate data collection. This is the first and most crucial step to getting started. **2.** [**DNS A-Record Setup (Mandatory) \[max. 1-2h\]**](/getting-started/quickstart/make-tracking-first-party-set-your-dns)\ A DNS A-Record must be configured to route tracking requests through your own subdomain for optimal data accuracy and seamless server-side tracking. **3.** [**Cookie Lifetime Extender (Optional) \[max. 1 PD\]**](/key-features/cookie-lifetime-extender)\ Enhance tracking durability with our optional Reverse Proxy solution. This allows you to extend cookie lifetimes even in restrictive environments – perfect for privacy-conscious businesses seeking long-term data quality. ### From Your Tracking Team Once the technical base is in place, your marketing and tracking specialists can begin setting up the core elements of your tracking configuration within the JENTIS platform: **1.** [**Data Layer Bridge (1-2 PD)**](/developer-guide/data-layer/jentis-data-layer)\ Easily transition your existing setup by bridging your current data layer to JENTIS. This allows for a smooth migration of existing tags and tracking logic. **2.** [**Tool Configuration**](/getting-started/quickstart/create-a-new-tool) **&** [**CMP Integration (0,5h per Tool)**](/getting-started/quickstart/setup-consent-with-jentis-dcp)\ Set up your analytics and marketing tools, integrate Consent Management Platforms (CMPs), and configure Essential Mode for compliant data collection. {% hint style="success" %} At JENTIS, **fast and efficient tool creation** is one of our core competencies. Our platform automatically sets up the most common tags for your tools, reducing the need for manual configuration and eliminating time-consuming setup steps. This means that migrating the **basic tags** for your tools to JENTIS typically takes **just a few minutes** — allowing you to start tracking sooner and focus on what matters most: gaining insights from your data. {% endhint %} **3. Testing & Parallel Setup (1-3 weeks)**\ Run comprehensive tests to ensure everything works as intended. You can even run JENTIS in parallel with your current solution, minimizing risk and ensuring a seamless transition.

## We’re With You All the Way Our onboarding specialists will guide your teams through every stage – from initial snippet implementation to tool migration and live deployment. With JENTIS, you’re not just switching to a tag manager; you’re future-proofing your data infrastructure. {% hint style="info" %} The implementation time for JENTIS depends on the **size and complexity of your existing setup**.\ Factors such as the **number of tags** in use and the **volume of special events** you want to track can influence the timeline. Implementation can be completed very quickly for simpler setups. Larger, more complex configurations may take longer, but our team and partners ensure that even the most sophisticated tracking environments are migrated **smoothly and efficiently**. {% endhint %}

# Create Your Account In this page, you receive information about account and container creation within the JENTIS tool. Congratulations on becoming a JENTIS client! Once you sign the contract, your designated contact will inform our support team to create an account for your organization. **Accounts are isolated workspaces.** Items can’t be shared across accounts. **Containers**, created within an account, are the unit where tags, triggers, states, functions, and tools live—and **can be shared or reused across containers inside the same account**. ## Key Takeaways * **No cross-account sharing.** Treat accounts as separate entities. * **Container-level reuse.** Within a single account, reuse configurations across multiple containers. * **Subdomain strategy.** Most subdomain setups work cleanly with **one container**; you may still split by subdomain for organizational reasons. * **Identity continuity.** Multiple containers on the same domain/subdomains can share a user ID via the **Main Domain Cookie** (configurable). *** ## Common Scenarios & Recommended Setups ### 1) One site, multiple country domains **Example:** `example.at`, `example.de`, `example.ch`

*** ### 2) One site with a shop subdomain **Example:** `www.example.at` and `shop.example.at`

*** ### 3) Multiple owners (tenants) across different domains **Example:** Several independent stakeholders each responsible for their own domain(s).

*** Read more about Account Structure *** ### FAQs

Do I need multiple containers for subdomains?

\ No. Technically, most subdomain setups work well with **one container**. Split into multiple containers only if it helps your organizational workflows.

Can I share items across accounts?

No. Accounts are isolated. Share and reuse configurations **only within the same account**.

Will containers on the same domain share user IDs by default?

If the **Main Domain Cookie** is enabled, yes—containers on the same main domain and its subdomains will share a user ID. You can disable this per container to prevent sharing.

What if I operate different country domains?

Create **one container per domain** within **one account** and reuse shared configurations across those containers.

# Create Your First Container 1. To create a container, navigate to the Settings: Containers page and click "Add New Container" in the top right corner.

2. After this, you will need to name your container uniquely to differentiate it from others, and input the top-level domain on which you want to track with JENTIS. In the image below, you see an example domain being used for an example container.

3. You can specify which CMP you will be using for this container or do so at a later point in your implementation. Eventually, before publishing and going live, you will have to associate the container with at least one consent management solution. 4. After you click "Add" on the bottom right, the next step in your container creation is to display the DNS Address and the JENTIS JS Snippet.

Setting the DNS A-record for JENTIS and copying the JS code snippet onto your website´s code are two necessary steps to complete a container creation. You will not be able to publish any other changes with JENTIS until these two steps are complete. Typically, we recommend that our clients prioritize these tasks first and get these done within a week of receiving access to their JENTIS accounts. ## Tracking Verification and Container Status After you configure the DNS A Record and the HTML Code on your website, it will be automatically verified in up to 30 minutes. Alternatively, you can return to your container’s configuration and click on **Verify**. Next to your container’s name, you will find the status of your container: * If GREEN, the consent bar is selected, DNS A Record and HTML Code are verified, and the container is published. * If BLUE, the consent bar is selected, DNS A Record and HTML Code are verified, but the container is not yet published. * If GREY, at least one of the configuration steps (DNS A Record, HTML Code, or Consentbar) is not completed.

{% hint style="success" %} After creating your container and correctly configuring your DNS A Record and the HTML Code, make sure you publish your changes on the **Publish** menu. {% endhint %} ### Edit a Container {% hint style="warning" %} It is only possible to edit your container once the DNS A Record and HTML Code are verified. {% endhint %} You can easily edit your container’s configuration by going to your **Containers** menu and click on **Edit**:

You can change the following fields: ### **Basic Settings:** * **Container name** – A descriptive name for your container. * *Optional field:* **Consentbar (CMP)** – Select from the list of supported consent bars. {% hint style="info" %} Once the container is created, you can not change the **website domain**. {% endhint %} ### **Advanced Settings (Optional):** * **Preview URL**—For the container configuration preview session, set a custom URL instead of the website domain. If this field is left empty, the website domain configured in the basic settings will be used. * **Main Domain Cookie** — This feature allows you to configure whether first-party identifiers (e.g., JENTIS User-ID) are implemented at your website’s main domain or subdomain level in your containers. This enables the identification of users across the main domain and its subdomains. For more information, read [Main Domain Cookie](/key-features/main-domain-cookie). Once you change any of these fields, click **Save** and **Publish** your container again. ## How to Grow and Scale * To define the right number of containers on your account, please consider: * How many websites (domains) do you have? Are they similar in nature (same data, same requirements)? Can they be grouped where the requirements overlap (same tools with the same conversion goals)? * Do you want to split a single website (domain) into multiple sections (i.e., by subdomain)? Do they require separate management and have different requirements (e.g., different data, different tools, and different conversion goals)? * Once you consider these questions, you have some options to configure your containers: * **Multiple containers for one same domain**: We recommend that you use this option if your website has multiple subdomains with particular management requirements—different data, tools, and conversion goals.\ For example, on the main domain `example.com`, you have `shop.example.com` and `blog.example.com`. While the first has a clear purchase conversion type and an e-commerce structure, the second is a content website. You could configure one container for each of these. * **One container for the same domain and all its subdomains**: We recommend using this option if your website has multiple subdomains that share the same type of data, tools, and conversion goals.\ For example, your main domain, `example.com`, has the subdomains `de.example.com` and `at.example.com`. These are all e-commerce pages with the same structure and purchase conversion goal, just varying their language. You only need one set of configurations for these. * **One unique container per domain**: If you have different domains, you should configure one container for each one, as one container can not be used on multiple domains.\ For example, your company owns the websites `example.com` and `mycompany.com`. Each should be configured with a different container. **Remember**: A container can hold multiple configured tools; it can be the same tool (e.g., GA4) with two different instances. # Invite Your Team - User Permissions Welcome to our comprehensive guide on the access permissions of JENTIS. ### **Introduction** In today's digital age, understanding and effectively managing access permissions is crucial for maintaining the security and functionality of any product. This article is designed to provide a thorough overview of the various access permissions available within JENTIS. | Permission Group | Description | Restrictions | | ----------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | | ADMIN | The admin is the highest permission group a customer can have. | Cannot delete containers. | | ANALYST (default) | Currently, ANALYST/TRACKING/TECHNICIAN have the same rights and do not differ in any way. | Admin restrictions + cannot create/update/delete users. | | TRACKING | Currently, ANALYST/TRACKING/TECHNICIAN have the same rights and do not differ in any way. | Admin restrictions + cannot create/update/delete users. | | TECHNICIAN | Currently, ANALYST/TRACKING/TECHNICIAN have the same rights and do not differ in any way. | Admin restrictions + cannot create/update/delete users. | | REPORTER | A REPORTER can only navigate through the UI, can open the debug monitor, but cannot publish. | Cannot modify anything but can read everything | | READACCESS | A user with READACCESS can only navigate through the UI and cannot open the debug monitor. | Cannot modify anything + cannot open preview monitor | | RESTRICTED | A user with RESTRICTED is allowed to log into the JENTIS DCP, but can not navigate through the UI | Cannot navigate at all. | ### **Commitment to Continuous Improvement** At JENTIS, we believe in continuously enhancing our security features and access permissions. Our dedicated team regularly evaluates and updates our systems to address emerging security challenges and evolving user needs. This commitment to ongoing improvement means that users can always expect the most advanced and user-friendly access control options, designed to offer both robust protection and ease of use. We encourage feedback and suggestions from our users. # Install the JENTIS Tracking Snippet Integrating a JavaScript code snippet is necessary to begin collecting data with JENTIS on your website. We suggest inserting this code snippet as high as possible within the HTML head section of your website. This will create the optimal conditions for a stable and reliable data stream. {% hint style="info" %} Inserting the tracking code snippet directly on your website and not via third-party tools is essential. {% endhint %} {% hint style="warning" %} **Please do not copy/paste the following snippet or parts of it. The following code is just a visual example.**\ You will find your code in your JENTIS account (Containers -> Setup). {% endhint %} {% code lineNumbers="true" %} ```js // DO NOT COPY - JUST FOR VISUAL REFERENCE ``` {% endcode %} {% hint style="warning" %} You will find your exact JavaScript snippet by creating a new container or editing an existing one {% endhint %}

Placeholder	Description	Type	Example
<trackdomain>	Your JENTIS container DNS Domain. This will be replaced in your individual JTM container automatically when the code is generated in the UI.	string	hhd728ju.example.org
<filehash>	A unique identifier for a container source file. This will be replaced in your individual JTM container automatically when the code is generated in the UI.	string	hj8kds

## Testing If you have correctly set up the JENTIS tracking code snippet, you can find a network log entry (HTTP stream) in your browser's developer tools. The resource loaded looks like the following: ```none https://.example.at/.js ``` To ensure the JENTIS script is loaded correctly, the DNS A record must be set. For more information, read the article [DNS Setup](/getting-started/quickstart/make-tracking-first-party-set-your-dns). After these steps, the script will load and respond with a 200 status code. A secure connection can now be established, and your JavaScript is available. Your configuration will also be automatically verified within up to 30 minutes after you set up the JENTIS tracking code snippet on your website. Alternatively, you can return to your container’s configuration and click **Verify**. You can always check the status of your HTML Code on your containers' configuration:

## Start Tracking ### Implementing Pageview Tracking with JENTIS To start tracking with JENTIS, use the following JavaScript function calls. These commands enable automatic tracking whenever a page is visited. Add the following lines of code to your web application: ```javascript _jts.push({track: "pageview"}); _jts.push({track: "submit"}); ``` ## **Alternative Method** Alternatively, under the [Codes](/jentis-dcp-elements/codes) section, insert the code snippet as a custom element within your JENTIS account. This ensures that a pageview is tracked each time the basic JENTIS tracking code snippet is executed. *** If you have any questions or suggestions, contact us through our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1). # Make Tracking First-Party: Set Your DNS How to set the DNS A-record for JENTIS and your website. JENTIS is a first-party tool that becomes part of your main tool stack, just like your shop- or content management system. Therefore, you must grant it certain privileges that third parties would not have, which also indicates a higher level of data security and privacy. That means you must create a DNS entry for a particular subdomain on your hosting. This subdomain is the main communication channel JENTIS uses. To recognize hits from the same user (via first-party cookies) and send data to the JENTIS backend server side. A DNS A (Address) record maps a domain name to an IP address, allowing browsers and other devices to locate your server. ## **Why is an A-Record needed for JENTIS?** Adding the DNS A-Record to your hosting settings ensures that the tracking requests made from your website are correctly routed to the JENTIS server. Essentially, it enables communication between your website and JENTIS’s server-side infrastructure. Please access your DNS management console (usually provided by your hosting provider or domain registrar) and add the DNS settings informed in your JENTIS Account as explained below: ## Entries In preparation for the JENTIS implementation, you will find specific documentation in your account that looks like the following: {% hint style="danger" %} Example: do not use on productive systems! {% endhint %} | DNS Type | DNS Domain | IP Address | | -------- | ----------------- | --------------- | | A-RECORD | 123abc.myhero.com | 123.123.123.123 | Simply copy your individual settings from your JENTIS account to your hosting DNS entries and select "A RECORD" to define the details. You will find this information by creating a new container or editing an existing one:

Once you add the DNS A Record, we will automatically verify the configuration in up to 30 minutes. Alternatively, you can return to your container’s configuration and click on **Verify**. You can always check the status of your DNS Entry on your container’s configuration:

*** If you have any questions or suggestions, contact us through our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1). # Setup Your First Connector (GA4, Meta, etc.) You can find the connectors section at the top of the main navigation in your JENTIS Data Capturing Platform account. This is where you can manage instances of different connectors and services, such as Facebook, Google Ads, Google Analytics, and others. These connectors can be configured multiple times, which is useful if you need to set up multiple data recipients (such as Pixel or Property IDs) with a single provider.

Instances of connector configurations have properties that can be accessed in all tags associated with them. These properties are used for global configuration values, such as a property or account ID. In the context of Google Analytics, the Measurement ID (GA4) or the Property ID (UA-ID for Universal Analytics) is an example of such values. Additionally, you can define additional custom parameters that are required as global constants for your configuration. A connector configuration instance consists of the following settings: * **Name**: Give your connector instance a human readable and meaningful name. We'd recommend to specify here a brief connector handle ("GA") and its purpose ("Web Analytics") and optionally the data target, if there are multiple instances ("UA-12345-0"). * **Containers**: This very important setting defines on what containers this connector configuration (with all associated Tags, Triggers and other elements) will be activated on a given JENTIS Tag Manager Container (ie. a given domain or website). * **Constant Settings:** These are the global fields, that are shared across all tags of this connector instance. Those fields and values can hold different values for each environment (live, stage) and container (each to be defined in its column). This way you can create basic lookup tables for each individual container configuration. To set individual values in a field please click the "three boxes"-icon in the field input (at the most right of the input field).

## Connector Automatic Tag Creation When a connector is created a toggle to "Automatically create Tags" is opted in. You can keep this enabled to generate all tags that are designed to work out of the box with the JENTIS Data Layer default. It is recommended to keep this toggle if you intend to push data to the JENTIS Data Layer. If you primarily want to pull data based on your custom website and data layer design you can switch this toggle of, to not create tags that will not be triggered in that case anyway. # Make Consent Work: Connect Your CMP One of the key features of the JENTIS Consent Engine is its easy setup. You only apply an initial setting when a tool is added to your configuration for the first time. After that, it is fire and forget—easy as that. Follow these instructions when a tool is added to a configuration. First, we will go through a very broad set of steps, and then we will go through each step in detail one by one. 1. Add a tool to your account and decide in which containers (on which websites) it will be used. 2. Set the vendor of this tool instance (optional). 3. Define your preferred consent application for this vendor (consent, essential mode, or without consent). 4. Select which CMP connector is to be used (once per container) for your container. 5. Adjust mapping of JENTIS vendors to CMP vendors (optional, if customization is required). 6. Adjust mapping of tools to JENTIS vendors (optional, if customization is required). Multiple of those steps are only optional if you need more customization options. In most cases, the default will be a good starting point. {% hint style="info" %} Before continuing, please read [Setup Your First Connector (GA4, Meta, etc.)](/getting-started/quickstart/create-a-new-tool) {% endhint %} Each container is, in general, a surrogate for a website. With this setting, you control if the same tool should be activated on multiple websites with the same settings (tags, triggers, variables, etc). If you need more information on the account and containers, here you go: [JENTIS Accounts and Containers](/core-concepts/jentis-account-and-container-structure) ## Set the Vendor for this Tool Now, when a tool is configured, you have vendor settings available (Advanced Settings).

On the "Vendor Settings" you can adjust the mapping if required. By default every tool in JENTIS has a default vendor with the same generic name. For example if "Google Analytics 4" is a generic tool in JENTIS, you can configure your specific instance of this tool and name it "GA4". The default vendor for this tool will be the same generic: "Google Analytics 4". If you decide to have it mapped to a different vendor you can do so in this setting. You can also create custom vendors in the next steps. ## Set the Consent Application The following setting must be applied closely with your Data Privacy Officer. Navigate to the "Legal Hub" from the main menu section. Open the "Vendors" sub-menu section.

By default, the "Consent Mode" is selected with a vendor in JENTIS. You can decide to use the "Essential Mode" to have two configuration options for these tools' tags (a "default" with consent and a "fallback" without, where personally identifiable information is removed securely with JENTIS). Because of this topic's high complexity, we created its own article to guide on this setup [JENTIS Essential Mode](/jentis-dcp-elements/tags/how-to-configure-a-tag/essential-mode).

## Select the CMP Connector The following section applies if you will use either "Essential Mode" or "Consent Mode" for a given vendor in JENTIS. Navigate to the "Legal Hub" from the main menu section. There select the "Consentbars" sub menu item. Here comes a list of all supported CMP providers. Select which one applies to your website, ie. "User Centrics". You can now select to use this CMP with a particular website (container) with JENTIS Data Capture platform.

Make sure to select a CMP connection for your container. This setting is only required once per container, and only once you decide to use a different CMP. Thus, it is a setting that you will often see only once on the initial setup. ## Adjust Vendor (JENTIS) to Vendor (CMP) Mapping Now JENTIS knows which tools you want to use and which CMP (Consent Management Platform) provider you have. There is one more level of detail configuration that however is optional. This relates to the mapping of a vendor in JENTIS to a vendor in the CMP. For example a tool "Google Analytics 4" is a default vendor in JENTIS that might map to either a category or vendor on your CMP providers endpoint. Navigate to the "Legal Hub" from the main menu section. Open the "Vendors" sub menu section.

Here, you can select how each vendor is represented in your CMP for each CMP connection. For example, for a Use Centrics connection, that means that a vendor will be mapped to a "template ID" from User Centrics. With this setting JENTIS will establish a connection to your CMP provider and apply consent accordingly based on the CMPs information. *** ## Turn Off Consent Engine in JENTIS Tag Manager You can turn off the Consent Engine in JENTIS Tag Manager with the following setting. This will result in a configuration where no consent is awaited and tracking can be activated anytime. However, all JENTIS Consent functionality is lost simultaneously, disconnecting your Tag Management from any consent information. Navigate to your account administration settings and select “Consent Administration”. Here you will find a toggle to apply this decision. **Warning**: Be sure to only use this mode in respect of all legal consequences that are subject of your compliance assessment.

This setting will allow you to apply different tool and tag configurations based on consent, even before a user interacts with a consent banner. You can combine this with JENTIS Essential Mode. # Test Before You Go Live With server-side tracking architecture, a configuration preview is key. It makes transparent what is not visible to any third party or website visitor: the communication stream from user to any service provider (tools) made with your JENTIS server. The preview monitor enables you to preview and debug all data streams, be they client—or server-side tags and their streams. To open the preview monitor, navigate to the "Containers" section that displays all containers with respective versions.

In the containers overview, you can click on the “Preview” button to open your website in preview mode with any version (the currently edited or any of your past versions published, which are available when selecting an individual container).

Now you can see in the preview tab the button to open your website (“Start Debug Session”-button) or copy paste the parameters to open your website manually. {% hint style="warning" %} You might need to allow the JENTIS DCP to open the popup in a new tab or window. Some browsers are blocking this action by default. Please note that you can open the preview with any device or browser; it must not be opened in the same window as the current browser (that displays the data streams received in the preview). {% endhint %} The query parameters (`jts_preview`, `jts_debug` and `jts_log`) will instruct the JENTIS code in that website to display more information for debugging. There are two levels to inspect the debugging information: * client-side (in the browsers developer tools you can find information in the JS console); to fully inspect all client-side executed details the browsers tools can be used (ie. network protocol) or browser extensions (ie Google Tag Assistant in Chrome) * server-side (in the JENTIS Preview window you'll see the server-side posted data streams and a brief client-side tag overview) In the inspector window, you will see the incoming State events and the data that was then sent to a tool following a tag configuration. The following example displays a data stream to a Google Analytics tools pageview-tag. It consists of the payload and HTTP parameters to check if the configuration meets your requirements.

# What New Users Ask Most

What if I forgot my password?

If you forget your login credentials, please navigate to your JENTIS account and use the option to reset the password. Ensure you are trying to log in to your specific DCP and not via the JENTIS website. The login screen should look like this:

If you are still having difficulties, please get in touch with your DCP's main admin. They will be able to reset your user status and re-send you a log-in invite. If this also doesn´t work, please contact [JENTIS Support](https://jentis.atlassian.net/servicedesk/customer/portal/1) and request that your access be refreshed. Please try to include the DCP admin in the CC / as a ticket participant so we can verify with them that you are granted access to the JENTIS DCP.

How can I change my password?

We've created an article about resetting your password. [Read more.](/best-practices/how-to-change-your-account-password)

How can I use the same tool or tag on multiple implementations?

All containers are maintained in a single JENTIS account. So you can use the same tools, tags and codes in all or only in selected containers. You don’t need to copy-paste settings from one account to another. Even if the container and embed snippet is different on all domains, the JENTIS Tag Manager configuration is always managed globally in a single account.

How do I set up a tool only in one domain?

A domain is always connected to a single container; this is a 1:1 relationship. To implement a tool or a tag on only one container, you have to select that container.

Can I have only one global container on multiple websites (domains)?

No, a container, embed snippet, and DNS record are defined per domain. JENTIS is a first-party tool and can only be used in a first-party context. As the cookies set and associated with JENTIS are set via HTTP, this architecture does not support loading a third-party JS embed snippet, as the cookies would still be set in that third-party context via HTTP. This browser security and data privacy measure can not be circumvented.

How to implement Essential Mode?

We've prepared a detailed guide on our JENTIS Essential Mode Configuration. [Read more](/best-practices/how-to-implement-essential-mode)

How does a JENTIS CMP Bridge work?

You may be wondering how JENTIS integrates with different CMPs. You may have questions such as “Is it needed that a CMP code is already loaded before JENTIS loads its bridge?” or “Are there any wait mechanisms in JENTIS that take care of a CMP that is added later than JENTIS Bridge?” JENTIS always integrates with CMPs using interfaces provided by the specific CMP and uses those to collect the user's consent decisions. It’s irrelevant whether the CMP code or the JENTIS CMP bridge is loaded first, as we will always make sure to access either existing consent information (static) or consent updates (dynamic) based on events and listeners. Both interfaces are available with all CMPs.

Can I change the domain of an existing JENTIS container?

The best way to proceed is to create a new container for the new domain. Changing the domain of an existing container leads to a change in DNS A-record , and this is as much work as the creation of a new container. If you create a new container for the new domain, you will be more mindful with the tailoring to the new domain. Just make sure to connect the JTM Elements such as the tools and the CMP Bridge in the way you did for the current container. {% hint style="warning" %} Please note that a container configuration CANNOT be copied onto a new container. You must reproduce container configurations manually. {% endhint %}

# Release Notes & Changelog Welcome to the JENTIS Changelog! Here, you'll find the latest updates on our product, new functionalities, improvements, and fixed bugs. Stay up to date and explore how our updates improve performance, privacy, and data quality!

Available for Beta Customers	General Availability	Notes
Aug 25, 2026	Aug 25, 2026	Connector Bugfix: Snapchat: Fixed a placeholder on the "START_CHECKOUT" tag template where `payment_info_available` contained an incorrect constant. The default constant has been removed, so the optional placeholder is no longer populated automatically and must be set manually to 0 or 1 by the customer.
Aug 24, 2026	Aug 24, 2026	Connector Update Dymatrix: Extended the connector to support AI Search detection. Zbozi: Extended the connector to support server-side conversions. CMP-Bridge Bugfix: Datareporter: In a specific scenario, the CMP-Bridge defaulted to denied automatically. This behavior was identified and has now been fixed.
Aug 21, 2026	Aug 21, 2026	New Connector Dymatrix Click-Monitor: Introduced the Dymatrix Click-Monitor connector. It can be installed alongside the Dymatrix Analytics Connector, and both are fully compatible with each other out of the box. Connector Update X (formerly Twitter): Extended the X connector to support the server-side Conversion API.
Aug 06, 2026	Aug 06, 2026	Connector Bugfix Dymatrix: Resolved an issue where enabling the Post-Conversion feature corrupted campaign names.
Aug 05, 2026	Aug 06,2026	Changed Differentiated educational and new-feature tour behavior. Added description field to Frontend Codes Improved search fields with fuzzy search. Added Adobe Datalayer bridge structure and standard mapping.
Aug 05, 2026	Aug 05, 2026	Connector Bugfix attriXus: Added the missing `ntmData=atxsData` URL parameter to the script loading request.
Jul 22, 2026	Jul 22, 2026	Changed All customer-facing timestamps are showing the clientside timestamp now. Improved the Tables component with support for resizable and hideable columns, pagination, and advanced filtering for a more flexible and efficient data browsing experience. Fixed Search in the Tables is working for all values again. Timestamps in Preview Monitor, now display correctly in your local timezone. Fixed a bug where auto-filling browser extensions are able to overwrite fields in the DCP.
Jul 17, 2026	Jul 17, 2026	New CMP-Bridge Piwik PRO (https://piwik.pro/gdpr-consent-manager/)
Jul 15, 2026	Jul 15, 2026	Connector Update Reddit: We have extended our Reddit integration with tag templates from the new Version 3. To migrate from Version 2 to Version 3, you must manually install the new tags and deactivate the old ones, as outlined in Reddit's documentation.
Jul 09, 2026	Jul 09, 2026	Connector Update Meta: Resolved naming inconsistencies across Meta templates, especially within the `InitiateCheckout` tag template. Shopping24: Extended client-side tag templates to include missing product filters. Matomo: Updated Matomo server-side tag templates to support Version 5 authentication via the HTTP Authorization header. This update is fully backward compatible with older Matomo instances; no manual configuration is required. Google Ads: Corrected naming inconsistencies introduced during the recent merger of the Google Ads Dynamic Remarketing connector into the primary Google Ads connector. Tag names are now clearer and more intuitive. LinkedIn: Updated the LinkedIn Conversions API (CAPI) version to `202606`.
Jun 26, 2026	Jun 26, 2026	Connector Update Amazon Ads: Implemented the new v2 Conversational API (CAPI).
Jun 25, 2026	Jun 25, 2026	Template "Get JTM data layer variable" Extended: We extended the Template Variable for accessing properties from the `_jts` data layer, making it possible to search the entire `_jts` object for specific track commands. Additionally, we updated the wording and naming conventions for better clarity.
Jun 25, 2026	Jul 6, 2026	Changed Introducing the JENTIS Health Center: a smarter way to monitor tag reliability, spot high failure rates or dropped triggers, and stay ahead of issues with in-app and email notifications. Elements can now be connected to multiple triggers at the same time, giving users more flexibility when configuring trigger-based behavior. The 'consent' field is no longer marked as mandatory when using the HTTP-API. Fixed Fixed an issue where an error is thrown on functions where hidden references containing escaped quotes are used
Jun 24, 2026	Jun 24, 2026	Connector Update Google Ads, Google Floodlight: We implemented an initialization guard to ensure that the library initializes only once per page load.
Jun 23, 2026	Jun 23, 2026	App SDK Update iOS - 1.0.7 Fixed The userAgent string is now formatted to match a real-world example. removed U+00A0 indentation warnings in Package.swift
Jun 10, 2026	Jun 22, 2026	Changed Fixed an issue where codeblocks connected to the 'Before bundle load' trigger could cause runtime errors that prevented tracking execution. These codeblocks are now wrapped safely to improve reliability. Fixed Fixed an issue where the 'Update snippet' button was not shown for some containers when verification could not detect the snippet or was blocked by the provider, such as on login-protected websites. Optional fields are now excluded from the calculation that triggers the consent bar warning, helping ensure warnings only appear when required fields are missing.
Jun 22, 2026	Jun 22, 2026	App SDK Update Android - 2.0.9 Fixed The userAgent string is now formatted to match a real-world example. Connector Update Reddit: We created a new Tag Template for 'ViewContent' events on article lists that lack product data.
Jun 17, 2026	Jun 17, 2026	Connector Update Google Analytics 4: Essential Mode Placeholders have been updated to support Essential Mode out-of-the-box. The core architecture for tracking GA4 Server-Side is now preconfigured to run natively in Essential Mode.
Jun 15, 2026	Jun 15, 2026	Connector Update AmazonAds: Updated the client-side implementation to fully support the new user consent signals. PiwikPro: Fixed an issue where the tracking source incorrectly appeared as "Unknown (jentis)." The source now accurately displays as "JENTIS."
Jun 10, 2026	Jun 10, 2026	New Connector Chat GPT Ads (https://ads.openai.com/)
Jun 09, 2026	Jun 09, 2026	Connector Update All Google connectors using GTAG were updated to make them configurable for the First-Party Google Gateway.
Jun 08, 2026	Jun 08, 2026	New Connector Attentive (https://www.attentive.com/)
May 21, 2026	May 21, 2026	Connector Update Shopping24 has been extended and now supports a client-side integration in addition to the existing server-side integration.
May 20, 2026	Jun 3, 2026	Changed Publishing just got faster. You can now publish multiple containers at the same time, instead of releasing each container one by one. This makes it easier to roll out changes across several containers, reduces repetitive work, and helps you move from setup to launch with fewer clicks. Select the containers you want to publish, confirm once, and let the DCP handle the rest. Read more!
May 12, 2026	May 12, 2026	Connector Update META default CAPI version has been updated to v24.0. Google Ads and Google Ads Dynamic Remarketing have been merged into a single Google Ads tool. The Google Ads Dynamic Remarketing tool has been deprecated and should no longer be used. The new Google Ads tool now supports configurable deduplication for both client-side and server-side tracking out of the box.
May 8, 2026	May 8, 2026	New Connector Snowplow (https://snowplow.io/) Connector Update Taboola has been extended to support the `quantity` property on conversion tags.
May 5, 2026	May 5, 2026	Connector Update Webgains has been updated to support all GDPR fields and to make the required fields mandatory. AWIN has been updated to support AWIN’s non-consent mode for both client-side and server-side tracking.
Apr 30, 2026	Apr 30, 2026	Connector Update Dymatrix Billext custom dimensions are now available by default in JENTIS and no longer need to be added manually as custom dimensions. New Connector eKonsilio (https://www.ekonsilio.com)
Apr 29, 2026	Apr 29, 2026	New Connector Marfeel (https://www.marfeel.com/) Connector Update Dymatrix Postconversion Tracking has been extended to include additional parameters in the request.
Apr 23, 2026	Apr 23, 2026	Connector Update INFOnline Measurement has been extended and now includes a client-side version.
Apr 22, 2026	Apr 22, 2026	Connector Update LinkedIn Conversion API version updated to 202604. Snapchat has been updated to version 3.
Apr 13, 2026	Apr 27, 2026	Changed The new Data Layer Mapping is here! - JENTIS will now auto-detect and map standard behavioral and e-commerce events from a website’s existing data layer during new container creation. A more streamlined publishing experience — The Publish page is now part of Containers, and each container now has a cleaner, more focused overview page. Newly created tags will use "Pseudonymisation" as a default Essential Mode function now. Added a hint on client-side tags not supporting Essential Mode. Fixed "Secure" variables are not able to be used in frontend enrichment anymore. Cookie Life Time Extender is not verified anymore after a Superadmin sets it manually Fixed a bug with server-side execution of transformation functions.
Apr 1, 2026	Apr 1, 2026	New CMP-Bridge Cookieinformation (https://cookieinformation.com/)
Mar 26, 2026	Mar 26, 2026	New Connector attriXus (https://attrixus.de/) Readpeak (https://www.readpeak.com/)
Mar 24, 2026	Mar 24, 2026	Connector Update Shopping24 Server-Side API got updated to version 2.
Mar 19, 2026	Mar 19, 2026	Connector Bugfix The Reddit UUID was initially generated with a null value by the Reddit client-side JavaScript library on first load and passed to the Reddit Conversion API, which resulted in the page visit not being tracked. The Solute URL query parameter was malformed due to incorrect quotation marks. New CMP-Bridge Hubspot (https://www.hubspot.com/)
Mar 18, 2026	Mar 18, 2026	Connector Update AdWords Conversion Template has been extended to support wbraid and gbraid URL parameters. Shopping24 has been updated to version 2.
Mar 12, 2026	Mar 12, 2026	Connector Update Dymatrix received an update and now supports enabling Post-Conversion Attribution directly in the tool configuration screen. TikTok has been updated to Events API v2. The previous tag templates are now deprecated, and customers need to manually migrate to Version 2.
Mar 03, 2026	Mar 03, 2026	New Connector Parse.ly (https://www.parse.ly/)
Feb 23, 2026	Feb 23, 2026	New Connector Glassbox (https://www.glassbox.com/)
Feb 17, 2026	Feb 17, 2026	New Connector Salesforce Marketing Cloud (https://www.salesforce.com/eu/marketing/)
Feb 16, 2026	Feb 16, 2026	Connector Update Microsoft Clarity received an update and now has the Consent Mode v2 included.
Feb 03, 2026	Feb 03, 2026	New Connector Maileon (https://maileon.com/)
Jan 29, 2026	Jan 29, 2026	Connector Update Spotify received an update and now has the new Server-Side Conversion API available.
Jan 29, 2026	Feb 16, 2026	Changed SYU Preview now includes a Model timeline. You can now follow what happens to your Models (and when 😄) Fixed Fixed a bug where the 'Referrer' placeholder could not be amended in specific tools. Fixed a bug where deleting a tool instance did not also delete the tag assistants related to this tool instance Template variables referenced by tags cannot be deleted anymore. Deployed security updates for the latest MongoBleed vulnerabilities.
Jan 8, 2026	Jan 8, 2026	Connector Update Extended Amazon Advertising with new tag-templates for sending events to the Conversion API.
Dec 17, 2025	Dec 17, 2025	Changed We’re introducing a new DCP Home area to give us Follow your onboarding status from every view of the JENTIS DCP with our new 'Onboarding Status Widget' Enable alternative cookie setting methods to exchange Set-Cookie response header method Always keep an eye your account usage & limits with the new 'Account Usage' block of the JENTIS Dashboard Fixed Aligned Trigger condition evaluation between J-Tracker and Twin Browser
Dec 5, 2025	Dec 5, 2025	New Connector Bloomreach (https://www.bloomreach.com/) Connector Update Extended ABLyft with a new tag-template for sending custom events. Extended AWIN with custom dimensions functionality.
Dec 3, 2025	Dec 3, 2025	New CMP-Bridge Klaro (https://klaro.org/) Changed We’re introducing a new DCP Home area to give users a clear, guided starting point for managing their tracking setup. This dedicated space reduces uncertainty during onboarding and helps prevent information overload. We’ve updated several platform terms to more accurate and user-friendly variants—for example, replacing “tool” with “connector.” Fixed We fixed, that videos in the assistants were not being shown correctly.
Nov 26, 2025	Nov 26, 2025	Connector Update TheTradeDesk received an update to automatically retrieve the necessary third-party cookie information in order to link first-party data with existing third-party customer profiles.
Nov 10, 2025	Nov 10, 2025	New CMP-Bridge Traffective (http://traffective.com/)
Oct 22, 2025	Nov 3, 2025	Changed We've added the possibility to set the permission group of a user on the user creation screen Introducing a new Datepicker — now available in both the main Dashboard and the Synthetic User Dashboard for effortless time-based insights. Fixed Synthetic User campaign parameters are shown correctly in the changelog. Change serverside variables in array list to behave like clientside variables Preview Monitor "Not executed" now shows a complete list of tools again.
Oct 13, 2025	Oct 13, 2025	New Connector Mida (https://www.mida.so/) Adrecord (https://www.adrecord.com/)
Oct 8, 2025	Oct 20, 2025	Important We’ve upgraded our Synthetic Users performance measurement approach for greater precision and reliability. Data is now available starting from 20 October 2025. Historical data before this date has been reset as part of the improvement. Changed Adapted the Look & Feel of JENTIS Synthetic User Synthetic User suggests the configuration by redirecting to tool-specific documentation now. Synthetic User Segmentation statistics are now available. SELECTORACTION state is now shown correctly on the preview monitor Fixed Fixed a bug where a 2nd click always was needed when verifying the Cookie Lifetime Extender. After sending a "Synthetic User Request", the page stays interactable. Version log of a template variables is showing the correct history again. Essential Mode numbers in the JENTIS Dashboard are shown correctly again. Unified login error messages to “Invalid username or password.” to prevent user enumeration and improve security. Updated forgot password response to enhance security and user experience. Clicking on the JENTIS logo in your DCP will trigger a "Unsaved changes" pop-up again if necessary.*
Oct 3, 2025	Oct 3, 2025	New Connector KLAR! (https://www.getklar.com/) Insider (https://useinsider.com/)
Sep 25, 2025	Sep 25, 2025	New Connector FinanceAds (https://www.financeads.net/) FactFinder (https://www.fact-finder.com/) Rakuten Advertising (https://rakutenadvertising.com/) Funnel.io (https://funnel.io/) Favi (https://favi.sk/) Coveo (https://www.coveo.com/en)
Sep 5, 2025	Sep 9, 2025	Changed The latest update to Synthetic Users introduces Paid Traffic Analysis and Recovered Conversions Metrics, revealing the conversions your ad tools miss. Now with Preview access and no extra setup, you can instantly: See the conversion gap caused by consent restrictions Break down missed conversions by platform, campaign, and event Prove ROI with a clear, data-driven value story Start seeing real performance from day one. Just enable it in your JENTIS account and discover the conversions you’ve been missing. Learn more! We've made it easier to understand which version of the JENTIS DCP you're working with. From now on, your account's channel — such as Beta or Stable — is clearly shown inside the platform. JENTIS Cookie Lifetime Extender now also supports Cloudflare, Azure CDN & Google CDN
Aug 4, 2025	Aug 21, 2025	Changed All you need to know, right where you need it: The new JENTIS Dashboard shows exactly how much data you're capturing, correcting, and recovering with JENTIS. Make smarter decisions with full confidence in your tracking performance and easily report the value of your setup back to your teams. Learn more!
Jun 18, 2025	Jul 1, 2025	Changed Introduced the JENTIS Cookie Lifetime Extender to help overcome the latest browser restrictions and extend your first-party cookie lifetime. We’ve streamlined interactions in the DCP, making it easier to update tags, triggers, and related elements without switching screens. Fixed States triggered with sendBeacon are now showing up in the preview monitor. The ".addEventListener" on CSS-Selectoraction Triggers was changed from "document.body" to "document".
May 21, 2025	Jun 02, 2025	Improved Improved the Click ID assignment for Synthetic Users. Improved backend stability & Performance.
May 7, 2025	May 20, 2025	Improved We've added changelogs for Vendor, Consent Bar, User, Template Variables, Consent Administration, and Maximum Storage Lifetime to bring more transparency to changes in the DCP. We've added a copy button to the tag-field-editor to easily duplicate values from the default value to the essential mode value. Fixed Resetting fields in the Vendor or Consent Bar settings now correctly re-enables the Save banner. Variable input for lookup tables is now properly validated
Apr 10, 2025	Apr 22, 2025	Changed: Containers that are not fully configured are highlighted in picklists and input fields as such. Frontend variables can now be referenced in codeblocks by using "this.getFrontendVariable()".
Feb 27, 2025	Mar 7, 2025	Changed: The "Tabulator" key is no longer jumping out of Codeblocks within the DCP. Now you can open elements from the JENTIS Platform in a new tab by right-clicking or CMD-clicking on them. Optional Constants were moved from the "Advanced Settings" page to the bottom of the "Default settings" page. Custom Optional Constants can now be deleted, as long as they are not in use/referenced. We adapted the function wrappers for each JENTIS Element which allows JavaScript coding to always be present. Syntax Checker was added to all fields that enable JavaScript coding. Pop-ups no longer need an extra click to be removed before taking another action in the JENTIS Platform.
Feb 12, 2025	Feb 26, 2025	Changed: Containers can now be published with just a valid DNS A record, removing the HTML installation requirement. A new validation prevents duplicate names when creating, updating, or copying elements, even across multiple users or tabs. Elements in use can no longer be deleted, with a pop-up listing dependent entities for clarity. Various improvements for better stability, security, and a smoother experience. Fixed: Essential Mode fields no longer appear when the feature is inactive.
Jan 29, 2025	Feb 12, 2025	Changed: Added a label to the previously unlabeled field in the copy dialog, ensuring users know they need to provide a name when copying elements Improved the platform’s look and feel by introducing a structured design system for colors, typography, and spacing. Fixed: DNS and HTML verification now work independently, preventing failures when one method is incorrect. Fixed an error that occurred when creating a container during system unresponsiveness. The preview “Try Again” button now works correctly after session expiration. Fixed inconsistent card sizes on the "Tools" page for long names. The "Next" button is now disabled until all tool creation requirements are met. Fixed an issue where system-wide changes were missing from changelogs.
Jan 15, 2025	Jan 27, 2025	Changed: Enhanced the experience of saving changes across all components of our platform by introducing an "Unsaved Changes" banner that appears only when edits are detected Improved the use of our platform by unifying the header styles for Tools, Server Tag Manager, Legal Hub, and Settings. Fixed: Resolved an issue where the number of pages was displayed even when less than 10 items were displayed and no other pages existed. Fixed an issue where variables used exclusively as "Filter Variables" in array lists within tags could be mistakenly deleted due to a missing dependency check. Fixed a bug where modifying and saving an existing tag would fail due to an error stating the tag already exists. Fixed an issue where the "Published By" field was incorrectly populated for the current container version, even when it had not been published. Fixed an issue where container connections for a newly created vendor were displayed as empty until the page was refreshed.
Dec 11, 2024	Jan 8, 2025	Added: New Main Domain Cookie feature available. Changed: New container management experience.

*** If you have any questions or suggestions, contact us through our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1). # FAQ

We are currently using GTM. How does the migration to JENTIS work?

We’ve prepared a **detailed step-by-step migration guide** to help you transition smoothly to JENTIS.\ This guide covers everything needed, ensuring your migration is seamless and without data loss. You can access the migration guide here: [Migration to JENTIS: A Short Guide](/data-capture/web-tracking-setup/migration-to-jentis-a-short-guide)

Does JENTIS affect website performance?

Yes, indeed! Since significantly fewer scripts need to be loaded in the frontend, pagespeed usually improves significantly. Read the Article

Is it legal to use Google Analytics?

From the decisions made so far by the data protection authorities of the EU member states, a recommendation crystallized for how US tools can be used in a DSGVO-compliant manner. The solution is very simple: Instead of transferring data directly to the USA (or to US servers in the EU), JENTIS interposes its patented twin-server technology. Here, personal data is pseudonymized and only then is the data forwarded to US tools such as Google Analytics. Read the docs Read the article

What resources are needed to implement JENTIS?

Based on our experience, you will need a **developer/IT employee** for the initial setup, which includes adding the JavaScript snippet and configuring the A-record.\ This task typically requires **no more than one person-day** of a technician's time.\ After this step, the remaining implementation can usually be handled by **team members with tracking experience** or by your **agency partner.** Read more

# Platform Enhancements Welcome to our Platform Enhancements! While major new tools and core functionalities get their own dedicated [guides in our documentation](/key-features), this is the place where we celebrate the smaller, iterative changes designed to make your daily workflow smoother, faster, and more intuitive. From subtle design polish to layout tweaks and quality-of-life adjustments, we are constantly refining the JENTIS interface based on your feedback. {% hint style="info" %} Looking for major feature releases? For large architectural shifts, new integrations, or major tool rollouts, please head over to our main [Release Notes & Changelog](/support-resources-and-product-updates/release-notes-and-changelog) page. {% endhint %} ### What You’ll Find Here Unlike a raw technical changelog, our enhancement roundups group micro-updates together so you can quickly see how the interface is evolving. We typically bucket these updates into a few main categories: * Workflow Adjustments: Changes to buttons, menus, and navigation that reduce the number of clicks to get things done. * Visual Clarity: Improvements to tables, labels, tooltips, and data displays to make tracking and setup easier to read. * Form & Validation Fixes: Small updates to how data input fields behave, preventing errors before you hit save. ### Have Feedback? Many of these minor adjustments come directly from support tickets and user feedback. If you spot a clunky part of the UI or a small quality-of-life fix that could use attention, let our [support team know](https://jentis.atlassian.net/servicedesk/customer/portal/1/group/1/create/35)! # How to publish multiple containers at once You can now publish multiple containers in one workflow. Instead of opening and publishing each container separately, you can select several containers, choose the target environment, and publish them together. This is useful when you want to release changes across multiple containers simultaneously, keep deployments consistent, and reduce repetitive manual steps. ### How to publish multiple containers #### 1. Open the Containers section Go to **Containers** from the main navigation.

#### 2. Start the publishing workflow Click the **Publish Containers** button. This opens the multi-container publishing flow, where you can choose which containers should be included in the release.

#### 3. Select the containers you want to publish Tick the checkboxes next to the containers you want to publish. You can select one or more containers, depending on what you want to release.

#### 4. Continue to publishing details After selecting the containers, click **Continue**. #### 5. Add a description and select an environment Enter a publication description. Then select the environment you want to publish the selected containers into. The description helps your team understand what was released and why. It is especially useful when several containers are published together as part of the same update.

#### 6. Publish the selected containers Review your selection and publish the containers Once confirmed, all selected containers are published into the chosen environment as part of the same publishing workflow.

{% hint style="info" %} All selected containers are published into the same environment. If different containers need to be published into different environments, publish them in separate publishing workflows. {% endhint %} # Multi-Trigger Assignment & Smart Preview Debugging Managing server-side tracking at scale just got a whole lot faster. We’ve rolled out two highly requested interface updates designed to save you clicks, eliminate duplicate work, and make it a breeze to track down elusive data layers. Here is a look at what’s new in your JENTIS DCP. ## Assign Multiple Triggers at Once Go to **Tag Manager - Tags** from the main navigation and open any Tag.

The "Triggers" selection is now a multi-select field :tada: ## The Upgraded Preview Monitor Adding multiple triggers to a single element shouldn't make your testing phase feel like guesswork. To complement our bulk-assignment update, we have begun overhauling the "Preview Monitor State Debugger". This is just the start of our journey to make the Debugging View more usable and enjoyable. When you are testing your container, the debugger now provides a beautifully transparent breakdown of complex trigger logic: * **Trigger Event Mapping:** See exactly *which* of your multiple triggers fired the tag on any given event. * **State Snapshots:** Inspect the precise data layer state at the second the trigger condition was met. * **Visual Status Indicators:** Green, yellow, and red status cues instantly show you if a tag was skipped due to an exception rule or successfully passed on to your server.

## Ready to try it? These updates are already live in your JENTIS account according to our [deployment plan](/support-resources-and-product-updates/release-notes-and-changelog). Head over to your workspace, spin up the updated Preview Monitor, and experience how easy managing complex server-side logic can be. # What is JENTIS? **JENTIS** is a next-generation tag management and data collection platform that enables organizations to collect, process, and activate **first-party data** - fully compliant with growing desires for privacy and resulting laws like GDPR, ePrivacy and the CCPA. Unlike traditional client-side tag managers, JENTIS operates with a hybrid architecture, combining client-side flexibility with server-side control. It allows you to track user behavior accurately, even with reduced cookie consent, and to transform and forward the data to tools like Google Analytics, Meta, LinkedIn, or your own data warehouse.

With **JENTIS**, you can: * Achieve privacy-compliant first-party tracking that delivers unrivalled data quality and better visibility of the customer journey. * Manage all your domains and tracking in a single UI * Transform data — anonymize, pseudonymize, or enrich it — before sending it to your platforms * Easily handle data privacy through built-in consent handling or external CMPs. * Integrate with 130+ marketing and analytics platforms, sending the best quality data to maximize ROI. * Export clean, enriched raw data for your own analytics, AI, or BI pipelines. * Build custom functions and connectors to internal and third party systems. * Send AI-enhanced data to the ad platforms to dramatically improve ROAS and overall marketing performance. For more detailed information on JENTIS's technical specifications and architecture, please refer to [Getting Started](/). # Why use JENTIS? JENTIS provides a competitive advantage by transforming data into actionable intelligence. Businesses choose JENTIS for several compelling reasons: * **Improved ROI**: Optimize campaigns and allocate resources effectively by understanding what drives conversions and engagement. * **Improved User Experiences**: Poor quality data caused by browser restrictions, non-consent and ad blocking lead to misleading attribution and fragmented customer journeys. Use JENTIS to fix attribution and understand the full customer journey. * **Enhanced Decision-Making**: Gain deep insights into user behavior, enabling data-driven decisions that improve product development and marketing efforts. # Who uses JENTIS? JENTIS is a versatile platform that caters to a wide range of professionals and organizations across various industries. Its flexible architecture, API integrations, and comprehensive features make it suitable for: * **Marketing Teams:** For tracking campaign performance, optimizing ad spend, and understanding customer journeys. [Giesswein](https://www.jentis.com/en/article/case-study-giesswein-achieves-25-higher-roas-with-jentis-synthetic-users/) improved ROAS by 25% using JENTIS’ Synthetic Users, while [Pixum](https://www.jentis.com/en/article/blog-case-study-adtriba-2/) collects up to 29.2% more data with JENTIS Server-Side Tracking, corrects 55% of customer journeys, and increased its campaign performance by 176%. * **E-Commerce Teams:** are looking to close data gaps, improve campaign performance, and strengthen their commercial touchpoints. [Vileda](https://www.jentis.com/en/article/case-study-vileda-captures-42-more-purchases-in-ga4/) captured 42% more purchases in Google Analytics after implementing JENTIS. * **Martech Specialists:** For easy tag and consent management and for integrating JENTIS into existing systems, developing custom data connectors and building robust data enrichments. Moreover, JENTIS is not a rip-and-replace tool - it slots seamlessly into your existing martech stack. * **Data Analysts:** require reliable, enriched datasets to create custom reports, and develop reliable predictive models. For this, they need complete and clean data. JENTIS provides exactly this. For [Playmobil](https://www.jentis.com/en/article/blog-how-playmobil-achieved-over-97-data-accuracy-with-server-side-tracking/), achieving 98% data accuracy was a game-changer in making precise and impactful decisions, especially during peak seasonal periods. * **Data Privacy Officers:** In industries with the strictest compliance and regulatory requirements, JENTIS provides security and builds user trust. For these reasons companies in highly regulated sectors such as Santander and Societe Generale, implemented JENTIS.

# Architecture Overview JENTIS is built around a flexible, modular **data pipeline architecture** that supports **Web**, **Mobile Apps**, and **Server/API-based** data sources — and delivers structured, compliant data to destinations of your choice.

#### 🔄 **Data Flow Overview** **Capture:** * **Web (Browser)** — via JENTIS JavaScript tag * **Mobile Apps** — via SDK or HTTP endpoints * **Backend Systems** — via HTTP Tracking API **Control:** * Consent-aware data collection * Event enrichment & transformation * Server-side routing logic * Session and ID management * Pseudonymization & anonymization **Activate:** * Marketing tools (Google Ads, Facebook, LinkedIn, etc.) * Analytics platforms (GA4, Adobe, Amplitude) * Webhooks & APIs * Your own **Raw Data Lake** (S3, BigQuery, Snowflake, etc.) # Core Concepts # JENTIS Account & Container Structure What is a container in JENTIS? How are they used for managing tags, domains, and environments? JENTIS has a three-level hierarchy: 1. **JENTIS Platform Account:** This is the highest level of administration. In general, an account represents a single company and has one single point of contact. Here, you log in and can manage users, containers, and environments. 2. **Container:** A container is always directly connected to a domain and a JavaScript embed snippet. 3. **Container Environment:** Part of the JavaScript embed snippet is the definition of an environment. By default, a JENTIS Container will always have two: `stage` and `live`. The JENTIS hierarchy and structure are mirrored in its code. In other words, the JENTIS server-side tracking architecture as a first-party solution forms the foundation for scaling across multiple sites. Each integration must be implemented in a first-party context, making having different JavaScript snippets, DNS A records, and containers inevitable. Let's have a look at the generic short version of the JENTIS Code Snippet: {% code overflow="wrap" lineNumbers="true" %} ```markup ``` {% endcode %} There are multiple dynamic parameters in that code: * `JENTIS_SUBDOMAIN`: This is a dynamically generated value where you must map the DNS A record entry. All details are shared in your JTM account setup guide. * `JENTIS_CONTAINER_NAME`: This refers to the name of your container, which will be used with the JS embed snippet. * `JENTIS_CONTAINER_ENVIRONMENT`: Either `stage` or `live`. # Data Scopes - Sharing Information ## Sharing: Global and Local Elements To efficiently handle multiple integrations, elements in JENTIS have references to containers. The following elements are either local definitions or global. If a local element selects ALL containers, it becomes the same as a global element. There are two types of Shared elements: * Local: you can select which container those elements are implemented in * Global: always the same for all containers, available in all containers

Element	Scope
Tools Each tool configuration instance (Google Analytics, Facebook, etc.) is always connected to a container.	Local
Tags Each tag is always part of a tool and shares its setting, making it always connected to containers selected in the appropriate tool.	Local
Codes All frontend code snippet elements are defined per container.	Local
Vendor Consent Management Platform setting and vendor consent options.	Local
Triggers	Global
Variables (clientside, serverside, static and enrichment variables)	Global
Transformation Functions	Global
States	Global

{% hint style="info" %} **Remember**: In your JENTIS account, you can have either a tool on multiple containers or a container with multiple different tool instances. Defining how various tools are connected to containers is up to you.\ \ If you want to manage a tool only once and share the configuration on multiple websites (domains), you can select it to be available in multiple containers.\ \ If a tool has a specific tag or configuration, then you can add a tool and assign it only to the required container. A container can hold multiple configured tools, including the same tool (e.g., GA4) with two different instances. {% endhint %} A tool instance can be shared on multiple containers. So, the same configuration applies to multiple sites (with the same tags, triggers, and variables):

**In conclusion,** you can use a tool on multiple containers with the same configuration. It scales from bottom to top, hierarchy speaking. At the same time, you can have one container and run multiple tool instances on the same container, scaling from the top to the bottom. Both directions are possible. So, it is up to you to see if a common tool definition applies to multiple containers, if you want to have a single container with multiple tools or even multiple containers with different tool definitions on the same website. The following parts will examine more complex topics related to setting up containers and tools. a) **Shared elements**: reusing code, variables, triggers, etc., in multiple configurations. b) **Sharing data**: accessing the same data with different tool instances. *** When deciding on the appropriate account and container structure for your project, you must consider the scope of data. By design, a tool and container in JENTIS will not automatically share data with any other container or tool instance. This basically means that when you have two tools, **Web Analytics A** and **Web Analytics B,** and two containers, **Website X** and **Website Y**, the data between those will **not** be shared. A visitor with a `client-id` in **Web Analytics A** will be a different user and visitor, with its own unique `client-id`, in **Web Analytics B**. The same is true for Containers. If a user navigates both websites, `website-X.com` and `website-Y.com`, they are two different identities in JENTIS, meaning there is no common identifier. Again, both web analytics tools will count two unique visitors. Now, there is a solution for this: ### **Cross-Domain Tracking** With Cross-Domain tracking, the same user in two containers will be identified as the same user in JENTIS by sharing the `user-id` on both websites. If you have configured your web analytics tool as a single tool configuration that is applied on both containers for **Website X** and **Website Y**, the data will be merged. As of now, the client ID is consistently the same, even if the user navigates back and forth between both websites. See more information on [Cross Domain Tracking](/use-cases-and-tutorials/sharing-information-cross-domain-tracking) ### Subdomains and Multi-Container on a single top-level domain Generally, we do not advise having multiple containers on a single top-level domain (e.g., ".my-website.com" is the top-level part of your domain, excluding any subdomain or www), as data between those containers will not be shared by default. ### Tool Instance Data Sharing Limitations The general idea of a tool instance is that it is a single configuration for a generic tool in your account. The generic tool is the "parent" (e.g., "Google Analytics 4"), and a tool instance is your configuration of this tool (e.g., "Google Analytics 4 - EN Shop"), the "child.” As we know, you can have multiple interpretations of the same generic tool (e.g., "Google Analytics 4 - EN Shop" and "Google Analytics 4—All Shops"). Currently, the data between both tools is not shared, so for example, GA4 has a `client-id` assigned for each user. This `client-id` will be different for "Google Analytics 4 - EN Shop" and "Google Analytics 4—All Shops". Even if JENTIS recognizes the same user, the scope of the data is per tool configuration instance. Today, this limitation can not be worked around. If you must share data explicitly on the tool, you can do so by using this one tool for all applications, if possible (i.e. by selecting multiple containers with this tool so it operates on multiple websites). # How to Structure your Account In your JENTIS Data Capturing implementation life cycle, you will soon be confronted with the question of how to set up your account, containers, and tools to maximize the efficiency and accessibility of the data pipelines. In the next sections, we will discuss your options and the concepts behind them, helping you resolve the question of how many containers and tool instances you actually need. Here are the topics you should consider when setting up your account: ## **Container Configuration** * To define the right number of containers on your account, please consider: * How many websites (domains) do you have? Are they similar in nature (same data, same requirements)? Can they be grouped where the requirements overlap (same tools with the same conversion goals)? * Do you want to split a single website (domain) into multiple sections (i.e., by subdomain)? Do they require separate management and have different requirements (e.g., different data, different tools, and different conversion goals)?
* Once you consider these questions, you have some options to configure your containers: * **Multiple containers for one same domain**: We recommend that you use this option if your website has multiple subdomains with particular management requirements—different data, tools, and conversion goals.\ For example, on the main domain `example.com`, you have `shop.example.com` and `blog.example.com`. While the first has a clear purchase conversion type and an e-commerce structure, the second is a content website. You could configure one container for each of these.
* **One container for the same domain and all its subdomains**: We recommend using this option if your website has multiple subdomains that share the same type of data, tools, and conversion goals.\ For example, your main domain, `example.com`, has the subdomains `de.example.com` and `at.example.com`. These are all e-commerce pages with the same structure and purchase conversion goal, just varying their language. You only need one set of configurations for these.
* **One unique container per domain**: If you have different domains, you should configure one container for each one, as one container can not be used on multiple domains.\ For example, your company owns the websites `example.com` and `mycompany.com`. Each should be configured with a different container. {% hint style="info" %} **Remember**: A container can hold multiple configured tools; it can be the same tool (e.g., GA4) with two different instances. Read more about tools and instances: [Tools](/jentis-dcp-elements/tools) {% endhint %} Further, on the tool level, you can decide where to execute it with its configuration of tags, triggers, and variables. A tool instance can be shared on multiple containers. So, the same configuration applies to multiple sites (with the same tags, triggers, and variables): **In conclusion,** you can use a tool on multiple containers with the same configuration. It scales from bottom to top, hierarchy speaking. At the same time, you can have one container and run multiple tool instances on the same container, scaling from the top to the bottom. Both directions are possible. So, it is up to you to see if a common tool definition applies to multiple containers, if you want to have a single container with multiple tools or even multiple containers with different tool definitions on the same website. # Account Structure - Best Practices **Accounts are isolated workspaces.** Items can’t be shared across accounts. **Containers**, created within an account, are the unit where tags, triggers, states, functions, and tools live—and **can be shared or reused across containers inside the same account**.\ This page explains how to structure accounts and containers for multi-domain, subdomain, and multi-tenant setups, and how identity sharing works via the [**Main Domain Cookie**](/key-features/main-domain-cookie). ## Key Takeaways * **No cross-account sharing.** Treat accounts as separate entities. * **Container-level reuse.** Within a single account, reuse configurations across multiple containers. * **Subdomain strategy.** Most subdomain setups work cleanly with **one container**; you may still split by subdomain for organizational reasons. * **Identity continuity.** Multiple containers on the same domain/subdomains can share a user ID via the **Main Domain Cookie** (configurable). *** ## Common Scenarios & Recommended Setups {% hint style="info" %} Remember: JENTIS Accounts and Containers have global and local elements. **Local elements** are configured specifically for a container (Connector, Vendor and Consent Management Platform, Tags and Codes). **Global elements** are configured with all elements in mind - changing it applies the change to all containers that utilize it (Trigger, States, Functions and Variables). {% endhint %} ### 1) One site, multiple country domains If you have the same requirements and technical facilities (ie. same data layer implemented with each domain) you can stretch one configuration across multiple domains easily. **Example:** `example.at`, `example.de`, `example.ch` **Requirement**: Configure same tracking of events (pageviews, conversions, etc.) on all sites. You "stretch" this configuration across all domains.

**Recommended:** * **1 Account**, create **one Container per country domain**. * Reuse shared configurations (Tools/Tags/Triggers/States/Functions) **across these containers** inside the same account. **Why it works:** * Keeps localization and governance clean per ccTLD, while centralizing shared logic. *** ### 2) One site with a shop subdomain or path In this setup you have per website section a different JENTIS Container, which can hold different tool instances and configurations. **Example:** `www.example.at` and `shop.example.at` {% hint style="warning" %} This separation does not require a technical subdomain. You can also separate it by page path. However, a site must run **only one JENTIS JavaScript snippet**. Multiple snippets on the same page cause malfunctions. {% endhint %}

**Step 1 — Confirm scope:**\ Check with your web manager whether `shop.example.at` is a **subdomain** of the same site or is operated as a **separate domain/site**. **Step 2 — Read up on identity:**\ Review the [**Main Domain Cookie**](/key-features/main-domain-cookie) concept (see the dedicated article) to understand cross-container identity sharing options. **Quick answer:** * **If the shop is a subdomain or path (but runs on the same domain):** * A **one-container strategy** is technically sound and commonly used. * You **don’t need multiple containers** for subdomains for technical reasons. * **If you prefer more organizational separation:** * You can create **multiple containers**, one per subdomain. * It’s still easy to keep configurations in sync: select in each **Tool** which **Containers** it should apply to—scaling shared setups is a one-click operation. **Identity behavior by default:** * When you create **multiple containers for the same main domain and its subdomains**, they can **share data (user ID)** via the **Main Domain Cookie**. * **Opt-out:** If you do **not** want data sharing between containers, disable the Main Domain Cookie feature in each relevant container. *** ### 3) Multiple owners (tenants) across different domains

**Example:** Several independent stakeholders each responsible for their own domain(s). **Recommended:** * Create **separate Accounts**, each with their own Containers. * **Note:** It is **not possible** to share DCP elements (Tools, Tags, Triggers, States, Functions) **across different accounts**. *** ### Main Domain Cookie (Overview) The **Main Domain Cookie** enables a **shared user identifier** across multiple containers on the **same primary domain and its subdomains** (e.g., `example.at`, `shop.example.at`). * **Use it when:** You want consistent identity and session logic across subdomains/containers. * **Disable it when:** You require strict data isolation between containers (e.g., compliance or organizational boundaries). See the [Main Domain Cookie](/key-features/main-domain-cookie) article for setup details, edge cases, and privacy considerations *** ### How to Reuse Configurations Across Containers (Same Account) 1. **Create or open a Tool** (or Tag/Trigger/State/Function) that should be shared. 2. **Select target Containers** inside the same account where the item should apply. 3. **Publish**—the configuration (including all settings) will be available everywhere you targeted. 4. **Maintain centrally**—update once, propagate to all selected containers. **Benefits:** Faster scaling, consistent governance, and reduced configuration drift. # Account Structure - FAQ

Do I need multiple containers for subdomains?

No. Technically, most subdomain setups work well with one container. Split into multiple containers only if it helps your organizational workflows.

Can I share items across accounts?

No. Accounts are isolated. Share and reuse configurations **only within the same account**.

Will containers on the same domain share user IDs by default?

If the **Main Domain Cookie** is enabled, yes—containers on the same main domain and its subdomains will share a user ID. You can disable this per container to prevent sharing.

What if I operate different country domains?

Create **one container per domain** within **one account** and reuse shared configurations across those containers.

How can I use the same tool or tag on multiple implementations?

How do I set up a tool only in one domain?

A domain is always connected to a single container; this is a 1:1 relationship. To implement a tool or a tag on only one container, you must select only this specific container.

Can I have only one global container on multiple websites (domains)?

No, a container, embed snippet, and DNS record are defined per domain. JENTIS is a first-party tool and can only be used in a first-party context. As the cookies set and associated with JENTIS are set via HTTP, this architecture does not support loading a third-party JS embed snippet, as the cookies would still be set in that third-party context via HTTP. This is a browser security and data privacy measure that can not be circumvented.

# JENTIS Cookies What cookies does JENTIS set? What do you need to know about them technically? JENTIS is a **first-party** **data** and **server-side** focused platform. The tag management and capture of consistent data rely on cookies and local storage. Some cookies are only set if you configure their respective tools, and some are set by default. In this article, you will find a complete list of cookies that are set by our service when using JENTIS: ### JENTIS Cookies When the JENTIS Code Snippet is implemented on a website, cookies are set according to one of the following conditions: * After the user actively grants consent to any installed tool in your JENTIS Platform OR * Consent administration is turned off (you have actively turned off the link between your Consent Management Platform and JENTIS vendors) OR * If a single tool’s vendor is configured with **JENTIS Essential Mode** and consent is actively granted/denied by the website visitor (user's decision is awaited) OR * A single tool's vendor is configured with “No Consent” (the decision of the user is not awaited) {% hint style="info" %} It’s important to remember that even though the JENTIS Cookie might be set before the user’s decision is considered, the tags will be fired according to your configuration on the JENTIS Platform. And, as a fully server-side and first-party data platform, no third-party cookies will ever be set on your user’s browser. {% endhint %} Based on the conditions above, the following cookies are set:

Cookie Name	Purpose	Lifetime
jts-rw	The JENTIS first party identifier (User-ID).	2 Years
jctr_sid	The JENTIS session identifier (Session ID).	30 Minutes
jts_log	Activates the JENTIS-Debug-Log function for developers (only set in Preview Mode for JTM users and developers).	1 Year

See also optional cookies: [#jentiscookies-toolspecificcookies](#jentiscookies-toolspecificcookies "mention") ### JENTIS Storage (Local/Session) The following browser storages are read and written when the JENTIS Code Snippet is implemented on a website:

Storage Name	Purpose
jentis.consent.data	Storage of Consent-Vendors and JENTIS Consent-ID Settings.
jentis.core.tracker.rawdata-controller	Storage of the ID-Relation between the different collected Document-Types.
jts_preview_version	Activates the JENTIS-Debug-Log function for developers (only set in Preview Mode for JTM users and developers).
jts_debug	Storage of JENTIS-Debug ID (only set in Preview Mode for JTM users and developers).
ongoingSession	A flag that indicates either if this is an ongoing session or not (boolean), the value is either “true” or “false”.

You can configure the maximum lifetime for cookies and local storage entries set by JENTIS. Read [Maximum Storage Lifetime](/jentis-dcp-elements/account-settings/maximum-storage-lifetime) . ### Tool-Specific Cookies JENTIS has multiple tools and configurations available. Those vary based on your individual configuration and the tools and tags you intend to use. Certain tags and tools may set cookies according to that tool's configuration. On each Tool documentation, you can understand which cookies and data storage will be used for that tool individually: [JTM Tools](/jentis-dcp-elements/tools) Optional Cookies by tool: * META ( [fbp/fbc Handling & Deduplication](/data-activation/connectors/meta/fbp-fbc-handling-and-deduplication) ) # Tracking Modes: Client Side, Server-Side, Hybrid This is an overview of the tracking modes or types of tags within JENTIS. Choose the right model for your privacy, performance, and feature needs. ## 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](https://docs.jentis.com/documentation/jtm-tools-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. {% hint style="warning" %} **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. {% endhint %} 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
(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
(i.e. third-party cookies)

| ✅ | ❌ | ✅ | Continue to learn more about the different tag types in 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. {% hint style="info" %} **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. You may note that there is a "/commands" request in the network protocol after installing JENTIS on your website. This constant pulling enables communication between the previously described hybrid tags. 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 corresponding pulling service to save resources on your site. {% endhint %} # JENTIS States Framework In this article, we will look into why events are so important in tracking and how JENTIS has internal concepts, like JENTIS States, to give you all the options to connect to your website environment ## Page Lifecycle, Events, and JENTIS Data Layer To understand the JENTIS States and how they function, it’s essential to first delve into the **Page Lifecycle** and **Events** concepts in web development and how the JENTIS Data Layer works. JENTIS States are built on an event-driven data model architecture, so they are often used interchangeably with events. However, there are key differences between them that we will explore in detail in this article. ### Page Lifecycle We all know what it means to browse a website—but what does that technically mean? In the web development community, there is a thing often described as the **page lifecycle**. A page lifecycle refers to the different stages a webpage goes through, from when it loads in a browser to when it is closed or navigated away from. It helps developers understand how a page interacts with the browser and when specific events happen so they can optimize performance and manage resources efficiently. ### Events **Events** are milestones or triggers that occur during the page lifecycle, signaling key moments in the lifecycle stages. Developers use these events to execute specific actions, like initializing scripts, managing resources, or saving data. **DOMReady** (`DOMContentLoaded`) and **On Page Load (**`load`) are specific events within the **page lifecycle** that indicate when certain things are ready on the webpage. * The **DOMReady** event happens after the HTML is fully loaded and the DOM (Document Object Model) is built. The page structure is ready for interaction, but images, styles, and other resources may still be loading. * The **On Page Load** event happens after the entire page, including all images, styles, scripts, and other resources, is fully loaded. the page is completely ready for use. {% hint style="info" %} If you want to know more about events, we recommend reading {% endhint %} ## JENTIS Data Layer The most resilient way to connect JENTIS to your data is to actively push data to the **JENTIS Data Layer**—read more on [JENTIS Data Layer: Push Data](https://docs.jentis.com/documentation/jentis-data-layer-fundamentals). With that approach, you will push descriptive data (product name, page title, etc.) and commands (events, tracking signals to invoke a state like pageview, virtual pageview, productview, etc.). We highly recommend implementing JENTIS using this approach with an aligned up-tracking map that displays all requirements and parameters. However, that is not the only option in practice. Signals and data can also be picked up during the **page lifecycle** and on certain **events**. These can be any interactions of the user or other applications submitting data to a generic (non-JENTIS flavor) data layer. {% hint style="info" %} In the following articles, we have covered popular examples and use cases for events translated into JENTIS States: * Listen to Google Tag Manager Data Layer Events: [Listen to Datalayer Events](/use-cases-and-tutorials/events-and-custom-states/listen-to-datalayer-events) * Clicks, Form Submits and Scroll Tracking: [Form Submit, Click and Other Actions](/use-cases-and-tutorials/events-and-custom-states/form-submit-click-and-other-actions) * History Change States and Virtual Pageviews: [History Change State and Virtual Pageviews](/use-cases-and-tutorials/events-and-custom-states/history-change-state-and-virtual-pageviews) Both implementation types, pushing or listening, will create a JENTIS State. The default push of events, page views, etc., is the same in the internal framework, and we will treat both options equally in the architecture. {% endhint %} ## JENTIS States Architecture Now that we better understand **page lifecycle**, **events,** and both options to **push active data on the JENTIS Data Layer** and/or listen to **page lifecycle events**, we can zoom out on the topic and understand the **States Architecture**. In the JENTIS States, there are the **triggers**. When a JENTIS State is activated, all variables and triggers will be evaluated as the event is called or the push is submitted. This is where the tags can now be activated, creating a logical chain of events, as in the following diagram:

In each JENTIS State, all variables and triggers are evaluated simultaneously. This ensures that each variable has a single, static value at that specific moment. As a result, all triggers and tags activated within that JENTIS State use the same consistent parameter values. For example, a new JENTIS State is created when a user clicks a button. This state signals the relevant triggers to evaluate whether they should fire based on the updated conditions (e.g., the button's ID or the current user session). Variables are re-evaluated at different moments (e.g., when a button is clicked on the same page a few seconds later). At that time, their values may change if they are updated due to changes in the website's presentation during interaction or loading. For a better understanding, here is an example:

JENTIS State	Variable "Page Title" Value	Variable "Price Tag" (CSS Selector - Text Value)
_jts.push({ track: "submit" });	"My Product Detail Page"	undefined
DOM ready	"My Product Detail Page"	19.99 €
Button Click	"My Product Detail Page"	19.99 €

Imagine a user is shopping in an online store. They visit a product page, and the price tag is initially hidden or dynamically loaded by JavaScript after the page starts rendering. You want to track the price tag value when the user clicks the "Add to Cart" button. 1. **Page Load**: When the page first loads, the JavaScript begins to render the page. * **JENTIS State 1**: The “Price Tag” element is not yet visible because the script hasn't rendered it. The **Price Tag variable** is **undefined** at this moment. 2. **DOM Ready**: After a short delay, the DOM is ready, and the page structure is fully loaded. * **JENTIS State 2**: The "Price Tag" is now visible on the page, and its value has been set (e.g., "19.99 €"). This value is available for tracking. 3. **Button Click**: The user clicks the "Add to Cart" button, triggering another event. * **JENTIS State 3**: The "Price Tag" variable is evaluated again, but now the price is available and can be tracked accurately. In this scenario, the **JENTIS State** ensures that the value of the "Price Tag" variable is consistent and tied to specific moments, such as when the DOM is ready or when the button is clicked. {% hint style="info" %} If you want to understand better how to create and manage JENTIS States on our platform, read [States](/jentis-dcp-elements/states) {% endhint %} # JENTIS States, Variables, and Scopes of Data Now that you understand how the [JENTIS States architecture](/core-concepts/jentis-states-framework) works, this article will explain more about individual data that you are accessing during the operation of a JENTIS State: **Variables**, which are elements describing an individual dimension of data (e.g., "Page Title,” "Product Name," or "Event Category."). A variable returns a value of a given property. For example, this article's "Page Title" variable value is "JENTIS States Framework”. Easy, right? But what about the scope of this data? What can I access, and at what time and/or event (JENTIS State)? There are two types of variables that are very different when it comes to JENTIS States: **pushed variables** that are event-driven (JENTIS Data Layer values) and **pulled variables** (that are accessed from a global scope, e.g., document, title). ### Pushed Variables Pushed variables are pieces of data tied to specific contexts, meaning they are available only when the corresponding event occurs. Below are the most common types of context-based variables, along with examples for better understanding: 1. **JENTIS Data Layer Variables** These variables are submitted in a `_jts.push` function call. For instance: {% code lineNumbers="true" %} ```javascript _jts.push({ track: 'pageview', page_category: 'sports', user_type: 'guest' }); ``` {% endcode %} In this example, `page_category` and `user_type` are variables bound to the `pageview` event, making their values (`sports` and `guest`) accessible in that context. A**ny further state can not access these values**, as the JENTIS data layer is reset with each submit (`track:"submit"` call). You will access those custom properties with your JENTIS Data Layer with the variable “Get JTM data layer value” when creating a new variable. For example:

2. **Click Variables** These variables are only available when a click action happens. For example, when a user clicks a button, the following variables might be available: * Clicked Element's Class: `class` * Clicked Text: `innerText` Example: In **JENTIS Tag Manager** > **Variables,** you can add a new **Click Trigger Properties** variable (which provides access to the clicked element and all its attributes and properties).

3. **GTM Data Layer values** These variables have a hybrid approach: * **Pull Variables**: They retrieve the earliest or latest observed value in the `dataLayer` when a JENTIS State is submitted. * **Event Object Variables** (beta): They allow direct access to `dataLayer` event objects as they are pushed, enabling granular contextual data retrieval without iterating through the `dataLayer`. Example of a `dataLayer` push: {% code lineNumbers="true" %} ```javascript dataLayer.push({ event: 'purchase', transactionId: '12345', revenue: 150 }); ``` {% endcode %} In this case, the variable `transactionId` can be accessed as a **pull variable** (`12345`) or directly from the **event object** during contextual evaluation. This is especially interesting for race conditions, where events occur not in full control for the tracking (tag manager). ### Pulled Variables Pull variables are dynamically accessed during a specific JENTIS State, retrieving values from the browser's current state or defined constants. These variables provide flexibility by pulling the most recent or relevant data available during evaluation. Below are examples for each type of pull variable to illustrate their behavior: 1. **Custom JavaScript Variables** These variables are calculated at the moment a JENTIS State occurs. **Example:** {% code lineNumbers="true" %} ```javascript function calculateDiscount() { return userCart.total > 100 ? 'eligible' : 'not eligible'; } ``` {% endcode %} If `userCart.total` is $150 at the time of the JENTIS State, the variable will return `"eligible"`. If evaluated at a later state when `userCart.total` drops to $50, the result will be `"not eligible"`. 2. **URL Parameters, Cookies, and JavaScript Variables** These variables are accessed directly from the browser's current context during the JENTIS State. **Example:** * **URL Parameter:** If the current page URL is `https://example.com/?campaign=spring`, the variable `campaign` will return `"spring"`. * **Cookie:** If a cookie named `userType` has the value `"member"`, it will be retrieved as `"member"`. * **JavaScript Variable:** ```javascript function(){ let currentPage = document.title; return currentPage; // If the page title is "Welcome", the variable will return "Welcome" } ``` If any of these values change between two JENTIS States, the new value will be pulled when re-evaluated. 3. **Constants** Constants behave like other pull variables, except their values remain unchanged regardless of state or context. You can create such variables JENTIS Tag Manager: **Variables** > **New** > **“Constant”**:

No matter when or how this variable is accessed, it will always return `10`. This is helpful with global IDs, such as a Measurement ID or a database table ID. 4. **GTM Data Layer Values** As with pushed variables, these values are pulled from the dataLayer when a JENTIS State is evaluated. **Example:**\ If the `dataLayer` contains: ```javascript dataLayer.push({ event: 'pageview', pageType: 'product' }); ``` The variable `pageType` will pull the value `"product"` if it exists at the time of evaluation. {% hint style="info" %} **Important Note:** If a value has not been pushed to the `dataLayer` before the JENTIS State submission, you may encounter **data inconsistencies** due to race conditions. For more on this phenomenon, read [this tutorial on race conditions](https://jsremote.jobs/tutorials/race-condition/). {% endhint %} ### About Server-Side Variables All variable values that are computed on the server side are treated the same as pulled variables. They must not be explicitly pushed, but they have one special property. Server-side variables are computed customarily for each tool's tag execution. So, even when executed on the same JENTIS State, a single server-side variable can have a different value than when examined in the context of a different tool. This is because the read-and-write operation with server-side local storage persists values in the context of the tool - read [Functions (Transformation)](/jentis-dcp-elements/functions-transformations) for reference. Data is, by default, not shared between tools on the server. ### Examples of State and Variable Combinations Now, let's put all this into practice one more time to see what and how variable values might differ on possible JENTIS States. All events appear on the same page (website), with no reloads and navigation, and are all in the same scope.

Event Time	JENTIS State	JENTIS Data Layer commands (push)	JENTIS Data Layer event name (push)	Page Title (pull)	GTM Data Layer - most recent event (pull)
10:00:45 AM	page_load	undefined (no JENTIS data layer value found)	undefined (no JENTIS data layer value found)	"My Website"	Assuming the dataLayer at this moment contains: `dataLayer = [{ event:"gtm.init", },{ event:"pageload" }]` This variable returns "pageload" (the most recent event property).	undefined (no click-element in this JENTIS State)
10:00:46 AM	The following data was pushed to the JENTIS Data Layer (by the frontend web application) JavaScript JS `_jts.push({ track:"pageview" }); _jts.push({ track:"submit" });` Copy	["pageview", "submit"] (a JSON parsed string describing an array of strings)	undefined (no JENTIS data layer value found)	"My Website"	Assuming the dataLayer at this moment contains: `dataLayer = [{ event:"gtm.init", },{ event:"pageload" }]` This variable returns "pageload" (the most recent event property).	undefined (no click-element in this JENTIS State)
10:00:50 AM	A button with the text "Click here" was clicked on the site, activating a click tracking.	undefined (no JENTIS data layer value found)	undefined (no JENTIS data layer value found)	"My Website"	Assuming the dataLayer at this moment contains: `dataLayer = [{ event:"gtm.init", },{ event:"pageload" },{ event:"gtm.click" }]` This variable returns "gtm.click" (the most recent event property).	"Click here"
10:00:55 AM	The following data was pushed to the JENTIS Data Layer (by the frontend web application) JavaScript JS `_jts.push({ track:"event", name:"my event" });` Copy	["event"] (a JSON parsed string describing an array of strings)	"my event"	"My Website"	Assuming the dataLayer at this moment contains: `dataLayer = [{ event:"gtm.init", },{ event:"pageload" },{ event:"gtm.click" }]` This variable returns "gtm.click" (the most recent event property).	undefined (no click-element in this JENTIS State)

# Key Features JENTIS provides a powerful suite of tools to manage and activate your tracking infrastructure across platforms: #### 1. **Server-Side Tracking** All tracking data is collected and processed on the server, minimizing client-side dependencies and reducing the impact of browser restrictions or consent refusal. #### 2. **Consent Management Integration** Works with any CMP (Consent Management Platform) or with JENTIS' native consent logic to dynamically adjust data collection per user. #### 3. **Hybrid Tracking Model** Combine client-side data richness with the security and reliability of server-side delivery. #### 4. **Data Layer Enrichment** Normalize and enhance data with custom rules, derived values, and parameter mappings before sending it downstream. #### 5. **First-Party Raw Data Export** Generate structured, anonymized, and complete first-party data streams for your own systems — ideal for BI, ML, or compliance audits. # Cookie Lifetime Extender Make your tracking resistant to the latest tracking preventions and extend your first-party cookie lifetime across all major browsers with the **Cookie Lifetime Extender.** Modern browsers like Safari and Firefox are enforcing stricter privacy policies to curb long-term and cross-site tracking. While these changes aim to protect users, they also limit the lifespan of first-party cookies, even when server-side tracking is in use. For example: * Safari (ITP 2.3+, especially version 16.4 and newer) limits first-party cookies to just **7 days** if they’re set via a server that doesn't share the same subnet (first 2 octets of the IP address) as the website content. * Firefox (ETP) applies similar restrictions, especially to cookies related to known tracking behaviors or domains not closely associated with the website host. These restrictions lead to: * Shortened cookie lifetimes (1–7 days); * Broken user journeys; * Missed conversions and attribution gaps; * Reduced campaign performance and reporting accuracy. With **JENTIS’ Cookie Lifetime Extender**, you can confidently preserve cookie lifetimes in the face of browsers' privacy restrictions. The feature ensures your tracking remains **accurate**, **durable**, and **compliant**, without compromising performance or setup complexity. * Maintain **full cookie lifetime** in Safari, Firefox, and other privacy-focused browsers; * Reduce data loss and conversion drop-offs; * Compatible with different infrastructures: Cloudflare, NGINX, Apache, IIS, Plesk, and more; * With built-in verification to ensure a reliable setup. # Enable the Cookie Lifetime Extender {% hint style="warning" %} Verification requires public access. Ensure the website is not behind authentication (for example, Basic Auth). {% endhint %} To enable the Cookie Lifetime Extender in your JENTIS container: 1. Navigate to **Settings > Containers**; 2. Either **create** a new container or **edit** an existing one; 3. In the **Basic Settings** section, enable the **Cookie Lifetime Extender.**

# Configure Your Tracking Once the Cookie Lifetime Extender is enabled: 1. Go to the **Tracking Configuration** tab; 2. Select your **web server or CDN provider** (e.g., NGINX, HAProxy, Apache, IIS, Cloudflare, Plesk); 3. Follow the **step-by-step guided setup.** We currently offer tailored instructions for: * [**NGINX**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/nginx-configuration-guide) * [**Plesk**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/plesk-configuration-guide) * [**Amazon CloudFront (AWS)**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/amazon-cloudfront-aws-configuration-guide) * [**IIS (Microsoft Server)**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/iis-microsoft-windows-server-configuration-guide) * [**Apache**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/apache-configuration-guide) * [**HAProxy**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/haproxy-configuration-guide) * [**Cloudflare**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/cloudflare-configuration-guide) * [**Azure**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/azure-cdn-configuration-guide) * [**Google Cloud**](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/google-cdn-configuration-guide) Detailed configuration guides for each infrastructure are linked in the Tracking Configuration tab. {% hint style="info" %} **Why do I need to configure my web server/CDN?** To extend cookie lifetimes reliably, your web server/CDN must act as a proxy that meets the strict requirements enforced by modern browsers like Safari and Firefox. Browsers such as Safari (with Intelligent Tracking Prevention) limit the lifespan of first-party cookies if they detect the cookie was set by a server not considered closely tied to your website, for example, servers with a different IP subnet or hostname. By configuring your web server to proxy tracking requests via your main domain or infrastructure, you ensure: * Cookies appear to be set directly by your site, not a third-party tracker. * You comply with the latest browser rules. * You regain the ability to store cookies beyond 1–7 days. This configuration allows JENTIS’ Cookie Lifetime Extender to do its job: protect your cookie durations and ensure accurate tracking across sessions and devices. {% endhint %} ### Verify Configuration {% hint style="warning" %} Please be aware that the Cookie Lifetime Extender will only be verified on "live" containers. Containers with the "stage" environment will not be checked and verified. {% endhint %} After completing your server setup: 1. Return to the **Cookie Lifetime Extender section** in your container; 2. Click on **Verify Configuration**; 3. JENTIS will check if the proxy is configured correctly and the cookie can persist beyond the browser-imposed limits. {% hint style="warning" %} Note: You must verify your DNS A Record before running the verification tool for this feature. {% endhint %} {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be set up on `https://domain.*/hash` it; however, if it is set up for `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. {% endhint %} ### WWW Configuration Guide (Optional) In case you wish to configure your CLE server-route with a `www` subdomain section in the forwarding (ie. for Content Security Policy compliance) then you must adjust the JENTIS JS Code snippet with an additional configuration. {% hint style="info" %} This section refers only to your server-forwarding configuration, not specifically if a website visitor visits your website on a "www" website URL. As by default JENTIS CLE assumes the forwarding address is based on your container configuration (which is your website domain without the "www"). If you configure the server-forwarding with "www" then you must apply the following change. If the forwarding is set without the "www" then you must not implement it. {% endhint %} It is possible to implement this as a "Code" Element in JENTIS Tag Manager: Codes section. Use the trigger "Before JENTIS Bundle Load". Implement this code: ```javascript if(window.jentis?.config?.jtm?.cookieExtender?.url !== undefined){ window.jentis.config.jtm.cookieExtender.url = "https://{{*alternative CLE domain*}}"; } ``` Exchange the value of the URL with your websites address and proxy path, ie. `https://www.mywebsite.com/jtshash`. ### Final Steps Make sure to publish the changes made in your container. Your tracking will now automatically route through the Cookie Lifetime Extender proxy. First-party cookies will **retain their intended lifespan**, even under the latest browser restrictions. # Cookie Lifetime Extender - Webserver/CDN Configurations {% content-ref url="/pages/6K2SRC21jXmByZ0kTM7O" %} [Amazon CloudFront (AWS) Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/amazon-cloudfront-aws-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/aYcWg7cwJiDbdpTIdSS6" %} [Apache Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/apache-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/aFasGquFdJqyPGP3ATzJ" %} [HAProxy Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/haproxy-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/cIa1vBrSiJni9FbP1kFJ" %} [IIS (Microsoft Windows Server) Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/iis-microsoft-windows-server-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/tYZIBOBKfeoDQark505i" %} [NGINX Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/nginx-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/o1iSgg0Wx5wjyh7xLfg1" %} [Plesk Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/plesk-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/PBtXrQeQwTAFCpNT7ayp" %} [Cloudflare Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/cloudflare-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/MC9mJpZUu2sP4ZHd1QkT" %} [Azure CDN Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/azure-cdn-configuration-guide) {% endcontent-ref %} {% content-ref url="/pages/FpzGHKwj83vHKFRtqkCg" %} [Google CDN Configuration Guide](/key-features/cookie-lifetime-extender/cookie-lifetime-extender-webserver-cdn-configurations/google-cdn-configuration-guide) {% endcontent-ref %} # Amazon CloudFront (AWS) Configuration Guide ### **Introduction** To forward requests to JENTIS via CloudFront, we need to add a new custom origin to the CloudFront distribution and define a behavior for the origin. *** ### **Prerequesits** * Admin access to the AWS Management Console. *** ### **Step 1: Create Origin** 1. Sign in to the AWS Management Console and open the CloudFront console at . 2. Navigate to Distributions 3. Open the distribution for your website 4. Navigate to Origins 5. Click Create origin

6. Specify the following: 1. Origin domain: `hash of the JENTIS container as subdomain` + `.` + `website domain`, e.g. [hash.yourwebsitedomain.com](http://hash.yourwebsitedomain.com/) 2. Protocol: HTTPS 3. Port: 443 4. MinimumSSL protocol: TLSv1.2 5. Name: [hash.yourwebsitedomain.com](http://hash.yourwebsitedomain.com/) (or any other) 6. Enable Origin Shield: No

7. Press Create Origin *** ### **Step 2: Define Behavior** 1. In your website distribution go to Behaviors; 2. Click Create behavior

3. Specify the following: 1. Path pattern: '/' + hash of the tracking container, e.g /hash 2. Origin and origin groups: [hash.yourwebsitedomain.com](http://hash.yourwebsitedomain.com/) (origin from the previous step) 3. Compress objects automatically: No 4. Viewer protocol policy: HTTPS Only 5. Allowed HTTP methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE 6. Cache HTTP methods: disabled 7. Allow gRPC requests over HTTP/2: disabled 8. Restrict viewer access: No 9. Cache key and origin requests → Cache policy: CachingDisabled 10. Cache key and origin requests → Origin request policy: Custom policy with:\ Headers: None\ Cookies: All\ Query strings: None 11. Cache key and origin requests → Response headers policy: None

4. Press Create Behavior *** ### **Step 3: Create CloudFront Function** A CloudFront Function is required to rewrite the request path to `/` before forwarding to JENTIS. 1. In the CloudFront console, navigate to **Functions** 2. Click **Create function** 3. Enter a name: `jentis-cle-path-rewrite` 4. Replace the default code with: ```javascript async function handler(event) { var request = event.request; request.uri = '/'; return request; } ``` 5. Click **Save changes** 6. Click the **Publish** tab → click **Publish function** 7. Go to your distribution → **Behaviors** → find `/hash` behavior → **Edit** 8. Under **Function associations** → **Viewer request** → select `jentis-cle-path-rewrite` 9. Click **Save changes** *** ### **Conclusion** You have now created your new custom behaviour, and your request will be forwarded from now on. {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} *** If you have any questions or suggestions, contact us through our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1). # Apache Configuration Guide This guide walks you through setting up an Apache web server on Ubuntu 22.04 with: * A reverse proxy configuration where your `website.com/hash` points to `hash.yourwebsite.com` * HTTPS support using Let’s Encrypt via Certbot *** ### **Prerequisites** * A server running **Ubuntu 22.04** * A registered domain name (e.g., `yourwebsite.com` ) * DNS A record pointing `yourwebsite.com` to your server’s IP *** ### **Step 1: Install Apache Web Server** ``` sudo apt update sudo apt install apache2 -y ``` *** ### **Step 2: Enable Required Apache Modules** ``` sudo a2enmod proxy sudo a2enmod proxy_http sudo a2enmod headers sudo a2enmod rewrite ``` Restart Apache to apply changes: ``` sudo systemctl restart apache2 ``` *** ### **Step 3: Configure Apache Virtual Host for site.com** {% hint style="info" %} Replace `yourwebsite.com` below with your actual domain {% endhint %} Create a new site configuration file: ``` sudo nano /etc/apache2/sites-available/yourwebsite.com.conf ``` Paste the following content: ``` ServerName yourwebsite.com DocumentRoot /var/www/html SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off ProxyPreserveHost Off Require all granted ProxyPass /hash http://hash.yoursite.com ProxyPassReverse /hash http://hash.yoursite.com/ ErrorLog ${APACHE_LOG_DIR}/yoursite.com_error.log CustomLog ${APACHE_LOG_DIR}/yoursite.com_access.log combined ``` Enable the new site and disable the default: ``` sudo a2ensite site.com.conf sudo a2dissite 000-default.conf sudo systemctl reload apache2 ``` *** {% hint style="info" %} Steps 4, 5, and 6 are only necessary if you do not have a signed certificate for your web server already {% endhint %} ### **Step 4: Install Certbot and Apache Plugin** ``` sudo apt install certbot python3-certbot-apache -y ``` *** ### **Step 5: Obtain SSL Certificate with Certbot** {% hint style="info" %} Replace `yourwebsite.com` below with your actual domain {% endhint %} ``` sudo certbot --apache -d yourwebsite.com ``` Certbot will: * Automatically configure HTTPS in Apache * Enable HTTP to HTTPS redirection * Reload Apache automatically *** ### **Step 6: (Optional) Test Auto-Renewal** Verify Certbot renewal service: ``` sudo systemctl list-timers | grep certbot ``` Simulate a dry run renewal: ``` sudo certbot renew --dry-run ``` *** ### **Step 7: Verify Setup** Test the proxy by visiting: ``` https://yourwebsite.com/hash ``` It should forward the request to: ``` http://hash.yourwebsite.com/ ``` *** ### **Conclusion** You now have: * Apache running on Ubuntu 22.04 * HTTPS enabled via Let’s Encrypt * A reverse proxy from `yourwebsite.com/hash` to `hash.yourwebsite.com` {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} *** If you have any questions or feedback, please open a request on our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1/group/1/create/220). # HAProxy Configuration Guide This guide walks you through setting up an HAProxy reverse proxy on Ubuntu 22.04 with: * A path-based reverse proxy where `yourwebiste.com/hash` points to `hash.yourwebsite.com` * HTTPS support using Let’s Encrypt via Certbot and a standalone method *** ### **Prerequisites** * A server running **Ubuntu 22.04** * A registered domain name (e.g., `yourwebsite.com`) * DNS A record pointing `yourwebsite.com` to your server’s IP *** ### **Step 1: Install HAProxy** ``` sudo apt update sudo apt install haproxy -y ``` Enable and start the HAProxy service: ``` sudo systemctl enable haproxy sudo systemctl start haproxy ``` *** ### **Step 2: Install Certbot (Let’s Encrypt Client)** ``` sudo apt install certbot -y ``` *** ### **Step 3: Generate SSL Certificate with Certbot (Standalone)** Temporarily stop HAProxy to allow Certbot to bind to port 80: ``` sudo systemctl stop haproxy ``` Run Certbot with the standalone plugin: ``` sudo certbot certonly --standalone -d yourwebsit.com ``` After success, your certificate will be in: ``` /etc/letsencrypt/live/yourwebsite.com/fullchain.pem /etc/letsencrypt/live/yourwebsite.com/privkey.pem ``` Restart HAProxy: ``` sudo systemctl start haproxy ``` *** ### **Step 4: Configure HAProxy** Edit the HAProxy config file: ``` sudo nano /etc/haproxy/haproxy.cfg ``` Example configuration: {% code overflow="wrap" lineNumbers="true" %} ``` global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners stats timeout 30s user haproxy group haproxy daemon ca-base /etc/ssl/certs crt-base /etc/ssl/private ssl-default-bind-options no-sslv3 ssl-default-bind-ciphers PROFILE=SYSTEM defaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 frontend http-in bind *:80 redirect scheme https if !{ ssl_fc } frontend https-in bind *:443 ssl crt /etc/letsencrypt/live/yoursite/yoursite.pem mode http acl is_hash path_beg /hash use_backend hash_backend if is_hash default_backend your_website_backend backend hash_backend mode http http-request set-path "%[path,regsub(^/hash, /)]" http-request set-header Host hash.yoursite.com server apache_server hash.yoursite.com:443 ssl verify none backend your_website_backend server apache_server 127.0.0.1:8080 check ``` {% endcode %} Check the config: ``` sudo haproxy -c -f /etc/haproxy/haproxy.cfg ``` Reload HAProxy: ``` sudo systemctl reload haproxy ``` *** ### **Step 5: Verify Setup** Visit: ``` https://yoursite.com/hash/ ``` It should forward the request to: ``` http://hash.yoursite.com/ ``` *** ### **Step 6: Auto-Renew Certificates** Edit the crontab: ``` sudo crontab -e ``` Add the following to renew and reload HAProxy every 12 hours: {% code overflow="wrap" %} ``` 0 */12 * * * systemctl stop haproxy && certbot renew --quiet && systemctl start haproxy ``` {% endcode %} *** ### **Conclusion** You now have: * HAProxy running on Ubuntu 22.04 * HTTPS via Let’s Encrypt * Reverse proxy from `site.com/x` to `x.site.com` {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} *** If you have any questions or feedback, please open a request on our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1/group/1/create/220). # IIS (Microsoft Windows Server) Configuration Guide ### **Introduction** This guide explains configuring **Microsoft IIS (Internet Information Services)** as a reverse proxy using the **Application Request Routing (ARR)** module. IIS with ARR allows you to forward incoming HTTP requests to one or more backend servers, providing benefits like **load balancing**, **centralized traffic management**, and **security filtering**. *** ### **Prerequisites** * Microsoft Windows Server with **IIS** installed. * IIS URL Rewrite Download and install the [URL Rewrite](https://www.iis.net/downloads/microsoft/url-rewrite) extension. URL Rewrite must be installed prior to ARR, as ARR depends on URL Rewrite. * IIS Application Request Routing (ARR) Download and install the [Application Request Routing](https://www.iis.net/downloads/microsoft/application-request-routing) extension. After installation, you should see the **Application Request Routine Cache** and **URL Rewrite** features in the IIS Manager. *** ### **Configuration Steps** #### **1. Activate Proxy** -Open the IIS manager, select the server in the **Connections** pane, and then double-click **Application Request Routing Cache** to open the feature.

In the **Actions** pane, click **Server Proxy Settings**.

On the **Application Request Routing** page, select **Enable Proxy**; and then in the **Actions** pane, click **Apply**. This enables ARR as a proxy at the server level.

#### **2. Create a URL Rewrite Rule** To route incoming requests to the backend server: 1. In **IIS Manager**, select the **site** you want to configure. 2. Double-click **"URL Rewrite"**.\ ![](/files/Fy8SJaGeZlSccxiDYiod) 3. In the Actions pane, click **"Add Rules…"**. 4. Under **Inbound Rules**, choose **"Blank Rule"** and click **OK**.\ ![](/files/OE06k3eV8eYIOUOZbCdc) **Rule Configuration**

Click **OK** in the Actions pane to save the rule. *** ### **Conclusion** You’ve successfully configured IIS with ARR as a reverse proxy. This setup allows you to forward requests transparently while retaining the ability to apply additional logic via rewrite rules or filters. {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} *** If you have any questions or feedback, please open a request on our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1/group/1/create/220). # NGINX Configuration Guide This guide walks you through setting up an Nginx web server on Ubuntu 22.04 with: * A reverse proxy configuration where yourwebsite.com/hash points to hash.yourwebsite.com * HTTPS support using Let’s Encrypt via Certbot *** ### **Prerequisites** * A server running **Ubuntu 22.04** * A registered domain name (e.g., yourwebsite.com ) * DNS A record pointing yourwebsite.com to your server’s IP *** ### **Step 1: Install Nginx** ``` sudo apt update sudo apt install nginx -y ``` Start and enable Nginx: ``` sudo systemctl start nginx sudo systemctl enable nginx ``` *** ### **Step 2: Configure Nginx Server Block for** yourwebsite.com Create a new config file: ``` sudo nano /etc/nginx/sites-available/yourwebsite.com ``` Paste the following content: ``` server { listen 80; server_name yourwebsite.com; location /hash { proxy_pass https://hash.yourwebsite.com/; proxy_set_header Host hash.yourwebsite.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 50M; } access_log /var/log/nginx/yourwebsite.com_access.log; error_log /var/log/nginx/yourwebsite.com_error.log; } ``` Enable the configuration: ``` sudo ln -s /etc/nginx/sites-available/yourwebsite.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx ``` *** ### **Step 3: (Optional) Install Certbot and Nginx Plugin** ``` sudo apt install certbot python3-certbot-nginx -y ``` *** ### **Step 4: (Optional) Obtain SSL Certificate with Certbot** Replace yourwebsite.com with your actual domain: ``` sudo certbot --nginx -d yourwebsite.com ``` Certbot will: * Automatically configure HTTPS in your Nginx config * Enable HTTP to HTTPS redirection * Reload Nginx automatically *** ### **Step 5: Verify Setup** Test the proxy by visiting: ``` https://yourwebsite.com/hash ``` It should forward the request to: ``` http://hash.yourwebsite.com/ ``` *** ### **Step 6: (Optional) Test Auto-Renewal** Verify Certbot renewal service: ``` sudo systemctl list-timers | grep certbot ``` Simulate a dry run renewal: ``` sudo certbot renew --dry-run ``` *** ### **Conclusion** You now have: * Nginx running on Ubuntu 22.04 * HTTPS enabled via Let’s Encrypt * A reverse proxy from yourwebsite.com/hash to hash.yourwebsite.com {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} *** If you have any questions or feedback, please open a request on our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1/group/1/create/220). # Litespeed Configuration Guide ### Prerequisites * LiteSpeed Web Server (OpenLiteSpeed or LiteSpeed Enterprise) installed and running * Admin access to LiteSpeed WebAdmin Console * A domain configured on a Virtual Host (e.g., litespeed.jtm-demo.com) with DNS pointing to your server ### Step 1: Create an External App (Web Server) Navigate to your Virtual Host, then open the **External App** tab and add a new Web Server definition with the following settings: | **Field (Web Server Definition**) | **Example Value** | **Notes** | | --------------------------------- | ---------------------- | ---------------------------------------------------------------- | | Name | hash\_proxy | Descriptive identifier referenced by rewrite rules | | Address | | Full URL of backend (HTTP or HTTPS). Match your upstream scheme. | | Max Connections | 100 | Range 1–2000. Tune based on backend capacity. | | Connection Keepalive Timeout | 60 | Use persistent connections to improve performance; -1 disables. | | Initial Request Timeout (secs) | 60 | Must be >= 1. Increase for slow upstreams. | | Retry Timeout (secs) | 1 | Backoff window before retrying failed connections. | | Response Buffering | No | Disable for streaming/low-latency responses. | Optionally set Environment variables and Notes as needed using PROPERTY=VALUE syntax. If your backend uses HTTPS with a certificate that is self-signed or not publicly trusted, ensure your LiteSpeed build trusts the upstream or use HTTP to the backend within a private network. ### Step 2: Enable and Add Rewrite Rules Within the same Virtual Host, open the **Rewrite** tab. 1. In Rewrite Control, set Enable Rewrite to Yes. Optionally adjust Log Level. 2. In Rewrite Rules, click Edit and paste the following rules, then Save: 3. Gracefully restart LiteSpeed to apply the changes (Actions > Graceful Restart). {% hint style="info" %} Please make sure to replace the values "hash" and "url.com" with your values from the DCP configuration page {% endhint %} ``` RewriteEngine On # The E=proxy-host part forces the correct Host header to the backend RewriteRule ^/?hash(/.*)?$ http://hash_proxy/$1 [P,L,QSA,E=proxy-host:hash.url.com] ``` ### Result Requests to /kndmjf on your domain will be proxied to the external app defined as kndmjf\_proxy, preserving query strings and forwarding the correct Host header to the upstream. # Plesk Configuration Guide ### **Introduction** This guide explains how to configure reverse proxy capabilities in your Plesk setup. A reverse proxy acts as an intermediary for client requests, forwarding them to a designated backend server. This setup enhances **load balancing**, **security**, and **caching** capabilities. *** ### **Prerequisites** * Admin Access to your Plesk installation * Your Website is running on Plesk *** ### **Configuration Steps** **Step 1 - Sign in into your plesk setup:**

#### Step 2 - Configure the directive:

\ Under “Additional nginx directives” add the location from /hash(the first part of the tracking URL) and add the proxy\_pass directive to the JENTIS tracking URL

#### Step 3: Save and apply After applying the directives, the webserver will restart and activate the new configuration. *** ### **Conclusion** Your Plesk should now act as a reverse proxy and forward all request to /hash to your tracking domain. {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} *** If you have any questions or feedback, please open a request on our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1/group/1/create/220). # Cloudflare Configuration Guide This Documentation is based on the following official Cloudflare Docs: [URL forwarding](https://developers.cloudflare.com/rules/page-rules/how-to/url-forwarding/) *** ### 1. Create the Cloudflare Worker You will write a simple JavaScript function to intercept the request, modify the URL, and fetch the content from the new location. #### Worker Code (JavaScript) 1. **Log in to your Cloudflare Dashboard** and navigate to **Workers & Pages**. 2. Click **Create Application** and then **Create Worker**. Give your worker a meaningful name (e.g., `reverse-proxy-hash`). 3. Replace the default code with the following script: {% code overflow="wrap" lineNumbers="true" %} ```javascript export default { async fetch(request, env, ctx) { const url = new URL(request.url); const hash = "{{your-subdomain-hash}}"; const domain = "{{your-domain}}"; const trackingDomain = `${hash}.${domain}`; if (url.pathname.startsWith(`/${hash}`)) { // 1. Define the destination const targetUrl = new URL(request.url); targetUrl.hostname = trackingDomain; // 2. Strip the '/{{hash}}' prefix so the second server sees the request as root '/' targetUrl.pathname = url.pathname.replace(`/${hash}`, ""); if (targetUrl.pathname === "") targetUrl.pathname = "/"; // 3. Create a new request to modify headers const modifiedRequest = new Request(targetUrl, request); // 4. CRITICAL: Tell the second server it's receiving a request for the subdomain modifiedRequest.headers.set("Host", trackingDomain); return fetch(modifiedRequest); } return fetch(request); }, }; ``` {% endcode %} ### 2. Deploy the Worker and Set the Route Once you have saved and deployed the worker code, you need to tell Cloudflare **when** to execute it. This is done by setting a **Route**. #### Route Configuration 1. Navigate back to your **Workers & Pages** dashboard and select your new Worker. 2. Go to the **Triggers** tab. 3. In the **Routes** section, click **Add route**. 4. Configure the route: * **Route:** `url.com/hash` (Replace `url.com` with your actual domain). * **Worker:** Select the Worker you just created (e.g., `reverse-proxy-hash`). 5. Click **Add route**. {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} # Azure CDN Configuration Guide ### Implementation steps #### Step 1: Go to your website Front Door configuration *** #### Step 2: Choose origin groups → Add origin *** #### Step 3: Set any name, uncheck Enable health probes *** #### Step 4: Select Add an origin

*** #### Step 5: Fill in origin details: 1. Set any name 2. Set Origin type = Custom 3. Set Hostname as following: hash of the JENTIS container as subdomain + . + website domain, e.g. [hash.yourwebsitedomain.com](http://hash.yourwebsitedomain.com/) 4. Press Add

*** #### Step 6: Go to Rule Sets → Add Routing Rule: 1. Set name 2. Set Condition: if Request URL Value Contains /hash (hash of the JENTIS container) 3. Set Action: Overwrite origin group = Yes, Origin group you created in the previous step, Forwarding protocol = Match the incoming request, Caching = Disabled 4. Save

*** #### Step 7: Go to Front Door configuration panel and choose edit the website route

*** #### Step 8: Add the rule from the previous step and press Update {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} # Google CDN Configuration Guide ### Prerequisites: To be able to configure the reverse proxy on a Load Balancer in Google Cloud you should be either a project [owner or editor](https://cloud.google.com/iam/docs/understanding-roles#basic), or you should have the following roles: `roles/compute.networkAdmin` and `roles/compute.instanceAdmin` *** ## Implementation steps ### Step 1 Create the NEG and internet endpoint: 1. In the Google Cloud console, go to the **Network endpoint groups** page. [Go to Network endpoint groups](https://console.cloud.google.com/compute/networkendpointgroups/list) 2. Click **Create network endpoint group**. 3. Enter the name of the network endpoint group: `jentis-fqdn-neg`. 4. For **Network endpoint group type**, select **Internet NEG**. 5. For **Default port**, enter `443`. 6. For **New network endpoint**, select **Fully qualified domain name and port**. 7. For the FQDN, enter: hash of the JENTIS container as subdomain + . + website domain, e.g. [hash.yourwebsitedomain.com](http://hash.yourwebsitedomain.com/). 8. For **Port type**, select **Default**, and verify that **Port number** is `443`. 9. Click **Create**.\ ![](/files/EPeYAJy4hd3yAI6RuJw6) *** ### Step 2: Create the backend service and add the internet NEG 1. In the Google Cloud console, go to the **Load balancing** page. [Go to Load balancing](https://console.cloud.google.com/networking/loadbalancing/list) 2. Select the classic Application Load Balancer of your website, and then select **Edit**. 3. Click **Backend configuration**. 4. In the **Backend services & backend buckets** menu, select **Create a backend service**. 5. Set the name of the backend service to `jentis`. 6. For **Backend type**, select **Internet network endpoint group**. 7. Select the protocol **HTTPS**. 8. Under **New backend > Internet network endpoint group**, select `jentis-fqdn-neg`, and then click **Done**. 9. Select **Disable Cloud CDN**. 10. In **Advanced configurations**, under **Custom request headers**, click **Add header**. 1. For **Header name**, enter `Host`. 2. For **Header value**, enter `hash.yourwebsitedomain.com`. 11. Click **Create**.\ ![](/files/DAzKhQQUqJC8buL5juhw) 12. Attach the backend service to an existing URL map 1. Click **Host and path rules**. 2. The first row or rows have Google Cloud services in the right column, and one of them is already populated with the default rule `Any unmatched (default)` for **Hosts** and **Paths**. 3. Ensure that there is a row with `jentis` selected in the right column. If it doesn't exist, click **Add host and path rule**, and select `jentis`. Populate the other fields as follows: 1. In **Hosts**, enter `*`. 2. In **Paths**, enter '/' and the hash of the container: `/hash`.\ ![](/files/xnonErghITFFhnaY4kow) 4. Click **Update** {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} # General Configuration Guideline ### Overview The Cookie Lifetime Extender feature can be implemented with any CDN or web server setup that supports HTTP 301 redirects. It works by issuing a 301 redirect to refresh cookies and extend their lifetime without affecting the user experience. This guideline provides a general overview of how to configure your CDN or edge network to ensure the JENTIS Cookie Lifetime Extender functions as intended. While specific steps may vary depending on your provider, the general concept remains the same across all CDN environments. *** ### Prerequisites Before you begin, ensure that: * The JENTIS Cookie Lifetime Extender is correctly enabled in your DCP according to the [main configuration guide.](/key-features/cookie-lifetime-extender/enable-the-cookie-lifetime-extender) * Your CDN or web server allows you to define custom redirect rules (e.g., 301 permanent redirects). * You have administrative access to modify these rules or page rules within your CDN or edge platform. *** ### Example Redirect Rule (Generic) Below is an example of a redirect configuration that applies to most CDN or reverse proxy environments: Source URL / Path → Example: `/hash`\ Destination URL → Example: `https://hash.example.com/`\ Redirect Type → `301 Permanent Redirect`\ Preserve Query String → `Enabled`\ Cache Level → `Bypass or standard (depending on CDN)` Tip: In most CDNs, this rule can be defined via a Page Rule, Redirect Rule, or Edge Function configuration. *** ### Verification Steps After applying the redirect rule: 1. Open your browser’s developer tools and go to the Network tab. 2. Trigger an event that invokes the Cookie Lifetime Extender (as defined in your JENTIS setup). 3. Verify that: * A 301 redirect occurs. * The redirect response leads back to the target URL. * The cookie(s) are correctly updated or extended. {% hint style="danger" %} After enabling Cookie lifetime extender, the DCP will give a proxy code that is expected to be setup on `https://domain.*/hash` however, if it is set up on `https://www.domain.*/hash` it will cause a CORS Error on the Cookie Lifetime Extender Requests. For more details on WWW configuration follow this [guide](https://docs.jentis.com/key-features/cookie-lifetime-extender/configure-your-tracking#www-configuration-guide-optional). {% endhint %} *** ### Notes * Always test changes in a staging environment before deploying to production. * If your CDN automatically caches redirects, make sure the rule is set to bypass cache for the extender path. * Refer to your CDN provider’s documentation for exact syntax or configuration UI for redirect rules. # Manually verify your CLE configuration We are already working on improving the debugging capabilities of the Cookie Lifetime Extender verification. Until improved error messaging is implemented, please find a guide on manually checking the status of the verification and possible reasons here. ## Installing Postman CLI For the manual verification check to be working, you need to install the official Postman CLI. You can find the guide [here](https://learning.postman.com/docs/postman-cli/postman-cli-installation/). ## Sending the Postman request Copy/Paste the codeblock below, replacing "\ and \ with the values from your DCP CLE settings page. ``` postman request POST 'https:///' \ --header 'Content-Type: application/json' \ --header 'Cookie: jts-rw={"u":"91409167904637152936318"}' \ --body '{ "client": { "clientTimestamp": 1743756071564, "domain": "." }, "cmd": { "key": "setcookie-itp-proxy", "data": [ { "name": "jts-rw", "value": "{\"u\":\"91409167904637152936318\"}", "exdays": 17280000 } ] } }' ``` ## Interpreting the response The responses to this request will be HTTP Response codes | Response Code | Meaning | | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | |

200

| The redirect worked, cookies were set with correct duration! You successfully configured the CLE. :tada: | |

404

| The redirect is not working and the request is ending up on a page that is giving back "404 - Not found". | # Main Domain Cookie With JENTIS, you can easily capture complete user journeys across all your subdomains. The **Main Domain Cookie** feature allows you to configure whether first-party identifiers (f.e. JENTIS User-ID) are implemented at your website’s main domain or subdomain level in your containers. With just one click, all data can be shared across the main domain and all its subdomains, ensuring consistent user sessions, unified tracking, and a clearer understanding of how users engage with your entire digital ecosystem. In this article, we’ll explain how to configure this when creating or editing a container, how to verify if the JENTIS cookie is set on your main domain or subdomain, and how to configure it. # Why does it matter which level the cookie is set? Imagine a user starts their journey on `shop.example.com` and later visits `blog.example.com`. If cookies are set at the subdomain level, their session won’t carry over, making capturing their interactions across these different subdomains difficult. This fragmentation disrupts your ability to analyze cross-domain behavior. The same happens on journeys between subdomains and the main domain. If a user starts their journey on `shop.example.com` and then visits `example.com` with cookies set at the subdomain level (`shop.example.com`), capturing their interactions across both of them won’t be possible. By setting cookies at the main domain level (e.g., `.example.com`), data can be shared across all subdomains. This ensures consistent user sessions, unified tracking, and a clearer understanding of how users engage with your entire digital ecosystem. > The **Main Domain Cookie** feature in JENTIS allows you to configure whether first-party identifiers are implemented at the main domain or subdomain level. This flexibility is essential for businesses managing multiple websites within the same main domain. With just one click, all data can be shared across the main domain and all its subdomains, ensuring consistent user sessions, unified tracking, and a clearer understanding of how users engage with your entire digital ecosystem. # Setting Cookie on the Main Domain This feature determines whether first-party identifiers (f.e. JENTIS User-ID) is stored at the website’s subdomain or main domain level in your containers. To configure this, go to **Account Settings** on the JENTIS Platform and click on **Containers**. Then, create a new container by clicking on **Add New Container**, or choose the container you want to edit and click on the three dots > **Edit**. You will see the **Main Domain Cookie** feature in the **Advanced Settings** on your container configuration.

{% hint style="info" %} By default, the Main Domain Cookie option is enabled, which means the first-party identifiers are configured to be set at the main domain level. {% endhint %} To demonstrate the impact of setting the JENTIS Cookie on the main domain or subdomain levels, let's consider the following example: JENTIS is implemented in this domain . The behavior of the JENTIS First-Party User ID (jts-rw cookie) can be observed based on whether the **Main Domain Cookie** is enabled or disabled: 1. **If the Main Domain Cookie is enabled** (Default)**:** * The cookie is set on the **main domain level**, in this case: `.jtm-demo.com`. * This means the cookie is accessible across all sub-domains of `jtm-demo.com`, such as `ckion-dev.jtm-demo.com`, `analytics.jtm-demo.com`, etc.\\ 2. **If the Main Domain Cookie is disabled:** * The cookie is set on the **current sub-domain** level, in this case: `ckion-dev.jtm-demo.com`. * This means the cookie is only accessible within the specific sub-domain `ckion-dev.jtm-demo.com` and not shared with other sub-domains. {% hint style="warning" %} **Important**: Disabling the Main Domain Cookie (which sets the JENTIS cookie on the subdomain) will result in users from the subdomain receiving different identifiers, such as JENTIS User-ID. This change can impact your tracking and data consistency. {% endhint %} In case you’ve already had a container configured before 11 Dec 2024: * If your container is configured to your main domain (e.g., `example.com`), the Main Domain Cookie option will be enabled. This means the first-party identifiers will be set at the **main domain level**. * If your container is configured to a subdomain (e.g,. `shop.example.com`), the Main Domain Cookie option will be disabled. This means the first-party identifiers will be set at the **subdomain level**. To change this configuration, follow the steps mentioned above. # How to verify the domain where the JENTIS Cookie is set To check in which domain the JENTIS First-Party Cookie is set, follow these steps: 1. Open your browser's Developer Tools by pressing **F12**. 2. Navigate to the **Application** tab (or its equivalent, depending on your browser). 3. In the sidebar, go to **Storage > Cookies** and select the domain of your current website. 4. A list of cookies set on your domain will be displayed.\\ Look for the **jts-rw** cookie name, which stores the JENTIS First-Party User ID. In the **Domain** column, you can see the specific domain where the cookie is set:

If we use the previous example domain , this means: * With the Main Domain Cookie enabled, the domain should appear as `.jtm-demo.com`. * With the Main Domain Cookie disabled, the domain should appear as `ckion-dev.jtm-demo.com`.

Disabled	Enabled
`Domain: .ckion-dev.jtm-demo.com`	`Domain: .ckion-dev.jtm-demo.com`

*** If you have any questions or suggestions, contact us through our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1). # Automatic Data Layer Mapping Track faster with your existing website setup JENTIS can automatically detect and map standard behavioral and e-commerce events from your website’s existing data layer during new container creation. This means you can start collecting relevant tracking events immediately without rebuilding your data layer, writing custom bridge logic, or manually configuring every event from scratch. > **In short:** JENTIS uses your existing tracking setup and translates standard events into the JENTIS schema automatically. ## Why this matters Many websites already have a data layer in place. It may be used by tools such as tag managers, analytics platforms, or e-commerce integrations. Previously, using this data in JENTIS often required a technical setup step: * defining how the existing data layer should be read, * mapping existing events to JENTIS events, * configuring values and parameters, * validating the setup manually, * and often involving developers or implementation specialists. {% hint style="info" %} Automatic Data Layer Mapping reduces this friction. Instead of treating JENTIS onboarding as a migration project, JENTIS can work with your existing setup from the beginning. {% endhint %} ## What JENTIS detects automatically During container creation, JENTIS checks whether standard behavioral or e-commerce events are available on the website.

When supported events are detected, JENTIS creates mappings into the JENTIS schema automatically. Typical examples include: | Event category | Example events | | ----------------- | ------------------------------------------------------------ | | Behavioral events | Page views, clicks, form interactions | | E-commerce events | Product views, add to cart, checkout steps, purchases | | Data layer values | Product IDs, product names, prices, quantities, order values | The exact detected events depend on the data layer implementation available on the website. ## How it works #### 1. Create a new container When you create a new container, JENTIS analyzes the website setup and checks for existing data layer structures. You can check how to create a container here: [Create a Container](/jentis-dcp-elements/account-settings/container-administration/create-a-container) #### 2. JENTIS detects standard events JENTIS identifies supported events and values that can be mapped into the JENTIS tracking schema. This allows the container to start with useful event mappings instead of an empty technical configuration.

#### 3. Events are mapped automatically Detected events are translated into the JENTIS schema. For example, an existing e-commerce purchase event can be mapped to the corresponding JENTIS purchase event, including relevant order and product data.

*** #### 4. Review and adjust mappings The DCP lists the created mappings so users can review them before or after activation. Users can: * preview mapped events, * disable mappings that should not be used, * adjust existing mappings, * extend the setup with additional mappings, * validate whether the captured data matches expectations. \[Screenshot placeholder: Mapping list with preview, edit, disable actions] *** ## Benefits #### Faster onboarding New containers can start tracking key events immediately. This reduces setup time from days or weeks to a much shorter onboarding flow. #### Less technical implementation effort Users do not need to manually recreate standard tracking logic that already exists on the website. #### Easier migration from existing setups JENTIS can work with the customer’s existing data layer. This reduces the feeling of a technical migration and makes adoption easier. #### Better first-time experience Users can see data flowing earlier, validate the setup faster, and understand the value of JENTIS sooner. #### Full control after setup Automatic mappings are not a black box. They can be reviewed, disabled, edited, or extended in the DCP. *** ## Who is this feature for? Automatic Data Layer Mapping is useful for teams that already have tracking structures on their website and want to activate JENTIS without a heavy implementation project. It is especially helpful for: * marketing teams that want faster time to value, * analytics teams that want to validate data quickly, * implementation teams that want to reduce repetitive setup work, * agencies or consultants onboarding multiple customers, * sales and proof-of-concept scenarios where “works out of the box” behavior is important. *** ### User control and customization Automatic mapping gives you a starting point. You remain in control of the final tracking setup. After the mappings are created, you can manually adapt them in the DCP. | Action | Description | | -------- | ----------------------------------------------- | | Preview | Check which events and values JENTIS detected | | Disable | Turn off mappings that should not be used | | Edit | Adjust how an existing event is mapped | | Extend | Add further mappings for custom business logic | | Validate | Confirm that event data is captured as expected | {% hint style="info" %} ### Important notes Automatic Data Layer Mapping is designed to cover standard and commonly used event structures. Custom or highly specific tracking logic may still require manual mapping or additional configuration. The feature is intended to reduce implementation effort, not remove the need for validation. We recommend reviewing the generated mappings before using them in production reporting or activation workflows. {% endhint %} ### Summary Automatic Data Layer Mapping helps JENTIS work with your existing website tracking setup from the start. It reduces technical setup work, accelerates onboarding, and makes it easier to activate tracking without treating the implementation as a migration project. With automatic detection, generated mappings, and full control inside the DCP, users can start faster while still keeping the flexibility to adapt the setup to their needs. # Health Center The JENTIS Health Center helps you detect and investigate tags with unusually high failure rates or dropped triggers in your server-side tag manager container. It provides a centralized view of tag health, recent issue history, and notification settings, enabling teams to identify problems earlier and reduce the impact of broken or degraded tag execution. ## Overview Health Center monitors tag execution and highlights tags that show signs of degraded behavior. A tag may be marked as unhealthy when it has an elevated failure rate or when triggers are dropped before the tag can run. ### Filtering by tool or container Health Center supports two primary scopes: | Scope | Description | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Container level** | Shows tag health across the entire server-side container. Use this to understand overall container health and identify broad problems. | | **Tool level** | Shows tag health for tags associated with a specific tool. Use this when investigating issues related to a particular integration, destination, or vendor. | Filtering helps reduce noise when a container contains many tags or when ownership is split across different teams.

Health Center filtered by Tools -> Containers

Health Center filtered by Containers -> Tools

## Tag status Each monitored tag has a health status that reflects its current behavior.

The status view allows you to: * Review the current health of each tag * Filter tags by **tool** * Filter tags at the **container level** * Identify tags with active or recent issues * Compare healthy, degraded, and failing tags in one place A tag’s status is based on observed execution behavior. When the Health Center detects an abnormal failure rate or trigger drops, the tag may be flagged with an issue. ## 24-hour issue history Health Center includes a rolling **24-hour** history for each tag. The history view shows: * Periods with high failure rates * The number of dropped triggers * Recent changes in tag health * Whether an issue is ongoing or has already recovered ### Issues and UI notifications When the Health Center detects abnormal tag behavior, it creates an **issue** in the UI. Issues are displayed directly in the Health Center interface to draw attention to tags that may require investigation. An issue may indicate: * A high tag failure rate * A sudden increase in failures * Dropped triggers * A recurring or unresolved tag health problem Use issues as the starting point for investigation. After selecting an issue, review the affected tag, recent history, and any related configuration changes.

*** ## Email notifications The Health Center can send email notifications when issues are detected. Notification settings allow you to configure: * Who receives Health Center emails * A suppression window to avoid repeated notifications for the same or similar issues ### Notification recipients Recipients should usually include the team or individuals responsible for maintaining server-side tags. Recipients can be either active user accounts within the DCP or custom email addresses. The recipients can be set in the "Settings" sub-menu of the Health Center.

### Suppression window The suppression window controls how often email notifications are sent for recurring issues.

For example, if a tag continues to fail after an issue has already triggered an email, Health Center will wait until the suppression window expires before sending another notification for that issue. This helps teams focus on meaningful alerts without receiving repeated emails for the same ongoing problem. ## Limitations Health Center detects observed tag health issues based on execution behavior. It does not automatically determine the root cause of a failure. A detected issue may require further investigation into: * Tag configuration * Trigger conditions * Server-side container configuration * Vendor endpoint availability * Authentication or permission problems * Network or request-format errors # JENTIS DCP Elements # Glossary - JENTIS Terms and Components **JENTIS Account**: This is your single point of entry to the JENTIS Data Capturing Platform (DCP). Managing multiple accounts with one login is currently not supported. **JENTIS Container**: A single definition of a data processing unit for the JENTIS DCP. A JENTIS account consists of one or multiple containers. Each container is connected to a particular website (domain), while a single domain can hold one or multiple containers. Each container has a unique DNS A record and JS Code snippet. Please check [JENTIS Accounts and Containers](/getting-started/quickstart/create-your-first-container) for more details. **Connectors**: \~ in JENTIS refers to the software or platforms used to manage tags on a first-party company’s behalf. A single connector instance (see below) is a configuration based on your settings for a given connector. **Connector Instances**: A configuration of a connector in JENTIS. A single connector can be installed multiple times with different configurations. Unlimited connector instances of the same connector can be installed on the same container. Each connector instance consists of tags that define executable data transmission. **Tags**: Tags are snippets of code (JavaScript) used to collect and send information to third parties. They are used for various purposes like tracking visitor behavior, persisting data and applying transformations, integrating third-party services (like analytics or advertising platforms), and monitoring website performance. JENTIS tags can be executed client-, server-side, or hybrid ( [JENTIS Tags: Server-side, Client-side and Hybrid](/core-concepts/tracking-modes-client-side-server-side-hybrid)). A tag in JENTIS is always connected to a connector instance. **Triggers**: Triggers are conditions that determine when a tag should be activated or fired. They are set within the tag management system and can be based on user interactions, such as clicks, form submissions, page loads, or other custom events. Variables determine these dynamic values in triggers. **Variables**: Variables in tag management are named placeholders for values that can change, such as user IDs, transaction amounts, or any other dynamic data. They are used in tags and triggers to pass specific data points or to control the behavior of tags based on the variable's value. Variables are computed either on the client- or server-side based on their configuration. **JENTIS Event States**: \~ refer to the various stages or conditions under which certain events are tracked or tags are fired. A state holds the technical definition that is the foundation to activate the framework. All triggers and variables are computed on each state, and trigger conditions are applied. The states guarantee a seamless integration of client- and server-side operation (so a single variable can be used on both ends without the need to define it on each end (client and server) anew). **JENTIS Data Layer**: A data layer is a central repository of structured data on your website or web application. It acts as a uniform data source that a tag management system can use to collect and send information to various analytics, marketing, and other third-party services. The data layer is typically implemented as an object in a site's global scope (window). JENTIS can connect to generic data layer definitions (such as Google Tag Manager) or to our preferred format of the JENTIS Data Layer ([JENTIS Data Layer: Push Data](https://docs.jentis.com/documentation/jentis-data-layer-fundamentals)). **Plugins**: \~ are additional modules or extensions that enhance the functionality of the tag management connector. They can provide extra features like generating a native integration for video tracking or customization that are not part of the core system. **Custom Code**: This refers to any code written specifically for your website or application that goes beyond the standard functionalities provided by the tag management system. Custom code can be used for complex tracking setups, unique user interaction tracking, or integrations not natively supported by the system. Custom code can only be executed client-side. **Vendors**: In tag management, vendors are third-party services or platforms for implementing connectors and their tags. Examples include Google Analytics, Facebook Pixel, and various advertising platforms. Each vendor is connected to a Consent Management Platform with the JENTIS Consent Engine. At the same time, a connector instance in JENTIS is always connected to a vendor. Multiple connector instances can connect to the same vendor or each to a custom vendor. **Essential Mode**: Each vendor has a setting of how to apply consent information. One of those options is the Essential Mode. This provides a fallback configuration on a tag-level configuration. In the fallback (of a situation where consent is not granted) a different configuration of that tag will be applied. See [JENTIS Essential Mode](/jentis-dcp-elements/tags/how-to-configure-a-tag/essential-mode). # Connectors In the context of the JENTIS Data Capturing platform, a connector is an abstract object that stores the configuration settings for a data recipient. This recipient can be an external third-party data application (such as web analytics or data science connectors), marketing and advertising technology, or even an internal data storage system. The configuration settings include the properties of individual networks or applications that are required for their basic setup. This means that you can adjust a setting for multiple tags in your JENTIS Tag Manager configuration using a single entry point. If you're looking for a comprehensive list of connectors supported by JENTIS, please follow this link: JENTIS Connector Knowledge Base # What is a Connector Instance? A connector instance is used to define the properties of a service that you want to enable using the JENTIS Data Capturing platform. Connectors, in this case, refer to partner networks and databases such as Facebook, Google Ads or Google Analytics. Additionally, a connector can also be a configuration for a custom endpoint that your JTM server needs to interact with. A configuration instance of a defined connector is referred to as a "connector instance configuration". You can have multiple configuration instances of the same connector in your JENTIS DCP, for example, "Google Analytics Europe" and "Google Analytics US" to cater to different configurations per region. The most important wording in short: * **Connector**: A service definition in JENTIS Data Capturing Platform, ie. “GA4”. * **Connector Configuration** (or *Connector Instance*): A configuration of a connector in your account with a certain purpose, ie. “GA4 - [website.com](http://website.com)”. You can have multiple connector instances of the same connector configured in your account. # Advanced Settings On the advanced settings tab of a tool instance, you can adjust the **vendor setting**, manage the **HTTP request headers** to be shared, and add **custom global variables** to this tool.

# Vendor Settings In JENTIS, every tool needs to be assigned to a vendor. By default, each tool has an equivalent vendor with the same name. However, you can create custom vendors with different settings and map your tool to your preferred vendor. This way, you can have more control over the tool-vendor mapping. Further, a vendor, based on its configuration, can be connected to a CMP (consent management platform) to receive consent information and operate based on the consent provided. For more information on this topic, please refer to JENTIS CMP Connectors # HTTP Headers Management HTTP headers are key components of web communication. The Referer and User-Agent headers provide valuable context about where requests come from and the devices making them, but they can also raise privacy and security concerns. In the JENTIS Platform, you can control whether these headers should be shared in a server-side tag. ### What Are the Referer and User-Agent Headers? The `Referer` tells a website where the user came from. For example, if you click a link on a news website to visit an online store, the request sent to the store includes a Referer header showing the news website’s URL. This header, however, can unintentionally expose sensitive information, such as search terms typed into a search engine or URLs containing personal identifiers. Malicious actors could misuse this information to track users across websites. The `User-Agent` header provides information about the browser and device making the request, such as: `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/114.0.5735.199 Safari/537.36`. The potential issue is that it can be used to fingerprint users based on their browser, operating system, and device details, making it easier for advertisers or malicious actors to track individuals across the web. ### Manage the HTTP Headers on server-side tags In the JENTIS Platform, you can control whether these headers should be shared in a server-side tag. 1. In the **Tools** section, select the tool you want to edit or create a new one.

2. Go to the **Advanced Settings** tab. In the HTTP Headers section, select which headers you would like to share in the tag or unselect the box for the ones you would like to remove. {% hint style="info" %} By default, both options will be **enabled**. {% endhint %}

{% hint style="warning" %} **This option is only available for tags implemented on the server side.** {% endhint %} When a tag (e.g., JavaScript snippet) is implemented on the client side, it runs inside the user’s browser. The browser automatically generates and sends HTTP headers as part of its internal request process. While JavaScript can control some aspects of a request (like the body of a POST request), headers like `User-Agent` or `Referer` are off-limits to ensure consistent and secure browser behavior. When requests are handled on the server side, the server itself acts as the "client" making requests to other servers. Unlike a browser, a server operates without the sandbox or security restrictions imposed on client-side code. This gives developers full control over the HTTP request. This is why modifying the headers that will be shared in a tag is only possible with server-side tags, and not hybrid or client-side ones. *** If you have any questions or suggestions, contact us through our [Helpdesk](https://jentis.atlassian.net/servicedesk/customer/portal/1). # Backend Data Storage Each configuration instance of a tool in your JENTIS account will function within its own scope. This means that data cannot be shared between different tools in JENTIS, ensuring enhanced privacy and data security. Whenever a value is saved on the JENTIS server for a tool, the action executed is saved only for that specific tool. For instance, if a tool saves a "Client ID" value to identify a website visitor, only that specific tool will have access to it. Even if two tool instances are of the same class, such as "Google Ads - EU" and "Google Ads - US", they cannot access each other's data. With the feature to set custom Backend Data Storage options in a tool, you can now share data for the same tool classes. Here is how to configure this setting. Let's examine it in the example of Google Ads. ### **Activate Backend Data Storage - Background and Example** Let's cover some background first. Google Ads requires a parameter value that must be stored from page entrance up to the event of conversion (which might be on a later page or session of a visitor). It's the "gclid" URL query parameter value that must be stored, and the best option is to use server-side storage, as it is the most secure and reliable option. JENTIS, by default, will persist this information when a Google Ads tool instance is installed in your account with all tags automatically created (you must select this option when the tool is configured initially). Now, whenever a user enters the website and this tool is executed (based on the triggers and consent information), it will persist the "gclid" value on the server. For more information on which Google Ads tags to configure, please refer to the tools documentation: [Google Ads](/data-activation/connectors/google-ads) In a manual configuration, you must activate the "Google Ads Campaign Detection" tag to persist any "gclid" parameter value received at the page entrance. As soon as the conversion signal is received (again, based on the triggers and consent information), it will access the accordingly stored information to submit the value of the "gclid" parameter to Google Ads. This access refers to the backend storage that holds the information. Generally this is on a per-tool-instance basis, as mentioned before, each tool must persist its own data. Here comes the option to share data between tool instances. You can adjust the "Default Storage" setting to select another tool of the same class. If you do so, both tools will share the same storage.

There will be a hint if data is shared in the menu item. In the Google Ads example, if multiple instances of this tool are installed in your account and you select this option, the "gclid" value will be available to all tool instances. So, a conversion tracked in any of the tools will access the "gclid" value from any other tool, possibly enhancing your data quality as fewer restrictions on sharing data now apply. This option is generally a good idea when multiple containers are used or when multiple instances of the same tool are configured. Please also make sure to check our guide [Sharing information - Cross-Domain Tracking](/use-cases-and-tutorials/sharing-information-cross-domain-tracking), which is often related. Data sharing might possibly also be technically restricted based on different website domains. Further, for custom implementations and code, you must be aware that this setting (Backend Data Storage) on a tool affects the associated functions "storage.write" and "storage.read". For more details, see: [Server-Side Storage Interface](/developer-guide/server-side-storage-interface) # Optional Constants Some tools come with optional global settings: "Optional Constants". Just as with the main "Constants" on the tool, you can configure different values here that you can then access in the tool's tags. Further, you can configure your own tool constant values to refer to in the tags. Again, those values can be a default setting or set to individual values on the container and environment levels. # Tags The data capture and load process of JENTIS centers around the submission of data to partners and networks. This involves setting up rules and configurations that dictate when to send what data to which partner. Tags play a crucial role in this process by enabling detailed configuration of individual parameters and values to be transmitted to the intended data recipient. JENTIS Tag Manager allows for flexible and scalable tag configurations, enabling multiple setups in one configuration. Every tag in your JENTIS account consists of the following parts: * **Tool**: Select a tool you previously created that will hold global configurations for this tag. * **Template**: JENTIS includes templates for tags that cover use cases per tool, ie. the “pageview” template for Google Analytics. * **Trigger**: Every Tag references a trigger that defines conditions on when to actually activate a tag and submit data to a recipient. * **Field Configuration**: Here you will define every parameter that needs to be mapped to a value that will be submitted to the recipient. # Create a new Tag Navigate to the **Server Tag Manager** section in the main navigation.

In the list of all tags configured in your account you have now the option to create a new tag (clicking on the "Add New Tag"-button, located at the lower right corner of the screen). Every tag needs a name. A common syntax is to use the tool name combined with the template or event description, ie. “Google Analytics – Pageview”. Additionally every tag is associated with a tool (that you previously created). This way any tag can access global configuration parameters and re use those values.

Templates follow a tools data schema to capture data. For Google Analytics in this example the given templates follow GAs data model of Pageviews, Events and enhanced Ecommerce Tracking. Each JENTIS Tag Template will provide a different tag runtime and configuration options in the next steps.

The actual configurations of a tags parameters and their respective values is defined in the next step: “Configure Template”. Here you can define parameters values according to a template. Later this setup can be changed and adjusted.

The last step is now to also select a trigger that will activate this tag newly configured.

# How to configure a tag? Mapping parameters of a tag to data references (variables) is key to receive the right data. All tools have custom parameters that fit their interface protocol (API) which is one side of the table. On the other side is your JENTIS configuration that holds all the values that you implemented for tracking (JENTIS Data Layer, fetching data dynamically or calculating and enriching data). So the job is to bring both sides together by mapping the tools fields to values of variables available to your JENTIS Tag Manager. In every tag the JENTIS Tag Template provides individual configurations to provide a given parameter (ie. “Page Title” for Google Analytics if it is a Pageview-tag or an Event Category if it is an event type hit). Now you can select any JENTIS Tag Manager Variable value to submit it as the tag is triggered and hence data streaming is activated.

You can select any variable that you manually configured previously (as a data source) or that is by default available in JENTIS Tag Manager. All JENTIS integrations start with a rich set of default variables to work with. How to: * **add a variable to a field**: simply click the "+" icon to open the variable selection modal * **apply order of elements**: drag & drop elements in place as required * **apply functions on elements**: drag & drop a variable into a function-box * **add static text string:** either CTRL+left-mouse-click (CMD+lft-mouse-click) to open text-input or add a text-input in the Variable Selector * **delete elements**: either SHIFT+left-mouse-click or right-mouse-click the element and select the “trash”-icon * **more options**: right-mouse-click an element to get a context-menu of an element # Essential Mode With the [Essential Mode](https://jentis.atlassian.net/wiki/spaces/DD/pages/842727535) enabled in your JENTIS Tag Manager you will get new configuration options in a tag. Now a tag has two columns for each tag field configuration. The following toggle-button will show/hide the settings (this button is not activating any functionality but simply a visual element to the UI):

Each value of a parameter can be treated according to the consent of a user. Instead of configuring a tag twice (with two different triggers that act on consent and without) this makes each tag configuration more convenient. Simply select all parameters that must be anonymized or pseudonymised in the “Essential Mode Value” column. # Extendable Parameters Some configurations have extendable parameters, like an index based dimension value.

# Maintenance Elements in JENTIS are flexible in terms of customization. You can even edit all the default settings of tags, triggers, variables, etc. This flexibility brings a new icon to the interface, so that you can see which parts are customized and which are on default settings:

This indications help you to see where an element is receiving updates and which elements will remain as they are, as they are customized and are not receiving updates. # Pause and Activate Tags You can temporarily disable and quickly reactivate your Tags anytime:

#### **How to Pause or Activate a Tag** 1. In the **Server Tag Manager**, navigate to **Tags**. 2. You can use the **toggle** next to each tag to pause or activate it, or you can click the **three dots** on the right and select **Pause** or **Activate**. 3. Additionally, you can also pause or activate a tag when editing it. 4. A confirmation message will appear before applying the change. Each tag's Change Log shows all pause and activation actions. Additionally, the **Tools** section shows the number of **active and paused tags** for each tool. Changes must be **published** for them to take effect after pausing or activating a tag. Only after publishing will the paused tags stop firing, and the activated tags start working again. # How to duplicate tags? You can easily duplicate your tags and their configuration on the JENTIS Tag Manager. By simply selecting the tag and clicking on the "Copy" option, you can either duplicate it with the same tag configuration or modify the values before saving.

# Multi-Tag Edit ### Problem When managing tags in your system, you may encounter situations where several tags share identical fields. Previously, updating the value of a field for multiple tags required manual editing of each tag individually, which was particularly cumbersome for list items intended for uniform tracking across tags. This process was not only time-consuming but also prone to inconsistencies. ### Our Solution With the Multi-Tag Edit on the JENTIS Tag Manager, users can update multiple tags simultaneously, significantly saving time and ensuring uniform field values across different tags.

### How to use it 1. Access the tags section on the Tag Management and click on the "Multi Tag Edit" button;

2. Select the type of tool which tags you would like to edit. E.g.: Google Analytics, Google Analytics 4 Server-Side.

3. Select the tags you want to edit simultaneously. On the "Name” column, you can check to which tool configuration each tag is associated.

4. You'll find on the left sidebar a selection of fields that are common across all tags. By selecting any of these fields, they will be automatically updated across all the tags you previously selected. You can also click to select all common fields if you want to edit everything.

5. The fields within the tags are categorized into three types for ease of management: * simple fields * grouped fields * list fields **`Google Analytics - Join ID (jid)`** here is a simple field

`Products` here is a grouped field with the selected simple field `Product ID`

`Custom Metrics` here is a list field

[Check here how to edit each type of field](https://docs.jentis.com/documentation/what-are-the-types-of-common-fields-and-how-to-edi). 6. You have several options for customizing the data you input into these fields: 1. **Variables**: Choose from four types of variables to insert into your fields. 2. **Text Inclusion**: Opt to include plain text if variable functionality is not required. 3. **Function Wrapping**: For more complex data manipulation, you can wrap variables with a function to perform specific operations or calculations.\ This flexible approach allows you to tailor the data entry process to meet the specific requirements of your tagging system efficiently.

7. When your adjustments are complete and you are satisfied with the setup, click on the "Update Tags" button. This action ensures that only the fields you have selected are updated across the corresponding tags, maintaining accuracy and consistency in your tag management. 8. Once you save the changes, you can go back to all your tags, order by edited date and check the latest ones that were changed. You can also click on the three dots, then “change log” and see exactly which values were changed in that tag.

# What can be edited using the Multi-Tag Edit? With the Multi-Tag Edit Feature, you can easily update the common fields and their values on several tags simultaneously. You have several options for customizing the data you input into these common fields: 1. **Variables**: Choose from four types of variables to insert into your fields. 2. **Text Inclusion**: Opt to include plain text if variable functionality is not required. 3. **Function Wrapping**: For more complex data manipulation, you can wrap variables with a function to perform specific operations or calculations. This flexible approach allows you to tailor the data entry process to meet the specific requirements of your tagging system efficiently. However, you can not change the tags’ names, filters, or triggers. For that, you still need to access each tag and change it separately. # What are the types of common fields and how to edit them? The fields within the tags are categorized into three types for ease of management: 1. simple fields

2. grouped fields

3. list fields

`Google Analytics - Join ID (jid)` here is a simple field On this field, you can easily delete a value, wrap it around a function or add a new value.

`Products` here is a grouped field with the selected simple field `Product ID` When modifying grouped fields, you have the option to select specific simple fields within the group for editing. Only the fields you select will be updated, ensuring that changes are applied precisely where needed without affecting the entire group. This selective editing feature allows for more targeted updates, enhancing the flexibility and accuracy of data management.

`Custom Metrics` here is a list field When editing list items you see first on the right side an overview about the list. You see how many list items are in common and how many items are different. {% hint style="info" %} list items in different order in different tags are also resolved as uncommon. {% endhint %}

To edit the list, simply click on the overview section. This action will take you to a detailed editing interface where you can modify, add, or reorder the list items as needed. This feature ensures a comprehensive and intuitive approach to managing the content of your lists effectively.

In the editing interface, you can view all list items collectively. If there is a conflict between items, it will be highlighted in a yellow box. This box not only indicates a conflict but also provides information about which tags the conflicting item is used in. To resolve a conflict, you can click on the button within the yellow box to select the tags to which you wish to apply the list entry. This action allows you to harmonize list entries across multiple tag.

On the right side of each list entry, you have options to either sort or delete the entries: * **Sorting:** Use the arrows accompanied by a line to quickly move an entry to the top or the bottom of the list. * **Deletion:** Next to the sorting arrows, you will find an option to delete the entry if it is no longer needed

The top bar is designed to enhance your interaction with the list entries by providing several useful tools: * **Quick Search:** Utilize the quick search feature to swiftly find specific entries within the list. * **Sorting Options:** Alter the order of the entries through various sorting options, helping you organize the list to better suit your needs. * **Adding Entries:** The top bar also allows you to conveniently add new entries, facilitating the expansion of your list directly from this interface.

# Essential Mode on Multi-Tag Edit If all the tags selected have Essential Mode, you’ll see a different column for Essential Mode. However, if the tags have different consent definitions, you’ll only see the common values. Example: if one selected tag has Essential Mode, and the other selected one doesn’t, you will not see the Essential Mode value available for change.

# Triggers Whenever data is to be streamed to a recipient the conditions play a crucial part in the process. Those conditions are defined in JENTIS Tag Manager via triggers. Within triggers you will access variables and check their value to decide whether to activate a tag or not. # Trigger Creation Process In your JENTIS DCP navigate to the Server Tag Manager: Trigger to create new triggers or adjust conditions in existing triggers. The basics that you need to define are: * **Name**: This is the value that will appear in the selection in a Tag configuration. You should use a descriptive name here. * **ID**: This technical reference can be used to reference a trigger explicitly, as this ID is unique per JTM account. * **Description**: Feel free to give a Trigger a description to understand better the motivation to handle certain conditions. * **State**: You can choose between predefined states, such as the "loaded document" (domload) or something pushed into the datalayer ("jts\_submit"). There is also the possibility to choose a CSS-selector with an action (SELECTORACTION) like `.button click` * **Exclude Trigger:** These Triggers define that if they trigger, this trigger shouldn’t trigger. For example, a Google Analytics product view tag also includes the pageview. In the case of a product view, a page view and a product view event will be sent to the server. Therefore, the pageview trigger needs the exclude triggers, which exclude the product view, leading to unique events. * **Conditions**: Here, you can select the parameters to check and how the value is validated. The following section describes this in detail.

# Available Condition Operators Trigger conditions can be any complex logic of combined AND or OR statements, where parameters are checked with comparison operators against predefined values. The input parameters for any condition to be checked are Variables you previously created in your DCP (or any system-predefined existing variables). Various operators are available to help you precisely target when defining conditional logic or filtering rules. Below is a list of supported operators, along with explanations of their usage and behavior: | Exactly matches | True if the value is exactly equal to the specified string (case-sensitive). | | ---------------------- | ---------------------------------------------------------------------------- | | Does not exactly match | True if the value is not exactly equal to the specified string. | | Contains | True if the value contains the specified substring. | | Does not contain | True if the value does not contain the specified substring. | | Starts with | True if the value begins with the specified string. | | Does not start with | True if the value does not begin with the specified string. | | Ends with | True if the value ends with the specified string. | | Does not end with | True if the value does not end with the specified string. | | Matches regex | True if the value matches the provided regular expression pattern. | | Does not match regex | True if the value does not match the provided regular expression pattern. | | Bigger | True if the value is greater than the specified number. | | Bigger-equal | True if the value is greater than or equal to the specified number. | | Lower | True if the value is less than the specified number. | | Lower-equal | True if the value is less than or equal to the specified number. | Use AND or OR statements to combine multiple condition checks. # States JENTIS's goal is to make tracking website interactions easy. A rather abstract but very helpful concept comes into play: states. Every event can be a State, and with each, JENTIS takes a snapshot of all properties and variables so you can retrace each data point. So, all tracking with JENTIS will stay in contact with a State, as all Tags, Triggers, and Variables all work in some context to a State. The JENTIS States concept creates a uniform scope for working with data on the server side. During data computation (evaluating server-side variables, executing tags on triggers, etc.), the server can not conveniently access data from the client (website visitors' browser). Users interacting with your website will open it, wait for it to load, click somewhere, and navigate. Generally speaking, all websites are built differently; it can be a single-page application or a classic link-per-link navigating website. Now it is up to you to use the core web protocols (such as “DOM Ready” or “Page Load”) events and define default JENTIS States or create your definitions. In any case, JENTIS comes with many built-in definitions, so technical skills are not mandatory. Here is a basic guide to dive deep into this concept: [JENTIS States Framework](/core-concepts/jentis-states-framework) If you are more into the use cases, here are some guides for you to get started: * Listen to (GTM) Data Layer Events: [Listen to Datalayer Events](/use-cases-and-tutorials/events-and-custom-states/listen-to-datalayer-events) * Clicks, Form Submits and Scroll Tracking: [Form Submit, Click and Other Actions](/use-cases-and-tutorials/events-and-custom-states/form-submit-click-and-other-actions) * History Change States (Virtual Pageviews): [History Change State and Virtual Pageviews](/use-cases-and-tutorials/events-and-custom-states/history-change-state-and-virtual-pageviews) # State Registry - Creating and Managing JENTIS States Creating and customizing a state can be achieved in your JENTIS DCP. Navigate to the Server Tag Manager: States area to edit or create new State objects. Here you can edit existing State definitions or create new ones.

A State has the basic parameters such as name, description, or id, as with all elements in JENTIS. The JavaScript code will define a function with a single input parameter (a function) and must call the input parameter at the end. The following example will help you to understand this concept better.\\ # State Function Reference A state is an anonymous JavaScript function with one input parameter. This function will determine the event (a moment in time or interaction of a client) and submit a callback. **Anonymous Function Input Parameter**: {function} initState The state code statement must begin with an anonymous function with an input object. That input is a callback function and must be called whenever this JENTIS State is determined to be activated. Further the initState (callback function) takes an Object as the input with certain properties. This object and its properties is optional and only for advanced users. initState input Object properties: * stateCallback: if you want to call a function after this JENTIS State was processed this is the place to go. * contextualStateInformation: this is a customizable Object that you can submit when this JENTIS State is processed and access this properties and values in JENTIS Frontend Variables. For the usage of this advanced settings please see in the section below for a detailed use case running through this options. # Basic State Definition – DOM Ready State The most basic use case for a state is the DOMContentLoaded event handle. This will create a JENTIS State in your JTM account that activates on the named web browsers event. Further details on this api and specs can be found here: [DOMContentLoaded event – Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/DOMContentLoaded_event) {% code title="DOM Ready State - Javascript Function" lineNumbers="true" %} ```javascript function(initState) { document.addEventListener('DOMContentLoaded', (event) => { initState(); }); }; ``` {% endcode %} With this State in place, your DCP will react as soon as the event is triggered in a user's browser, activating all triggers, checking conditions, and calculating all Frontend Variable values. So, with this state, you are ready to go if this event fits your requirements. \\ # Advanced State Use Case In some cases, it is essential to customize a JENTIS State further. The optional properties documented before can be used with the input to the initState function. Let's run through an example that generates a more enhanced JENTIS State. Here we will activate a JENTIS State for each external data layer item, where we must process each item individually and not from a global perspective. This is important in situations where JENTIS is loaded asynchronously and accesses a pre-existing data layer. The following might be a simple precondition. {% code lineNumbers="true" %} ```javascript var dataLayer = [{ event: "1" name: "event_1" },{ event: "2", name: "event_2" }]; ``` {% endcode %} If such a dataLayer object is defined before JENTIS is loaded, we must be sure to process each of these events individually. From a global perspective, there is no certain "event" but multiple entries, which might bring us into trouble if we'd like to activate a trigger on the event name "event\_1." The array contains two such entries, and we might miss either of them if we do not check each event individually as a JENTIS State. To resolve this, the contextualStateInformation comes into play. For each JENTIS State, an object with a snapshot of an event can be submitted. Let's give this a try: {% code lineNumbers="true" %} ```javascript function(initState){ //generate this object with the mentioned properties in an appropriate scope optionalParamObj = {}; //resetting the JENTIS Data Layer is optional in this case, as no further information is pushed this time optionalParamObj.stateCallback = function() { window.jentis.tracker.resetDatalayer(); } for(var i = 0; i < dataLayer.length; i++){ optionalParamObj.contextualStateInformation = dataLayer[i]; initState(optionalParamObj); } } ``` {% endcode %} With this example, we execute each entry of the dataLayer (presumably an event object). Now, we can be sure each such external event is translated into a JENTIS State without losing the context (event object). Now, this would be fruitless if no element took advantage of the contextual object. This can be accessed in frontend variables (custom Javascript variable—[Variables](/developer-guide/variables)). You can create such a variable and access the corresponding object from a JENTIS State. Which might be the event's "name" value. {% code lineNumbers="true" %} ```javascript function(stateContextObject){ if(stateContextObject.stateContext && stateContextObject.stateContext.name) return stateContextObject.stateContext.name; else return undefined; } ``` {% endcode %} This will return the event's "name" property (from the dataLayer object submitted in the JENTIS State code above). With this functionality, you can build and customize your JENTIS DCP configuration around all use cases. # Functions (Transformations) The TWIN-Browser JENTIS technology allows you to run JavaScript functions on the server and client side. It empowers your setup to run custom data operations within the runtime of a virtual environment, such as persisting information on a machine's local storage or applying complex logic or processing with the full capability of a programming language. The backbone for the TWIN is NodeJS. JENTIS DCP functions apply further logic to customize data to your implementation's use case. These functions are used in tag configurations to apply to specific variables (values). They help transform values before they are submitted in a tag, for example, shortening a string, putting all characters in lower or upper case, or hashing the submitted value. {% hint style="warning" %} **Clientside and Serverside Warning** Please be aware that the transformation functions use different runtimes and scopes based on the tag's execution. If a tag is executed server-side, it is in an ES6 environment capable of resolving asynchronous functions. However, client-side code is more restricted. Beware not to use the same transformation function on both server-side and client-side tags. {% endhint %} # Function Creation Process Every function object has the following parameters: * **Name:** This is the value that will appear in the selection in a Tag configuration. Here, you should use a descriptive name. * **ID**: This technical reference can explicitly reference a function, as this ID is unique per DCP. * **Description**: Feel free to describe your Function to better understand the motivation to this application later. * **Javascript**: This is the actual function code that you will define

As a function is referenced in a tag to process and return a value, you must define an input and output value. Use the following basic syntax, as any function must return a value. {% hint style="warning" %} Functions can only work with **one input**. Adding more variables in the tag edit view will concatenate the inputs into a single parameter. {% endhint %} {% code lineNumbers="true" %} ```javascript async function(input){ var processed_value = input+1; return processed_value; } ``` {% endcode %} ### Transformation Functions Any transformation function that runs server-side can fully support async features like \`await\` and \`promise\`. Hence, if you intend to use async features, you must always declare the code to be async in the first line of code. {% code lineNumbers="true" %} ```javascript async function _(input) { // use await or promise if required } ``` {% endcode %} {% hint style="danger" %} You can not use async features on client-side executed transformation functions, so the same transformation functions are not applicable to both client—and server-side tags. {% endhint %} ### Workaround for multiple arguments If you need multiple input arguments, a possible workaround is to use a delimiter to concatenate the different variables and then split the information within the function.

{% code title="Example Function Code" lineNumbers="true" %} ```javascript function hashed_id_sha256(args) { let params = args.split(':::'); let id = params[0]; let account = params[1]; if (['abc','cdf'].includes(account)) { return this.tools.getSHA256(id); } return id; } ``` {% endcode %} # Plugins Plugins are externally submitted applications from third parties and JENTIS (internally) to cater certain use cases as a single component (the plugin). In favor of creating all elements (tags, triggers, codes, etc.) manually.

# YouTube Video Tracking Plugin Use this JENTIS Tag Manager plugin to track how users interact with embedded YouTube videos. The plugin captures events such as `play`, `pause`, and `resume`, then pushes them to the JENTIS video tracking model: [Video Event Model](/data-capture/web-tracking-setup/set-up-jentis-data-layer/video-interaction-tracking). The YouTube Video Tracker is a plugin, not a connector like Google Analytics or Facebook Conversion API. It does not send data to analytics tools or third parties on its own. Instead, it writes standardized video interaction data to the JENTIS data layer. You can use that data in downstream tools or build your own trigger logic from the values the plugin provides. {% hint style="info" %} The plugin can only track videos when it can access the underlying YouTube player events. Some embed methods block that access. In rare cases, a specific combination of website setup and embed code can prevent interaction tracking. {% endhint %} ### Plugin Generated Data This example shows a typical data layer push after a user interacts with a video. ```javascript window._jts.push({ track: "video", // JENTIS data layer command provider: "youtube", start: /* Timestamp when the user started the video. */, duration: /* Duration of the currently playing video in seconds. */, currenttime: /* Elapsed playback time in seconds. */, percent: /* Current playback progress as a percentage. */, status: /* Current playback status: play, seek, pause, complete. */, url: /* URL of the video. */, title: /* Title of the video. */, id: /* Unique ID of the video. */ }, true); ``` ### Configuration of the YouTube plugin To enable and configure the plugin, open **JENTIS Tag Manager** and go to **Plugins** → **Add New Plugin**.

Review these six settings: 1. **Track other interactions with the video**: Enable this option to track actions such as `pause`, `seek`, and `buffer`, and push them to the JENTIS data layer. The default interactions `play`, `pause`, and `progress` are controlled by the settings below. 2. **Enable API support and reload videos**: YouTube videos are embedded as iframes. When you enable this option, the plugin checks each video URL for the `enablejsapi=1` query parameter. If the parameter is missing or set to `0`, the plugin updates it and reloads the iframe. 3. **Track start of video**: Enable this option to track the initial start of the video, including autoplay. 4. **\* Bind library to element click**: Some YouTube videos are not available at page load because they only load after a user clicks another element. In that case, tracking cannot start immediately. Enter a valid CSS selector for that clickable element, or leave the field empty if you do not need this behavior. Once the user clicks the element, YouTube tracking starts. Example: `.play-button` 5. **Track end of video**: Enable this option to track when playback reaches the end of the video. 6. **Track progress**: Enable this option to track playback milestones. For example, if you enter `25|50`, the plugin sends an interaction event when the user reaches 25% of the video and again at 50%. Use integers only. Separate values with a pipe character. Do not add spaces. \
**Quick guide: create a variable to retrieve YouTube tracking data** Use these four steps to create a variable for YouTube interaction data. In this example, the variable returns the video title: 1. Create a new variable for a video property, such as the video title.\ ![](/files/E9xYmGXoZkoDv6GyGXsM) 2. Click **Add New Variable**. 3. Select **Get JTM data layer value**.\ ![](/files/sP94pKuhg0Kv0enUkaho) 4. Define the properties as follows: 1. Document name: `video` — this matches the `track` property in the data layer push event. 2. Property: `title` — this is the value you want to return. 3. Leave the other properties empty. \
# Legal Hub The JENTIS Data Capturing platform was developed in a modern web era, where consent and privacy were already established topics. Compared to other solutions that have to adapt their defaults as something new and not part of their core from the beginning on. Hence why our framework benefits from ideas that are building blocks to a resilient foundation such as the JENTIS Consent Engine.\ This enables JENTIS to detach triggers (conditions that define when to activate a data stream) from actual consent information. As this is a highly complex topic with many facets, we will cover all the basics first. Then we will dive into more specific and individual setups in this article. # JENTIS Essential Mode **JENTIS Essential Mode** is the superpower in your data privacy and quality endeavors. It allows you to collect the most precise data, while at the same time respecting privacy and protecting the data of your website visitors. In this article, we will explain the concept of Essential Mode, give you the technical descriptions to configure it for your website, and how to raise awareness for this topic in your organization. ### What is JENTIS Essential Mode? JENTIS Essential Mode is a feature that enables website owners to define what type of data to collect according to the users' consent status. When consent is given, the access and storage of data on the user’s device are enabled after the consent is received. However, if users actively don’t give consent, all the data will be lost—in some cases, this could mean up to 70% of data lost. To solve this, JENTIS Essential Mode allows website owners to configure a fallback to maintain data quality in cases where no consent is given. This is possible by enabling website owners to configure their tracking within the limitations of accessing and storing data on users' devices under the “strictly necessary” exception in the ePrivacy Directive.

This means that JENTIS customers can define, within their Data Protection guidance, what is considered “strictly necessary” data for their business and configure its tracking for cases where consent is not given. This data can then be modified before being shared with third-party tools.

In summary, with JENTIS Essential Mode, you can: * Have up to 100% of your website’s data collected with fully compliant methods. * Make better data-driven marketing and business decisions with a complete view of your users' journeys. * Recover information you’d have previously lost due to no consent. No more blind spots on your data. ### Data Persistence and Identifier Basics in JENTIS In general, this is how Essential Mode works: JENTIS steps in as a privacy-enhancing measure with your website. These privacy-enhancing elements enable Customers and their data protection teams to configure “strictly necessary” access and storage to comply with the consent exception rules under Art. 5 para. 3 sentence 2 ePrivacy Directive (also see § 25 (2) TTDSG): * **Time of data storage**: JENTIS Essential Mode allows for a synchronous load of the JENTIS Tag Manager and the Consent Management Platform (CMP) of the customer’s choice to increase page speed. By default, the reading of information & storage in the JENTIS systems is activated after the website visitor interaction with the consent banner. * **Content of the information**: Some data parameters are minimized and modified when the Essential Mode is activated by default. For example, JENTIS does not store the user's IP Address and shares only the JENTIS Server IP Address in communication with third parties. * **Duration of information storage**: Data storage in the Essential Mode is limited to a maximum of 13 months by default. This can also be set individually by the customer. * **Information readability**: JENTIS will use a first-party cookie to identify signals, but it will not share any sensitive data if configured correctly and accordingly with Essential Mode. Now, let’s see how JENTIS Essential Mode can be configured in the following steps below: ### Essential Mode Setup There are three steps in the configuration of the Essential Mode in JENTIS: 1. The foundation defines what variables (parameter values) are PII (personally identifiable information). These variables will be automatically converted into wrapped “Anonymization” functions in all tags where Essential Mode applies. 2. The next step is to activate the Essential Mode for individual tools and their vendors in the JENTIS Tag Manager. 3. Last but not least, you can customize the settings of the Essential Mode in each tag individually. #### 1. PII Definition This step is optional, but it can be convenient to set this setting per variable (and the later tags will automatically set the proper configuration by default). Every data point in JENTIS Tag Manager has a toggle switch to set the foundation on the most detailed level: per variable.

If a variable is considered to handle PII data you must set this to “true”. Please apply this to all variables to ensure every use case is covered. #### 2. Activate Essential Mode To activate the Essential Mode per tool, navigate to the "Legal Hub" section in the main menu. Select the list of vendors and, for each tools vendor, you can define the consent setting as applicable:

The options you have are: * **Consent Mode**: tools related to this vendor will activate only when consent from the user is received. * **Essential Mode**: You can apply a split configuration in each tag of this vendor's tools: one version for when consent is given and another for when consent is denied. * **No Consent Mode**: This tool will activate immediately without consent.

#### 3. Customize Tags in Essential Mode Settings When you select **Consent Enabled (Essential Mode)** for a vendor in the previous step, the tools within that vendor will show on the tag editor view a second column in the parameter definition:

Now that the JENTIS Essential Mode is active for your tool, you can customize those settings for each parameter in all tags of this tool. You can customize those settings individually for each parameter. The default will anonymize all variables marked as PII in all tags. In Essential Mode, you can select different parameter values, i.e., apply a function to fully anonymize the variable value or pseudonymize it (it will remain the same for a single user). # JENTIS CMP Connectors ### Native CMP Connectors in JENTIS JENTIS offers **convenient, easy-to-use native connectors** to all major Consent Management Platforms (CMPs). These connectors make it simple to integrate your CMP with JENTIS, ensuring your tracking setup is always compliant with user consent decisions. **Examples of available native connectors** (list constantly growing): * OneTrust * CookieBot * Usercentrics * Borlabs Cookies (WordPress) * Datareporter * Truendo * CookieFirst * Consentmanager * iubenda * Commanders Act (TrustCommander) * Sourcepoint * Clickskeks * CCM19 * Didomi * DC-Shopsystem * Shopware Cookie Consent Manager #### How the JENTIS CMP Connection Works When you use a third-party CMP, JENTIS creates a **native communication stream** in the background. This connection is **managed, developed, and maintained by JENTIS**, so you can rely on your tracking to always align with your CMP’s consent decisions. This native connection ensures that both: 1. **Explicit consent updates** – changes a user makes in real-time 2. **Existing stored consent** – consent decisions saved from previous sessions …are applied correctly in your tracking setup. #### Technical Details JENTIS connects to available APIs provided by your CMP—such as event listeners, cookies, or local storage—based on the provider’s documentation. These APIs are used to **synchronize consent data** with the JENTIS Tag Manager, ensuring both real-time and persisted consent information is respected. # Setup Consent with JENTIS One of the key features of the JENTIS Consent Engine is its easy setup. You only apply an initial setting when a tool is added to your configuration for the first time. After that, it is fire and forget—easy as that. Follow these instructions when a tool is added to a configuration. First, we will go through a very broad set of steps, and then we will go through each step in detail one by one. 1. Add a tool to your account and decide in which containers (on which websites) it will be used. 2. Set the vendor of this tool instance (optional). 3. Define your preferred consent application for this vendor (consent, essential mode, or without consent). 4. Select which CMP connector is to be used (once per container) for your container. 5. Adjust mapping of JENTIS vendors to CMP vendors (optional, if customization is required). 6. Adjust mapping of tools to JENTIS vendors (optional, if customization is required). Multiple of those steps are only optional if you need more customization options. In most cases, the default will be a good starting point. {% hint style="info" %} Before continuing, please read [Setup Your First Connector (GA4, Meta, etc.)](/getting-started/quickstart/create-a-new-tool) {% endhint %} Each container is, in general, a surrogate for a website. With this setting, you control if the same tool should be activated on multiple websites with the same settings (tags, triggers, variables, etc). If you need more information on the account and containers, here you go: [JENTIS Accounts and Containers](/core-concepts/jentis-account-and-container-structure) ## Set the Vendor for this Tool Now, when a tool is configured, you have vendor settings available (Advanced Settings).

This setting will allow you to apply different tool and tag configurations based on consent, even before a user interacts with a consent banner. You can combine this with JENTIS Essential Mode. # Versions and Preview In the "Publish" section of your JENTIS DCP, you can control the versions, preview, see change logs, and publish the latest updates of your JENTIS DCP configuration to your website. # Versions Tag Management configuration orchestrates all data streams using tags, variables, and triggers to solve data needs. Each JENTIS DCP configuration of your settings comes packed as a version. So you can edit and change your settings in a new version and have that separated into different packages from what is published to productive or staging systems. Here you can find more details on the JENTIS account and container structure, including the environments of containers: [JENTIS Account & Container Structure](/core-concepts/jentis-account-and-container-structure) A list of all your versions can be found in the Publish section. Each configuration version can be in one of three states: 1. **Current edit** (this one contains all the changes you did recently, but has not been published) 2. **Published** to live, stage or both 3. **Legacy** (these can not be edited anymore, but you can publish those to rollback a published version) You can also inspect a log of all changes in a version. # Preview Monitor With server-side tracking architecture, a configuration preview is key. It makes transparent what is not visible to any third party or website visitor: the communication stream from user to any service provider (tools) made with your JENTIS server. The preview monitor enables you to preview and debug all data streams, be they client—or server-side tags and their streams. To open the preview monitor, navigate to the "Containers" section that displays all containers with respective versions.

There are two ways to present the preview data. The “Data Logs” view will simply log all the data streams as they appear and show the JENTIS system logs. The “State Debugger” view, however, will group all the data streams by the state (event) they executed based on. ### JENTIS Preview Best Practices Follow these practices to get reliable preview results: 1. Open your website with the preview URL parameters in a new browser session. Use an incognito window to avoid data from earlier sessions (cached content, previous preview versions or consent decisions). This best reflects a real visitor. 2. Do not switch between subdomains during preview. JENTIS Preview uses browser session storage, and session storage is not shared across origins. If you start on `www.mywebsite.com` and move to `shop.mywebsite.com`, the preview does not continue. Add the URL parameters again and restart the preview on the new domain. 3. Client-side tags appear in JENTIS Preview. However, the preview is server-side, so it cannot show every client-side execution detail, such as full network requests. Check your browser developer tools or provider-specific tools, such as Google Tag Assistant, for deeper client-side debugging. # Publishing When your preview results look just as required, it's time to create and publish a new version. You can select to publish your environment to staging, production, or both. When publishing to live systems, a new “current edit” version will automatically be created for the next release cycle. In the publish options, you can also add a commit message.

# Codes Using code snippet elements, you can publish JavaScript snippets on the client side. These snippets will be fetched from the same first-party server as the JENTIS JS SDK as a single JavaScript resource. Please be aware that with those custom codes: 1. **Code Elements execute by default on the "JENTIS Framework Load" trigger, which** means whenever JENTIS is initiated on your website. 2. **Code snippets are executed one by one.** Prioritizing all those code elements is possible if a sequence is required. Use the "order" field property in a code element. The order of code snippets is from low to high numbers (Integer) 3. **No HTML.** The field "Javascript Code" only allows the use of Javascript, please do not enter HTML (like "\" - do not use this). # Add a Code Element To add a JavaScript code snippet to your JENTIS Tag Manager container, please follow these steps.

Navigate to the “Server Tag Manager: Codes” section in your JENTIS DCP account. Click the "Add Code Element"-button to add a new element.

In a code element, you must provide the following fields: * **Name**: a descriptive short name of the code element. * **Order**: a number that defines the execution order on initialization (Integer). Low numbers are executed first, starting with 0. * **Containers**: select the containers in your JENTIS Tag Manager account, that will include this code element when loaded. * **Javascript Code**: the actual code. Please be aware that this code will be interpreted in a closure and minified, so always consider the scope you are working with. * **CSS Code** (optional): You can add custom CSS to publish to your webpage with this element. * **Trigger**: Select a trigger that activates this code. Leave it on the default "**JENTIS Framework Load**" to execute immediately. --- [Next Page](/llms-full.txt/1)