Installing a Consent Management Platform is the easy part. Configuring it correctly — so it holds up under regulatory scrutiny, works across browsers, and doesn’t silently break your analytics — is where most teams stumble. The following ten errors are drawn from real-world audit findings, regulator decisions, and developer post-mortems. Work through this list before your next compliance review.
1. Firing Tags Before the Consent Signal Resolves
The single most fined implementation mistake. If your tag manager fires Google Analytics, Meta Pixel, or any other tracking tag on page load — before your CMP has read the visitor’s stored preference or received a new choice — you are collecting data without a legal basis. Always wrap every non-essential tag in a consent-based trigger, and test with browser storage cleared to confirm cold-load behaviour.
2. Storing Consent Without a Record of What Was Shown
A valid consent record must capture what the user consented to, the version of the banner they saw, and the timestamp. Many teams store only a boolean cookieConsent=true. That string proves nothing when a regulator asks for evidence of informed, specific consent. Audit your consent storage format now — it should include banner version, IAB TCF string (if applicable), and a UTC timestamp at minimum.
3. Using Pre-Ticked Boxes or Forced Acceptance
Opt-in checkboxes that arrive pre-selected, “Accept all” buttons styled to dominate, or banners that bury the “Reject” option in a submenu all fail the voluntariness test under GDPR Article 7. Dark patterns have become a specific enforcement priority — the French CNIL, the Dutch AP, and the Irish DPC have all issued fines based solely on banner design. Make acceptance and rejection equally prominent and equally easy.
4. Not Propagating Consent State to Google Consent Mode
Your CMP may correctly collect a consent signal but never pass it to gtag('consent', 'update', {...}). The result: Google’s tags run in a default denied state (good), but never receive the update when the user accepts, so conversion modelling and remarketing remain broken even for consented users. Verify the update call fires within the same tick as the user’s choice using the browser console or a proxy tool.
5. Setting Default Consent to “Granted” in Consent Mode
Some integrations ship with:
gtag('consent', 'default', {
analytics_storage: 'granted',
ad_storage: 'granted'
});This is functionally identical to having no consent gate at all. Defaults must be 'denied' for any purpose that requires consent under your applicable law. Check every environment — staging, production, and any A/B test variant — separately.
6. Ignoring Geo-Specific Rule Sets
A banner configured correctly for the EU may be completely wrong for California (CCPA opt-out model), Canada (PIPEDA), or Brazil (LGPD). CMPs that support geo-targeting often ship with a single global template enabled by default. If you serve visitors across jurisdictions and haven’t configured regional rule sets, you are almost certainly non-compliant in at least one of them.
7. Failing to Block Third-Party Scripts Loaded Outside the Tag Manager
Many sites load marketing scripts directly in <head> via a theme, plugin, or hard-coded snippet — entirely outside the tag manager that the CMP controls. These scripts execute on every page load regardless of consent state. Audit your full HTML source, not just your tag manager container. Tools like browser DevTools network waterfall or a headless cookie scanner will surface these rogue loads.
8. Not Surfacing a Persistent Opt-Out Mechanism
GDPR requires that withdrawing consent be as easy as giving it. If your consent banner disappears after the first interaction and the only way to change preferences is a footer link buried under five other links, that fails the accessibility and ease-of-withdrawal tests. Implement a sticky icon, a floating widget, or a clearly labelled link in your site footer that re-opens the preference centre.
9. Letting Consent Records Expire Silently
Most regulators expect consent to be refreshed periodically — typically every 6 to 12 months. Many CMP implementations set an indefinite cookie expiry or fail to prompt returning visitors when the banner version has changed. Set an explicit expiry on your consent cookie aligned to your legal basis documentation, and trigger a re-prompt when you update your vendor list or purposes.
10. Treating the CMP as a Set-and-Forget Deployment
This is the meta-error that enables most of the others. Sites change: new tags get added, plugins get updated, CMS themes swap out script snippets. A consent configuration that was valid on launch day can be completely broken six weeks later without anyone noticing. Schedule regular cookie scans — at least monthly — and set up alerts for any net-new cookies or domains that appear without a corresponding CMP entry.
A Quick Self-Audit Checklist
- Clear all browser storage and load your homepage — do any non-essential requests fire before the banner appears?
- Check your consent cookie payload — does it store version, timestamp, and specific purposes?
- Open the browser console and confirm
gtag('consent', 'update')fires on acceptance. - Verify your Consent Mode defaults are all set to
'denied'. - Inspect your raw HTML source for scripts loaded outside your tag manager.
- Test from a European IP (or with a VPN) and from a US IP — do you see different banner variants?
- Check your footer — can a user easily re-open the preference centre?
None of these errors require advanced engineering to fix, but all of them require deliberate attention. The gap between a CMP being installed and a CMP being correctly implemented is exactly where regulatory exposure lives. Close that gap before an automated scanner — or a regulator — does it for you.