Server-side conversion tracking for healthcare, without pixels

Server-side conversion tracking means your own server, not a script in the visitor’s browser, tells Meta, Google, TikTok or Microsoft that a conversion happened. For a healthcare website it is the practical way to measure ads without third-party pixels: take the pixels off intake pages, then send a small event (a neutral event name, a hashed email or phone, a click id, a value) only for visitors who consented, and never the health answers behind it. This guide covers how it works, what the HHS guidance says, what each platform expects and what to check before you switch.

What is server-side conversion tracking?

A browser pixel is ad platform code that runs on your page and reports straight to the platform. It decides much of what it collects: page URL, title, cookies and, with some settings, what people type into forms.

Server-side tracking turns that around. Your server builds the event and calls the platform’s API, so the only data that leaves is what your server put in the request.

The two paths, step by step

The browser pixel path:

1. A visitor clicks an ad and lands on your intake flow.
2. The platform’s script loads from the platform’s domain and sets its cookies.
3. On each step, the script reports page views and events, often with the full URL and title.
4. The platform receives that directly. You never see the request and cannot edit it.

The server-side path:

1. A visitor clicks an ad and lands on your intake flow. The click id (gclid, fbclid, ttclid or msclkid) and UTMs are captured as first-party data.
2. The visitor answers questions. The answers go to your intake system, not to any ad platform.
3. On a conversion (completed intake, sign-up, purchase), your server builds an event: name, time, click id, a SHA-256 hash of the normalized email or phone, and for a purchase the value, currency and order id.
4. Your server checks that this visitor consented to ad tracking. No consent, no event.
5. Your server sends the event to the platform’s conversion API. The health answers stay behind.

Step 3 is what matters for a health brand: you write the payload, so you can show what was and was not sent.

Why pixels on intake pages are a HIPAA problem

The most cited source is the HHS Office for Civil Rights bulletin Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates, first issued in December 2022 and updated in March 2024. The points that matter for intake:

• Tracker data can be PHI. The bulletin lists email address, IP address, appointment dates and device ids among what trackers may disclose. For a regulated entity, identifiable health information collected on its website is generally PHI, even if the person is not yet a patient.
• Pages without a login can still involve PHI. The bulletin’s example is a tracker collecting an email address or the reason for seeking care on an appointment or symptom-checker page. That is a disclosure of PHI to the tracking vendor.
• A vendor that receives PHI needs a BAA. Without one, PHI cannot go to that vendor unless the patient gave a HIPAA authorization.
• A cookie banner is not an authorization. Banners asking visitors to accept or reject tracking “do not constitute a valid HIPAA authorization.”
• Removing PHI after receipt is not enough. A vendor’s promise to strip it later does not fix the disclosure.
• A middle layer is an accepted pattern. The bulletin describes using a vendor that signs a BAA, such as a Customer Data Platform, to de-identify tracking data and pass only de-identified information to vendors that will not sign one.

What the court changed in 2024

On June 20, 2024, in American Hospital Association v. Becerra, the U.S. District Court for the Northern District of Texas vacated one part of the bulletin: that HIPAA is triggered when a tracker connects an IP address with a visit to an unauthenticated public page about specific health conditions or providers. HHS shows that note at the top of the bulletin, and it withdrew its appeal in August 2024.

The ruling concerns public pages such as a blog post. The rest of the bulletin stands, and an intake flow is a different case: the person is entering their own health information, contact details and often payment.

The FTC covers brands outside HIPAA

Many cash-pay and DTC health brands are not HIPAA covered entities. The FTC has still acted on health data sent to ad platforms:

• GoodRx (February 2023). The FTC said GoodRx shared prescription and health condition information with Facebook, Google and others and used it for targeted ads. It was the first action under the Health Breach Notification Rule, with a $1.5 million civil penalty.
• BetterHelp (March 2023). According to the FTC, BetterHelp revealed email addresses, IP addresses and health questionnaire information to Facebook, Snapchat, Criteo and Pinterest for advertising. The order banned that sharing and required $7.8 million for consumer refunds.

In July 2023 the FTC and HHS also sent a joint letter to about 130 hospital systems and telehealth providers about tools such as the Meta pixel and Google Analytics. Note that the BetterHelp case centered on an intake questionnaire.

How each ad platform’s server-side API works

All four major platforms accept conversions from a server. They differ in matching and deduplication.

Platform	Server-side route	Matches on	Deduplication
Meta	Conversions API	Hashed email, phone and other customer fields; click id (fbc)	Same event_name and event_id as the pixel, within 48 hours
Google Ads	Enhanced conversions and the Data Manager API	gclid; hashed email, phone, name, address	Order id
TikTok	Events API	Hashed email, phone, external id; ttclid	Same event_id from pixel and Events API, within 48 hours
Microsoft Ads	Offline conversions	msclkid, or hashed email or phone	Same msclkid and conversion time; no order id field

From each platform’s documentation:

• Meta requires email, phone, name, date of birth and other customer fields to be SHA-256 hashed, and says the click id (fbc), browser id (fbp), IP address and user agent must not be hashed. Its deduplication guide matches server and pixel events by event_id and event_name.
• Google asks for normalized, SHA-256 hashed email and phone (phone in E.164) and calls the order id optional but strongly recommended. It says certain offline conversion uploads move to the Data Manager API from June 15, 2026. That API also carries Customer Match lists.
• TikTok lowercases and trims emails and puts phones in E.164 before SHA-256 hashing, and deduplicates on a shared event_id. Its help center also describes Automatic Advanced Matching, which “automatically identifies form fields on pages where the Pixel is installed” and collects what people enter. On an intake page, that is the behavior to avoid.
• Microsoft needs a conversion goal name, a time within the last 90 days, and an msclkid or a SHA-256 hashed email or phone. With no order id field, it cannot match a server purchase to one a browser UET tag already reported.

Hashing, and what must never be sent

Hash the identifiers you send

Normalize, then hash with SHA-256: trim and lowercase emails, and put phone numbers in E.164 with the country code. If your normalization differs from the platform’s, the hashes match no one.

Hashing keeps the raw email out of the request, but it does not make the event anonymous: the platform uses the hash to match a specific person. Treat a hashed email as personal data and gate it on consent.

Never send these

• Health answers. Conditions, symptoms, medications, BMI, mental health screens, pregnancy status, lab results.
• Anything that implies them. An event named glp1_eligible or depression_screen_complete gives the answer away. Use neutral names such as flow_completed or purchase.
• Page URLs and titles that reveal a condition. /hiv-prep/intake/step-4 tells the platform why the person was there.
• Date of birth, full name and address, unless you have a clear reason and a legal basis.
• Free text. You cannot know what a patient typed into “anything else we should know?”

Generally reasonable to send: a neutral event name, the time, the click id, a hashed email or phone, and for a purchase the value, currency and order id. Your counsel decides what is permitted for your program.

Consent gating and deduplication

Consent gating. Ask for ad-tracking consent in the flow, store the answer with the visit and check it on the server before every send. A visitor who never answered counts as opted out. Remember the HHS point: a cookie banner is not a HIPAA authorization. Consent gating is good practice under privacy laws, but it does not by itself permit sending PHI to a vendor without a BAA.

Deduplication. Many brands keep a pixel on their marketing site while sending purchases from the server. Without a shared id, one order counts twice. Send the same id from both sides: event_id for Meta and TikTok, the order id for Google. The payment processor’s order id works well, because a browser tag can report the same one.

Match quality: what you trade

A pixel automatically sends cookies, IP address, user agent and page context. A clean server event sends a click id and one or two hashed identifiers. Fewer signals can mean fewer conversions matched to ads in the platform’s reports. That is the honest trade: some reported conversions for a setup you can defend.

Two things narrow the gap: capture click ids on the first page view and keep them with the visit, and send a hashed email so a visitor who returns later on another device can still be matched.

Signal	Pixel	Server-side
Who decides what is sent	The ad platform’s script	Your server
Page URL and title	Sent by default	Only if you add them
Form field contents	Can be collected (automatic matching)	Never, unless you add them
Email and phone	Hashed in the browser when configured	Normalized and hashed on your server
Click ids	Read from the URL and platform cookies	Captured first-party, sent with the event
Consent check	Depends on your consent tool firing first	Checked on the server before each send
Third-party script on the page	Yes	No

How PathwAI does it

PathwAI is an AI-native builder for intake flows, eligibility quizzes and checkout, with a built-in Data Platform for server-side conversion tracking. It follows the server path above, with no third-party ad pixels:

• First-party loading. The PathwAI script and its tracking endpoint load from your own domain, with first-party cookies only.
• Events come from the server. Built-in events such as flow started, each step, sign-up, purchase and flow completed are sent by PathwAI’s server, not the visitor’s browser.
• Identifiers hashed, PHI stripped. Email and phone are SHA-256 hashed, and PHI such as date of birth and condition is stripped before any event leaves.
• Consent recorded once. Ad-tracking consent is stored with the visit and every later event carries it. Visitors who never consented are never sent to ad platforms.
• Purchases counted once. Purchases carry value, currency and the order id, which ad platforms use to avoid counting the same order twice.
• Attribution. Conversions are tied to the ad, campaign and keyword using click ids (gclid, fbclid, msclkid) and UTMs captured on the visit.

Destinations are the Meta Conversions API, Google Ads enhanced conversions and Customer Match, the TikTok Events API and Microsoft Ads offline conversions. PathwAI signs a BAA on the Enterprise plan; see HIPAA at PathwAI. For the intake side, read our HIPAA-ready intake playbook.

What PathwAI sends: the conversion and a hashed identifier, never the answers.

Checklist before you switch

• Remove ad pixels from every intake, consent and checkout step.
• Capture click ids and UTMs as first-party data on the first page view.
• Use neutral event names; keep conditions out of events and URLs.
• Normalize and SHA-256 hash email and phone on the server.
• Send no health answers, free text or condition-revealing URLs.
• Gate every send on stored consent, defaulting to opted out.
• Share an event_id or order id with any pixel still running elsewhere.
• Confirm a BAA with every vendor that may receive PHI.
• Test each destination in its test mode and log what you send.
• Have counsel review the setup.

Frequently asked questions

Is server-side tracking automatically HIPAA compliant?

No. It gives you control over what is sent, which makes a compliant setup possible. Compliance still depends on what the events contain, consent or authorization where needed, and BAAs with vendors that receive PHI.

Did the 2024 court ruling make pixels on health websites fine again?

No. American Hospital Association v. Becerra vacated the part of the HHS bulletin about IP addresses and visits to unauthenticated public pages. Intake pages where people enter health information, contact details or payment are a different case, and FTC rules still apply to brands outside HIPAA.

Can I keep the Meta pixel on my marketing site?

Many brands keep pixels on general marketing pages and remove them from intake, consent and checkout. Whether that suits your public pages is for your counsel. If you do, send a shared event_id or order id from both sides.

This guide is general information, not legal advice. Talk to your own counsel about the rules that apply to your program.