The pixel you pasted in is the compliance problem.
A GLP-1 brand wants the same thing every advertiser wants: to know which ad produced which patient, so it can spend into what works. The ordinary way to get that answer is to drop a Meta pixel and a Google tag on the site and read the conversions back. On a store selling socks, that is fine. On a page where the visitor is telling you they want semaglutide, the same pixel is sending an ad platform both who the person is and what they are seeking treatment for, from the visitor's own browser, where you cannot see most of what leaves.
That combination is the thing regulators have treated as protected health information, and it is why healthcare marketers froze on tracking for two years. The good news is that attribution for a telehealth funnel is a solved engineering problem. The work is in understanding what the rule actually is now, and then building the feed deliberately instead of pasting in a snippet.
What the HHS bulletin actually says, and what a court took back.
In December 2022 the HHS Office for Civil Rights published a bulletin on online tracking technologies, and updated it in March 2024. Its headline position was that when a covered entity's website uses tracking that discloses protected health information to a third party like an ad platform, HIPAA applies, and you need a business associate agreement or a different approach. Few people argued with that for logged-in, authenticated pages.
The fight was over public pages. OCR took the position that an identifier such as an IP address, combined with a visit to an unauthenticated public page addressing a specific health condition, was itself protected health information. The hospital groups called that the Proscribed Combination and sued.
On June 20, 2024, the U.S. District Court for the Northern District of Texas, in American Hospital Association v. Becerra, agreed with them on that point. It ruled that OCR had exceeded its authority and vacated the Proscribed Combination portion of the bulletin. OCR later withdrew its appeal.
Two honest qualifications, because this is exactly where people overread the headline.
First, the ruling vacated one part. The AHA did not challenge, and the court left intact, the rest of the bulletin. The decision is about whether a bare IP address plus a public-page visit is automatically protected health information, not a general clearance to send intake data anywhere.
Second, none of this touches authenticated pages. A patient portal, a logged-in dashboard, a post-checkout page a patient reaches after identifying themselves: those were never the contested part, and tracking on them is the clearer HIPAA exposure, not the murkier one. The vacatur narrowed an aggressive reading of public pages. It did not make a Meta pixel on your intake flow a good idea.
Why server-side is the fix, and why server-side alone is not.
The durable pattern does not depend on how the Texas case ages, because it does not rely on the data being allowed through in the first place. You stop sending events from the visitor's browser straight to the platforms, and you route them through a server you control.
A standard web pixel runs client-side. It fires in the browser and reports to Meta or Google directly, which is why it is so hard to audit and so easy to over-collect. The server-side alternative, built on the platforms' server APIs such as Meta's Conversions API, reverses that: your server receives the event, and your server decides what, if anything, is forwarded.
Here is the part most guides skip. Moving to server-side tagging does not make you compliant. It changes where collection happens, not whether you are permitted to share what you collected. If a filtered-looking event still arrives at Google carrying a visitor's identity and their condition, the fact that it passed through your own container on the way did not help anyone. The vendors who sell server-side hosting say this plainly. Stape, a common host for server-side Google Tag Manager, frames its own HIPAA guidance around signing a business associate agreement for covered services and routing only approved events, not around the hosting itself being the compliance.
The allowlist is the real work.
Two controls do the actual compliance work, and both live on your side of the connection.
The first is the business associate agreement. Any party that handles protected health information on your behalf needs one where HIPAA applies. Freshpaint, a tracking tool built for this problem, states that it signs a business associate agreement, is implemented server-side only, and by default sends nothing to non-compliant destinations like Google or Facebook unless you explicitly allowlist it. Stape says a business associate agreement is available for covered services, generally on a Custom plan arranged with their team. Google will sign business associate agreements for eligible Cloud services such as Cloud Run, which is why some teams host their own container there instead. The ad platforms, as a rule, will not sign one, which is the entire reason the filtering has to happen before data reaches them.
The second is the allowlist itself: the explicit, reviewed list of which events leave your environment and which fields ride along. A compliant feed usually forwards that a conversion happened and a coarse value, with identifiers hashed or dropped and nothing that reveals the condition. Default-deny is the safe posture. You start from nothing leaving, and you add back the minimum each platform needs to optimize, with your privacy or legal team signing off on the list rather than an engineer deciding in a tag.
What this looks like for a GLP-1 funnel.
In practice a compliant GLP-1 attribution stack has a recognizable shape. Marketing pages and the top of the funnel can carry ordinary analytics. As the visitor crosses into intake, eligibility, and anything that reveals the condition or the person, collection moves server-side, through a host that will sign a business associate agreement, behind a default-deny allowlist. Conversions are reported to Meta and Google through their server APIs as filtered events, so the platforms still get a signal to optimize against without receiving the raw intake. The messy, high-value middle, which patient started, which plan, which lifetime value, stays in systems you control and reconcile there.
That is also where attribution quality actually comes from. A clean server-side feed with stable event definitions usually reports better than a half-blocked browser pixel fighting consent prompts and ad blockers, which is the quiet upside: the compliant architecture is frequently the more accurate one.
A short honest list of what to check.
- List every page where the visitor reveals a condition or identifies themselves, and confirm what tags fire there today. Intake, eligibility quizzes, booking, checkout, portal.
- Decide which events each platform genuinely needs to optimize, and write that allowlist down. Everything not on it does not leave.
- Confirm who touches the data and whether they will sign a business associate agreement. The host, the tag manager, the warehouse. The ad platforms will not.
- Hash or drop identifiers, and keep condition-revealing context out of every forwarded payload.
- Separate marketing-page analytics from intake and portal tracking, so a change to one never quietly re-enables the other.
This is operational guidance, not legal advice, and the description of the HHS bulletin and the 2024 ruling here is a summary, not a substitute for the source documents or for counsel who knows your business. If you want the intake, the events, and the ad feed built or audited as one system before you scale spend, that is the work in telehealth and GLP-1 website development, and the narrower read-through is a telehealth program fit review. The adjacent question of what the ad platforms look for on the page itself is in what a telehealth website needs before you run Google or Meta ads, and the review your site has to clear before it can advertise at all is in the web developer's checklist for passing LegitScript the first time. Have qualified counsel and your privacy team review your tracking before it goes live.
Common questions
Can I put a Meta or Google pixel on a GLP-1 intake page?
Not the way it ships by default. A standard client-side pixel sends data from the visitor's browser straight to the ad platform, and on a telehealth intake it can carry identifiers alongside the fact that this person is seeking treatment for a specific condition. The HHS Office for Civil Rights has treated that kind of combination as protected health information in its online tracking guidance. The workable pattern is to collect events on a server you control, strip identifiers your privacy or legal team has not approved, and forward only allowlisted events to the platform through its server-side API. Moving the pixel server-side is the start of the fix, not the whole of it.
Didn't a court throw out the HHS rule on tracking pixels in 2024?
It threw out one part. On June 20, 2024, the U.S. District Court for the Northern District of Texas, in American Hospital Association v. Becerra, vacated the portion of the OCR bulletin known as the Proscribed Combination, which treated a visitor's IP address plus a visit to an unauthenticated public webpage addressing a health condition as protected health information. The court found OCR exceeded its authority on that specific point, and OCR later withdrew its appeal. The rest of the bulletin was not challenged and still stands, and nothing in the ruling touches authenticated pages like a patient portal. Treat it as narrowing one aggressive reading, not as permission to send intake data to Meta.
Does moving to server-side tracking make me HIPAA compliant?
No. Server-side tagging changes where the data is collected, not whether you are allowed to share it. If events still reach Google or Meta carrying protected health information, hosting the container yourself has not helped. Server-side is only compliant when the party handling the data will sign a business associate agreement where one is required, and when you allowlist the specific events and fields that leave your environment. Vendors who host server-side Google Tag Manager, such as Stape, say the same thing: the architecture is a tool, and the business associate agreement and the allowlist are the controls.
What is the difference between a web pixel and the Conversions API?
A web pixel runs in the visitor's browser and reports to the ad platform directly, which is why it is hard to inspect and easy to over-collect. The Conversions API, or CAPI, is a server-to-server connection: your server decides what to send and when. CAPI is what makes a filtered, allowlisted feed possible, but it does not filter anything on its own. You still have to define which events qualify, hash or drop identifiers, and keep condition-revealing context out of the payload.
Which tools actually sign a BAA for this?
Some do and some do not, and it is worth checking directly rather than assuming. Freshpaint states it signs a business associate agreement, runs server-side only, and sends nothing to non-compliant destinations unless you allowlist it. Stape says a business associate agreement is available for covered services, typically on a Custom plan arranged with their team rather than on self-service. Google offers business associate agreements for eligible Cloud services such as Cloud Run, which some teams use to host their own server container. The ad platforms themselves generally will not sign a BAA, which is the whole reason the filtering sits on your side.
Sources
- HHS Office for Civil Rights, Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates checked 2026-10-07
- American Hospital Association, Judge rules in favor of AHA, vacating HHS online tracking bulletin checked 2026-10-07
- McDermott Will and Emery, Federal Court Invalidates Key Part of HHS OCR Bulletin Regarding Online Tracking Technologies checked 2026-10-07
- Freshpaint, How Tracking Technologies Work, And Why They Violate HIPAA checked 2026-10-07
- Stape, HIPAA-Compliant Tracking, Strategies for Healthcare Companies checked 2026-10-07
Want this costed for your build?
Tell us what you already have and what is not working, and we will come back with the shape of the work and what drives the number.