Facebook pixel sending health data: how page URLs and event names give it away

The Meta pixel is a very obedient piece of code. That's the problem.

A browser pixel passes along whatever it finds on the page. You can't tell it "send the booking, but leave out what the booking is for". It sends what it sees, faithfully, every time. So let's look at what it typically sees on a clinic site, because most people have never looked.

The address bar. Something like yourclinic.com/treatments/acne-scarring/book. That whole path is sent with the event. The visitor's condition is spelled out in the link.

The page title. "Weight Loss Programme: Book a Consultation". Sent.

The button or form text. Sometimes sent, depending on how the pixel is set up.

The event name. If someone set up a custom event, it's often named after the service: Book_Implant_Consult, Scalp_Treatment_Lead. That reads as health information the moment it leaves your site.

Any of those can be enough for Meta to hold back or drop the event. And because the pixel is doing exactly what it was built to do, nothing looks broken on your side. That's what makes it so hard to diagnose.

There's a mental model that helps. Think of every event as a postcard. The pixel writes on it whatever it can find: where the person was, what the page said, what the button was called. Then it posts it. You never see the postcard. And nobody asked whether the postcard should say what someone is being treated for.

How do you see the postcard? Open Events Manager, go to Test Events, and trigger a booking on your own site. Read the parameters as if you were seeing them for the first time. The URL parameter is usually the eye-opener.

Why does it keep coming back after you fix it? Because the pixel is on every page, and every page is a chance. A new landing page for a new treatment. A plugin update that adds the page title. A marketer who creates a custom event with a helpful name. None of these feel like privacy decisions, so nobody reviews them.

What to do about it, in a sensible order. Move the sending from the browser to your server, so you decide what goes. Cut the link down to the domain, so no treatment path travels. Use neutral event names, so the name reveals nothing. Send hashed email and phone, and keep anything else that could describe a person's health out of the event. And keep a record of what you sent, so the next review is a lookup, not a hunt.

Let me walk one booking event field by field and give each a rough risk rating, so you can see where the danger sits.

Page URL: high. It's the most descriptive field and the one most often carrying a treatment name.

Page title: high. Often more descriptive than the URL, and easy to overlook.

Event name: high if named after a service, low if neutral.

Referrer, meaning the page they came from: medium. A collection or category page can carry a condition.

Hashed email and phone: low. They identify a person, and they're what matching needs.

The ad click ID: low. It identifies a click.

IP address and user agent: low to medium. Standard for matching, and not descriptive of health.

Custom fields and form values: high if they're clinical, and the hardest to justify.

Notice the pattern. The high-risk fields are the descriptive ones, and the low-risk fields are the ones matching actually uses. That's why you can clean without losing the signal: the parts that cause trouble aren't the parts that do the work.

What did your Test Events show that surprised you?

For reference, DataCops cuts the link to the domain and renames the event before it leaves, and the delivery log lets you open a purchase and check the product name isn't in it.