Share consent across subdomains and allowed origins with signed tokens.
Share one consent decision across multiple domains you control without re-prompting users on every property.
Overview
Cross-domain consent uses allowed origins, optional parent domain rules, and signed tokens so sibling sites read the same consent state securely.
Why it matters
Brands often run shop, blog, and app on different hostnames. Without sync, users see repeated banners and analytics double-counts. Cross-domain consent keeps UX consistent and evidence centralized.
Setup
- Open Consent Setup → Cross Domain Consent.
- Set the parent domain (e.g.
.example.com) when all sites share a registrable domain. - Add allowed origins for each HTTPS origin that may receive tokens (one per line).
- Publish the banner on the primary site first.
- Install CookieShift on secondary origins with the same workspace property or linked configuration.
- Test: accept on site A, open site B — banner should reflect stored consent.
Examples
| Pattern | Configuration |
|---|---|
www + shop subdomains | Parent .example.com |
| Separate apex domains | Explicit https://app.example.net in allowed origins |
Troubleshooting
- Token rejected — Origin not in allow list; check trailing slashes and
https. - Consent not syncing — Clock skew or blocked third-party cookies; verify same workspace.
- Banner shows again — Secondary site uses different
siteId; align property in dashboard.
Best practices
- Minimize allowed origins to production hostnames only.
- Rotate signing keys per Security guidance when staff leave.
- Log consent events centrally via Consent logs.