DSO Conversion Tracking: A Location Rollup

A dental support organization tracks conversions across locations by capturing every practice's events into one measurement layer, tagging each event with a location identifier, and rolling those events up to group level while keeping per-practice reporting intact. The hard parts are attribution across a shared website, deduplicating patients who contact more than one location, and doing all of it without sending patient information to ad platforms that have not signed a Business Associate Agreement. Curve is the HIPAA-compliant tracking, attribution, and analytics platform built for exactly this: multi-location healthcare groups that need group-level rollups and practice-level detail from one compliant pipeline, with a signed BAA on every plan.

Why DSO tracking breaks in ways single-practice tracking does not

A single practice has one website, one phone number, one ad account, and one set of conversions. A DSO has none of those cleanly, and the resulting problems are structural rather than technical mistakes.

One website, many practices

Most groups run a single domain with location pages beneath it. A patient lands on a group page, browses two locations, and books at the third. Which practice earned the conversion, and which campaign gets credit? Naive setups attribute to the landing page, which systematically over-credits whichever location ranks best organically.

Acquired practices bring their own stack

Groups grow by acquisition, and acquired practices arrive with legacy websites, their own Google Ads accounts, their own call tracking, and their own conversion definitions. Six months after a deal the group is running four different definitions of "new patient," none reconcilable.

Phone is the dominant conversion

Dental patients call. A meaningful share of high-value conversions, especially implants and emergency visits, never touch a web form. Any measurement approach built purely on form submissions will misread the channel mix badly.

The conversion happens later, and elsewhere

The valuable event is not the enquiry. It is the appointment attended, the treatment plan accepted, the case started. Those live in the practice management system, days or weeks after the click.

Patients contact more than one location

Someone shopping for implants calls three practices in the group. Counted naively, that is three new-patient conversions from one patient, and the group's reported cost per acquisition is a third of the truth.

The tracking model that holds up

Build around events tagged with location, not around separate per-practice tracking installs.

One measurement layer, one event schema. Every practice sends into the same pipeline using the same event definitions. A booked appointment means the same thing at every location. Without this, rollups are arithmetic on incompatible numbers.

Location as an attribute, not a separate system. Each event carries a location identifier as a property. This is what makes both views possible from one dataset: filter by location for practice reporting, aggregate across for group reporting. Running separate installs per practice makes group rollup a manual reconciliation exercise forever.

Neutral conversion names. Events reaching ad platforms should not encode the procedure. A conversion named for a specific treatment discloses the patient's clinical interest to a platform with no BAA. Keep descriptive names in your own reporting and send neutral aliases outward.

Click IDs captured at landing, everywhere. The gclid, fbclid, and msclkid must be captured on arrival and carried through. Attribution cannot be reconstructed later if the click ID was never stored, and this is the single most common reason DSO attribution is unrecoverable.

Outcomes flow back from the practice management system. Attended appointments and started treatment come back through a server-side path, matched to the original session. Without this you optimize toward enquiry volume, which in dental means optimizing toward price shoppers.

Handling the multi-location attribution problem

Decide the rule deliberately, because the default will be wrong.

The usual mistake is crediting the landing page. On a group site the landing page is often a general service page or the homepage, so credit collects there while the practice that actually delivered the appointment shows nothing.

A better rule credits the location where the conversion completed, while preserving the full path for analysis. The booking at the Riverside practice is a Riverside conversion, even if the patient arrived on a group-level implants page. The group page still gets credit as an assist in path analysis, but the location attribution follows the outcome.

For cross-location duplicates, deduplicate on a hashed contact identifier inside your own systems, before anything is reported and well before anything reaches an ad platform. One patient contacting three practices should count as one group-level acquisition and three location-level enquiries. Both numbers are true; they answer different questions.

Phone calls need the same rigor

Call tracking is where DSO measurement usually leaks, in two directions at once.

Attribution leaks because the call happens off-site. Dynamic number insertion ties a call back to a session, but only if the call tracking platform passes the session context back into your measurement layer and the click ID survived the round trip.

Compliance leaks because call tracking platforms record and transcribe. A transcript of a patient describing symptoms is unambiguously PHI. If that platform's vendor has not signed a BAA, the recording itself is a problem, entirely separate from the ad tracking question. And if transcripts or call outcomes flow into an ad platform as conversion metadata, the disclosure compounds.

The rule is the same as everywhere else: recordings and transcripts stay in BAA-covered systems, and only a neutral conversion signal continues outward.

How Curve does the rollup

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and multi-location groups are a core use case.

The Curve script installs once on the group domain in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than directly to ad platforms, which is what makes location tagging and payload control possible.

• One install, location-tagged events. Practice-level and group-level reporting come from the same dataset rather than from reconciled spreadsheets.
• Per-destination field mapping. Only explicitly mapped fields forward to each platform. Procedure names, page URLs, and form content stay behind by default.
• Neutral event aliases. Your team sees descriptive names internally; ad platforms see neutral ones.
• Hashed identifiers. Contact fields are SHA-256 hashed to each platform's conversion API requirements before forwarding.
• Bridge tokens. Attribution survives the handoff when a patient leaves the group site for a separate booking or intake tool, which is where most dental funnels lose the chain.
• Incoming webhooks with attribution matching. Practice management and call tracking systems post outcomes back, matched on email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields, so one misconfigured practice cannot corrupt group reporting.
• Offline conversion uploads. Bulk upload of started treatment and attended appointments with automatic click ID matching, so ad platforms optimize toward real cases.
• PHI-pattern detection. Payloads are flagged when they contain PHI-shaped values, which is how you catch an acquired practice's legacy form quietly sending something it should not.

Curve forwards clean conversions server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok, Microsoft, and LinkedIn, with a signed BAA on every plan. Related reading: dental group attribution across multiple practices and the DSO marketing technology stack.

Using the rollup to allocate budget

Once location-tagged events are flowing, the reporting question changes from what happened to where the next dollar should go, and group-level averages actively mislead here.

Cost per new patient varies enormously between practices in the same group, driven by local competition, the practice's organic footprint, its case mix, and how quickly the front desk answers the phone. A group average conceals all of it. One practice at twice the group's cost per new patient and another at half will average out to something that describes neither and justifies no decision.

Read three numbers per location instead. Cost per attended appointment, not per enquiry, since enquiry cost is where front-desk performance hides. Case acceptance rate, because a location converting enquiries into started treatment at a much higher rate deserves more budget even at a higher enquiry cost. And capacity, because spending into a practice with no chair time available converts a marketing win into a scheduling complaint.

That third number is the one groups most often ignore. Location-level tracking makes it visible: when a practice's cost per attended appointment climbs while its enquiry volume holds steady, the constraint is usually capacity or follow-up speed rather than media.

An onboarding order for a newly acquired practice

1. Inventory the legacy stack before switching anything off. Existing ad accounts, call tracking, forms, and any pixels on the old site.
2. Map legacy conversions to the group schema. Decide what the practice's "new patient" maps to.
3. Install the group tracking layer with the practice's location identifier.
4. Remove legacy client-side pixels. They are the compliance exposure and they will double count.
5. Wire the practice management outcome webhook.
6. Verify the outbound payload for a real test conversion. Inspect what left, not what you configured.
7. Run parallel for one cycle before retiring legacy reporting, so you can explain any variance.

Frequently asked questions

Should each practice have its own ad account?

Usually yes for budget control and local optimization, but they should all report into one measurement layer. Separate ad accounts with separate measurement is what produces irreconcilable group numbers.

How do we count a patient who contacts three locations?

As one group-level acquisition and three location-level enquiries. Deduplicate on a hashed contact identifier inside your own systems before reporting, and never resolve this by sending contact details to an ad platform.

Can we send procedure type to Google or Meta?

No. Procedure type attached to an identifiable person is health information, and neither platform signs a BAA for its advertising products. Use neutral conversion names and keep procedure detail in your own reporting.

Our practices use different practice management systems. Does that break this?

No. Each system posts outcomes through its own webhook into the same measurement layer, mapped to the shared event schema. Heterogeneous back ends are normal in a group that grew by acquisition.

What about Google Business Profile calls and direction requests?

Worth reporting on, but treat them as a separate local-presence channel rather than folding them into paid attribution. Mixing them inflates paid performance.

How long before an acquired practice's data is trustworthy?

Plan on a full reporting cycle running in parallel. The variance you find in that period is almost always a legacy conversion definition rather than a tracking fault, and it is worth understanding before you switch the old system off.

Where to start

Group-level conversion tracking is a schema problem before it is a tools problem. One event definition, location as an attribute, click IDs captured at landing, outcomes returned from the practice management system, and neutral names going outward.

Curve provides that pipeline for multi-location healthcare groups: one install, location-tagged events, per-destination field mapping, bridge-token attribution, webhook and offline outcome matching, and a signed BAA on every plan. Run our free compliance scanner against a group site or a recently acquired practice, or visit curvecompliance.com to map out a rollup.

Reviewed August 2026. Ad platform conversion APIs and healthcare advertising policies change frequently. Verify current requirements before implementation.