This article walks through what happens, technically, between a visitor loading your page and Termly recording their consent choice, useful if you're integrating Termly with other tools, debugging a consent-related issue, or just want to understand how the pieces fit together.
The flow, step by step
- Page loads. Termly's script (loaded directly or via Google Tag Manager) initializes on the page. Auto Blocker scans the page for third-party tracking scripts, cookies, and embedded content (iframes, e.g. YouTube embeds or maps).
- Everything non-essential is blocked by default. Before any consent choice is made, Auto Blocker prevents non-essential trackers from firing. Trackers are categorized (Necessary, Analytics, Advertising, Social Media); anything Termly can't classify is marked "Unclassified" and stays blocked until the visitor accepts all categories or explicitly allows unclassified tracking. You can override this with custom blocking rules or by manually blocking specific scripts.
- The banner renders and the visitor makes a choice. The visitor accepts, declines, or customizes their preferences per category through the consent banner UI.
- Termly assigns an anonymous visitor ID at the browser level. This is a random ID generated in-browser, Termly does not use cookies to store consent, and the ID isn't tied to any personal identity. This keeps consent records anonymous by design.
- The consent choice fires an event and is recorded. Termly's script exposes a
consentevent that fires whenever consent changes. It carries the approved categories, the whitelisted cookies (name, provider, type), and the visitor's anonymous ID. This is recorded and stored securely on Termly's side, associated with the browser session, not with a person. - Auto Blocker reacts to the consent state. Based on the categories the visitor approved, Auto Blocker dynamically enables the corresponding tracking scripts/cookies and continues blocking the rest.
- Downstream tools pick up the signal. If Termly is loaded via Google Tag Manager, the consent state is also pushed to the dataLayer, where Google Consent Mode uses it to adjust how Google tags behave. This doesn't change where or how consent itself is stored, it's a downstream signal only.
- Consent state can be queried afterward. Two ways this happens:
- Client-side:
Termly.getConsentState()can be called at any time in-browser to read current consent. - Server-side: Termly's Consent API can be queried with the visitor's UUID (or an API key) to retrieve which categories/cookies that visitor consented to, useful if a backend needs to enforce consent decisions on server-set cookies.
- Client-side:
Diagram
If you have any questions, please reach out to Termly Support.