A treatment center we work with reached out last quarter with a request that captures the most common misunderstanding in this space. Their paid social agency had told them to “just turn on CAPI” to solve their HIPAA exposure.
The implication was that the server-side API was inherently more compliant than the browser pixel.
That is the wrong framing. Turning on Conversions API without the rest of the Meta tracking architecture moves the same protected health information through a different channel.
The exposure stays the same. In some configurations, server-side transmission carries fewer browser-level privacy constraints, which makes the exposure worse rather than better. HHS Office for Civil Rights guidance on tracking technologies applies regardless of which API delivers the event.
Meta does not sign Business Associate Agreements for either the browser pixel or the Conversions API. The compliance does not come from which API the program uses.
The compliance comes from what data the API receives, what BAA-covered intermediary processes it before transmission, and how Event Match Quality is maintained without sending PHI.
CAPI is not a HIPAA solution by itself. The compliance comes from what data is sent, not which API sends it.
Mitch Marowitz, Director of Paid Admissions, Webserv
This guide walks through what Conversions API actually is, why a direct CAPI implementation is not HIPAA-compliant by itself, the three pathways for compliant implementation, and the specific event parameters and Event Match Quality patterns that produce a working setup.
Key Takeaways
- Meta Conversions API (CAPI) is not a HIPAA solution by itself. Meta does not sign Business Associate Agreements for CAPI any more than for the browser pixel — the compliance comes from what data is sent, not which API sends it.
- The recommended implementation pathway routes events through a HIPAA-compliant intermediary platform (Freshpaint, Piwik PRO, Matomo) that signs a BAA, strips PHI from event payloads, and forwards de-identified events to Meta via CAPI on behalf of the advertiser.
- Event parameters are where most CAPI implementations succeed or fail compliance review. URL paths referencing health conditions, custom_data form content, and unhashed user identifiers must always be stripped. Hashed email and phone are technically supported but carry residual PHI exposure that most treatment centers should avoid.
- Event Match Quality (EMQ) is the trade-off. Compliant treatment center implementations typically operate at EMQ 5 to 7 versus 7+ in non-regulated verticals. Operators who push for higher EMQ at the expense of HIPAA architecture are the ones who end up in the suspension or audit category 18 months later.
What Conversions API actually is
Conversions API (CAPI) is Meta’s official server-side tracking pathway. It exists in part because the browser pixel has become unreliable across iOS privacy updates and ad blockers, and in part because server-side tracking gives advertisers more control over what data is transmitted to Meta.
The technical mechanics are straightforward. The advertiser’s server (or a third-party service) sends conversion event data to Meta’s CAPI endpoint via a structured POST request.
The payload includes the event name, the event timestamp, and a set of user identifiers that Meta uses to match the event to a Facebook or Instagram user.
The user identifier set is what makes the architecture sensitive. CAPI accepts hashed email, hashed phone, hashed first name, hashed last name, IP address, user agent, click ID (fbc), and browser ID (fbp).
Meta uses these to construct an Event Match Quality (EMQ) score that determines how reliably the event is attributed to a known user.
The hashing is one-way, but the underlying identifiers are still PHI when combined with a behavioral health context. Sending hashed PHI to Meta is the same compliance issue as sending unhashed PHI, because the BAA gap exists regardless of the encoding.
Why CAPI alone is not a HIPAA solution
Three specific compliance issues persist with a direct CAPI implementation that is not routed through a HIPAA-compliant intermediary.
Meta still does not have a BAA in place. The Conversions API is a Meta product. Meta has not signed Business Associate Agreements for any of its advertising APIs, and there is no current path to obtain one.
A treatment center sending event data directly to Meta’s CAPI endpoint is sending regulated data to a non-covered entity. The HIPAA exposure is identical to the browser pixel exposure.
Event parameters can carry PHI. A direct CAPI implementation that sends URL paths in the event_source_url parameter or page-context data in custom_data fields is transmitting the same PHI as a browser pixel firing on a behavioral health page. The transmission method changed. The data did not.
User parameters carry PHI when combined with health context. Hashed email and hashed phone are PHI in the context of a substance use disorder treatment center. The hashing is reversible at scale by anyone with access to enough source data.
More importantly, the combination of a hashed identifier with the implicit context (this user converted on a treatment center site) is itself protected health information.
The compliant pattern requires that PHI never reach Meta in the first place, regardless of which API delivers the event.
The three implementation pathways
Three implementation pathways exist for CAPI in a HIPAA-compliant treatment center setup. Each has trade-offs, and they parallel the same architecture decisions on the Google Ads side of conversion tracking.
Pathway 1: HIPAA-compliant intermediary platform. This is the recommended pathway for almost every treatment center.
Platforms like Freshpaint, Piwik PRO, and Matomo sign BAAs and operate as a server-side intermediary that ingests conversion events from the website, strips PHI, and forwards de-identified events to Meta via CAPI.
The platform handles event hashing, parameter mapping, and deduplication on behalf of the advertiser. The cost runs $1,500 to $3,500 per month for most behavioral health programs.
Pathway 2: Server-side Google Tag Manager with custom logic. A custom server-side GTM container can be configured to intercept conversion events, strip PHI, and forward to Meta via CAPI.
The setup requires engineering work, including custom server-side templates, parameter scrubbing logic, and deduplication handling. The implementation typically takes 4 to 8 engineering weeks to build correctly.
The ongoing maintenance cost is real because Meta updates CAPI specs every quarter or two.
Pathway 3: Fully custom server-side implementation. A development team can build a custom server that receives website events, processes them, and transmits to Meta via CAPI directly. The pathway is technically valid.
It is also rarely worth the engineering investment for a single-platform paid social account. Custom builds are common at programs that have engineering teams already managing other infrastructure and that want to centralize event handling across multiple advertising platforms.
For most treatment centers, Pathway 1 is the right choice. The HIPAA intermediary platform is a known, validated solution that integrates with the rest of the marketing stack. The other pathways exist for programs with specific engineering needs that the standard platforms do not meet.
How the HIPAA intermediary pathway actually works
The implementation through a HIPAA-compliant intermediary follows a consistent pattern across vendors.
Step one: install the intermediary’s tracking script on the website. The script replaces the browser-side Meta pixel. The script collects event data in the same way the pixel did, but transmits it to the intermediary’s BAA-covered infrastructure rather than to Meta directly.
Step two: configure event mapping. Inside the intermediary’s interface, map each website event (page view, form submission, phone click) to its corresponding Meta CAPI event. Standard events like Lead, ViewContent, and Contact map cleanly. Custom events require deliberate mapping decisions, which is where most implementation errors happen.
Step three: define what data is forwarded versus stripped. The intermediary’s PHI handling rules need to be configured deliberately. URL paths that reference health conditions get stripped.
IP addresses get either hashed or removed depending on the intermediary’s BAA terms. Form field content is never forwarded. The configuration is the compliance layer, and it has to be reviewed by someone who understands HIPAA.
Step four: connect the intermediary to Meta via CAPI. The intermediary handles the actual server-to-server transmission to Meta. The advertiser provides Meta credentials (Pixel ID and access token) and the intermediary builds the CAPI payload using the de-identified event data.
Step five: validate the implementation through Meta’s Events Manager. Meta provides a CAPI test mode that shows incoming events without affecting attribution. Use the test mode to confirm that the events Meta is receiving contain only de-identified data and that no PHI is appearing in the payload.
The full setup takes 2 to 4 weeks for a program with cooperative IT and a clean website. Programs with complex tracking accumulation often take 6 to 8 weeks because the cleanup of the existing pixel implementation runs alongside the new build.
Event parameters: what to send and what to strip
The event parameter layer is where most CAPI implementations succeed or fail compliance review.
Server-side parameters that should be transmitted. Event name (Lead, Contact, ViewContent, etc.). Event time. Hashed click ID (fbc) when available. Hashed browser ID (fbp) when available. Action source set to “website.” Currency and value when applicable, calculated from non-PHI sources.
User parameters that need careful handling. Hashed email and hashed phone are technically supported by CAPI but carry the PHI exposure described earlier.
The compliant pattern hashes only after the email or phone has been collected via a BAA-covered intake form, and forwards the hash only with the patient’s documented consent.
Most treatment centers should not transmit user identifiers at all in CAPI events. The Event Match Quality cost of omitting them is real but the compliance benefit is larger.
Parameters that should always be stripped before transmission. event_source_url containing health-condition paths. custom_data fields containing form content. user_data fields containing unhashed identifiers. Any parameter that encodes patient demographic, clinical, or insurance information.
Parameters that need verification on every implementation. The fbc and fbp parameters are not PHI by default, but they become PHI when paired with a behavioral health context.
Their inclusion is a judgment call that depends on the program’s HIPAA risk tolerance and the BAA terms with the intermediary platform.
The general rule: send the minimum data required for Meta to attribute the event, route everything through the BAA-covered intermediary, and verify in Meta’s Events Manager that no behavioral-health-specific data is appearing in the received events.
Event Match Quality without PHI
Event Match Quality (EMQ) is Meta’s score for how reliably an event can be attributed to a known Facebook or Instagram user. Higher EMQ correlates with better campaign optimization. Standard CAPI implementations target EMQ scores of 7 or higher on Meta’s 1-to-10 scale.
Treatment center implementations that strip PHI from event payloads typically operate at lower EMQ than non-regulated verticals. The trade-off is real. The mitigation is also real.
EMQ levers that work without transmitting PHI. Click ID (fbc) and browser ID (fbp) when available add meaningful EMQ without adding PHI exposure. Action source and event source both contribute. Event timestamp accuracy matters. Adding these parameters consistently raises EMQ even without user-identifier data.
EMQ levers that require transmitting PHI. Hashed email, hashed phone, and hashed first name are the highest-impact EMQ contributors. Including them increases EMQ but requires the compliance evaluation described in the prior section.
The practical EMQ target for treatment centers. Most behavioral health programs operate at EMQ 5 to 7 with PHI stripped.
The optimization performance is real but slightly lower than non-regulated verticals. Most operators find that the campaigns still produce admits at workable cost when the EMQ is in this range.
The EMQ trade-off is fundamentally a choice between optimization performance and compliance. Operators who push for higher EMQ at the expense of HIPAA architecture are typically the ones who end up in the suspension or audit category 18 months later.
How Profound Treatment drove 31 admits and a 42% drop in cost per viable in one quarter
Broad match pivot, negative keyword management, and intake-level conversion tracking turned a fragmented paid strategy into a predictable admissions engine.
Read the case study →68 viable VOBs at $4,529 cost per viable
Browser pixel deduplication
Programs that run both the browser pixel and CAPI in parallel need to handle event deduplication. Meta uses event_id and event_name combinations to identify duplicate events arriving from both pathways and counts them only once.
The deduplication logic requires consistent event_id generation across both transmission methods. The intermediary platform handles this when configured correctly. Direct implementations need to assign event IDs in the website code and pass them through both the pixel and the CAPI payload.
The compliant pattern for treatment centers is usually to remove the browser pixel entirely and rely on CAPI through the intermediary. This eliminates the deduplication concern and removes a potential PHI transmission pathway in one decision.
Some implementations keep a stripped-down browser pixel for Meta’s automated event matching, but only after the pixel has been audited to confirm it is not transmitting URL paths or form content. The audit takes 30 minutes per page using browser network tools. The audit is not optional.
Testing and verification
Three verification steps confirm that a CAPI implementation is operating compliantly.
Verification one: Meta Events Manager test mode. In the Events Manager, enable test events for the relevant Pixel ID. Trigger conversions on the live website.
Confirm that the events Meta receives contain only the de-identified parameters described above. Specifically check the event_source_url field and any custom_data or user_data parameters for PHI leakage.
Verification two: browser network tab review. Open Chrome DevTools or Firefox Developer Tools, go to the Network tab, and load behavioral-health-specific pages on the website.
Filter the network traffic for facebook.com and meta.com endpoints. Confirm that no traffic is going directly to Meta with PHI in the payload. If the implementation is correct, the only Meta-bound traffic should be from the HIPAA-compliant intermediary.
Verification three: intermediary platform audit. Log into the HIPAA-compliant intermediary platform and review the events being forwarded to Meta.
Most platforms provide a log or dashboard showing the exact payload structure of outgoing CAPI events. Verify that the payload structure matches the compliance specification and that no PHI is being transmitted.
These verification steps should be performed on initial implementation and quarterly thereafter, because tracking implementations drift over time, especially when websites are updated, agencies change, or new platforms are added to the marketing stack. Quarterly verification catches drift before it accumulates into compliance exposure.
What to ask your paid social partner this week
Three questions surface whether a paid social partner is operating with a HIPAA-compliant CAPI implementation. Ask all three.
First, ask whether the program’s CAPI implementation routes through a HIPAA-compliant intermediary platform with a signed BAA. If the answer is “we send events to Meta directly through the API” or “we use server-side GTM without BAA coverage,” the setup is non-compliant.
Second, ask the partner to demonstrate the event payload that Meta is currently receiving. If the partner cannot pull a sample event payload from the Events Manager test mode, they are not operating with the visibility a compliant setup requires.
Third, ask what user_data parameters the implementation sends. If the answer includes hashed email or hashed phone without a documented PHI handling protocol, the program needs to evaluate whether that EMQ benefit is worth the HIPAA exposure it creates.
CAPI is the right pathway for treatment center Meta advertising. The implementation pattern that produces a compliant setup is specific.
The shortcut version that just enables CAPI in Meta’s interface and assumes the rest is handled produces the same legal exposure as the browser pixel did, with a cleaner-looking interface obscuring the underlying problem.
The fix is closeable in a quarter, and the foundation it builds is what every other Meta advertising optimization gets to stand on.
The perspective in this article comes from 9 years working exclusively inside behavioral health.
We are a team built by people in recovery who understand that behind every admission is someone asking for help. If that resonates, get to know us.
Mitch Marowitz is the Director of Paid Admissions at Webserv. Webserv works with behavioral health and addiction treatment centers on SEO, paid media, and full-funnel admissions strategy.
