Know which ad produced which paying patient.
Browser pixels miss a large share of clinic conversions. Bookings happen inside embedded calendar widgets the pixel cannot see, most ad traffic arrives in in-app browsers that block trackers, and the payment usually happens on a telehealth platform on a different domain entirely. We wire the whole chain server-side so Meta optimizes on real outcomes and you can prove your cost per patient.
Where clinic tracking breaks, and how we fix it
Almost every clinic we audit is missing at least one leg of the chain. The pattern is consistent: leads are tracked, bookings are partially tracked, and payment is not tracked at all, which means the most important number in the business is an estimate.
Pixel and Conversions API together
Browser and server events fire in parallel with deterministic event IDs so Meta deduplicates them correctly. You get the coverage of server-side tracking without double-counting.
Booking events from the CRM
Calendar bookings inside an embedded widget are invisible to the site pixel. We fire the booking event server-side from the CRM workflow instead, which is the only reliable way to capture it.
Provider webhooks for the purchase
Patient checkouts happen on your telehealth provider's domain, not yours. We build a receiver for their webhooks so the purchase event, with real cash value, reaches Meta and your CRM.
Monitoring, because receivers fail silently
A broken integration returns a success response and quietly stops sending. We run a daily health check across the receivers and alert on failure, so a dead tracking leg is caught in a day rather than a quarter.
What full-chain tracking gives you
attribution across the whole patient journey
events that in-app browsers cannot block
automated health checks on every integration
How far the chain can reach depends on your telehealth provider. Some platforms expose full purchase and abandoned-session webhooks, others expose none, and no amount of engineering on our side creates an event the provider does not send.
The guarantee
Tracking is built as part of the ScaleClinics system, and it is what makes the booked-patient guarantee measurable by both sides. We settle the counting method before ads launch, not after, because a guarantee neither party can count is worth nothing to either of us.
“The receivers return 200 even when they are broken, so failures are invisible by default. That is why we monitor them daily. A tracking integration nobody is watching is a tracking integration that stopped working some time ago.”
Built for clinics that cannot answer what a patient costs
If your reporting stops at leads, your cost per patient is a guess, and so is every decision built on it. Worse, Meta is optimizing toward the event you gave it. Feed it landing page views and it will find you people who view landing pages.
This is most acute for telehealth clinics, where the patient pays on a provider platform you do not control. Getting that purchase event back requires an integration the provider has to cooperate with, and the time to start that conversation is day zero of onboarding, not week ten when the guarantee is being counted.
Patient conversion tracking, answered
What is the Meta Conversions API and why do clinics need it?
The Conversions API sends conversion events to Meta from a server rather than from the visitor's browser. Clinics need it because browser pixels miss a large share of real conversions: in-app browsers and tracking protection block them, bookings inside embedded calendar widgets never reach the page pixel, and payments often happen on a different domain entirely. Without server-side events, Meta optimizes on incomplete data and your reported cost per patient is wrong in a direction you cannot measure.
Why do bookings made in an embedded calendar not show up in tracking?
Because the booking happens inside an iframe served from the calendar provider's domain, the page's own pixel cannot observe it. The reliable fix is to fire the booking event server-side from a CRM workflow that triggers when the appointment is created. This applies to essentially every clinic using an embedded booking widget, and it is one of the most common gaps we find during an audit.
Can you track a purchase that happens on my telehealth provider's platform?
Usually yes, if the provider sends webhooks. We build a receiver that accepts their events, verifies them, and relays a purchase event to Meta with the real cash value while also updating the patient record in your CRM. The constraint is entirely on the provider side. Some platforms expose new patient, purchase, and abandoned session events; others expose very little and have no test mode, which changes what we can promise. We establish this before designing the guarantee counter.
How do you avoid double-counting when both pixel and server fire?
Deterministic event IDs. Both the browser and the server send the same event with the same identifier, and Meta deduplicates on the combination of event ID and event name within its matching window. Getting this wrong inflates your reported conversions and corrupts optimization, so we verify deduplication in Events Manager rather than assuming it worked.
How would I know if my tracking has stopped working?
Without monitoring, you generally would not, and that is the real problem. Webhook receivers typically return a success response to the sender regardless of whether downstream processing succeeded, so a broken integration looks healthy from the outside while quietly sending nothing. We run an automated daily check across every integration and alert on failure. Before we built that, the honest answer was that failures were invisible.
Stop chasing leads.
Start booking patients.
15-minute strategy call. We'll look at how you're getting patients now, tell you what we'd change, and give you a guaranteed patient number for your clinic.
Book your strategy call