Nothing set before they answer.

Selected Client Engagements

Client

Selected Client Engagements

Sector

Across Sectors

Discipline

Data & Automation

Outcome

Nothing set before the visitor answers

Built for named clients, shown anonymised.

The problem on the table.

A consent banner is a statement of intent. What actually happens is decided by the tags in the container and by the scripts already in the page. Compliance reports tend to read the banner's own configuration, which is how a site can hold a clean report and still write a year-long identifier before anybody has clicked anything.

The usual audit counts requests, and that misses the case that matters. A script already present in the page can write to browser storage and read an existing cookie without making a request an audit would attribute to it, and under the privacy rules storage and reading are in scope exactly as a cookie write is.

Consent Mode makes this harder to see rather than easier, because it governs how the major platform tags behave and says nothing at all about a tag that never declared a consent requirement in the first place.

What forensic looked like here.

The instrument was rebuilt to read the artefact. It loads each site in a real browser and reads every cookie and storage key present before the banner is touched, then again after it is answered, instead of counting the requests it happens to see.

The readings are classified rather than counted, and that distinction is the whole design. A session identifier, a security token and the consent tool's own record of the answer are permitted before a visitor responds, by the law and by the consent tools' own rules, so a report that condemned them would flag every site on every run and stop being read. Anything unrecognised is listed for a person to judge, never quietly cleared and never condemned.

Where a fault was found, the fix was a consent requirement on the tag itself rather than a change to what triggers it. A consent requirement holds the tag and fires it once permission is granted, where re-pointing the trigger at a permission event loses every visitor who agreed on an earlier visit.

Every requirement added is a narrowing. The permissions a tag needs are combined with whatever it already required, so the change can restrict what runs without consent and can never widen it.

• A browser-based census reading real cookies and storage before and after consent
• Classification that permits a session, a security token and the consent record
• Unrecognised entries listed for a person rather than cleared automatically
• Consent requirements added at the tag, so earlier agreement still counts
• A permissions change that can only ever narrow what runs

What changed.

Clients now have a measured answer to what their site writes before a visitor responds, taken in a real browser rather than read off a configuration screen. Where a tag was firing with no stated consent requirement, the corrected tag is prepared and staged, so going live is a single reviewed publish rather than a rebuild.

The method separates two things that are routinely confused: what the consent tool believes it is doing, and what the browser actually does. Only the second is evidence.

• Real browsermeasured, not configured
• Before + afterthe visitor's answer
• Classifiedrather than counted
• Narrowing onlypermissions can never widen

Other engagements.