A Consent Management Platform is the system that renders the cookie/tracking consent banner, records each visitor's choice as a timestamped, auditable consent record, and then propagates that choice to every script and tag on the page that needs to respect it. OneTrust, Cookiebot, Usercentrics, and Didomi are the common commercial options; most sites building without one hand-roll a basic banner that handles the UI but skips the harder half of the job — actually blocking scripts until consent is given and keeping a legally defensible record of what was consented to and when.

The UI (the banner) is the visible 10% of a CMP. The real engineering work is the other 90%: scanning the site for every tracking script and cookie in use, categorizing each one by purpose, blocking non-essential scripts from firing until the relevant category is accepted, and maintaining that categorization as the site's tag inventory changes over time.

The core architecture

A CMP implementation has four layers that have to work together:

1. Cookie/script scanning and categorization — an automated or manual audit of every script and cookie the site sets, sorted into standard categories (strictly necessary, performance/analytics, functional, targeting/advertising). This inventory has to be re-run periodically because marketing teams add new pixels and tags continuously, and an uncategorized or misclassified script is a common compliance gap.
2. Banner rendering and choice capture — the visible UI, which must offer a genuinely equal reject path (not a dark pattern), granular per-category toggles, and a way to revisit/change consent later (a persistent "cookie settings" link, typically in the footer).
3. Script blocking — technically preventing categorized scripts from executing until their category is accepted. This usually works by the CMP intercepting script tags (via a script-blocking snippet that holds type="text/plain" placeholder tags, or via Google Tag Manager's built-in consent checks) and only activating them once the matching consent signal is granted.
4. Consent signal propagation — passing the recorded choice downstream to every system that needs to act on it: ad platforms via Consent Mode-style signals, server-side tag infrastructure, and any internal system that logs or processes the data.

cmp_architecture.txt

text

Page load
   |
   v
CMP script loads FIRST (before any marketing/analytics tags)
   |
   +-- No prior consent record? --> render banner, set default = all denied
   |                                  (fires gtag('consent','default',{...denied}))
   |
   +-- Prior consent record found (via CMP's own cookie)?
   |     --> apply stored choice immediately, no banner shown
   |
   v
User interacts with banner (accept all / reject all / customize)
   |
   v
CMP writes consent record (choice + timestamp + banner version shown)
   |
   v
CMP fires gtag('consent','update', {...granted/denied per category})
   |
   v
GTM / tags check consent state before firing
   -> Analytics tag: fires only if analytics_storage = granted
   -> Ad tag: fires only if ad_storage = granted (or in limited/cookieless mode)

Common CMP categories and what they gate

Category	Example scripts	Default state	Blockable?
Strictly necessary	Session cookies, load balancer, CSRF tokens	Always on	No — legally exempt from consent
Performance/analytics	GA4, Hotjar, Mixpanel	Off until accepted	Yes
Functional	Chat widgets, video embeds, language preference	Off until accepted	Yes
Targeting/advertising	Google Ads, Meta Pixel, LinkedIn Insight Tag	Off until accepted	Yes

CMP + Consent Mode integration specifics

Most commercial CMPs now ship a native Google Consent Mode v2 integration that handles the gtag('consent', ...) calls automatically once configured — in OneTrust this is a toggle in the script settings; in Cookiebot it's enabled by default when Google tags are detected on the domain. The integration still requires the implementer to verify two things manually, because the native integration alone doesn't guarantee a correct setup:

First, that the CMP's consent script loads and sets the default state before any GTM container or gtag snippet executes — if GTM loads first, tags can fire with no consent restriction at all before the CMP has had a chance to set the denied default. Second, that the category mapping inside the CMP actually maps to the correct Consent Mode signal — a script miscategorized as "functional" instead of "targeting" won't be gated by ad_storage denial even though it should be.

Script order is the most common CMP implementation bug

The single most frequent real-world CMP bug: the CMP's blocking script is placed after GTM in the page <head>, or GTM is set to fire via a tag manager container that loads before the CMP initializes its default consent state. The result is a brief window — sometimes the entire page lifetime for fast-loading pages — where marketing tags fire completely unrestricted before the user has made any choice at all. This defeats the purpose of the CMP while still giving the appearance of compliance, and it's specifically the kind of gap that's visible to a regulator doing a basic technical audit of the page source.

Consent record retention and proof of consent

Regulators increasingly expect businesses to be able to produce evidence of what a specific user consented to and when, not just assert that a compliant banner exists today. CMPs address this by storing a consent receipt per user — typically including a unique consent ID, timestamp, the specific categories accepted/rejected, the IP address or approximate region used to determine which legal framework applied (GDPR banner vs. CCPA banner vs. no banner, depending on geolocation), and the version of the banner/policy text shown (since policy text changes over time and a stored consent needs to be tied to the version it was given against).

This consent log itself is personal data and needs its own retention policy — most CMPs default to retaining consent records for a defined period (commonly tied to the underlying marketing data's own retention window) rather than indefinitely.

Choosing between CMP options

Enterprise CMPs (OneTrust, Usercentrics) tend to offer deeper cookie-scanning automation, multi-domain/multi-brand management, and dedicated compliance reporting, at higher cost and implementation overhead. Lighter options (Cookiebot, Osano) cover the core banner-plus-blocking-plus-Consent-Mode-integration need well for a single site or smaller team, with less compliance-reporting depth. The decision driver in practice is less about banner appearance and more about how many domains/brands need centralized management, how automated the cookie re-scanning needs to be as the site evolves, and whether legal/compliance stakeholders need built-in audit reporting beyond raw consent logs.

What's next

The consent signals a CMP produces are what Consent Mode v2 actually consumes on the Google Ads/Analytics side — worth reviewing that mechanism in detail if the banner-to-tag handoff above wasn't already familiar.

See also: Consent Mode v2 →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →