HIPAA-Compliant Tracking: How We Implement Ours Privacy for Healthcare
A default Meta pixel on a health site sends more than you think. Here is what HIPAA-compliant tracking actually requires, and how we implement Ours Privacy for everyone from health startups to large health systems.
HIPAA-compliant tracking means measuring your website and ads without sending protected health information (PHI) to vendors who haven't signed a Business Associate Agreement (BAA) with you. In practice, that means pulling third-party pixels off sensitive pages, collecting events first-party and server-side, and stripping or generalizing anything identifying before each event goes out to Google, Meta or anyone else. We do this with Ours Privacy, a HIPAA-compliant CDP that sits between your site and your ad platforms. We've wired it in for everything from a small health startup to a large health system.
A default Meta pixel on a health site is a very polite houseguest. It doesn't make a mess. It just reads your mail and texts the details home.
You can fix that without going dark on marketing. You just have to rebuild the plumbing.
In this post
- Why pixels are a problem on health sites
- What HIPAA-compliant tracking actually requires
- How Ours Privacy works
- How we implement Ours Privacy, step by step
- Health startup vs. health system
- Keeping your ads smart without the pixel
- Why a technical partner matters
- FAQ
Why tracking pixels are a problem on health sites
A client-side pixel runs in the visitor's browser. Every time it fires, the browser sends the platform a bundle of data straight from that page: the URL, the page title, the IP address, cookie IDs, and often whatever the visitor typed into a form.
On an ecommerce site, that's the point. On a health site, the URL alone can say a lot. A page path like /conditions/ plus a booking-form event plus an IP address starts to look like "this person is seeking care for this thing." That's the combination regulators care about.
They've said so in writing. In July 2023 the FTC and HHS sent a joint letter to approximately 130 hospital systems and telehealth providers warning about technologies "such as the Meta/Facebook pixel and Google Analytics."
Google is pretty blunt about its own tool, too. Its help page says Google does not offer Business Associate Agreements for Google Analytics, and that HIPAA-regulated entities "must refrain from exposing to Google any data that may be considered Protected Health Information."
So the default setup most teams inherit, GA4 and a Meta pixel pasted into the site header, is exactly the one you don't want.
What HIPAA-compliant tracking actually requires
[Switches to serious face] We're not lawyers, and nothing here is legal advice. Your privacy counsel should sign off on the final setup. But every serious guide on this topic, ours included, lands on the same short list:
- A BAA with anyone who touches PHI. If a vendor receives health data on your behalf, they need to sign one. If they won't, PHI stays out of their system. Full stop.
- Collect the minimum. Don't capture fields you don't need. The safest PHI is the PHI you never collected.
- De-identify before it leaves. Strip or generalize anything identifying before an event reaches an ad or analytics platform. Hashing is not anonymization: a hashed email is still a match key, so whether any hashed identifier goes out is a call for your counsel.
- Know your page types. Patient portals and logged-in pages carry the most risk. Booking flows, intake forms and condition pages come next.
- Treat consent and authorization as two different things. A cookie banner manages consent for cookies. Don't assume a click on it counts as a HIPAA authorization. Ask counsel what your situation needs.
A word on where the law stands. In June 2024 a federal court in Texas vacated part of HHS's online tracking guidance, specifically the idea that pairing an IP address with a visit to an unauthenticated public page about a health condition automatically triggers HIPAA. That narrowed things. It did not make pixels safe. Logged-in pages, forms and booking flows are a different story, and state privacy laws keep moving. Our take: build the setup that holds up on the strictest reading, so the next ruling is just a news story.
How Ours Privacy works
Ours Privacy describes itself as a HIPAA-compliant CDP and privacy platform built around one job: "making sure sensitive data never reaches non-compliant tools." It lists signed BAAs and SOC 2 Type II on its site.
The architecture is the part that matters to an operator:
- A first-party web SDK collects events on your site as a first-party script. The third-party pixels come off.
- Server-side events can come in through Ours' Ingest API, so your backend can send events, not just the browser.
- Per-destination rules decide what each platform gets. Ours calls these mappers. For each destination, you can redact, rename, hash or anonymize fields.
- Server-side delivery sends the cleaned event to GA4, Google Ads, Meta and the rest from the server, so the visitor's browser never talks to those platforms directly.
Consent plugs into the same pipe. Ours' Osano integration docs describe two modes: one where the SDK doesn't load at all until consent is granted, and one where events are collected but the mapping layer blocks dispatch to destinations based on consent. Which mode you pick is a call for you and your counsel. Wiring either one correctly is the job.
It's one of the eight platforms we run deep, and the short version of this whole post is: capture first-party events server-side, strip PII before it reaches the ad platforms, get the risky pixels off the site.
How we implement Ours Privacy, step by step
The tool does the heavy lifting. The implementation decides whether it actually works. Our Ours Privacy implementation runs in eight steps:
- Audit what's firing. We crawl the site and the tag manager and list every pixel, script and embed. There's often one nobody remembers adding.
- Map the data. For every event, we write down what it carries and where it goes. This is the boring step, and it's the one that matters most. When you build these systems, the mapping has to be right. One wrong value and your whole attribution chain breaks.
- Classify pages by risk. Logged-in, booking and condition pages get the strictest rules. The careers page gets a lighter touch.
- Get the paperwork in order. You sign a BAA with Ours. We check which other vendors in the chain have one and which don't.
- Install the SDK and pull the pixels. Ours goes in first-party. The Meta pixel and the hardcoded GA tag come out.
- Build the mappers. Per destination, we decide what goes out. Event names get neutral too. "Booked: Dermatology Consult" becomes a generic "Appointment Booked," because the event name is data as well.
- QA in the network tab. We watch the actual requests leave the browser and the server and confirm what each platform received. Trust the payload, not the dashboard.
- Hand off with guardrails. Your team gets documentation on how to add a new event without reopening the leak.
Health startup vs. health system: same tool, different job
Small health startup or large health system, the tool is the same. The work around it is very different.
A health startup usually has one site, one booking flow, a small marketing team and a founder who needs paid acquisition to work next month. The risk is speed. Someone adds a pixel to test a campaign on a Tuesday and nobody checks what it sends. Here the work is a clean install, tight mappers on the booking funnel and a short playbook the team can follow without us.
A health system has many sites, many departments, several agencies with tag manager access and a compliance office that wants to see the data flow on paper. The risk is sprawl. Here the work is governance: who can add a destination, how changes get reviewed and how you prove what left the building.
Most guides treat "healthcare" as one buyer. A five-person startup and a hospital system are very different buyers. The hospital's process would sink a startup's launch, and the startup's playbook would give a hospital's compliance team heartburn.
Keeping your ads smart without the pixel
The usual fear goes like this: "If we pull the pixel, our ads go blind." Fair worry. Ad algorithms learn from the conversions you feed them, and a site that suddenly goes quiet trains them on nothing.
The fix is to keep sending signals, just fewer and cleaner ones. Ours delivers conversions server-side to Google Ads and Meta, so the platforms still learn that a valuable action happened. What they don't get is the condition, the page, or anything you and your counsel have decided is off-limits.
I've spent my career controlling paid pipelines that spent hundreds of millions of dollars, and maintaining solid Meta scores was part of the job. The lesson carries over here: a consistent conversion signal you can trust beats a noisy one stuffed with data you shouldn't be sending anyway. In healthcare you usually trade some match quality for a signal you can defend. A number you can trust, and defend in a compliance review, is the goal.
If your conversion events were a mess before any of this, fix that too. Our guide to setting up conversion tracking in Google Analytics covers the basics.
Why a technical partner matters
Compliant setups rarely break on launch day. They break six months later, when a campaign needs to ship by Thursday and somebody pastes a vendor's "quick install" snippet into the site header. Nobody's being careless. They just don't know the snippet is a pixel wearing a fake mustache.
That's why we stay on as the technical partner through the whole process: the audit, the build, the QA, and the "can we add this tool?" questions that show up after go-live. We wire it and document it, and we're the people you call before the snippet goes in.
I've spent seven years living in Google Tag Manager, and the rest of the bench isn't junior either (average tenure is 11 years). We'd rather know eight platforms cold than dabble in forty, and tracking and martech wiring is core to the work. Seven years in the Marine Corps taught me how to get a job done. Around here, done means checked.
Frequently asked questions
What is HIPAA-compliant tracking? It's website and ad measurement set up so protected health information never reaches a vendor that hasn't signed a BAA with you. Usually that means first-party, server-side collection with identifying data stripped or generalized before events go to ad and analytics platforms. It's a property of your whole setup.
Is Google Analytics HIPAA compliant? Not on its own. Google says it doesn't offer BAAs for Google Analytics and that HIPAA-regulated entities must not expose PHI to it. Some teams keep GA4 by routing events through a tool like Ours Privacy that strips PHI before anything reaches Google. Whether that holds up for your setup is a question for your privacy counsel.
Is the Meta pixel HIPAA compliant? A default Meta pixel sends data straight from the visitor's browser, including URLs and IP addresses, which is the risk regulators have warned about. The usual fix is to remove it from sensitive pages, or replace it with server-side delivery that strips identifying data first.
Does server-side tracking make you HIPAA compliant? No, not by itself. Server-side tracking gives you a place to filter data before it leaves, but you still have to configure the filtering, sign the right BAAs and decide what each platform receives. A badly configured server can leak PHI just as well as a pixel.
Is Ours Privacy HIPAA compliant? Ours Privacy describes itself as a HIPAA-compliant CDP and lists signed BAAs and SOC 2 Type II on its site. Compliance is still shared between the vendor and you. How it's configured, and what your team sends through it, decides whether your setup holds up.
Can healthcare organizations still run Google and Meta ads? Yes. Many do, with server-side conversion delivery that tells the platforms an action happened without sending the health details behind it. Expect less granular data, and a signal you can stand behind.
How long does an Ours Privacy implementation take? It depends on the size of the site and how many tools are already firing. A single-site startup is a much smaller job than a multi-site health system. We scope it after an audit of what's on the site today.
Get your tracking off the risky list
If you're not sure what your site is sending to Meta and Google right now, that's the place to start. Most teams are surprised by at least one tag.
We'll audit it, wire Ours Privacy end to end, and stay on as your technical partner after launch. Tell us what's on your site, and we'll show you where the data goes.