Med Spa Attribution: Walk-Ins and Online Bookings

A med spa closes the loop between an ad click and in-clinic revenue by capturing the click ID the moment someone lands, carrying it through every handoff (booking tool, phone call, front desk), and sending the eventual outcome back to the ad platform as a neutral, hashed conversion. Curve is the HIPAA-compliant attribution layer built for that path, with bridge tokens for external booking tools, webhook and offline matching for outcomes that happen in the clinic, and a signed BAA on every plan. The reason most med spa reporting undercounts is that the click ID was never stored.

Why med spa attribution is harder than ecommerce attribution

Aesthetics practices have an unusual funnel shape. The ad is digital, the money is physical, and there are typically two or three system boundaries in between. Each boundary is a place where the connection between click and revenue can break.

A meaningful share of med spa revenue never touches a web conversion at all. Someone sees an ad on Tuesday, checks the clinic's Instagram, asks a friend, walks past the clinic on Saturday and comes in. Or they call, because aesthetics buyers ask questions before booking. Or they book through a third-party tool that lives on a different domain and knows nothing about the ad that produced the visitor.

The consequence is systematic, not random. Whatever channel drives phone calls and walk-ins gets underreported, whatever drives online form fills gets overreported, and budget follows the reported numbers. Practices routinely cut the campaign that is actually working because it produces calls instead of forms.

The four paths from ad click to revenue

Booking on your own site

The easy case, and the rarest one. Someone clicks, lands, books through a form or scheduler hosted on your domain, and the conversion fires in the same session. Even here, the useful event is not the booking. It is the attended appointment and the treatment purchased, both of which happen later.

Booking through an external tool

The common case. Your site links out to IntakeQ, Calendly, Jane App, or a practice management scheduler on a different domain. The visitor leaves your site, and unless attribution is deliberately carried across that boundary, the booking arrives with no idea which ad produced it. Browser privacy controls have made this worse, not better, since cross-domain cookie recovery is no longer dependable.

Phone

Aesthetics prospects call. Price questions, candidacy questions, downtime questions. Dynamic number insertion can tie a call to a session, but only if the session knew its click ID and the call platform passes context back into your measurement layer.

Walk-in

The hardest case, and the one everyone assumes is unrecoverable. It usually is not entirely, because most walk-ins are not truly cold. They visited the site first, often more than once. What is missing is a link between that visit and the person now standing at the desk, and there is exactly one honest way to create it: ask.

Capture the click ID or none of this works

Every technique below depends on one thing that has to happen at the very start. When someone arrives from an ad, the URL carries a click identifier: gclid from Google, fbclid from Meta, msclkid from Microsoft. That value has to be captured on arrival and stored somewhere durable, ideally on the eventual patient or lead record.

Click IDs cannot be reconstructed after the fact. If a booking arrives in your CRM three days later with no click ID attached, no upload, integration, or clever report will recover which ad produced it. This is the single most common reason med spa attribution stops at the enquiry, and it is invisible until you go looking for the value and find an empty column.

Store it alongside UTM parameters and the landing page, and carry it through every subsequent handoff. Practical rule: any system that can hold a lead record should be able to hold a click ID, and if it cannot, that system is a break in the chain you need to design around.

Carrying attribution across the booking-tool boundary

When a prospect clicks out to a scheduler on another domain, you need to hand something across with them. A bridge token does this: a short-lived identifier appended to the outbound link and persisted on your side, so that when the booking tool later reports the appointment, the token connects it back to the original session and its click ID.

The failure mode worth naming is the half-implementation. Appending a token to the URL is not enough on its own. The token also has to be persisted server-side at the moment of the handoff, and the booking tool's outcome has to arrive carrying it. Practices that tag the link but skip the persistence step get a clean-looking setup that quietly attributes nothing.

Once the token is in place, the booking tool's webhook (or your CRM's) posts the appointment back and it matches. Related reading: routing leads from ad click to CRM without PHI.

Phone calls carry an attribution problem and a compliance problem

Call tracking leaks in two directions at once, and most practices are only watching one of them.

Attribution leaks because the call happens off-site. Dynamic number insertion swaps the displayed number based on the visitor's session, which works, but only if the session context (including the click ID) is passed back when the call completes. Many setups report call volume by source without ever connecting a call to a specific ad click, which is enough for a rough channel read and not enough to optimize.

Compliance leaks because call platforms record and transcribe. A prospect describing a skin condition or asking about a treatment for a specific concern is producing health information. A transcript of that call is unambiguously sensitive, and if the call platform's vendor has not signed a BAA, the recording itself is a problem independent of any ad tracking question. If call outcomes or transcript keywords then flow into an ad platform as conversion metadata, the disclosure compounds.

The rule is the same as everywhere else in this stack. Recordings and transcripts stay in BAA-covered systems. Only a neutral conversion signal continues outward.

Walk-ins: what you can actually recover

You cannot deterministically attribute a walk-in. Nobody can. What you can do is convert a portion of them from unknown into probable, and be honest about the rest.

Ask at intake, and make it one question. "How did you hear about us?" with a short fixed list beats an open text field, because free text produces "Google" a hundred different ways and nobody codes it. Keep the options to five or six and include "saw an ad."

Match on contact details you already have. If a walk-in's email or phone number matches a lead record created three weeks ago from a paid click, that is the same person and the click ID is sitting on that record. This recovers more walk-ins than practices expect, because most people who walk in have interacted with you online first. The matching happens inside your own systems, never by sending contact details to an ad platform.

Use offer codes for specific campaigns. A campaign-specific code mentioned at the desk is a deterministic link when it is used. Low coverage, high confidence, useful for validating a channel rather than measuring it.

Report the unattributed bucket rather than distributing it. The temptation is to allocate unknown walk-ins proportionally across known channels. Resist it. That method assumes walk-in behavior mirrors online behavior, which is exactly the assumption that is most likely to be wrong. Show the bucket, watch whether it grows or shrinks when you change spend, and treat that movement as evidence.

Sending in-clinic outcomes back to the platforms

Once outcomes are connected to click IDs inside your systems, the last step is returning them to the ad platforms so optimization has something real to work with.

Two routes cover almost every case. A webhook from your CRM or practice management system posts outcomes as they happen, matched by email, click ID, or bridge token. Or a periodic offline conversion upload sends a batch of outcomes with click-ID matching, which is the practical route for anything that closes in the clinic.

What travels is a neutral event name, a value, and hashed identifiers. What does not travel is the treatment, the service line, the intake answers, or the page path that names the procedure. That distinction is what keeps this workable, since neither Meta nor Google signs a BAA for its advertising products and the healthcare pixel litigation that has cumulatively crossed $100M in settlements ran on exactly this kind of leakage. For the platform-side mechanics, see server-side Enhanced Conversions without PHI leakage.

How Curve closes the loop

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and this multi-boundary funnel is the case it was designed around.

The Curve script installs on your site 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 the handoffs and the payload controls possible in the same system.

• Click ID capture at landing. gclid, fbclid, msclkid, and UTM parameters are captured on arrival and held against the session, including same-site referrer recovery.
• Bridge tokens. Attribution is preserved when a visitor clicks out to IntakeQ, Calendly, Jane App, or another external scheduler, with the token persisted server-side rather than just appended to a link.
• Incoming webhooks. Your CRM, practice management system, or call platform posts outcomes back and Curve matches them by email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields, so a misconfigured integration cannot corrupt attribution you already have.
• Offline conversion uploads. Bulk upload of attended appointments, treatments purchased, and walk-in revenue with automatic click-ID matching (up to 10,000 rows and 5MB per upload).
• Neutral event aliases. Your reporting keeps descriptive names. Ad platforms receive neutral ones, so the conversion never discloses the service line.
• Per-destination field mapping. Only explicitly mapped fields forward to a given destination, and the default is that nothing goes.
• SHA-256 identifier hashing per each platform's conversion API requirements, applied before anything leaves.
• CallRail as an inbound connector, so call attribution feeds the same measurement layer as everything else instead of living in its own silo.

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: Facebook Lead Ads for med spa consultation requests.

The numbers to actually report

Once the loop is closed, change what you look at. Cost per enquiry is a front-desk metric disguised as a marketing metric, because the gap between enquiry and attended appointment is mostly about how fast someone answers the phone.

Report cost per attended appointment, revenue per attended appointment, and the share of revenue you can attribute at all. That third number is the health check on the tracking itself. When it climbs, your loop is closing. When it drops after a website change, something in the chain broke and you want to know that in a week rather than a quarter.

Frequently asked questions

Can we send patient names or emails to Google or Meta to match walk-ins?

Not in raw form, and not the association between a person and a treatment in any form. Conversion APIs accept hashed identifiers for matching, which is different from uploading a patient list, and the event they attach to must stay neutral. Neither platform signs a BAA for its advertising products, so the treatment context can never travel.

How much of our revenue should we expect to attribute?

There is no correct number, and anyone quoting one is guessing about your funnel. What matters is the direction of your own attributed share over time. Set a baseline before you change anything, then watch it move.

Does "how did you hear about us" data actually help?

Yes, as a cross-check rather than a measurement. Self-reported attribution is biased toward the last thing someone remembers, which is usually search or a friend. Its real value is catching cases where a channel is clearly producing patients that your click-based reporting shows as zero.

Our booking tool is on a different domain. Is attribution simply lost?

No, but it has to be handed across deliberately with a bridge token, and the token has to be persisted at the moment of the handoff rather than only appended to the link. Half-implementations are common and look fine until you check whether anything is matching.

Should we track appointments or treatments as the conversion?

Both, as separate events with different values. Attended appointment is the volume signal and arrives quickly enough to optimize on. Treatment purchased is the money signal and matters for judging channels. Sending only the first optimizes toward consultations that do not convert.

Do we need call recording to attribute calls?

No. Attribution needs the session context and the call outcome. The recording is a separate product decision with its own compliance obligations, and the safest position is that recordings and transcripts never leave BAA-covered systems.

Where to start

Start by checking whether click IDs are being stored on lead records at all. Open ten recent leads and look. If the field is empty, that is the entire problem and nothing downstream will work until it is fixed. Then handle the booking-tool boundary with a properly persisted bridge token, wire the outcome webhook, and add offline uploads for whatever closes in the clinic.

Curve provides that chain end to end: click ID capture at landing, bridge tokens across external schedulers, webhook and offline outcome matching, neutral event aliases, per-destination field mapping, hashed identifiers, and a signed BAA on every plan. Run the free compliance scanner against your booking pages to see what is firing there today, or visit curvecompliance.com to map the path from ad click to in-clinic revenue.

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