First-party attribution that connects each ad click to the appointment booked in the practice system and the treatment that follows, then feeds that real value back to Google and Meta.
The group acquires patients through Google paid search and Meta, but the value shows up later: a first appointment booked in the practice management system, then the treatment. The ad platforms only ever saw a form submission, so the group was optimizing its budget toward cheap leads instead of toward patients who actually book and get treated.
01 The Challenge
Paid search and Meta produced form-fills and calls, but a form is not a booked appointment, and a booked appointment is not yet treatment revenue. Last-click and platform attribution stop at the lead: they cannot connect the ad to the first appointment recorded in the practice system, let alone to the treatment that followed. So the group was flying on cost-per-lead, which looked fine, while cost-per-treated-patient (the number that actually matters) was invisible. Budget flowed to cheap leads that no-showed and away from the keywords that brought in real treatment cases.
A form is not a patient. A booked, treated patient is.
02 The Approach
The governing rule: connect ad spend to the patient journey, to the first appointment in the practice system, and to the treatment revenue, then attribute it with data-driven models and feed the real value back so Google and Meta optimize toward patients who book and get treated.
This is healthcare-adjacent, so the privacy boundary was a first-class design decision: only the conversion event and its value, with hashed identifiers, go to the ad platforms. No treatment details, no clinical information, nothing that could be considered patient health data, ever leaves to Google or Meta. Identity is resolved deterministically and first-party, stitched at the point of booking.
What we deliberately did not do: no patient health data sent to ad platforms, no probabilistic device fingerprinting, and (importantly) no over-building. A practice group's traffic does not justify the high-throughput event-streaming stack a large e-commerce brand needs, so we did not use one.
03 The Build
A lightweight TypeScript snippet emits first-party, consent-aware events from the practice site to its own domain. A Python collector validates and stores them in PostgreSQL. Identity is stitched at booking: a hashed email or phone links the visitor to the patient, their first appointment, and the resulting treatment, pulled from the practice management system, Dentally, via its API. Python builds the journeys and runs the attribution models (Markov, Shapley, blended, against a last-click baseline). The modeled value, booked appointment and treatment revenue, is pushed back to Google Ads (offline conversion import) and Meta (Conversions API), with Temporal guaranteeing each conversion is uploaded exactly once. A dashboard shows the practice true channel and keyword performance by treatment value.
Deliberately right-sized: no Rust collector, Kafka, or ClickHouse. A practice group's volume doesn't call for them.
04 The Results
The group can now see which campaigns and keywords bring in patients who book and get treated, not just who fills in a form. Budget moved toward the spend that produces treatment revenue and away from cheap, no-show leads, bringing cost per acquired patient down around 30%. Feeding the booked-appointment and treatment value back to Google and Meta daily let their algorithms optimize toward real patients, and the practice plans against true channel performance instead of platform-reported leads.
05 What's Next
The first-party journey-to-treatment data is the foundation for more than acquisition: patient reactivation and recall, and a clean rollout across additional locations from one tuned baseline. The hard part, connecting ad spend to actual treatment revenue while keeping patient data out of the ad platforms, is built once and reused per practice.
First-party, server-side tracking and data-driven attribution that reveal which channels truly drive new revenue, then feed that value back to Google and Meta so the algorithms optimize on reality, not last click.
A real-time layer over the existing order flow that scores every purchase order for on-time-in-full risk and alerts the team to intervene before the delivery window closes and the fine triggers.
Numbers you can trust, operations that run themselves, all built into your stack and owned by you. Tell us where you want the edge, and we'll build it.
You'll hear from an engineer the same working day, not a sales sequence.
A short call, then a plan, and we start with Proof Week or a full build.
A fixed fee agreed before anything starts, for Proof Week or the full build.