Usercentrics fits consent setups that have to manage more than a single banner: many domains, multiple jurisdictions, a TCF obligation, or a server-side chain behind it. We have been a certified Usercentrics partner since June 2026.
Why Usercentrics
Usercentrics is the enterprise CMP from Munich. Central management across any number of configurations, geo rules per jurisdiction (GDPR, ePrivacy, US state laws), TCF 2.2, Consent Mode v2 templates, and an app SDK for mobile setups. Cookiebot belongs to the same company and covers the SMB segment; an honest comparison sits in our post OneTrust vs. Cookiebot.
The real lever is not the banner. A CMP setup is only as good as the chain behind it: does the consent state actually reach the server-side container? Do tags really wait for consent? Is the default state correct before the banner is answered? That is where most setups fail, not at the banner color.
Where we stand on Usercentrics
We completed the Usercentrics CMP Expert tech track, the technical certification for implementing and troubleshooting the platform. In practice that means a short path to Usercentrics on escalations and a setup that follows the official standards rather than a copy-paste snippet.
The partner agreement provides for a commission on licences. Nothing has been paid out so far. That does not change which CMP we build for which case: Cookiebot carries small setups, and where a stack runs without consent-requiring services, we say that too. This very site runs cookieless, without a banner.
What we build
- Banner setup with a full service inventory: every service categorized, every legal basis documented
- Consent Mode v2 mapping across GTM web and server containers
- TCF 2.2 configuration where programmatic monetization requires it
- Geo rules per jurisdiction, one banner behavior per legal regime
- Cross-domain consent for multi-domain setups
- QA protocol: tag behavior before consent, after consent, after withdrawal
- Handover documentation your team can actually read
After go-live we take over operations on request: service scans against new unvetted tags, banner updates when the legal situation shifts, consent audits on a fixed cadence. The full picture sits in our Measurement & Privacy Engineering service.
Consent Mode v2 and server-side
The chain is always the same: Usercentrics sets the default consent state, the web container forwards the signals, the server container receives the consent parameters and decides per destination what gets sent. Sounds simple. In practice it breaks in three places: tags fire before the default state, consent flags never reach the server container, or a tag added later bypasses the CMP entirely.
We build the chain end to end and test every link. How Consent Mode v2 works in detail is covered in Consent Mode v2 in practice. What declined consent costs your marketing, the consent loss calculator shows in two minutes.
When another CMP fits better
- Cookiebot, if one domain with a standard stack is enough and nobody needs geo rules
- OneTrust, if consent is meant to be part of a group-wide privacy governance suite and the budget matches
- no CMP at all, if the stack runs without consent-requiring services, for instance with cookieless analytics
What your banner actually covers today, our cookie banner check shows without a signup.
Common failure modes in CMP operations
- the banner is live, but tags fire before consent
- the consent state never reaches the server container, so server-side runs effectively consent-blind
- new marketing tags bypass the consent inventory through direct GTM access
- withdrawal is not propagated, and cookies set earlier just keep living
- nobody checks after a relaunch whether the CMP integration survived the deploy
Every one of these is an audit finding from real projects. The Audit Sprint surfaces them systematically, with documented findings and a prioritized fix list.
