In short
A consent management platform (CMP) is software that obtains consents from website visitors, documents them and passes them on to downstream tags and tools. It controls the cookie banner, manages consent per purpose and ensures technically that services requiring consent are only loaded after consent has been given.
In Germany it is the usual tool for implementing the requirements of § 25 TDDDG and the GDPR.
In everyday use, the term is often equated with "cookie banner". That falls short: the banner is only the visible surface. The real value of a CMP lies in managing the state of a consent, storing it verifiably and passing this state on to all systems that depend on it, from the tag manager to the analytics tool to the advertising network.
Core functions of a consent management platform
Regardless of the provider, every serious CMP fulfils a fixed set of tasks. Anyone comparing offers should check these functions individually instead of going by the range of functions on the marketing slides.
- Banner and layer control: display of the first level with equivalent options and a second level for the detailed selection.
- Granular purposes: separation by categories such as necessary, statistics, marketing and external media, so that users can decide individually.
- Withdrawal: a way of changing the decision that can be reached at any time, usually via a permanently visible trigger in the page footer.
- Audit-proof logging: proof of who consented to which purposes when and which banner version was shown in the process.
- Tag blocking: technically preventing scripts that require consent from loading before consent is given.
- Interfaces: connection to Google Consent Mode, to the Transparency and Consent Framework (TCF) for advertising ecosystems and to common tag management systems.
Tag blocking: the function that usually fails
The most important and most frequently incorrectly implemented function is blocking. § 25 TDDDG requires consent to be given before the device is accessed. A CMP must therefore prevent a script from being loaded at all as long as no consent exists, not merely inform it afterwards.
Technically, there are several ways of doing this. With server-side rendered pages, script tags are delivered with a placeholder attribute and only activated after the consent signal. In tag management systems, each tag is bound to a trigger that listens for the consent event. Some CMPs also offer automatic blocking that recognises and prevents known script domains. This automation is convenient but never complete: it does not recognise in-house developments, self-hosted scripts or newly integrated services. That is why every set-up includes a manual check in the browser's developer console.
Logging and accountability
Art. 5(2) GDPR requires the controller to be able to demonstrate compliance with the principles. For consents, this means specifically: it must be possible to prove that consent was given, for which purposes it applied, when it was given and what information was shown to the user in the process. For this, a CMP stores one record per decision, usually with a timestamp, list of purposes, banner version and a pseudonymous identifier.
Two details are relevant in practice. First, the retention period: the proof is only useful if it still exists when a supervisory authority asks. Second, the storage location: if the logs are kept by a provider outside the EU, a separate third-country check is added, of all things for the tool that is supposed to establish data protection compliance.
TCF integration and when it is needed
The Transparency and Consent Framework (TCF) is an industry standard through which consents are passed on within the programmatic advertising ecosystem. A CMP with TCF support translates the user's decision into a standardised signal that participating advertising partners can read. This is relevant above all for publishers and operators who market advertising space via networks.
For the typical B2B online shop or a corporate website, on the other hand, TCF is rarely necessary. Anyone who activates it without needing it ends up with a much longer and more confusing list of vendors in the banner, with the foreseeable consequence that the consent rate falls and the presentation becomes harder to understand. The rule of thumb: only activate TCF if an advertising partner specifically requires it.
Google Consent Mode v2
Since 6 March 2024, Google Consent Mode v2 has effectively been a prerequisite for Google Ads and Google Analytics providing their full range of functions in the European Economic Area. The trigger was the Digital Markets Act, which obliges Google to obtain a verifiable consent signal for processing user data. Without this signal, remarketing audiences and parts of conversion measurement, among other things, are lost.
Consent Mode does not transmit personal data but status signals. The two most important for advertising are ad_storage and ad_user_data, plus ad_personalization and analytics_storage. Each signal has the value "granted" or "denied", and the CMP is the source that sets these values.
Basic mode and advanced mode compared
| Criterion | Basic mode | Advanced mode |
|---|---|---|
| Loading behaviour | Tags only load after consent | Tag loads immediately, sends cookieless pings before consent |
| Data situation in case of refusal | No data | Modelled data from aggregated signals |
| Data protection classification | Lower risk, as nothing loads before consent | Trickier, as a connection is established before the decision |
| Typical use | Operators with a conservative risk position | Operators with a high need for conversion modelling |
The decision between the two modes is not purely a marketing question. In advanced mode, a connection to Google servers is already established before consent. Even if no identifier is set on the device in the process, the constellation is controversial in terms of data protection law. Anyone using advanced mode should document the decision and agree it with their legal advisers instead of making it on the side in tag management.
Consolidation of signal control since June 2026
In June 2026, Google consolidated signal control: for personalisation, Google Ads now relies essentially on the ad_storage signal. For operators, this mainly means that the mapping of banner categories to Consent Mode signals should be reviewed. Anyone who historically mapped the signals in the CMP to their own categories should check whether the mapping still produces the expected behaviour, in particular whether rejecting the marketing category really leads to ad_storage: denied.
Withdrawal is also underestimated. It must be as easy to reach as the original consent. In practice, a permanently visible trigger in the page footer that reopens the banner is sufficient. If it is missing or only located in the privacy policy behind several clicks, the consent is open to challenge, regardless of how cleanly the first level was designed.
What a CMP does not do
A CMP is a tool for implementation, not a legal basis. This distinction sounds academic but has very concrete consequences for projects.
No substitute for the legal basis
The consent is obtained by the tool, but its validity depends on factors outside the tool: is the information clear and understandable? Is refusing just as easy as agreeing? Are the purposes described accurately? A flawlessly configured banner that lists analytics cookies as "technically necessary" does not generate valid consent; it merely documents an invalid one cleanly.
Nor does a CMP solve the questions of subsequent processing: data processing agreements, deletion periods, third-country transfers and data subject rights remain the responsibility of the controller. The legal basis for this is described in the entry on the TDDDG (German Telecommunications Digital Services Data Protection Act).
No protection against wrong categorisation
Almost every CMP offers a scan that automatically sorts the cookies found on the website into categories. This automation is a starting point, not a result. It recognises known services by patterns but often misclassifies unknown or self-set cookies, if in doubt as necessary, because it does not know their purpose. The content assignment must be the responsibility of a person who knows what the respective cookie does in the specific system.
Selection and typical failure patterns in practice
When selecting a CMP, it is worth looking at a few hard criteria: where are the consent logs stored? How reliably does the tool block scripts that are not in its database? Can the banner be designed so that consent and refusal are equivalent on the first level? How quickly does the script load, and does it block page rendering? And is there a documented interface to the tag management system in use?
A recurring failure pattern from shop projects: a retailer migrates their shop to a new system and takes over the CMP configuration from the old installation. The categories and texts are right, and the scan reports nothing unusual. But the developer console shows that the new theme embeds its own analytics snippet directly in the template, which has never passed through the CMP: it loads before any decision. The CMP is working correctly; it simply does not know the script. Something like this is not found via the tool's dashboard but via a manual network capture on the first page view in a fresh browser profile, before anything has been clicked. Exactly this test has to be repeated after every relaunch, every theme update and every new tool integration.
A second pattern concerns administration itself: the CMP is set up once at launch and then not touched again, while marketing continually adds new tags via the tag manager. After a few months, the container contains services that do not appear in any banner category. A fixed rule that every new tag is assigned to a category before publication therefore makes sense, solved organisationally, not technically.
Classification: tool, law and implementation
The CMP is the technical answer to a legal requirement. It replaces neither the legal assessment of which services require consent nor the data strategy for the case where many users refuse. Anyone who bases their management exclusively on tools that require consent makes themselves dependent on a consent rate they cannot influence. Metrics available on the server side from your own shop or ERP system remain usable regardless.
How categories, tag blocking and documentation can be set up in concrete terms and which checks are due after a relaunch is described in the practical guide on cookie consent under the TDDDG. Background on centrally managed consents and the register of recognised services can be found at the German Federal Commissioner for Data Protection (BfDI); the European Data Protection Board commented in its opinion 08/2024 on the requirements for voluntariness in consent-or-pay models.