The Sensitive Data You Send to Ad Platforms Without Realising: Your URL Paths

When a team worries about sending sensitive data to an ad platform, they look at the event parameters. They check what the dataLayer push contains, they argue about whether an email hash is acceptable, and they satisfy themselves that nothing improper is being deliberately transmitted. Then they ship a booking flow where the page for a cardiology appointment lives at a URL that says cardiology, and that string is sent to every connected platform on every pageview, by design, before any custom event is involved at all.

The page path is a payload

Standard web tracking sends the page location. That is not an edge case or a misconfiguration, it is the core of what a pageview is. Google's own guidance is unambiguous about what this means in practice: "PII is often inadvertently sent in these URLs and titles. Both the URL path and parameters must be free of PII."

Note that it names the path, not just the query string. A lot of teams have internalised "strip the query parameters" and stopped there, which handles ?email= and misses /book/oncology/follow-up entirely.

The same applies to the page title, which is also transmitted by default and which, on most content management systems, is generated from the same source as the path. If the path says it, the title usually says it too.

Why this is a policy problem and not just a preference

It is tempting to file this under privacy hygiene, something to tidy up when there is time. It is more pointed than that, for two reasons.

Meta maintains categories of information that businesses are not permitted to send through its business tools at all. The responsibility sits with the advertiser, not the platform, and the enforcement mechanism is not a warning email. It is the dataset being restricted, which looks from the inside exactly like the tracking breaking for no reason. What a restricted dataset actually does to your tracking covers that experience in detail, and a surprising number of those cases start here.

Google restricts personalised advertising around a long list of sensitive interest categories, including health and several others that a booking or application flow will walk straight through. Sending the category in the URL does not just risk a policy action, it can also quietly restrict what you are allowed to do with the audience afterwards.

So the cost is not hypothetical reputational risk at some future date. It is a dataset restriction that stops your optimisation working, arriving with no explanation, weeks after the thing that caused it.

What actually counts as sensitive is broader than people assume

The usual mental model is "names, emails, phone numbers". The real boundary is wider and it catches ordinary-looking product and service structures.

• Health. Specialties, conditions, symptoms, test names, medication names. A path like /exams/hiv-panel is a health disclosure about an identifiable browser.
• Financial circumstance. Debt consolidation, bad-credit products, bankruptcy guidance, hardship applications.
• Belief and identity. Religious or spiritual products, political affiliation, sexual orientation, ethnicity-specific services.
• Legal situation. Immigration status, criminal defence, family law.
• Direct identifiers hiding in plain sight. Order confirmation pages with an email in the path, account pages keyed by username, password reset URLs, invitation links with tokens.

The last group is the one that catches ecommerce teams who were confident none of this applied to them.

Every place it leaks

Worth enumerating, because fixing one and missing the rest is the normal outcome.

1. The page location on every pageview. The default, highest-volume leak.
2. The page title. Usually derived from the same content, sent alongside.
3. The referrer on the next page. This one is sly. Even if you clean the sensitive page, the page the user lands on afterwards may report the sensitive URL as its referrer.
4. The source URL on server-side events.If you populate a source URL on Conversions API events, it carries the same string server-side, where people assume they are safe because "the browser is not involved".
5. Anything that copies the URL into a parameter. Form submission handlers and chat widgets frequently record the current page and pass it along.

Finding it, in about twenty minutes

You do not need a formal audit to establish whether you have this problem.

1. Walk the two or three highest-intent journeys on the site yourself: booking, application, checkout, account creation. Write down every URL you pass through.
2. Read that list as though it were a sentence about the person. If it tells you something about their health, money, beliefs or legal situation, it is telling the platforms too.
3. Open the network requests on one of those pages and look at what is actually being sent to each analytics and advertising endpoint. The page location will be there in full.
4. Check the referrer on the step after the sensitive page.

If you manage client sites, this is a reasonable thing to add to an intake review; auditing a client's tracking in fifteen minutes covers the rest of that pass.

Fixing it without a six-month replatform

The instinct is to rewrite the URL structure, which is slow, risky for SEO, and usually unnecessary as a first move.

Redact before sending. The practical fix is to overwrite the page location and page title in your tag manager before the hit goes out, replacing the sensitive segment with a stable placeholder. The user still browses /book/cardiology; the platform receives /book/specialty. You keep the funnel step, you lose the disclosure. Analytics still tells you how many people reached the booking step, which is the thing you actually needed.

Send identifiers, not names. Where you genuinely need to distinguish between categories for reporting, send an opaque ID that means nothing outside your own systems rather than the human-readable label.

Fix the referrer too. Redaction on the sensitive page does not clean the referrer reported by the following page. Handle both or you have moved the leak rather than closed it.

The minimum ask when you do not own the site

A lot of people hitting this problem have no development access and a development team with no spare capacity, which makes the size of the request decisive.

The smallest version that works is a single dataLayer push on the confirmation step containing: the type of action in broad terms, whether the person is new or returning, and a value. No specialty, no condition, no exam name, no free text. Everything else you can build in the tag manager yourself from that one push, including the redaction rules.

That is a request a developer can implement in an afternoon, which matters considerably more than whether it is the theoretically ideal implementation.

Consent does not solve this

A reasonable objection at this point: we have a consent banner, so anyone whose data reaches the platforms has agreed to it.

That argument does less work than people hope. Consent governs whether you may process someone's data for advertising. It does not make a prohibited category permissible to transmit. If a platform's terms say it will not accept health information through its business tools, a consent checkbox on your site does not change what the platform has agreed to receive. The restriction is contractual as much as regulatory.

There is also a practical gap. Consent tooling usually gates whether tags fire at all, which is a blunt instrument: either the pageview goes out with the sensitive path intact, or it does not go out. Redaction is the more precise tool because it lets you keep the measurement while removing the disclosure, and the two are complementary rather than alternatives. If you are working through the consent side as well, consent mode and what it does to your tracking covers that interaction.

Explaining it to a client who does not want to hear it

If you manage this account for someone else, you will have to raise it, and the framing determines whether anything happens.

Leading with compliance usually stalls, because it sounds like a legal opinion from a marketing agency and it lands as someone else's problem. Leading with the operational consequence works better: the realistic outcome of leaving this is that the dataset gets restricted and the campaigns stop optimising, at a moment nobody chooses, with a review process attached that has no committed timeline.

Then make the ask small and concrete. You are not proposing a replatform or a URL migration. You are proposing that the tag manager overwrite one segment of the page path before it is sent, which changes nothing a user or a search engine ever sees. That is a scoped, reversible change, and it is a much easier yes than "we need to talk about privacy".

Why leaving it is more expensive than it looks

The bill for this does not arrive as a fine. It arrives as a dataset that stops optimising properly, or an audience you are no longer allowed to build, or a restriction with a review process attached and no clear timeline, in the middle of your best quarter. The connection back to a URL structure decided two years ago by someone who no longer works there is not obvious to anyone trying to fix it.

It is also the rare tracking problem where the fix is cheap and the delay is the expensive part. Redacting a path segment is an afternoon. Getting a restricted dataset reinstated is not.