When we started building CookiePal, we assumed the difficult part would be the consent logic.
A visitor accepts analytics, rejects marketing, and the website responds accordingly. The choice is stored, the relevant services are notified, and everyone gets on with their day.
That was the neat version.
The real version involved scripts loaded directly in HTML, scripts injected by tag managers, scripts added by plugins, scripts created after the page had already loaded, and scripts nobody on the website owner’s team knew existed.
The problem was not understanding consent.
The problem was controlling a website we did not build.
There Is No Standard Website
A consent management platform has to work across WordPress, Webflow, Shopify, custom frameworks and the internal CMS somebody built in 2014 that is now apparently too important to replace.
Even two websites using the same platform can behave completely differently.
One might load Google Analytics through Google Tag Manager. Another might place it directly in the page header. A third might do both accidentally, with nobody quite sure which implementation is feeding the reports.
Then there are embedded videos, chat widgets, heatmaps, advertising pixels, CRM forms and plugins that inject their own scripts whenever they feel like it.
From the outside, the requirement sounds simple:
Do not load non-essential scripts before consent.
From the inside, that becomes a timing problem, a classification problem and occasionally a detective story.
Blocking Scripts Is Easy. Blocking the Right Scripts Is Not.
We could block every third-party request on a page.
The website would also stop working.
Payment providers, authentication services, security tools and essential application features often depend on third-party resources. A CMP cannot treat every external domain as suspicious and hope for the best.
The actual challenge is deciding which resources belong to which consent category, then controlling them without interfering with the rest of the website.
That gets harder when the same vendor can serve different purposes. A service might support essential functionality on one website and advertising on another.
A domain name alone does not always tell you enough.
Context matters.
Timing Causes Most of the Trouble
The CMP has to establish the consent state before optional scripts begin loading.
Unfortunately, browsers are very good at loading things quickly.
A script in the page header can execute before the banner appears. A tag manager can inject another script almost immediately. A plugin can create an iframe after the initial page load. A single-page application can replace half the page without performing a traditional navigation.
By the time the visitor sees the consent banner, the website may already have made several requests.
This creates a strange race:
- The website starts loading.
- The CMP establishes the default consent state.
- Third-party tools attempt to initialise.
- The visitor makes a choice.
- Everything updates without reloading or breaking the page.
The banner is the calm-looking part of this process.
Behind it, several systems are trying to be first.
The DOM Does Not Stop Changing After Page Load
A basic scanner can inspect the page once and report what it finds.
Modern websites rarely make things that easy.
Scripts can be injected after a button click. Videos may only load when they enter the viewport. Chat tools might appear several seconds later. Single-page applications can change routes without refreshing the browser.
Consent control therefore cannot rely only on what exists during the initial page load. It also has to account for elements and scripts created later.
This was one of the bigger lessons for us: a website is not a finished document. It is a running environment.
Scanning it once is useful.
Controlling it continuously is different.
Tag Managers Add Another Layer of Indirection
Google Tag Manager is useful because it lets teams manage tracking without changing the website code every time.
It also means the source code no longer tells the whole story.
The page loads a container. The container decides which tags to run. Those tags may depend on triggers, variables, routes, events and consent states.
When something fires unexpectedly, the cause may be inside the website, inside the tag manager or inside another tool loaded by the tag manager.
Debugging becomes less like following a straight line and more like interviewing several witnesses who all remember the event differently.
Consent Changes Need to Propagate
The initial choice is only part of the problem.
A visitor might reject marketing, later reopen the settings and accept it. The CMP must update the stored preference, notify the relevant integrations and allow the correct tools to initialise.
The opposite direction is more awkward.
When someone withdraws consent, stopping future activity is possible. Undoing everything a third-party script has already done is not always so simple.
This is why the order of operations matters. Prevention is more reliable than trying to clean up after a script has already run.
Testing the Interface Is Not Enough
A banner can look perfect while the consent implementation underneath it is completely wrong.
Clicking Reject all and watching the banner disappear proves almost nothing.
Testing a CMP means looking at network requests, cookies, browser storage, tag-manager behaviour and what changes between consent states.
We repeatedly test three moments:
- Before the visitor interacts with the banner
- After optional categories are rejected
- After specific categories are accepted or changed
The interesting bugs tend to appear between those states.
A tool stays active after consent is withdrawn. A script executes before the default state is ready. A page transition loads something that the first page correctly blocked.
None of this is visible in a screenshot of the banner.
Becoming a Google Gold CMP Reinforced the Same Lesson
Working towards Google Gold CMP status was not mainly about the visual interface.
The important work was in the integration: establishing the correct consent state, communicating updates properly and making the process reliable for website owners who do not want to become experts in browser internals.
Consent management is not one feature.
It is coordination between the visitor, the website, the browser, the tag manager and every third-party service waiting to load.
The visitor sees two or three buttons.
The engineering happens in everything those buttons are expected to control.
What We Learned
The hardest part of building a CMP was not creating a consent model. It was applying that model to websites with different architectures, tools and histories.
The web is flexible because almost anything can be added to a page.
That same flexibility makes consent enforcement difficult.
A good CMP has to operate inside an environment it does not own, manage technologies it did not install and remain mostly invisible while doing it.
When it works, the result is pleasantly boring.
The visitor makes a choice. The website respects it. Nothing loads through a side door.
That sounds simple.
Getting there was not.
Top comments (0)