Anatomy of a Pre-Consent Data Leak: One Site, Request by Request

Descriptions of tracking before consent are usually abstract. Data is shared, information flows to third parties, and the reader nods without picking up anything they could act on. So here is a concrete one: a single real practice website, scanned in July 2026, described request by request.

The site belongs to a hair restoration practice. We are withholding the domain, and everything below is what the scan recorded. It scored zero out of one hundred, which sounds dramatic and simply means that every non-essential tracker on the site fired before the visitor was asked anything.

What the scan found: tracking before consent, six times over

Six distinct trackers. Seven cookies. No consent management platform present at all, meaning there was no banner, no preference store and no mechanism by which a visitor could have expressed a view.

It is worth pausing on the absence of a platform, because it makes this case unusually clean. There is no argument here about whether a banner was correctly configured or whether consent mode was wired to the right event. Nothing was configured, so the site's behaviour is simply the default behaviour of the tags installed on it. That default is to transmit immediately.

The practice, for the record, is a competent operation with a well-designed site that ranks well and converts well. Nothing about the finding reflects a lack of care about patients. It reflects that nobody had looked at this particular property of the site, which is a different thing entirely and is the normal state of affairs. We know because we ran the same scan against our own parent company's website on the same day and it also scored zero.

Two further details from the scan are worth stating because they shape what the numbers mean. The trackers were counted as distinct third-party destinations rather than as individual requests, so six is the number of separate companies contacted rather than the number of network calls, which was considerably higher. And the cookie count covers only those set before any interaction; more appear later as scripts initialise.

The sequence, in order

What matters is not the total but the ordering, because the ordering is what makes consent impossible rather than merely absent.

Tags placed in the document head execute during initial parsing, which is before the browser has finished building the page and well before anything is painted on screen. By the time a visitor perceives the site, the requests have completed and the responses have been received.

This is why the distinction between blocking and signalling matters so much in practice rather than in theory. Google documents plainly in its consent mode overview that a denied signal still permits cookieless transmission, so even a correctly wired banner would not have produced silence here. A banner that renders after the page is visible is asking about something already done. That argument is made in full in consent mode is not tag blocking, and this scan is what it looks like in a real timeline.

What each request carried, before consent

The individual requests are unremarkable, which is exactly the point.

Each third-party request carried the page URL, the page title, the referring URL, a persistent identifier from a cookie, the browser and device string, and the visitor's IP address. That is the standard payload of an analytics or advertising tag, sent by design, documented by the vendors, and identical to what the same tag sends on a shoe retailer's website.

The seven cookies are the second half. A cookie is what makes an identifier persistent across pages and across visits, which turns a series of unconnected requests into a browsing history attached to one identifier. Without cookies you have six isolated observations. With them you have a record of everything that visitor read.

Why tracking before consent is the default

Nobody at this practice decided any of this. It is worth being clear about that, because the instinct on reading a scan like this is to look for negligence and there generally is not any.

Tags accumulate. An agency adds a conversion pixel for a campaign. A plugin adds analytics during a redesign. A tag manager container is installed so future changes do not need a developer, and then a contractor adds three more things inside it. Each addition is individually reasonable, made by a competent person for a good reason, and nobody is tracking the cumulative total. Where they all live is covered in where tracking tags actually load.

The other reason is that the default behaviour of every one of these tools is to fire immediately. Loading on page load is what a tag is for, and holding one back requires a deliberate mechanism that somebody has to install and maintain. Doing nothing produces the timeline above, on any site, in any industry.

There is a third reason, less obvious and probably the most important. The people who introduce tags and the people who would care about this are different people, and they rarely have a conversation. A marketing agency adds a conversion pixel because the practice asked for better attribution, which is a reasonable request that was reasonably fulfilled. Nobody in that exchange was thinking about disclosure, because nothing about the request raised it, and the agency is not a healthcare compliance advisor and did not present itself as one.

So the finding is best read as a coordination failure rather than a technical one. Every individual decision was defensible in its own frame. The aggregate was never anybody's job to look at, and it is not visible from inside any of the individual frames. That is precisely why an external measurement of the rendered page is useful: it is the only view that sees the total.

What fixing it changes

The remedy on a site in this state is not complicated, and the sequence matters. It is also not primarily a technical project, which surprises people: most of the work is deciding what is genuinely required rather than implementing the gate.

Inventory what is actually loading, from the rendered page rather than from anyone's memory. Decide which of those are genuinely essential, which on a practice site is usually a very short list. Then hold everything else until a visitor agrees, and record what they were shown and what they chose.

The second of those three steps is where the real work sits, and it is a business conversation rather than a technical one. Essential means necessary to deliver something the visitor asked for, not merely useful to the practice. A session cookie that keeps a booking form working is essential. An analytics tag that tells you which campaign produced the booking is valuable and is not essential, and reclassifying it as essential to avoid gating it is the most common way a correct implementation is quietly defeated.

Once that list is settled, eliminating tracking before consent is largely mechanical. The gate holds everything not on the list, and each visitor's answer determines what runs after that.

After that change, the same timeline shows the page loading, nothing leaving, a decision being asked for, and transmission beginning only if the answer permits it. The score moves from zero to a hundred, which is a crude measure and does capture the thing that changed: at no point did an unconsented request leave the browser. That is what consent gating does, and the reason the gate sits in front of the tag rather than inside it is visible in the timeline above.

One honest caveat about the number. A score of one hundred on this measure means no non-essential tracking fired before consent. It does not mean the site is compliant with anything, and we do not claim otherwise. It means one specific, observable, previously-failing property now holds, and that it can be re-checked tomorrow. Which trackers turn up most often across the sites we scan is the subject of the trackers we find almost everywhere.