Before working with dynamic domains and service user mapping, we hit a clear issue: cookie consent and tracking behaved inconsistently across domains, subdomains, and environments.

When integrating with third-party platforms such as Google Search, Google Tag Manager, and OneTrust, the inconsistencies became more visible and started impacting clients.

The root cause was clear:

• No centralized source of truth for domain configuration
• Domains were hardcoded or manually managed
• Consent and tracking logic differed across environments

This article shows how to solve the problem by centralizing domain management and using Service User Mapping in AEMaaCS, demonstrated through a practical OneTrust integration example.

Why Cookie Consent Doesn’t Scale Across Domains

When a new domain or subdomain is introduced:

• It must be added manually in OneTrust to enable consent management
• The same domain must be registered in Google Analytics for tracking
• It must also be configured in Google Tag Manager for tag execution

If any of these steps are missed or inconsistent:

• Consent banners may not appear correctly
• Tracking data may be missing or incomplete

In multi-environment setups (e.g., dev, staging, production), this process is repeated for each environment, increasing the likelihood of inconsistencies.

These inconsistencies show up as runtime failures.

Missing or misaligned domain in OneTrust causes consent script to fail loading:

cdn.cookielaw.org/consent/<domain-id>/OtAutoBlock.js:1  
Failed to load resource: the server responded with a status of 404 ()

cdn.cookielaw.org/consent/<domain-id>/OtAutoBlock.js:1  
Failed to load resource: the server responded with a status of 404 ()

This happens when:

• Domain is missing in OneTrust
• Domain ID does not match the current environment
• Configuration changes are not applied across environments

As a result:

• Consent scripts do not load
• Cookie blocking does not execute correctly
• Tracking data becomes missing or inconsistent

👉 Configuration drift becomes a visible production issue.

Where Domain and Subdomain Mapping Comes From

Domain resolution happens in AEM — but domains themselves originate outside AEM.

CDN routes incoming requests, Dispatcher forwards them, and AEM maps the domain to content using /etc/map.

👉 AEM does not define domains — it defines how domains behave.

AEM resolves domains using /etc/map, but it does not define all domains.

Business domains are defined outside AEM (DNS and CDN), while /etc/map only maps incoming domains to content paths.

👉 /etc/map contains mapping logic — not the full list of domains.

Centralized Domain Mapping with Service User Mapping

TODO