The way out isn't less measurement. It's an architecture where the stitching happens inside a BAA-covered platform and only stripped, minimal signals leave it. Here's that architecture, channel by channel, and how it resolves to the location level.

The core model: stitch inside, export events only

Every compliant attribution design reduces to one rule: patient data and campaign data may meet only inside a system covered by a BAA. Concretely:

1. Capture campaign context first-party. One tracker script on every site in the group. It records an allowlisted set of parameters — UTMs and ad-platform click IDs, nothing free-form — plus a hidden visitor ID. It never captures what a patient types.
2. Stitch to identity inside the platform. When the visitor calls, submits a form, or books, the visitor ID connects that person to the click that brought them — inside the CRM, under the BAA, where knowing both "this is Jane" and "she came from the implants campaign" is legal.
3. Export only conversion events. Ad platforms receive offline conversion uploads: this click ID converted, at this time, with this value. Never names, conditions, phone numbers, or form contents. If something is uploaded in error, retraction jobs pull it back.
4. Analytics get a scrubbed feed. The design here is a HIPAA-safe GA4 forwarding layer — synthetic client IDs (Google never gets a durable device identifier), a PII-scrubbing pass, and whitelisted parameters only — which we're building into the platform. Leadership keeps GA4; Google doesn't get patients. (Deep dive: Is Google Analytics HIPAA Compliant?.)

Everything below is this model applied to three channels and N locations.

Calls: dynamic number insertion, done as a system

Calls are most healthcare groups' biggest conversion path and their most commonly non-compliant tracking surface — mainstream call-tracking defaults record calls and store transcripts on infrastructure with no BAA (comparison: HIPAA-Compliant Call Tracking Compared).

The compliant mechanics we run:

• Pool-based DNI. Each location gets a pool of tracking numbers. When a visitor arrives, the site swaps the displayed number to one from the pool tied to that visitor's session — so the inbound call joins the same stitched journey as a form fill would.
• Gated by paid-click recency. Pool numbers are finite; burning them on every organic visitor destroys accuracy. Swaps fire for visitors with a recent paid click — the ones whose attribution actually informs spend — and everyone else sees the location's stable local number, which also protects NAP consistency for local SEO.
• Automated swap verification. DNI fails silently: a theme update or caching layer stops the swap and your call attribution quietly goes dark while reports keep rendering. We verify swaps with automated headless browser checks against the live site — the swap either provably happens or it's an alert.
• Call data handled as PHI. Recordings, transcripts, and caller identity live encrypted and audit-logged in the platform, not in a third-party call vendor's dashboard.

Forms: the click-to-inquiry stitch

Forms are the simplest channel if the pipeline is right: submissions go server-to-server into the CRM (never resting in the website database), and the hidden visitor ID rides along with the submission. That single field is the entire stitch — inquiry joins click, campaign, landing page, and location, with the ad platform none the wiser. Free-text form contents never enter the tracking layer at all.

Bookings: attribution to revenue, not to thank-you pages

Here's where healthcare attribution usually stops short: it counts "leads," and a lead is not a patient. Because our booking widget writes into the practice's EHR/PMS (30+ integrations) and emits micro-events at every step — opened, location chosen, slot chosen, details entered, booked — attribution reaches the event that actually correlates with revenue: a scheduled appointment in the practice system, at a specific location.

That closes the loop the strategy decks hand-wave: the offline conversion sent back to Google or Meta can be booked appointment, not form fill, which trains the ad platforms' bidding on the thing you actually want more of — while they still never see who booked.

Making it cross-location: the resolution problem

Multi-location groups add one genuinely hard question: which location gets credit? The answer must be rule-based, in this priority order:

1. Booking wins. If the journey ends in a booked appointment, the location is the one on the appointment. Ground truth.
2. Then the tracked number. A call to Location B's DNI pool attributes to Location B, whatever page it came from.
3. Then explicit page/form context. A form on the Riverside location page, or a location selection in the widget, attributes to Riverside.
4. Last, campaign geography. Only when nothing stronger exists — geo-targeting is a hint, not a fact (people work in one suburb and book near home).

Codify this once, apply it everywhere. Groups that let each report pick its own rule get location P&Ls that disagree with each other, and the marketing meeting becomes an argument about definitions instead of budgets.

The report this produces

(Illustrative numbers.) The decision it enables is the whole point: Riverside's search spend is producing bookings at twice Northside's cost — is that slot supply, listing drift, or landing-page rot? Because the widget's micro-events and the GBP monitoring layer are part of the same system, that's an afternoon's diagnosis, not a quarter's debate.

Compared to the default stack

The attribution-stack checklist

Before trusting any cross-location report, verify:

1. One first-party tracker on every property; zero third-party pixels on patient-facing paths.
2. UTM/click-ID allowlist enforced; visitor-ID stitch confirmed on a test journey.
3. Forms server-to-server with visitor ID attached.
4. DNI pools per location, recency-gated, with automated swap verification passing.
5. Booking events flowing from the widget to the EHR and into reporting.
6. Offline conversion uploads live to each ad platform; retraction path tested.
7. GA4 receiving only the scrubbed, synthetic-ID feed.
8. Location-resolution rules written down and applied identically in every report.

Actually doing the marketing

Attribution is only worth building because of what it lets you do: shift budget monthly to the location-channel cells with the lowest cost per booked appointment, feed booked-appointment conversions back to the platforms so bidding optimizes for patients rather than form spam — the discipline we unpack in what closed-loop PPC actually means — and fix operational leaks (slot supply, listing drift) that masquerade as media problems. That operating rhythm is the Multi-Location Practice Marketing playbook, and compliant retargeting on top of this stack is covered in Healthcare Retargeting Under HIPAA — all on the foundation of the HIPAA-Compliant Marketing guide.

Or run it on the platform where this is the default: PilotPractice ships the tracker, the DNI system with verified swaps, server-to-server forms, EHR-integrated booking, and the per-location reporting (with the scrubbed GA4 feed in active development) — under one BAA, operated by the team that also runs your campaigns. Book a demo and we'll trace a real click-to-booked-appointment journey across your locations, live.