consentmanager

What the visitor is asked and how: a reject option on the first layer with the same prominence as accept, consent by category and by vendor, withdrawal and changed choices as easy as the first consent (a persistent button or link), banner texts and layouts the site owner controls, languages, rules per country or regulation (GDPR, Swiss FADP, US state laws), accessibility of the banner itself, and consent-rate analytics or A/B tests that stay within the rules.

0 — Not a consent banner; the product shows a notice that cannot record a choice, or is a different kind of product.

3 — A banner with accept and a settings layer; whether reject sits on the first layer, how consent is withdrawn and how far the design can be changed are basic or not described.

5 — Accept, reject and settings on the first layer, consent by category, a way for visitors to change or withdraw their choice later, customisable texts, colours and layout, the banner in several languages, and a basic consent-rate statistic.

8 — Choice architecture documented in depth: reject and accept of equal weight stated as a default, consent per vendor or service as well as per category, geolocation rules that show a different banner per country or regulation, the banner stated as accessible (WCAG level named), dozens of languages with automatic detection, and consent-rate analytics or A/B testing with the limits on what may be tested explained.

10 — The choice is designed to stand up to a supervisory authority: templates mapped to named regulator guidance (for example the German DSK, CNIL or EDPB cookie banner report), dark patterns the product prevents listed, every banner version kept with its texts so the choice shown can be reconstructed, and consent-rate figures reported without nudging defaults.

What happens before the visitor decides: automatic blocking of scripts, pixels, cookies and embedded content until consent is given, content blockers with placeholders for videos, maps and social embeds, integration with tag managers (Google Tag Manager, Matomo Tag Manager) and server-side tagging, consent passed to forms and plugins, and a documented way for the site owner to check that nothing loads too early.

0 — No blocking of any kind; the product only shows a banner and leaves every script running.

3 — Blocking by hand: the site owner changes script tags or tag-manager triggers using the consent state; automatic blocking, embeds and testing are basic or not described.

5 — Automatic blocking of known scripts and cookies before consent, placeholders for embedded videos and maps, a Google Tag Manager template or integration, and the blocking method documented in the help centre.

8 — Blocking described in depth: an auto-blocking mode and a manual mode with their limits explained, content blockers for named services that the vendor maintains, consent passed to forms, CAPTCHAs and plugins through a JavaScript API or events, server-side tagging supported, and instructions to test in the browser or a tag-manager preview that nothing loads before consent.

10 — Prior blocking the site owner can verify: an automated check or monitor that reports scripts and cookies set before consent on the live site, alerts when a new tracker bypasses the banner, blocking covering local storage, fingerprinting and pixels as well as cookies, and the method published so an auditor can follow it.

How the product knows what the site sets: a scanner that crawls the site for cookies, local storage, pixels and third-party requests, scheduled rescans, a maintained database that classifies cookies and services by purpose, provider and lifetime, alerts on new or changed trackers, and a cookie declaration or policy section that updates itself from the scan.

0 — No scanning and no cookie list; every service is entered and described by the site owner from scratch.

3 — A one-off scan or a list of services the site owner fills in, with some predefined templates; scheduled scans, classification and the declaration are basic or not described.

5 — A scanner that finds cookies and third-party services on the site, regular rescans, automatic classification into categories from a vendor database, and a cookie declaration generated from the result and kept on the site.

8 — Scanning described in depth: scheduled scans with a stated depth or page count, scanning behind logins or in different regions, local storage and pixels as well as cookies, a large maintained database of services with purposes, providers and lifetimes, email alerts on new or changed trackers, and the declaration updated automatically in several languages.

10 — The cookie list stays true without manual work: continuous monitoring of the live site with a change history, unknown trackers flagged for review rather than silently classified, the classification sources and update process published, and scan reports exportable for an audit.

What the site owner can show afterwards: a record per consent with time, pseudonymous ID, the choices made and the banner version shown, how long records are kept and where, export of the consent log, re-consent when the services or texts change, consent expiry, records available to the visitor (a consent ID), and proof that withdrawal took effect.

0 — No record of consent is kept anywhere; the choice lives only in the visitor's browser.

3 — Consent stored in a cookie with a simple log or counter; per-visitor records, retention, export and banner versions are basic or not described.

5 — A consent log with a record per consent (time, pseudonymous ID, choices), a retention period stated, export of the log as a file, and the banner asking again when the configuration changes.

8 — Proof described in depth: each record tied to the banner version and texts shown, a consent ID the visitor can look up, retention and storage location stated, consent expiry configurable, withdrawal recorded as its own event, cross-domain or cross-device consent recorded consistently, and the log searchable and exportable through an API.

10 — Records built for a dispute: a tamper-evident or audit-proof log, every record reproducible with the exact banner and texts the visitor saw, documentation on how to answer a supervisory authority's request, and the full log exportable in an open format when the customer leaves.

Where the consent goes and where the product runs: the IAB Transparency and Consent Framework (TCF, current version) with a registered CMP ID, Google Consent Mode v2 and Google's CMP certification, Microsoft UET consent mode and other ad-platform signals, the Global Privacy Platform and Global Privacy Control for US laws, plugins and apps for WordPress, Shopify, TYPO3 and other systems, iOS and Android SDKs, connected TV, multi-domain and agency accounts, and an API.

0 — No consent signal is passed on; other tools cannot read the visitor's choice.

3 — Consent readable through a cookie or a JavaScript variable, perhaps one CMS plugin; TCF, Consent Mode, app SDKs and multi-site management are basic or not described.

5 — Google Consent Mode v2 supported with the vendor named as a Google-certified CMP, IAB TCF supported, plugins or integrations for several named CMS and shop systems, a JavaScript API, and several domains manageable from one account.

8 — Signals and platforms described in depth: a registered IAB Europe CMP ID and the current TCF version, Google Consent Mode v2 in basic and advanced mode, Microsoft UET consent mode and other named ad signals, GPP and GPC for US states, iOS and Android SDKs documented, agency or partner accounts managing many client sites, and a REST API for configuration.

10 — One consent across every channel: web, apps and connected TV under one configuration, consent shared across domains and logged-in devices, every signal (TCF, Consent Mode, GPP, ad platforms) documented with its mapping to the banner choices, and configuration exportable or managed as code.

Who the contracting entity and the parent company are, where the banner script is served from, where consent logs and scan results are stored, and who the subprocessors are (hosting, CDN, geolocation, scanner infrastructure, app SDK telemetry, email and support). Independently sourced by the sovereignty pipeline; a CMP runs on every page of the customer's site and sees every visitor, so the whole chain counts, not only the database. For a plugin that runs on the customer's own server, the vendor's licence, update and scanner services are the chain.

0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no data processing agreement offered.

3 — A privacy policy and a data processing agreement exist, but hosting location is unstated or non-EU and the subprocessors are not listed.

5 — EU hosting available and an EU contracting entity or EU representative, but parts of the chain (CDN for the banner script, geolocation, scanner, analytics, support) run through non-EU providers without a stated safeguard.

8 — EU hosting on named infrastructure, EU contracting entity, banner script and consent logs served and stored in the EU, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, SOC 2) stated.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting, CDN and every subprocessor, or a self-hosted option that keeps the banner and the logs on the customer's own server; data export and deletion documented, and certifications published with their scope rather than implied.

Whether a buyer can compute the real annual cost from public pages alone: price per domain or site licence, the page-view, session or consent limits of each tier and what happens above them, the free tier's limits, which features (TCF, app SDKs, A/B testing, multi-domain, white label) cost extra, agency or reseller terms, minimum term, and setup.

0 — No public prices at all; every customer is a sales call.

3 — A starting price or a free tier exists, but how cost scales with domains, traffic or features is unclear.

5 — Tiers are public with their price per domain or licence and their main inclusions, but at least one commonly needed piece (traffic overage, extra domains, TCF, app SDKs, agency use) is unpriced or "on request".

8 — Every tier priced publicly with its scaling rule (per domain, per page view or session band, per site licence), overage and extra domains priced, add-ons listed with prices, minimum term and VAT treatment stated.

10 — Complete price computability: annual cost derivable for a given number of domains, traffic and apps, with every add-on, setup, support, overage and agency fee and the cancellation and data-return terms published.