Meta CAPI for Finance & Insurance: A Compliance-Safe Setup Guide
If you run ads in finance or insurance, someone has probably told you to “set up CAPI” and then left you to it.
The good news: it’s not conceptually hard. The pixel reports from the browser, the Conversions API reports from your server, and the two get matched up so nothing gets counted twice. That’s the whole idea.
The catch is that most CAPI tutorials are written for ecommerce, and in a regulated vertical a couple of those instructions will actively get you in trouble. Sending the wrong thing to Meta here isn’t just a bad setup. It’s a privacy problem with your name on it.
Here’s how I build it.
Pick your install honestly
Three real options, and the right one depends less on sophistication than on how custom your funnel is.
A partner integration is the fastest path if one genuinely exists for your stack. It’s also the least flexible, and in lead gen it often can’t send the downstream outcome you actually care about.
Server-side GTM gives you real control without writing much. It’s a good middle ground, and a lot of teams land here.
A direct server-side implementation is what I use most, because lead-gen funnels are almost always custom and I want to decide exactly what gets sent. It’s more work up front and it never surprises you later.
There’s no prize for the complicated one. Pick the simplest option that can still send your real outcomes.
What to send
For each conversion, send the event name, an event_id, a timestamp, the action source, and your user data. The user data is what makes or breaks it: email, phone, first and last name, city, state, ZIP, country, plus the fbp and fbc cookies and the client IP and user agent.
Normalize before you hash. Trim and lowercase the email. Strip the phone to digits with country code. Then SHA-256. Get the normalization wrong and the hash simply won’t match, and nothing will tell you, your match quality will just sit there looking mediocre.
What never to send
This is the part the ecommerce tutorials won’t warn you about.
Never send raw personal data. Hash it on your server, always, before it leaves. If raw emails are going out over the wire, that’s not a tracking setup, that’s an incident waiting to be discovered.
And be careful what you put in custom data. It’s tempting to pass along helpful detail: the loan type, the coverage they asked about, a health condition from the form, the debt amount. Don’t. You’re in a category where information about someone’s health or financial situation is exactly the thing you should not be shipping to an ad platform as event metadata. Send the outcome and the value. Not the story.
What it costs you
A single sloppy custom-data field can turn a routine tracking build into a privacy disclosure problem, in the one vertical where regulators are actually paying attention.
Deduplication, or you’ve made things worse
Now that both the pixel and the server are reporting the same conversion, they have to agree. Generate one event_id per conversion, send it on both, and keep the event names identical, including case. Lead and lead are two different events to Meta.
Skip this and you’ve just doubled your reported conversions and taught the algorithm to chase a number that doesn’t exist. A CAPI install without deduplication is worse than no CAPI install.
Consent isn’t optional here
Gate the whole thing behind consent, and make the server honor it, not just the browser. This trips people up: the browser pixel respects a cookie banner naturally, but your server-side events will happily keep firing unless you explicitly carry the consent state through to them.
If someone declines, the server should stay quiet too. That’s the whole point.
Validate it, don’t assume it
Open Test Events in Events Manager and run a real conversion through your funnel. You want to see the event arrive from both browser and server, matched, counted once. Then check your deduplication rate over the next couple of days and your match quality after 48 hours.
“It’s installed” and “it’s working” are different claims. I’ve lost count of the accounts where somebody installed CAPI, never validated it, and it had been silently dropping events for months.
What I’d do: Install the simplest option that can carry your real outcomes, hash everything server-side, keep sensitive detail out of custom data, share one event_id across both sources, carry consent through to the server, and prove it in Test Events before you call it done.
If you’d rather find out what’s wrong with the current setup first, the free score takes about three minutes and needs no account access.
Common questions
Do I still need the pixel if I have CAPI?+
Yes. Run both. The pixel catches browser context the server does not have, and CAPI catches what the browser blocks. The two get deduplicated with a shared event_id so each conversion counts once.
Is sending customer data to Meta through CAPI a privacy problem?+
Not if you do it properly. Personal data must be normalized and SHA-256 hashed before it leaves your server, so Meta never receives raw emails or phone numbers from you. What you must not do is send sensitive detail about a person’s health or finances as event data, and you should gate the whole thing behind consent.
What is the easiest way to install CAPI?+
A partner or platform integration is the fastest if one exists for your stack. Server-side GTM offers more control. A direct server-side implementation gives you the most control and is what I use when the funnel is custom, which in lead gen it usually is.
Find out which of these are true for your account.
Get your Tracking 100 score in about three minutes. No account access.