Meta Conversions API for clinics: how to send bookings without sending the treatment

Moving to the Conversions API is the standard advice for clinics with tracking trouble. It's good advice. It's also incomplete, so let me finish it, because the missing half is where clinics get stuck.

The Conversions API sends events from your server instead of the visitor's browser. That gives you something the pixel never did: control over what goes. But control isn't the same as cleaning. If your server sends the same URL, the same event name and the same form details the pixel did, you've just moved the leak to a different pipe. The gain is that you now can clean. The cleaning is still your job.

So what does a clean booking event look like, in plain words?

Where it came from: your domain only. Not the treatment page.

What it's called: a neutral code, like L_1 for a lead or S_1 for a booking, not "Book_Implant_Consult".

Who it's about: a hashed email and phone, plus the ad click, so Meta can still match it to the person who clicked.

What else: nothing. Anything that could describe a person's health stays out.

And the match still works, because matching relies mostly on who the person is and which ad they clicked, not on the page they read. That's the reassuring part: you can strip the descriptive detail without stripping the matching.

Now the next problem, and it's the one that changes results: the booking isn't the sale. The sale happens after the consultation, and a form fill can't show it. So the strongest signal you can give the ads is the later stage: booked, showed up, treatment paid. Sent from your CRM, with the click attached and the identity hashed. That's what turns "find people who book" into "find people who turn up and pay".

A few practical points for doing it well.

Send the stage when it happens, not in a batch. Meta rejects events sent more than 7 days after they happened, so a weekly export loses the older rows.

Make sure the pixel and the server share an event ID if both report the same booking, or Meta counts it twice.

Keep a record of what was sent. If a review ever asks, "here is what left" beats "we think it's fine".

Keep patient records in your CRM, and send only what the platform needs.

Some mistakes I see when clinics move to server-side, so you can skip them.

Sending the same URL. The server has the page address too, and if it just forwards it, nothing changed. The cleaning has to be a deliberate step.

Forgetting the event ID. If the pixel and the server both report the same booking, they need to share an ID or Meta counts it twice.

Dropping the click ID. Server events are matched more strongly with the click ID and the hashed identity, and a server event with neither matches poorly.

Sending raw email or phone instead of hashed values. The identifiers should be hashed, and formatted before hashing, or they won't match.

Forgetting the thank-you page. Even after you clean the booking event, a separate thank-you event can leak the same treatment name.

Treating it as a one-off. Sites change. A cleaning step that runs on every event, in one place, survives a redesign. A one-time fix in a plugin doesn't.

How are you sending bookings today: pixel, server, a tool, or a mix?

For reference, this is the case DataCops health mode was built for: a neutral L_1 for a lead and S_1 for a booking, with hashed email and phone and the ad click, and a log of each event.