Offline conversion tracking for clinics without sending patient data: booked, showed, paid

The whole point of offline conversions for a clinic is to tell the ad platform what happened after the form. And the whole worry about health advertising is not telling the ad platform too much. Those two things sound like they fight each other. They don't, if you're careful about what you send.

Let me show you how they fit together, because I think this is the most useful idea in the whole topic.

Start with what makes an offline conversion valuable. It's the outcome: this click led to a person who booked, who turned up, who paid. That's a fact about behaviour, not about health. The ad platform doesn't need to know why the person came to learn that they came.

Now what a clean version looks like. Your CRM records the stages: the appointment was booked, the person showed up, the treatment was won, the invoice was paid. You send those stages back to the ad platform, and only these things go with them: the original ad click, a hashed email and phone, and the value where it's relevant.

What does not go: the treatment, the condition, the person's name, notes, or anything a clinician wrote down.

The ad platform learns "this click led to a person who showed up and paid". It learns nothing about why. That's a very different signal from a form fill, and a much more useful one. The campaign starts finding people who turn up and pay, not people who fill in forms.

A rule that keeps you safe: your CRM stays the place patient records live. Only the minimum needed to send a clean signal crosses over. If you're ever unsure whether a field should go, ask whether the ad platform needs it to match or to count. If it needs neither, leave it out.

A made-up example of how it plays out. 200 form fills. 100 booked. 70 showed. 40 paid. The ads used to see 200. Now they see 100, 70 and 40, each as a separate neutral event, matched to the click. You can optimise on "showed", watch "paid" as the profit check, and keep "booked" as the volume backstop. And in none of those events is there a treatment, a condition or a name.

Two practical points. Send each stage when it happens, because Meta rejects events sent more than 7 days after they happened. And mark cancelled and no-show in your CRM as their own statuses, but don't send them, because you don't want the campaign chasing people who don't come.

Here's an example mapping of CRM statuses to events, so you can adapt it to your clinic. It's a made-up mapping, and the structure is what matters.

CRM status "New enquiry" maps to a lead event.

CRM status "Consultation booked" maps to a booked event.

CRM status "Attended" maps to a showed event.

CRM status "Treatment accepted" maps to a won event, with the value.

CRM status "Invoice paid" maps to a paid event, with the value.

CRM statuses "Cancelled", "No-show" and "Lost" map to nothing that is sent. They're recorded in the CRM for your own use.

The rule for adding a status: does the ad platform learn something useful from it? If yes, map it. If it only matters for your operations, leave it out. A short list of well-chosen events beats a long list of every step.

Do you send later stages back today, or only the form fill?

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.