Skip to main content
Back to Guides
Basics18 min read

What Is a CMP (Consent Management Platform)?

Learn what a Consent Management Platform does and how it helps you collect valid consent, control tags, and keep audit trails for compliance.

A Consent Management Platform (CMP) helps websites collect and manage user consent for cookies and similar technologies. A CMP presents a banner or preference center, blocks non-essential tags until consent is given, and records consent for auditing.

What a CMP Typically Does

  • Displays a banner with clear choices

    Accept, reject/manage, customize options

  • Defers non-essential scripts

    Until consent is captured

  • Stores and updates consent preferences

    Provides a way to change them later

  • Integrates with tools like GTM

    Works with Google Tag Manager and Consent Mode v2

  • Keeps consent logs

    To support compliance audits

CookieBeam provides these capabilities and goes further: it uses automatic 5-layer script interception (no manual tagging), blocks tracking at the network connection level (fetch, XHR, beacon, WebSocket, EventSource), and runs continuous drift detection in every visitor's browser to catch new scripts and cookies between scans.

About CookieBeam

CookieBeam is a Consent Management Platform with automatic script interception, connection-level blocking, and drift detection. We help you collect and manage consent in compliance with GDPR, CCPA, and other privacy regulations. We're not officially registered with IAB Europe as a certified CMP. For most websites (e-commerce, SaaS, lead generation), IAB certification isn't required.

How a CMP Works: Step by Step

A Consent Management Platform operates by intercepting the normal page-load sequence and inserting a consent gate before any non-essential scripts are allowed to execute. Understanding this flow helps you evaluate whether a CMP is implemented correctly on your site and what a user's experience will look like.

When a visitor lands on your website for the first time, the browser downloads your HTML and begins parsing it. The very first script that runs should be your CMP's initialisation snippet, a small piece of JavaScript typically placed in the <head> element. At this point, the CMP checks whether a valid consent record already exists in the visitor's browser (stored in a first-party cookie or localStorage). If no record is found, the CMP immediately blocks all non-essential tags from firing and displays the consent banner.

The user is then presented with their choices: accept all, reject all, or configure their preferences by category. Once the user makes a selection, the CMP records the decision, including a timestamp, the version of the banner displayed, and the exact choices made, and releases (or continues to block) tags accordingly. If the user accepted analytics cookies, for example, your analytics tag is now permitted to fire. If they declined advertising cookies, those tags remain suppressed for the duration of the session and all future sessions until the user changes their preference.

Finally, the consent record is written to the user's device and, in platforms like CookieBeam, also logged server-side so you have a tamper-proof audit trail. This audit log is invaluable if a data protection authority (DPA) ever requests proof that a specific consent was obtained.

CMP Workflow in Practice

1

Page Load & Script Initialisation

The browser parses your HTML and executes the CMP's inline initialisation snippet before any other third-party scripts. The CMP sets a default consent state of denied for all non-essential categories and signals this state to tag managers such as Google Tag Manager so that no restricted tags fire prematurely. This synchronous initialisation is critical, if the CMP loads asynchronously, tags may fire before consent is checked.

2

Banner Display

If no prior consent record exists for the visitor, the CMP injects the consent banner into the page. The banner is typically rendered on top of the page content and may block interaction with the underlying page until a choice is made, depending on your configuration and the applicable legal standard. The banner presents the user's options clearly, as required by GDPR and the ePrivacy Directive.

3

User Interaction

The visitor selects their preferences, accepting all, rejecting all, or adjusting individual cookie categories via a preference centre. The CMP captures each decision and maps it to the relevant consent signals (for example, analytics_storage, ad_storage, and ad_user_data in the Google Consent Mode framework). The banner is then dismissed and the user continues browsing.

4

Tag Release or Block

Based on the user's choices, the CMP updates the active consent state and either releases or permanently blocks the corresponding tags for that session. Tags that were held in a pending state by Google Tag Manager are now allowed to execute (for accepted categories) or are discarded (for declined categories). In Advanced Consent Mode, Google's own tags fire in a restricted, cookieless state even on decline, enabling conversion modeling without setting cookies.

5

Consent Storage & Logging

The full consent record, including the timestamp, the banner version, the user's specific choices, and the jurisdiction, is written to a first-party cookie and/or localStorage on the user's device. The CMP also transmits this record to its server-side audit log. On future visits, the CMP reads the stored record and reinstates the appropriate consent state without showing the banner again, unless the banner version has changed or the consent has expired.

How CMPs Block Scripts: Three Approaches

Preventing non-essential scripts from executing before consent is a CMP's most critical job. There are three fundamentally different approaches, and the CMP you choose determines which one you get.

Manual Script Blocking (Tag-Based)

The website owner explicitly marks each script tag with attributes that tell the CMP which cookie category it belongs to. The CMP holds those scripts dormant until the user consents to the relevant category. This is the approach used by Cookiebot, CookieYes, and most CMPs. It requires the website owner to edit their HTML, but it's precise: you control exactly which scripts are blocked and how they're categorised.

A typical implementation looks like this:

manual-blocking-example.html
Copy to clipboard

The browser sees type="text/plain" and doesn't execute the script. When the user accepts analytics cookies, the CMP replaces it with an executable copy.

URL-Based Auto-Blocking

Some CMPs, notably Osano, take a different approach: they automatically detect scripts as the page loads and block them based on a vendor database, without requiring the website owner to tag anything. Osano offers three compliance modes: Listener (discovers scripts but doesn't block), Permissive (blocks classified scripts but allows unknown ones), and Strict (blocks everything that isn't classified as essential).

This is more convenient for site owners, but carries a risk: over-blocking. Because the blocker relies on URL pattern matching, it can misclassify essential services. For example, Osano's auto-blocker is known to block Google reCAPTCHA by default because it pattern-matches on google.com domains, even though reCAPTCHA is a security feature that should be classified as essential.

5-Layer Automatic Interception (CookieBeam)

CookieBeam uses a third approach that doesn't require manual script tagging but avoids the URL-only pattern matching that causes over-blocking. Its blocking engine applies five layers of automatic interception:

  1. createElement override: intercepts creation of script, iframe, img, and embed elements. Proxies the src property setter and setAttribute calls. Neutralises elements whose URLs map to unconsented categories.
  2. DOM insertion hooks: wraps appendChild, insertBefore, and replaceChild to catch scripts being added to the page regardless of how they were created.
  3. MutationObserver fallback: monitors the entire document tree for added nodes and src attribute changes as a catch-all.
  4. Worker blocking: wraps Worker and SharedWorker constructors to prevent third-party worker scripts from executing without consent.
  5. Anti-tamper protection: once a script element is neutralised (type set to text/plain, src removed), the engine locks the type property so it can't be reverted to an executable state.

The engine works from a script map built from CookieBeam's scanner inventory, not a third-party vendor database. You review the auto-classifications in the dashboard and publish. Blocked scripts are neutralised (not deleted), held in a queue, and revived in original order when consent is granted.

CookieBeam also offers two compliance modes: Learning mode (default) allows unknown scripts to run while building your inventory. Strict mode blocks all unclassified scripts by default (fail-closed).

Script Blocking Approaches Compared

AspectManual (Tag-Based)URL-Based Auto-Blocking5-Layer Interception (CookieBeam)
Setup effortWebsite owner must tag each script with data-categoryNo tagging needed, detects scripts by URL patternNo tagging needed. Script map built from scanner results, reviewed in dashboard
AccuracyPrecise, you control exactly what is blockedCan over-block essential services (e.g. reCAPTCHA, payment scripts)Scan-derived classifications. Learning mode lets unknowns run; Strict mode blocks them
Dynamic scriptsOnly blocks scripts present in HTML at page loadCan intercept scripts injected at runtimeIntercepts all runtime injection: createElement, DOM insertion, MutationObserver, Workers
Connection blockingNoNoYes. Blocks fetch, XHR, beacon, WebSocket, and EventSource per consent category
RiskLow, a script only blocks if explicitly taggedHigher, false positives can break site functionalityLow in Learning mode (unknowns allowed). Strict mode is fail-closed by design
Used byCookiebot, CookieYes, most CMPsOsano, partially OneTrustCookieBeam

Google Consent Mode makes both approaches less critical for Google tags

If you use Google Tag Manager with Consent Mode V2, Google's own tags (GA4, Google Ads, Floodlight) self-regulate based on consent signals, they don't need to be hard-blocked at all. In Advanced Mode, they fire in a restricted, cookieless state even without consent. Script blocking is primarily needed for non-Google scripts that don't respect Consent Mode, such as Facebook Pixel, Hotjar, LinkedIn Insight, and TikTok Pixel.

Basic vs Advanced CMP Operation

Not all CMPs, or CMP configurations, behave identically when a user declines consent. The two principal operating modes, particularly relevant in the context of Google Consent Mode v2, are Basic Mode and Advanced Mode, and the difference between them has a direct and measurable impact on your advertising performance.

In Basic Mode, the CMP completely prevents Google's tags from loading or executing until the user actively consents. If a user declines, no data whatsoever is sent to Google, not even an anonymous signal. This is the more conservative approach and is technically compliant, but it means Google Ads receives zero information about non-consenting users, making Smart Bidding and conversion tracking significantly less accurate for traffic from consent-required regions such as the EEA and UK.

In Advanced Mode, Google's tags are allowed to fire even when a user declines cookies, but they do so in a restricted, cookieless state. These 'cookieless pings' contain no personal identifiers and set no cookies on the user's device. Google uses these anonymous signals as inputs to its conversion modeling algorithms, which can recover up to 65% of conversions that would otherwise be invisible. Smart Bidding can then optimise bids using the modeled data, substantially reducing the performance gap caused by consent refusals.

From a legal perspective, both modes are GDPR-compliant. Data protection authorities have confirmed that sending non-personal, cookieless pings don't constitute personal data processing and therefore don't require consent. Advanced Mode is the recommended configuration for any business that relies on Google Ads performance in the EEA.

Basic vs Advanced CMP Mode

AspectBasic ModeAdvanced Mode
Tag firing before consentBlocked, tags do not loadTags fire in restricted, cookieless state
Data sent on declineNoneAnonymous cookieless pings only, no personal data
Cookieless pingsNot sentSent, enables conversion modeling
Conversion modelingNot availableAvailable, recovers up to 65% of conversions
GDPR complianceCompliantCompliant, cookieless pings are not personal data
Recommended forSites with strict DPO requirements or no Google AdsMost websites using Google Ads in the EEA or UK

What to Look for When Choosing a CMP

The consent management market is crowded, and the differences between platforms matter, both for compliance and for your day-to-day operational experience. Before selecting a CMP, evaluate it against the following criteria.

Ease of Installation

A good CMP should be installable without writing custom code. The two main installation methods are a direct <script> tag added to your HTML <head>, or a template in the Google Tag Manager Template Gallery. Both approaches should be supported. If a CMP requires a developer to configure it from scratch, factor that time and cost into your evaluation.

Google Consent Mode v2 Support

As of March 2024, Google requires Consent Mode v2 compliance for all websites using Google Ads or GA4 in the EEA and UK. Your CMP must support the full set of v2 signals: ad_storage, analytics_storage, ad_user_data, and ad_personalization. Verify that the CMP supports both Basic and Advanced modes and that it has been tested with GTM's built-in consent overview.

Audit Log Capability

A tamper-proof, server-side audit log is not just a nice-to-have, it is your primary defence in the event of a DPA investigation or a data subject access request (DSAR). The log should capture the timestamp, banner version, jurisdiction, and the exact choices made for every consent event.

Multilingual and Multi-Region Support

If your website serves visitors across the EU, your banner must be available in the official language of each member state. Look for CMPs that offer at least 24 EU languages out of the box and that can automatically serve the correct language based on the visitor's browser locale or IP-based geolocation. Region-specific rules (for example, stricter defaults for France or Germany) should also be configurable.

Preference Centre and Scanner

Users must be able to withdraw or change their consent at any time. A well-designed preference centre, accessible from a persistent floating button or footer link, satisfies this requirement. Look for a CMP with a scanner that goes beyond cookies: CookieBeam's headless browser scanner (via CDP) captures cookies, scripts, and network connections in a single crawl, then classifies them through URL pattern matching, inline content analysis, and external databases. Continuous drift detection in visitors' browsers catches changes between scans.

Pricing Transparency

Some CMP vendors charge per pageview, per domain, or add fees for advanced features like audit logs. Review the pricing structure carefully and check whether costs scale in a predictable way as your traffic grows. A flat monthly fee per domain is generally easier to budget for than consumption-based pricing.

Script and Connection Blocking

Understand how the CMP enforces consent at the script level. Manual tagging requires developer effort for each script. URL-based auto-blocking is convenient but can misclassify essential services. CookieBeam takes a third approach: automatic 5-layer interception that catches scripts regardless of how they're injected (createElement, DOM insertion, MutationObserver, Workers), using scan-derived classifications instead of a generic vendor database. It also blocks tracking at the network connection level (fetch, XHR, beacon, WebSocket, EventSource), which catches data exfiltration that happens through API calls rather than script tags. Also check whether the CMP supports per-service toggles that let users control individual scripts within a category.

CMP Evaluation Checklist

  • Easy installation (no coding required)

    Should be installable via a single script tag or a GTM template, with no custom development work needed to get a compliant banner live.

  • Google Consent Mode v2 support

    Must implement all four v2 consent signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) and support both Basic and Advanced operating modes.

  • Tamper-proof consent audit logs

    Server-side logs that record every consent event with a timestamp, banner version, jurisdiction, and the user's exact choices, accessible from the dashboard and exportable.

  • Multilingual banner support (24 EU languages)

    Banner text and preference centre should be automatically served in the visitor's browser language, covering all EU official languages without manual translation work.

  • Granular preference centre per category

    Users must be able to accept or decline cookies by category (e.g. analytics, marketing, functional) and change their choices at any time via an accessible preference centre.

  • Cookie, script, and connection scanner

    A headless browser scanner (via Chrome DevTools Protocol) that captures cookies, external scripts, inline scripts, and outbound network connections. Multi-layer classification pipeline: URL/domain pattern matching, inline content analysis, external cookie databases, and source grouping.

  • GTM Template Gallery integration

    A published template in the Google Tag Manager Community Template Gallery makes installation and Consent Mode configuration significantly faster and reduces the risk of misconfiguration.

  • Script and connection blocking

    The CMP should block non-essential scripts until consent. Look for automatic interception of dynamically injected scripts (not just statically tagged ones) and connection-level blocking for tracking via fetch/XHR/beacon calls. Two compliance modes (learning vs strict) let you control how unknown scripts are handled.

  • Transparent pricing (no per-pageview fees)

    Look for a flat monthly fee per domain with no hidden charges for audit logs, languages, or pageview volumes. Predictable costs make budgeting straightforward as your site grows.

CookieBeam as a Consent Solution

CookieBeam is a Consent Management Platform built around automatic enforcement rather than manual script tagging. Here's what sets it apart:

5-layer script interception. CookieBeam's blocking engine intercepts scripts at five levels: createElement override, DOM insertion hooks (appendChild/insertBefore/replaceChild), MutationObserver fallback, Worker/SharedWorker blocking, and anti-tamper protection that locks neutralised elements. It works from a script map built from your own scanner results, not a third-party vendor list. Two compliance modes control how unknown scripts are handled: Learning mode (default) lets them run while building your inventory, while Strict mode blocks everything unclassified.

Connection-level blocking. Separate from script blocking, CookieBeam wraps five browser APIs to block tracking at the network level: fetch() returns a 204 response, XMLHttpRequest fires an error without making the request, sendBeacon() returns false, and WebSocket/EventSource constructors return stubs. This catches tracking that happens through API calls, not script loading. Category-aware per connection, with first-party bypass and infrastructure host exclusions. Few if any CMPs offer connection-level consent blocking.

Drift detection. The CDN script runs continuous client-side monitoring in every visitor's browser, detecting three types of drift: unknown cookies appearing between scans, new scripts loading that weren't in the inventory, and new network connections to unknown third parties. After 5 sightings, drifted items auto-promote to the inventory for review. This is real-time monitoring, not periodic scanning.

GPC and DNT enforcement. The blocking engine detects Global Privacy Control and Do Not Track signals with per-region overrides. In the EU, GPC sets default deny while an explicit banner opt-in can override it. In US opt-out states, it follows CPRA 7025(b)(3): a privacy signal opt-out requires a deliberate, right-specific in-banner opt-in to override (not a generic Accept All).

Headless browser scanner. A Lambda-based headless Chrome scanner (via CDP) captures cookies, scripts (external URLs and inline content), and network connections. The multi-layer classification pipeline uses URL/domain pattern matching (140+ known domains), inline script content analysis (23+ vendor patterns), external cookie databases, and WordPress plugin/theme source grouping (~300 known sources).

CookieBeam also provides a customisable consent banner, a granular preference centre, Google Consent Mode v2 (including Advanced Mode), a server-side audit log, shield placeholders for blocked iframes, and a regional consent engine with legal framework presets for GDPR, CCPA, US opt-out states, LGPD, PIPEDA, and UK GDPR.

Installation works via a direct <script> tag or a Google Tag Manager template.

Important note on IAB TCF: CookieBeam is not registered with IAB Europe as a certified CMP. For the vast majority of websites, this isn't a requirement. IAB TCF certification is specifically required for publishers using Google AdSense, Google Ad Manager, or Google AdMob to serve programmatic advertising to EEA users. If you're running a content publisher monetised through these products, you'll need a TCF-certified CMP. CookieBeam is well-suited for all other use cases, including e-commerce, SaaS, and lead generation sites using Google Ads and GA4.

Frequently Asked Questions

Do I legally need a CMP?

If your website sets non-essential cookies, including analytics cookies like Google Analytics or advertising cookies like those placed by Google Ads, and you have visitors from the EU or UK, then yes: EU law requires you to obtain valid, informed, and freely given consent before those cookies are set. The ePrivacy Directive (implemented as national cookie laws in each EU member state) and the GDPR together establish this requirement. A Consent Management Platform is the standard mechanism for obtaining and documenting that consent. Operating without one puts you at risk of investigation and enforcement by data protection authorities (DPAs), which can result in fines and mandatory corrective action.

Is CookieBeam a certified IAB CMP?

No. CookieBeam isn't registered with IAB Europe as a certified CMP. This is perfectly fine for the majority of websites. IAB TCF certification is specifically required for publishers who use Google AdSense, Google Ad Manager, or Google AdMob to serve programmatic display advertising to users in the EEA. If you're running an e-commerce store, a SaaS product, or a lead generation site that uses Google Ads and GA4 but doesn't serve programmatic ads through IAB-connected supply chains, CookieBeam covers all your consent obligations without requiring TCF support.

Can I use a CMP without Google Tag Manager?

Yes. Google Tag Manager is a convenient way to manage your tags and integrate your CMP's Consent Mode signals with Google's measurement products, but it's entirely optional. Every CMP, including CookieBeam, supports direct installation via a <script> tag placed in the <head> of your HTML. If you install directly, you'll need to ensure the CMP's initialisation snippet is the first script to execute on the page, before any analytics or advertising tags, so the consent state is established before those tags attempt to fire. GTM makes this sequencing easier to manage but isn't a requirement.

How does a CMP store consent records?

Consent is recorded in two places. On the user's device, the CMP writes the consent record to a first-party cookie and/or localStorage. This stored record includes a timestamp, the specific consent choices made, the version of the banner that was shown, and in some implementations a cryptographic consent string. On subsequent visits, the CMP reads this record and reinstates the appropriate consent state without showing the banner again. CookieBeam also transmits each consent event to a server-side audit log, which is stored securely and accessible from your dashboard. This server-side log provides a tamper-proof record that can be produced as evidence in the event of a DPA inquiry or a data subject access request.