How to Audit Your Healthcare Website for Tracking Pixels

Last updated: August 10, 2026 · By Jason Garrett, Founder, Coast Studio. Not legal advice — run findings past healthcare counsel. Full legal landscape: The State of HIPAA Tracking.

Every pixel on a health site is a question: does it send anything that, joined to a person, reveals a health fact? Most teams have never checked. This is the audit we run before rebuilding a client's tracking — a method you can follow yourself in an afternoon, and a checklist to work through page by page. Do it before a regulator, a plaintiff firm, or a platform does it for you.

What you're looking for

PHI in a tracking context is any identifier (IP, cookie ID, email, phone, click ID) transmitted alongside something that implies a health condition, treatment, provider, or appointment. The identifier and the health signal are each harmless alone. Together, sent to a vendor without a BAA, they are a disclosure. The audit hunts for that pairing.

Step 1: Inventory every tag that loads

1. Open the site in Chrome, load a condition or service page, and open DevTools → Network.
2. Filter for the usual endpoints: facebook.com/tr, google-analytics.com, googleadservices.com, analytics.tiktok.com, hotjar, bat.bing.com, plus any call-tracking or chat script.
3. List every third-party that fires. A tag auditor extension speeds this up, but the Network tab is the ground truth.
4. Repeat on your highest-risk pages, not just the homepage: condition pages, service pages, the appointment or intake flow, and the confirmation page.

Step 2: Read what each tag actually sends

This is the step teams skip, and the one that matters. Click each tracking request and read the payload:

• The URL sent — does the path or query name a condition (/std-testing, ?condition=depression)?
• The page title — is it forwarded, and does it name a service?
• Event and custom parameters — any content_name, conversion label, or custom field carrying a diagnosis or treatment?
• Identifiers — hashed email/phone, external IDs, or the raw IP that always rides along.

If a request carries an identifier and a health signal to a vendor you have no BAA with, you have found a live disclosure. Log it.

Step 3: Check the intake and form flow closely

Intake is where the worst leaks live. Watch the Network tab as you fill and submit a form:

• Does any tag fire on submit and scrape field values?
• Does the thank-you URL encode what was booked (/confirmed/therapy)?
• Do session-recording or chat tools capture the fields a patient typed? See session recording under HIPAA.

Step 4: Audit call tracking and offline paths

The leak isn't always in the browser. Check whether your call-tracking tool records or transcribes appointment reasons and whether any of that feeds an ad platform. Check whether a CRM or email tool without a BAA receives condition data. Follow the data, not just the page.

Step 5: Reconcile every vendor against a BAA

List every vendor that touched patient-adjacent data in steps 1–4. For each, answer one question: is there a signed BAA? Google Ads, Google Analytics, the Meta pixel, TikTok, and Hotjar do not sign them. CallRail (Healthcare plan), HubSpot (Enterprise), Mixpanel, and Amplitude can. A vendor with no BAA must receive no PHI, full stop.

The audit checklist

Work through this per template — homepage, condition page, service page, intake, confirmation:

• ☐ Every firing tag inventoried from the Network tab
• ☐ No condition or treatment named in any transmitted URL or query string
• ☐ No page title naming a service forwarded to an ad platform
• ☐ No conversion label or custom parameter carrying a diagnosis
• ☐ No tag scraping form-field values on submit
• ☐ Thank-you and confirmation URLs neutralized
• ☐ Session-recording and chat tools off, or BAA-covered, on PHI pages
• ☐ Call tracking on a BAA plan; reasons for calls not sent to platforms
• ☐ Every vendor receiving patient-adjacent data has a signed BAA
• ☐ Findings documented with the exact request and payload as evidence

What to do with what you find

Any live disclosure is a two-track problem: stop the leak now (pull the tag, neutralize the URL), and decide with counsel whether past transmissions trigger breach notification. Then rebuild measurement the compliant way — server-side, scrubbed, and measured without user-level PHI. Speed matters; the plaintiff bar reads Network tabs too.

FAQ

Can I just use a pixel-scanner tool instead? Scanners flag which tags load, which is step 1. They rarely read whether the payload pairs an identifier with a health signal — the part that determines disclosure. Use a scanner to inventory, then read payloads by hand on your risk pages.

How often should I re-audit? Any time marketing adds a tag, a new tool goes live, or you launch condition pages — and on a standing quarterly cadence regardless. Tags creep back in.

We found a pixel that's been sending PHI for a year. Now what? Stop it today, preserve the evidence, and take the timeline to counsel to assess breach-notification duties before you publicize anything. Then rebuild.

Want this run for you, with the rebuild handled? Coast Studio audits and rebuilds healthcare tracking.