What the algorithm learns, and what it cannot
Meta's ad system is a prediction machine. It looks at the conversion data you feed it, decides "people who do this look like that", and goes hunting for that profile. Whatever you feed it is what it looks for.
In medical tourism, most companies feed it exactly one fact: a conversation started. Someone saw the ad and wrote on WhatsApp, sent a DM, or filled a form. The algorithm learns that well — it finds you people who will send messages.
But the person who sends a message and the person who has surgery are not the same profile. Of a hundred enquiries, forty ask a price and vanish, fifteen book, five travel. Until Meta learns about those five, it keeps chasing the forty. Cost per message falls, cost per patient does not, and the dashboard looks healthy while the bank balance does not move.
What the Conversions API actually is
The Conversions API reports conversions server-to-server instead of from the visitor's browser. The classic pixel runs in the browser, and cookie restrictions, tracking blockers and mobile permission prompts have narrowed that path considerably over the years.
CAPI sits outside those limits because your system sends the event, not the browser. For medical tourism, though, the deeper point is different: where the sale happens there is no browser at all. The close is negotiated on WhatsApp, the deposit arrives by bank transfer, the decision is made on a call. Only the CRM knows that event, so only the CRM can report it.
That is what sits behind Meta's insistence on getting your data back. It is asking you for the outcome it cannot see.
The healthcare-specific problem: conversion happens three weeks later
In e-commerce a conversion takes ten minutes: add to cart, pay, event sent. A treatment decision takes weeks, and no step in the chain happens on your website.
Three practical consequences:
- One conversion event is not enough. Sending only "sale" means a handful of events a week — far too little for the algorithm to learn from. Sending intermediate steps (interested, appointment) increases signal volume.
- Delay is fine. An event sent three weeks later still carries value; Meta ties it back to the ad the person first touched. Just set your attribution window deliberately.
- A human marks it. Software cannot tell on its own that a sale closed. That makes the CRM status change the only reliable source of a conversion.
Which events to send, and when
Three events are enough in practice, each mapped to one of your patient statuses:
- Contact — a real conversation started. High volume, low quality.
- Lead — qualified: details taken, suitable for treatment, price under discussion.
- Purchase — the sale closed. Most valuable signal, lowest volume.
The critical rule: do not send negative statuses. "Unreachable", "changed their mind", "not suitable" belong in the CRM. You report the behaviour you want more of; there is no such thing as reporting the behaviour you do not want — send it and you teach the algorithm the wrong audience.
In MetoCRM the mapping is per status, and any status can be set to send nothing, so negative outcomes stay in your reports and never leak into the ad account.
Value signal: flat amount or the real quote?
A Purchase event carries a value, and Meta's ROAS maths depends on it. Two approaches:
A flat average. Every sale reported with the same value. If your treatment prices cluster — say you only do hair transplants — this is enough and simple to set up.
The real quote total. The patient's quote in the CRM is used, with its own currency. For a mixed-treatment company the difference is large: reporting a €2,000 procedure and a €12,000 operation with equal weight teaches the algorithm to chase cheap procedures.
If you choose the second, decide one rule up front: what happens when no quote is found? Silently sending zero is the worst option. The right behaviour is to fall back to the average and record that it did — so that three months later "where did this number come from" has an answer.
Three signs of a badly built CAPI setup
- Double counting. Both the browser pixel and the server send the same event, and nothing deduplicates them, so your conversion count inflates. Every event needs a unique id, and the same id must never send twice.
- Everything is a Purchase. Skipping the intermediate steps means a few events a week. That is usually below what the learning phase needs, and the campaign stays unstable.
- Events with no identifier. An event carrying no phone, email or ad click id cannot be attached to anyone on Meta's side. It leaves, it appears to count, it teaches nothing. A well-built system tells you this before you rely on it.
GDPR and KVKK: what is actually sent
Meta needs an identifier to match a person — which does not mean uploading your patient list to an ad platform. The correct implementation hashes email and phone with SHA-256 before sending. What arrives is an irreversible digest.
A technical safeguard is still not a legal basis. State in your privacy notice that you process personal data for ad measurement, and stay consistent with your consent management. Health data is a special category: make sure what leaves is the event name and the hashed identifier needed for matching — not the treatment. Our patient data security guide covers the wider frame.