Cookie Consent Implementation Services

Why most cookie banners fail an inspection

The banner is rarely the problem. The problem is what happens in the 400 milliseconds before it appears. Analytics has already loaded. A chat widget has set two cookies. An A/B testing tool has written to local storage. By the time the user is asked, the answer no longer matters for a meaningful share of what was collected.

The second common failure is category drift. Someone maps vendors carefully at launch. Eighteen months later the site has three new tools, two of them added directly in the tag manager by a marketing contractor, and none of them are in the CMP's vendor list. The banner still looks fine. The categorisation is now fiction.

The third is the reject path. Regulators across the EEA have converged on the position that refusing must be as easy as accepting, and that pre-ticked boxes and 'continue browsing means consent' are not consent. Plenty of live banners still fail one of those tests, usually because the design was signed off before anyone read the guidance.

• Tags firing before a consent decision exists, or firing on a default-allow state
• Categories mapped to vendor names rather than to the cookies and storage those vendors actually write
• No reject-all control at the same level as accept-all
• A preference centre that saves the choice but never propagates it to the tag layer
• Consent records that cannot be exported or tied back to a specific banner version

How we implement it

We start with a scan, then we distrust the scan. Automated crawlers miss anything behind a login, anything that only loads on a checkout step, and anything a consent gate is already suppressing. So we scan, then walk the real journeys with the network panel open, and reconcile the two lists.

Categorisation comes next, and this is where the judgement calls live. Strictly necessary is narrower than most vendors would like you to believe: a session cookie for a shopping basket qualifies, an analytics cookie that happens to be useful does not. We document each decision, because a defensible categorisation is one you can explain, not one that merely exists.

Then the build: banner and preference centre styled to your design system, multi-language where you need it, and a tag layer that genuinely gates. Gating means the tag does not exist until consent, not that it exists in a disabled state that a redirect can bypass. Finally, testing across browsers and devices, including the paths people forget — returning visitors, users with an existing consent cookie from a previous banner version, and users arriving on a subdomain.

• Full cookie and storage inventory, automated plus manual verification of authenticated and transactional journeys
• Category mapping with written rationale per vendor and per cookie
• Banner and preference centre built to your brand, mobile-first, accessible, and multi-language
• Symmetric accept and reject controls at the first layer
• Tag gating via your tag manager or server-side container, with consent state verified in the data layer
• Cross-browser, cross-device and returning-visitor testing before go-live

Platform choice, and why it matters less than you think

We implement across the mainstream consent platforms, and we work most often with OneTrust as OneTrust implementation specialists. But the platform is a smaller factor in the outcome than teams expect. Every major CMP can produce a compliant implementation, and every one of them can produce a non-compliant one just as easily.

What actually differentiates them is operational fit: how much control you need over banner markup, whether you need consent to travel across a large multi-brand estate, whether your team will maintain vendor lists themselves, and whether you need consent signals available server-side. Those questions have different answers per organisation, which is why we ask them before recommending anything.

If you have already bought a platform, that decision is made and we work with it. Re-platforming to fix an implementation problem is usually the expensive way to solve the wrong thing.

Keeping it working after launch

Cookie consent decays. New tools get added, vendors change what they set, browsers change how they treat storage, and guidance moves. An implementation that was correct at launch drifts out of correctness on a timescale of months, not years.

We build for that: a documented process for adding a vendor, a periodic rescan cadence, and a change log tied to banner versions so you can show what a given user saw when they consented. Where teams want it, we run the rescan and the delta review as an ongoing engagement; where they do not, we hand over a process they can run themselves.

We also train the people who will touch it — usually a marketing operations lead and a front-end developer. The single best predictor of whether an implementation stays compliant is whether someone internal understands it well enough to say no to a request.