Virtual Care Intake: Where Tracking Belongs

Ad tracking belongs on the marketing pages of a virtual care funnel and on the fact that intake started or completed, and it stops at the first question that asks about symptoms, conditions, or medications, and Curve is the HIPAA-compliant tracking layer that carries attribution across that boundary without carrying answers across it. The hard part is that the boundary is not a domain change or a login wall. It is the moment your form starts collecting clinical content, which is often step two of a five step flow. Curve includes a signed BAA on every plan.

Where the boundary actually falls

Teams look for a structural marker: the login page, the domain change, the point where the patient becomes a patient. None of those is the real line.

The line is the first clinical question. A multi-step intake that asks for state, then email, then "what brings you in today," has crossed at step three, on the same domain, before any account exists, while the person is still an anonymous visitor by every marketing definition.

And the crossing does not require an answer to be transmitted. A page URL of /intake/weight-loss/eligibility sent to an ad platform as a page view has already disclosed what this person is being assessed for. So has a step name in an event payload. So has a form field label captured by an automatic event tracker.

This is why "we do not send the answers" is rarely a complete defense. The path, the step, the field names, and the timing all carry meaning, and client-side pixels collect them enthusiastically by default.

Three zones, not two

It helps to think in three zones rather than a before and after.

The marketing zone. Homepage, service pages, pricing, comparison content, blog. Standard tracking is appropriate here with the caveat that URLs and page titles should not themselves be diagnostic, and on a condition-specific landing page they often are.

The threshold zone. The start of intake, up to and including contact details and eligibility gates like state of residence. This is trackable, because the events here are about progression rather than clinical content. It is also where most of your conversion signal lives.

The clinical zone. Every screen from the first symptom, condition, medication, or history question onward, plus the account area, plus anything a clinician touches. No ad tracking here at all. Not a pixel, not a tag manager container, not a session recorder configured casually, not a chat widget.

What you can measure in each zone

The reason this split is workable rather than crippling is that the useful optimization signal lives almost entirely in the first two zones.

In the marketing zone you get traffic, engagement, landing page performance, and the click ID capture that everything downstream depends on. In the threshold zone you get intake started, contact captured, eligibility passed, and intake submitted, which is your primary conversion.

From the clinical zone you can still get outcomes, but they come back a different way: a server-side signal that says a milestone happened, with no detail about what the milestone contained. Consultation completed. Prescription issued. Subscription started. Those travel as neutral events with hashed identifiers, delivered from your systems rather than from the patient's browser.

That last distinction is the crux. The browser inside the clinical zone should never be the thing reporting to an ad platform, because the browser has access to the page and cannot be trusted not to describe it.

The failure modes that keep recurring

Tag manager loaded site-wide. The single most common one. A container placed in a global template runs on the intake flow and the patient portal too, and any tag added to it later inherits that reach. Nobody re-audits placement when a new tag is added.

Automatic event capture. Enhanced measurement and auto-event features capture form field names, button text, and URLs without anyone configuring them. On a clinical form that is exactly the wrong feature.

Session recording without scoping. A replay tool records the intake screen, including the answers. That is a full PHI capture, stored by a vendor, replayable by anyone with dashboard access. Session recording in healthcare needs to be built for it and scoped away from clinical screens.

Chat widgets. A support chat on the intake page collects free text where patients describe symptoms, and most chat vendors do not sign BAAs. The transcript then syncs to a CRM.

Query strings that carry answers. Multi-step forms that pass selections in the URL leak them into every analytics tool, every referrer header, and every server log.

Third party intake tools with their own pixels. The tool ships with its own tracking, and the marketing team never sees its configuration because it belongs to the product team.

Keeping attribution across the boundary

The reason teams over-track intake is that they are trying to solve a real problem: if tracking stops at the clinical zone, how do you know which campaign produced a paying patient?

The answer is a server-side chain rather than a client-side one.

Capture the click ID on landing and persist it server-side. When intake begins, attach that stored attribution to the intake record inside your own systems. When a downstream milestone happens, your backend reports a neutral event with the stored click ID and a hashed identifier. The patient's browser never has to carry attribution into the clinical zone, and the ad platform receives a conversion with no clinical context.

When intake lives on a third party tool at a different domain, a token has to survive the click-out, because the click ID will not. That token identifies the session, not the person, and lets the outcome match back when it returns by webhook.

How Curve draws the line in virtual care funnels

Curve is HIPAA-compliant ad tracking, marketing attribution, and analytics for healthcare, and telehealth is a core vertical. The script installs in place of the Meta Pixel and Google tag, so events reach Curve's US-hosted infrastructure rather than going straight to an ad platform. That single change is what turns the zone model from a policy into an enforced boundary.

• Per-destination field mapping. Only explicitly mapped fields forward to a given destination, and the default is that nothing goes. An intake payload that happens to include a condition field does not reach Meta because nobody mapped it, rather than reaching Meta because nobody blocked it.
• Neutral event aliases. Internal reporting keeps descriptive step names. The ad platform receives a neutral name that does not encode the service line or the intake stage's clinical content.
• SHA-256 identifier hashing. Contact identifiers are hashed per each platform's conversion API requirements before forwarding.
• Bridge tokens. When the funnel hands off to a separate intake or scheduling tool such as IntakeQ, Calendly, or Jane App, a token preserves attribution across the domain boundary without carrying patient data with it.
• Incoming webhooks. Your EHR, intake platform, or billing system posts downstream milestones back, matched by email, click ID, or bridge token. Incoming data cannot override protected core attribution and contact fields.
• Offline conversion uploads. Milestones that happen days later upload in bulk with click ID matching, so late-realizing value still reaches the bidding algorithm.
• PHI-pattern detection. Payloads containing PHI-shaped values (dates, MRN-style identifiers, long numeric sequences) are flagged as a monitoring signal, which is how you find out a form change started sending date of birth.

A signed BAA is included on every plan. For adjacent mechanics, see HIPAA-compliant lead routing from ad click to CRM and why client-side pixels are the exposure.

Designing intake so the boundary is easy to hold

The compliance work gets much simpler if the form is ordered deliberately, and the ordering is good product design anyway.

Put non-clinical qualification first. State of residence, age bracket, contact details. These do the most to disqualify unserviceable prospects, they are the least sensitive, and putting them first means your primary conversion event fires in the threshold zone where you can measure it cleanly.

Put clinical questions after that, on their own screens, on URLs that describe a step number rather than a condition. Use /intake/step-3 rather than /intake/thyroid-history. A neutral URL structure removes an entire category of leak with no engineering effort.

Keep answers out of query strings entirely. Post them, store them server-side, and keep the browser's address bar boring.

And review the actual outbound payloads rather than the configuration. Open the network tab on your own intake flow and read what leaves. Configuration describes intent; the payload describes reality, and they diverge more often than anyone likes.

Frequently asked questions

Can we track that someone started intake?

Yes, provided the event carries no clinical content, the URL is neutral, and identifiers are hashed. Intake started is a progression signal, not a health disclosure.

Is a page URL really PHI?

It can be. A URL like /intake/erectile-dysfunction/eligibility transmitted alongside an IP address and a browser identifier links an identifiable person to a specific health inquiry. That combination is the core of most healthcare pixel litigation.

Can we run session recording on intake?

Not with a general purpose replay tool. Recording clinical screens captures PHI. Any replay in a virtual care funnel needs to be built for healthcare, scoped away from clinical screens, and covered by a BAA.

What if our intake tool is a third party product?

Confirm it has a BAA, confirm it runs no ad pixels of its own, and carry attribution across with a token rather than by passing identifiers in the URL. The vendor's default tracking configuration is the thing to check first.

How do we optimize campaigns if the good signal is behind the clinical zone?

Optimize on the threshold-zone conversion for volume, and feed downstream milestones back as neutral server-side events or offline uploads with click ID matching. The platform learns which traffic produces value without learning why.

Does consent from the patient solve this?

Not for disclosures to ad platforms. A HIPAA authorization for marketing use is a specific instrument, and a cookie banner is not one. Consent tooling handles state privacy law obligations; it does not make an ad platform a lawful recipient of PHI.

Where exactly should the tracking script be removed?

From every page in the clinical zone and the authenticated patient area. If the script is placed in a global template, the boundary needs to be enforced in the template rather than trusted to a tag manager rule.

Where to start

Walk your own intake flow with the browser network tab open and write down every third party request each screen makes. That exercise takes twenty minutes and reliably finds at least one thing nobody knew was there.

Then draw the three zones explicitly, rename any URL that describes a condition, move non-clinical qualification to the front of the form, and remove client-side ad tracking from everything past the first clinical question.

Curve supplies the pipeline that keeps attribution intact across that boundary: server-side collection to US-hosted infrastructure, per-destination field mapping, neutral event aliases, hashed identifiers, bridge tokens across intake handoffs, incoming webhooks and offline uploads for downstream milestones, PHI-pattern monitoring, and a signed BAA on every plan.

Run the free compliance scanner against your funnel, read how subscription telehealth handles privacy and billing tracking, or visit curvecompliance.com to map your zones.

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