Google Tag Manager has been a bit of the wild west since its inception, with multiple agencies, analytics vendors and owners adding marketing tags without documentation or any kind of process. It kind of worked for years as everyone got what they needed and data flowed to intended platforms. 2026 is a whole new era (ok, even a couple years ago, but now it’s REAL).
Data privacy and protecting PHI is at the forefront of every healthcare marketer’s mind, but no one really knows where to start, especially with platforms like Google Tag Manager where years of changes can build up and not be audited regularly.
Server side tracking has become the gold standard to control precisely what leaves your server, critical in a highly sensitive vertical like healthcare for data compliance.
But “events” flowing through your server-side tracking setup aren’t generic ecommerce data. They’re things like: someone taking a screening quiz, submitting an insurance checker form, filling out the “reach out” contact form, or browsing specific treatment pages. That data can reveal a person’s likely health condition, and in some contexts counts as protected health information.
A few things worth flagging before we talk platforms:
- HIPAA exposure. If any of this data could be tied to an identifiable person seeking care, you’re likely in territory where standard ad-pixel/server-side setups (Meta CAPI, Google Ads conversion tracking, GA4 with default settings) have gotten providers into serious legal trouble with accompanying hefty fines. As you are building a form you need to understand what data you are sending and where it goes.
- This isn’t just a tooling choice. Before picking sGTM vs. Segment vs. Stape, the real first question is: what’s your BAA (Business Associate Agreement) situation, and has legal/compliance signed off on which destinations are allowed to receive which events? Google and Meta will not sign a BAA for their ad platforms. While Google signs for Cloud and Workspace in some cases they will not for GA4, Google Ads, or GTM, , meaning sending PHI-adjacent events (e.g., “user completed screening quiz”) to Meta CAPI or Google Ads could itself be a violation, regardless of client-side vs. server-side.
You want ad platforms to receive some signal so campaigns optimize, you want GA4 clean, but you can’t let PHI-adjacent data leak to Meta/Google in the process.
Here’s the architecture that fits all three goals.
- Server-side tag layer: Google Tag Manager Server-Side (sGTM), hosted via Stape
This is the piece that sits between your site and the ad platforms/GA4. Stape is the practical choice as it runs the sGTM container for you on managed infrastructure, so you’re not standing up GCP yourself. Stape will also sign a BAA, which matters more here than the convenience.
- The critical compliance layer: event scrubbing/allowlisting happens in sGTM, before anything reaches Meta or Google Ads
This is the actual point of doing this server-side for a healthcare site: you control precisely what leaves your server. Concretely:
- Page views on /condition or /treatment or quiz result pages, etc. are never forwarded to Meta CAPI or Google Ads conversion APIs, even in aggregate/hashed form. Condition-specific URLs and quiz answers are treated as PHI-adjacent regardless of hashing.
- Form submissions (insurance checker, “reach out,” admissions contact) are stripped of any field values (name, phone, condition selected, “policy holder” answer) before being sent anywhere. Only a generic “lead submitted” event with no identifying/condition payload goes to ad platforms.
- GA4 gets a fuller (stripped of form field values and condition-specific paths) event stream for internal analytics, ideally in a separate GA4 property, with IP redaction enabled on the server-side GA4 tag and granular location collection disabled and Google Signals off, since Google Ads/GA4 data sharing settings can otherwise leak this data back into ad audiences.
- Where PHI-adjacent data is allowed to flow: your CRM/EHR, not ad platforms
Full lead detail (who took the quiz, what they answered, insurance info) should route from the server-side layer to your CRM (Salesforce Health Cloud, HubSpot on Enterprise with the healthcare add-on (standard tiers aren’t covered), whatever intake system you use) under a signed BAA, not to Meta or Google, which won’t sign one for standard conversion APIs.
Where to start with Healthcare Data Compliance? With an audit of course!
Client-side tag inventory
- Pull the live GTM container and list every tag currently firing: Meta Pixel, Meta CAPI (if already partially set up), Google Ads conversion tag, Google Analytics/GA4, LinkedIn Insight, any retargeting pixels, chat widget scripts, form-analytics tools (Hotjar, FullStory, etc.)
- For each tag, check whether it fires on all pages or is scoped. Specifically check condition-specific URLs, quiz pages/results, or anything that infers condition/diagnosis content.
- Check if any tag captures the page title or URL path as an automatic parameter as even “generic” pageview pixels often pass full URL.
Form data capture
- For forms, inspect what’s actually submitted in the network payload (browser dev tools > Network tab, look at the POST request)
- Check if any field values (name, phone, “level of care interested in,” “I am the Policy Holder,” quiz answers) get passed into dataLayer events, URL parameters, or directly into a pixel call
- Check if Meta Pixel’s Automatic Advanced Matching or Google’s Enhanced Conversions is enabled as these auto-hash and send form field values (email, phone, name) without explicit tag configuration, which is easy to miss in an audit
Session/behavioral tools
- If Hotjar, FullStory, Clarity, or similar are running: check if session recordings/heatmaps capture the form fields un-masked. These tools often need explicit DOM-element masking rules for sensitive fields
- Check recording/heatmap tool’s data processing agreement as most consumer-analytics tools also won’t sign a BAA
Data sharing settings (not tags, but just as leaky)
- GA4/Google Ads linking: is “Google Signals” on? Is Ads Personalization on? These allow GA4 behavioral data to flow into ad audience-building even without a dedicated conversion tag
- Meta Business Manager: check if Automatic Advanced Matching is toggled on for the Pixel; check whether the account is flagged under Meta’s restricted health data categories and whether Limited Data Use is enabled
- Google Ads: check “Enhanced conversions for web” toggle and any imported audiences built from site behavior
Third-party leakage
- Any embedded widgets. Confirm what that vendor does with submitted data and whether they’re a BAA-covered subprocessor
- Any chat/live-chat widget: check if condition/page context gets passed into the chat session or forwarded to a marketing tool
Document this and establish roles/ownership! This is a critical piece. Ensure that legal/compliance has signed off on all endpoints. Review who has access to GTM at any level and lock it down based on whose actual role aligns to their level of access needed.
Keep the data flowing, but keep it safe. If you’re looking for marketing vendors with healthcare compliance standards look to Simple Search. If you’d like to discuss how we can put this to work for you, reach out!
Let’s Work Together!
