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 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
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
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.
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 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 article for setup details, edge cases, and privacy considerations
How to Reuse Configurations Across Containers (Same Account)
Create or open a Tool (or Tag/Trigger/State/Function) that should be shared.
Select target Containers inside the same account where the item should apply.
Publish—the configuration (including all settings) will be available everywhere you targeted.
Maintain centrally—update once, propagate to all selected containers.
Benefits: Faster scaling, consistent governance, and reduced configuration drift.
Last updated
Was this helpful?