How to connect ad clicks to patient intakes and purchases

To connect an ad click to a completed patient intake and a purchase, you do four things. Capture the click id and UTMs when the visitor lands. Carry them across domains to the intake. Store them on the patient’s run on your server the moment the intake opens. Then, when the purchase happens, send the conversion to the ad platform from your server, with the order id, the value and the click id attached.

Each step can break on its own. The usual weak point is the second: the website lives on one domain and the intake on another. This guide covers the whole chain and that jump in the middle of it.

What is journey stitching?

Journey stitching means joining the pieces of one person’s path into a single record: the ad they clicked, the landing page they read, the intake they started, and the step where they stopped or the purchase they made. Each piece is recorded by a different system, often on a different domain.

For a telehealth brand the chain is usually an ad, then a landing page on brand.com, then an eligibility quiz and intake on another host, then checkout. If the click id does not survive every hop, the ad platform never learns which campaign produced a paying patient, and its bidding optimizes toward what it can see, usually the landing page visit.

Click ids, explained

Each ad platform adds its own parameter to the landing page URL when someone clicks an ad. That parameter is what links the click to what happens next.

Platform	Parameter	What the platform says it is
Google Ads	gclid	A URL parameter passed with ad clicks that identifies the campaign and other attributes of the click (Google)
Google Ads	gbraid, wbraid	gbraid is present when a web ad click leads into your iOS app; wbraid when an ad in an iOS app leads to your web page (Google)
Meta	fbclid, sent as fbc	fbclid is the raw click id in the URL. The Conversions API takes it as fbc, formatted fb.subdomainIndex.creationTime.fbclid (Meta)
Microsoft Ads	msclkid	A 32-character GUID, unique for each ad click, appended when auto-tagging is on (Microsoft)

A few details matter in practice:

• Google recommends setting both the gclid and the gbraid on a conversion when you have both. It also calls the order id (transaction id) “optional, but strongly recommended.”
• Meta recommends storing the click in an _fbc cookie with a 90-day expiry, and updating it whenever a new fbclid arrives in the URL.
• Microsoft says the msclkid is only available on the landing page URL and does not carry over when the visitor moves to another page, so your site has to capture and store it. It also says a conversion uploaded more than 90 days after the last click will not be imported.

UTMs (utm_source, utm_medium, utm_campaign, utm_content, utm_term) are not click ids. They tell your own reporting which campaign sent the visit. Click ids tell the ad platform which click to credit. You want both.

Why cross-domain journeys break

The intake is on a different domain. Cookies belong to a domain. A click id stored in a cookie on brand.com cannot be read on intake-vendor.com. If the intake is on a subdomain such as start.brand.com, a cookie set on the parent domain can be shared. If it is on a different registrable domain, nothing is shared unless you pass it in the link.

Third-party cookies are blocked. WebKit, the engine behind Safari, says its Intelligent Tracking Prevention “by default blocks all third-party cookies” with no exceptions (WebKit).

First-party cookies set by script are short-lived in Safari. WebKit says ITP deletes cookies created in JavaScript, and other script-writeable storage, after 7 days without user interaction with the site. When it detects link decoration (click ids added to links by trackers), it caps cookies created in JavaScript on the landing page to 24 hours (WebKit). A patient who clicks an ad on Monday, reads, leaves, and comes back the following week to start the intake may arrive with nothing.

The fix for all three: do not rely on the browser to remember attribution beyond one visit. Move it to your server as early as you can.

The methods

1. Link decoration

Pass the click ids and UTMs as URL parameters on every link from the website to the intake. A “Start your assessment” button that points at https://start.brand.com/glp1 should be rewritten at click time to carry ?gclid=...&utm_source=google&utm_campaign=c104.

Google’s own tags do a version of this. Its conversion linker can append a linker parameter to links that point to domains you list (“Auto Link Domains”), and a compatible tag on the destination reads it and stores a first-party cookie there (Google Tag Manager Help). Google Analytics 4 uses a _gl parameter the same way so one visitor is not counted as two users on two domains (Google Analytics Help). Those linkers serve Google’s products. For Meta, Microsoft and TikTok you need your own decoration, or a tool that forwards every platform’s click id.

2. First-party cookies on each domain

On landing, read the click ids and UTMs from the URL and store them in a first-party cookie on the website’s domain. On the intake domain, do the same with whatever arrives in the URL. This covers the visitor who browses three pages before clicking “Start.” Microsoft’s own instructions follow this pattern: capture the msclkid and store it in a cookie so it follows the visitor through the session.

3. Server-side storage on the run

When the intake opens, write the click ids, UTMs and consent state onto the patient’s run (the intake session record) on your server. From then on, attribution no longer depends on any cookie. Every later event, including a purchase that happens days after the click, can read it from the run. This is the step that makes the chain survive Safari.

4. What never goes in a URL

URLs end up in logs, analytics tools and ad platforms. Keep them free of health information:

• No condition, symptom, medication or answer in a query parameter.
• No email, phone or name in a URL, hashed or not.
• No condition in UTM values. Use neutral campaign codes (c104) and keep the mapping in your ad account, rather than utm_campaign=diabetes-glp1.
• No condition in event names. intake_completed is fine; diabetes_intake_completed is not.

The chain, step by step

Step	What is captured	Where it lives
Ad click	Platform adds gclid, fbclid or msclkid	Landing page URL
Landing page	Click ids and UTMs read from the URL	First-party cookie on the website domain
Click to intake	Click ids and UTMs added to the link	Intake URL (link decoration)
Intake opens	Click ids, UTMs, consent state	Patient’s run on your server
Intake steps	Completion and drop-off per step	Your analytics, keyed to the run
Purchase	Order id, value, currency	Payment record, joined to the run
Conversion sent	Click id, order id, value, hashed email or phone (consented visitors only)	Ad platform, sent from your server

Attribution models, briefly

Once the conversion arrives, the platform decides how to credit it. Google Ads offers two models: last click, which “gives all credit for the conversion to the last-clicked ad and corresponding keyword,” and data-driven, which “distributes credit for the conversion based on your past data.” Google says data-driven is the default for most conversion actions, and that first click, linear, time decay and position-based models are no longer supported (Google Ads Help).

Either model needs the same input: a conversion with a click id and a real value.

How to measure from ad to paid patient

Report the funnel by campaign, not as one overall rate. For each campaign (from the UTMs stored on the run), track:

Metric	What it tells you
Intakes started	Whether the ad and landing page send people who begin
Intakes completed	Whether the intake itself holds them
Eligible	Whether the campaign reaches people your clinicians can treat
Purchased	Whether eligible patients pay
Revenue	The value the ad platform should optimize toward

An example, without numbers: campaign A sends more intake starts than campaign B, but B’s starts complete and purchase at a higher rate. A platform that only sees landing page visits keeps funding A. A platform that receives each purchase with its value, tied to B’s click ids, can move budget to B. Eligibility criteria are set by your clinicians, so an ineligible patient is not a failed conversion; it is a sign the campaign reaches the wrong people.

Where people drop inside the intake is a separate question from which campaign to fund. Step-level analytics and A/B testing cover that side.

PHI rules for attribution

An intake is a page where a patient answers health questions. Anything a tracking tool collects there can carry health information to a vendor, so treat every event that leaves an intake as a possible disclosure and decide in advance what it may contain.

In practice: no third-party ad pixels on intake steps; conversions sent from your server so you decide which fields leave; email and phone hashed; answers, conditions and dates of birth never sent; nothing sent for a visitor who has not consented. The HIPAA intake playbook covers the rest of the intake side, and server-side conversion tracking for healthcare goes deeper on the sending side.

How PathwAI does it

PathwAI builds the intake and handles the sending side of the chain.

• Flows run on your own domain, or embedded on your website, so the intake is first-party to your brand.
• First-party tracking only. The Data Platform script loads from your own domain and uses only first-party cookies. There are no third-party ad pixels.
• Click ids and UTMs captured on the visit. Conversions are attributed to the ad, campaign and keyword, using click ids (gclid, fbclid, msclkid) and UTMs captured on the visit.
• Conversions go server-side to Meta (Conversions API), Google Ads (Enhanced Conversions and Customer Match), TikTok (Events API) and Microsoft Ads (offline conversions).
• No PHI leaves. Email and phone are SHA-256 hashed, PHI such as date of birth and condition is stripped before any event leaves, and ad platforms receive identifiers only for visitors who consented.
• Consent is a step in the flow. Patients acknowledge before continuing, and consent is timestamped and stored with the intake data.
• Reporting by step. Step-level analytics show completion and drop-off for every screen, so you can see where each intake loses people.

This sits in the Data Platform. If your team runs its own tags, PathwAI also integrates with Google Tag Manager. For a paid-acquisition funnel end to end, see lead funnels, and for the compliance side, the HIPAA overview.

Checklist

• Auto-tagging is on in Google Ads and Microsoft Ads.
• Click ids and UTMs are stored in a first-party cookie on the website at landing.
• Every link to the intake carries the click ids and UTMs.
• The intake reads them from the URL, with a cookie fallback.
• Click ids, UTMs and consent are written to the run on the server when the intake opens.
• The purchase event carries order id, value and currency.
• Conversions are sent server-side, hashed, and only for consented visitors.
• No condition, answer or identifier in any URL, UTM or event name.
• Funnel reported by campaign: started, completed, eligible, purchased, revenue.

Frequently asked questions

Do I need cross-domain tracking if my intake is on a subdomain?

Less of it. A cookie set on the parent domain (brand.com) can be read on start.brand.com. You still want the click ids on the run on the server, because Safari limits how long cookies created by script last.

Is the order id really necessary?

It ties the conversion to a real order in your payment system. Google calls the order id (transaction id) “optional, but strongly recommended,” because it makes an imported conversion simpler to reference when you adjust it later, for example after a refund.

Can I put the treatment name in my UTMs?

Avoid it. A UTM travels with the visit into analytics and ad tools. Use neutral campaign codes and keep the meaning in your ad account.

Does server-side tracking replace consent?

No. Sending from your server controls what leaves; it does not make sending lawful. Send conversions only for visitors who consented.