This article explains how consent is stored in Termly, how Google Tag Manager (GTM) and Google Consent Mode interact with Termly, and what to expect when working with subdomains or authenticated users.
How Termly Stores Consent
When a visitor interacts with your consent banner (Accept, Decline, or Custom Preferences):
- Termly assigns a random, anonymous visitor ID at the browser level
- The visitor’s consent preferences are recorded and stored securely by Termly
- Consent is associated with that browser session, not with a person’s identity (name, email, account)
This approach aligns with GDPR and other privacy regulations, which do not require identity-level consent tracking and explicitly discourage collecting unnecessary personal data.
What Happens If a Visitor Clears Cache or Uses a New Device?
If a visitor:
- Clears their browser cache
- Uses a different browser
- Switches devices
Their previous consent record will no longer be available, and the banner will be shown again.
This is expected and compliant behavior. The correct outcome in these cases is to re-collect consent, not to attempt to re-identify the user.
Does Termly Use Cookies to Store Consent?
No. Termly does not store consent in cookies.
Consent is stored at the browser level and managed in a way that keeps Termly an anonymous consent management platform, rather than an identity-based consent verification system.
Short retention and re-consent are considered best practice, not a compliance gap.
Cross-Subdomain Behavior (e.g. www.example.com vs app.example.com)
Consent given on one subdomain does not automatically carry over to another subdomain.
Important notes:
- Each domain or subdomain must have the Termly script installed
- This behavior is expected due to how browsers scope storage
- Termly does not currently support root-domain or cross-subdomain consent sharing
To enable Cross-Subdomain sharing, please follow this Support article.
Does Loading Termly via Google Tag Manager Change This?
No.
Loading the Termly script via Google Tag Manager (GTM):
- ✅ Displays the banner correctly
- ❌ Does not change how consent is stored
- ❌ Does not enable cross-domain or cross-subdomain consent sharing
GTM controls how scripts are loaded, not how browser storage works.
How Google Consent Mode Works with Termly
Termly and Google Consent Mode work together, not as replacements for each other.
The flow is:
- Visitor interacts with the Termly banner
- Termly updates the consent state
- Consent signals are sent to Google via the dataLayer
- Google Consent Mode adjusts tag behavior accordingly
You still need to wait for Termly’s consent initialization so Google knows whether consent is granted or denied.
Can Customers Link Consent to Their Own Users?
Yes — optionally and entirely on the customer’s side.
Some customers with authenticated users choose to:
- Read the anonymous visitor ID after consent
- Store it alongside their own internal user identifier
If you choose to do this:
- The mapping is your responsibility
- You control lawful basis, retention, DSAR responses, and security
- This becomes your own personal data processing
Termly does not perform identity verification and does not store identity-level consent.
Is This Enough to Prove Consent in a Dispute?
Yes.
In a dispute, what matters is that you can demonstrate:
- A compliant consent mechanism was in place
- Consent was recorded appropriately
- Reasonable retention and governance policies were followed
Privacy regulators do not require the ability to re-identify every past visitor indefinitely.
Key Takeaways
- Termly is an anonymous, browser-level CMP by design
- GTM does not enable cross-domain consent sharing
- Consent loss after cache clearing is expected and compliant
- Identity-level consent tracking is optional and customer-implemented
- Short retention and re-consent are compliance features, not flaws