HIPAA‑Conscious Conversion Tracking for Telehealth Google Ads

Where exactly is the line?

The rule is simple to state: information that identifies an individual and relates to their health, care or payment for care cannot be sent to Google Ads or GA4. Hashed emails used for enhanced conversions are still personal data, so the question is never “is it hashed?” but “does the combination of what I am sending reveal a health context about an identifiable person?”

An email address forwarded from a generic newsletter signup is a different risk from the same email forwarded from /glp1-eligibility/thank-you with a URL parameter naming the condition. The identifier did not change. The context did.

This article describes engineering practice, not legal advice. Your counsel and your privacy officer decide what your organisation may transmit; our job is to make sure the measurement still works once they have.

Consent Mode v2, correctly implemented

Consent Mode v2 tells Google tags how to behave based on a user’s consent state. Four signals matter:

Signal	Controls
ad_storage	Advertising cookies
ad_user_data	Whether user data may be sent to Google for advertising
ad_personalization	Personalised advertising and remarketing eligibility
analytics_storage	Analytics cookies

Implementation checklist:

1. Set default consent state to denied before any Google tag fires. A default that runs after the tag is the same as no default.
2. Update the state when the visitor chooses, and persist it across pages and sessions.
3. Use a consent management platform that actually integrates with the Google tag rather than one that only hides a banner.
4. Verify in tag assistant and in the network tab that the gcs parameter reflects the choice made.
5. Re-test after every site release. Consent implementations break silently and nothing in the interface tells you.

Enhanced conversions without sending PHI

Enhanced conversions improve attribution by sending hashed first-party identifiers alongside a conversion. For a general ecommerce brand this is straightforward. For a clinic it demands care, because the conversion itself may carry health context.

Practical patterns that keep the line clean:

• Move the conversion upstream. Fire an identified conversion at a neutral event (account created, consultation booked) rather than at a treatment-specific confirmation page.
• Strip context. Send no page path, no query string, no referrer, and no custom parameters describing the service. Configure this explicitly — automatic collection defaults are not on your side.
• Use a server-side endpoint you control. Receive the conversion, drop every field not on an allow-list, hash what remains, forward that and nothing else.
• Allow-list, never deny-list. Deny-lists fail the moment a developer adds a field.
• Keep names generic. A conversion action called “Consultation booked” carries no clinical meaning; one named after a medication does.

Offline conversion import: the part that actually moves revenue

Almost every underperforming telehealth account we look at optimises toward form submissions. Google then does exactly what it was asked and finds the cheapest people willing to fill in a form — out-of-state, ineligible, and price-shopping. Offline conversion import fixes this by feeding real outcomes back.

1. Capture GCLID (and wbraid/gbraid for app and iOS paths) on the first landing and store it against the lead record in your CRM.
2. Define outcome stages that matter: consultation booked, consultation attended, clinically qualified, programme started, retained at 90 days.
3. Assign values reflecting real economics — expected programme value times stage conversion rate, not a made-up number.
4. Upload via the Google Ads API or scheduled import on a cadence fast enough to stay inside the conversion window.
5. Switch bidding to the qualified stage once volume supports it, keeping form fills as a secondary conversion for diagnostics.

Uploads carry GCLIDs and outcome flags — no names, no conditions, no clinical notes. That is what makes this the highest-value and lowest-risk build available to a clinic.

A reference architecture

Most clinics can get to a defensible setup with four components. None of them are exotic; the discipline is in what each one refuses to pass along.

1. Consent layer. A CMP that sets Consent Mode v2 defaults to denied before any tag loads, then updates and persists the choice. This is the only component that must run first.
2. Browser tag, deliberately thin. The Google tag fires events with no page path, no query string and no form values. Custom parameters are opt-in, never automatic.
3. Server container you control. Receives events, applies an allow-list, hashes permitted identifiers, and forwards only that to Google. This is where policy is enforced in code rather than in a document.
4. CRM as the source of truth. Stores GCLID against the lead, tracks outcome stages, and pushes offline conversions back with outcome flags and values — no clinical fields, ever.

Eight mistakes we see repeatedly

• Thank-you page URLs that name the treatment. Free to fix today, expensive to explain later. Use neutral confirmation paths.
• Conversion actions named after medications. The name travels into reporting and into Google's systems.
• Auto-collected form fields. Enhanced conversion auto-detection can scrape inputs you never intended to send. Configure fields explicitly.
• Consent tags firing after the Google tag, which makes the whole implementation cosmetic.
• Remarketing audiences segmented by condition page. The segmentation itself is the health inference.
• Counting every micro-event as a conversion, which makes optimisation meaningless and inflates reported performance to leadership.
• No GCLID column in the CRM, which makes offline import impossible and is usually a one-line form change.
• Never re-testing. Tracking breaks silently at every site release; without a scheduled check you find out from a month of bad data.

Reconciling Google's numbers with reality

Once consent modelling, enhanced conversions and offline imports are all in play, three different systems will report three different numbers. That is expected. What matters is that you know which number answers which question.

Question	Source of truth	Why
Which campaign should get more budget?	Google Ads, with offline conversions imported	It is the system making the bidding decision
How many patients did we actually acquire?	CRM / billing	Only place a real outcome exists
Is the site converting better?	Analytics, consent-modelled	Relative movement is reliable even when absolutes are not
What did a patient cost us?	Total spend ÷ CRM-confirmed patients	Blended and unarguable

Publish that table internally. Most measurement arguments inside clinics are two people answering different questions with the same dashboard, and settling which system owns which question ends the argument permanently.

Validating the whole thing

Run this quarterly, and after every website release:

• Consent default fires before tags; gcs values match user choice
• No conversion payload contains page path, query string or form values
• Conversion action names carry no clinical meaning
• Enhanced conversion identifiers derive only from allow-listed fields
• GCLID capture rate above 90% of paid sessions in the CRM
• Offline uploads landing inside the conversion window, with a match rate you monitor
• Ads reported conversions reconcile against CRM outcomes within a tolerance you have agreed

If several of these are unknown, that is the work — not another round of bid adjustments. Related reading: conversion tracking without fooling yourself and advertising compounded GLP‑1s. To get a scored view of your current setup, run the Readiness Score or book a strategy call.

Frequently asked