JENTIS Accounts and Containers
Your JENTIS Data Capturing Platform is a scalable product. There are many dimensions to scale where a tag management can be used efficiently to manage many similar or different implementations and also considering multiple web (frontend) applications or even domains. Websites and enterprises are a complex world and we want to cover as many possible ways to adjust to the different needs. For that we have containers, environments and JTM accounts. Here we will describe best practices on when to use which.
Hierarchies
JENTIS has a three level hierarchy:
JENTIS DCP - Account:
This is the highest level of administration. In general a single company is represented by an account. It has one single point of contact, here you login and can manage users, containers and environments.JENTIS DCP - Container:
A container is always directly connected to a domain and JavaScript embed snippet.Container Environment:
Part of the JavaScript embed snippet is the definition of an environment. Per default a JENTIS DCP Container will always have two:stageandlive.
Implementation Details
The hierarchies and structure of JENTIS is resembled in code. Or put it differently: the architecture of server side tracking as a first party sets the foundation for scaling to multiple sites. As each integration must be implemented in a first party context. Making it inevitable to have different JavaScript embed snippets, DNS A records and therefor containers.
Lets have a look on the generic JENTIS Code Snippet:
(short version)
<script>
(function (sCDN,sCDNProject,sCDNWorkspace,sCDNVers) {
... // shortened for brevity
})("https://JENTIS_SUBDOMAIN.mydomain.com","JENTIS_CONTAINER_NAME","JENTIS_CONTAINER_ENVIRONMENT","_");
</script>Now there are multiple dynamic parameters in that code:
JENTIS_SUBDOMAIN: this is a dynamically generated value, where you have to map the DNS A record entry. All details are shared in your JTM account setup guide.
JENTIS_CONTAINER_NAME: this is the reference to you containers name that is to be used with the JS embed snippet.
JENTIS_CONTAINER_ENVIRONMENT: either “stage” or “live”.
How to Grow and Scale
In your JENTIS Data Capturing implementation life cycle you will sooner or later be confronted with the question of how to setup your account, containers and tools. For the sake of being most efficient and accessibility of the data pipelines. In the next sections we will discuss what options you have and what are the concepts behind them. Helping you to resolve the question on how many containers and tool-instances you actually need.
Shortly the following topics you should consider when setting up your account.
First: Container
the right number of containers:
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 same conversion goals)?
do you want to split a single website (domain) to multiple sections (ie. by subdomain)? As they require separate management and have different requirements (different data, different tools and conversion goals)?
container options:
one domain can have multiple containers
each domain must have it's own unique container (a container can not be used on multiple domains)
Remember: A container can hold multiple tools configured, it can be the same tool (ie. GA4) with two different instances.
Further you can decide on tool level, 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 on multiple sites (with the same tags, triggers and variables to it):
Conclusion:
You can use a tool on multiple containers with the same configuration. It scales from bottom to the 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 there is a common tool definition, that applies to multiple containers. Or if you want to have a single container with multiple tools? Or even multiple containers with multiple different tool definitions on the same website.
In the next two chapters we will look into more complex topics when it comes to setting up you 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.
Sharing: Global and Local Elements
To make handling multiple integrations efficiently elements in the JENTIS Tag Manager have references to containers.
The following elements are either global definitions (same for all containers, available in all containers) and some are local (you can select in which container those are implemented). If a local element selects ALL containers it is the same as global.
Container Based Elements (LOCAL)
This JTM elements can be associated with all or only some JTM Containers:
Tools: each tool configuration instance (Google Analytics, Facebook, etc.) is always connected to a container.
Tags: as each tag is always part of a tool it shares the setting from the tool, making it also always connected to containers selected in the according tool.
Code Snippets: all frontend code snippet elements are defined per container.
Shared Elements (GLOBAL)
This JTM elements are defined globally and are available to all containers:
Triggers
Variables (all Frontend, Backend, Static and Enriched Variables)
Transformation Functions
States
Remember: In your JENTIS account you can have multiple tools, that are connected as you need to containers. Either a tool on multiple containers or vice versa a container with multiple different tool instances.
Any element is either global or only locally available in a container. Following your configuration of the "local" elements.
If you want to manage a tool only once and share the configuration on multiple websites (domains) then you simply select this tool to be available in multiple containers.
If a tool has a specific tag or configuration than you can simply add a tool and assign it only to the required container.
Data Scopes - Sharing Informations
A very important topic when deciding for the appropriate account and container structure for your project you must consider the scope of data. As a tool and container in JENTIS by design will not automatically share data with any other container or tool instance.
Basically this means when you have two tools "Web Analytics A" and "Web Analytics B" and two containers "Website X - Criamos o seu Website +Visibilidade +Negócios " and "Website-Y.com" 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 (http://Website-X.com and Website-Y.com) they are two different identities in JENTIS, meaning there is no common identifier and again both web analytics tools will count a unique visitor.
Now there is a way to work around this by sharing the user-id on both websites: Cross Domain Tracking
With the cross domain tracking the same user in two containers will be identified as the same user in JENTIS. 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 now the client-id is consistently the same, even if the user navigates back and forth between both websites.
Subdomains and Multi-Container on single Top Level Domain
Generally we do not advice to have multiple container on a single top level domain (ie. ".my-website.com" is the top level part of your domain without 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" (ie. "Google Analytics 4") and a tool instance is your configuration of this tool (ie. "Google Analytics 4 - EN Shop") aka the "child".
Now as we know you can have multiple interpretations of the same generic tool (ie. "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 recognize 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 (ie. by selecting multiple containers with this tool, so it operates on multiple websites).
Further we are working on a feature to make it available to you soon to make it an option to share data between tool instances of the same generic tool.
Best Practices
Now we need to discuss some best practices and common questions. Mainly on the scaling of multiple accounts/containers in a company with multiple websites on different domains.
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 setup a tool only in one domain?
A domain is always connected to a single container, this is a 1:1 relationship. To only implement a tool or a tag on a single container you have to select only this one 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.