The Meta Conversions API is one of those things where the difference between a competent implementation and a sloppy one shows up directly in your CPA. I’ve been deep in CAPI audits for clients across e-commerce and lead-gen for the last 18 months and the same gotchas keep appearing. Here’s the practical list, ranked by impact.

Event match quality is the single biggest lever

Meta’s Event Match Quality (EMQ) score, surfaced in Events Manager, is a 1-10 score based on how well your events identify the user. Below 6, your CAPI events are basically being treated as anonymous traffic for targeting purposes. Above 8, you’re getting genuine matched-user benefit.

Most implementations I audit are sitting at 4-6. The fixes are not glamorous but they work:

• Send hashed email AND hashed phone, not just one
• Send first name, last name, city, state, postcode — these are weak signals individually but they compound
• Send the Click ID (fbc) and Browser ID (fbp) properly — these are the highest-value parameters and a surprising number of implementations send only one or neither
• Send external_id if you have a stable user identifier from your auth or CRM system

A move from EMQ 5 to EMQ 8 is typically worth a 15-25 percent improvement in attributed conversions. That’s a meaningful campaign performance lift from a tagging fix.

Deduplication done badly

CAPI is meant to fire alongside the Meta Pixel, not replace it. The deduplication is meant to handle the overlap. Done badly, you either lose events (overly aggressive dedup) or double-count (no dedup at all).

The deduplication relies on event_id and event_name matching across the pixel and CAPI events. The two events also need to fire within a reasonable time window (Meta’s documented as a few minutes but in practice tighter is better).

The most common failure: the event_id is generated differently between client-side and server-side, so the dedup never matches. Result: every conversion is counted twice, looks great in the Ads Manager, kills your downstream analytics.

The fix: generate the event_id once, on the page, and pass it identically to both the pixel call and the server-side CAPI call. Test by firing a known conversion and checking it appears once in Events Manager, not twice.

Timing and event firing order

CAPI events arriving 24+ hours after the conversion get heavily discounted by Meta’s attribution system. Real-time or near-real-time delivery (under 60 seconds) is what you want for purchase events.

The trap is batch-style implementations where the CAPI events are sent in a hourly or daily batch from your data warehouse. This works for offline conversions but is suboptimal for online events that the pixel could have caught in real time.

The right architecture for an e-commerce site is: pixel fires on page, CAPI event fires server-side from the order confirmation endpoint, dedup pairs them up. Anything more complex than that is usually over-engineered.

Custom data parameters most people miss

Beyond the user_data block, the custom_data block carries the conversion details. The standard parameters (value, currency, content_ids, content_type) most implementations get right. The ones that get missed:

• content_name and content_category — useful for catalog ads optimisation
• num_items — Meta’s models use this for AOV signals
• order_id — needed for the deduplication-by-order-id pattern
• delivery_category — relevant if you have a meaningful pickup/delivery split

Sending richer custom_data isn’t a tax — it improves the model’s ability to optimise. There’s no downside.

Test events and validation

Meta Events Manager has a Test Events tool that’s underused. You can fire test events with a test event code and see exactly what arrived, what was matched, and what was thrown out. Building a regression suite of test events that runs after every deployment catches CAPI issues before they hit production.

The other validation tool that gets ignored is the Diagnostics tab in Events Manager. It surfaces specific events with specific issues — missing parameters, low EMQ events, deduplication mismatches. Most teams don’t look at it.

Server-side identity assembly

This is the harder problem. CAPI events fire server-side, which means the server needs access to all the user_data parameters. Your server probably has the email and the order details, but it might not have the fbp/fbc cookies (which live in the browser) or the click ID.

The pattern that works: the page fires a request to your own backend (not directly to Meta) that includes the fbp, fbc, and any other client-side identifiers. Your backend assembles the full user_data block and forwards to Meta CAPI. The pixel fires in parallel with the matching event_id.

Skipping the fbp/fbc handoff is the single most common reason EMQ scores stay in the 4-5 range.

Privacy and consent

Meta requires you to respect user consent and pass the appropriate opt_out and consent fields. If you’re operating in jurisdictions with consent requirements (Europe is the obvious one but Australia is heading the same direction with the Privacy Act amendments), you need to integrate your consent management platform with the CAPI calls.

Sending CAPI events for users who have opted out is a compliance risk and Meta will increasingly penalise it. Sending events with the wrong consent status is similar.

Data sources that aren’t the website

CAPI also accepts offline conversion uploads, CRM events, and physical store events. Most teams use it only for website events and miss the model improvements that come from feeding richer signal.

If you’re a B2B lead-gen business, sending CAPI events for SQL conversion (lead became sales-qualified) and won deal events feeds the model with downstream conversions Meta would otherwise never see. The match-back relies on email or phone, which means the EMQ work pays off here too.

If you’re a brick-and-mortar retailer, in-store transactions matched back to the originating online interaction are a strong signal that purely online attribution misses.

What I’d audit this week

Pull your Events Manager, look at the Diagnostics tab, look at your EMQ scores by event. Check the deduplication rate (it should be around 80-95 percent for events you’re firing both via pixel and CAPI). Identify which parameters you’re missing and prioritise the fixes by event volume.

If you’ve got the time and budget for one improvement, it’s almost always EMQ. The compound effect of adding fbp/fbc, a better identity payload, and more user parameters lifts performance more reliably than any other single CAPI fix. Meta’s own documentation is decent but reads like reference material — the practical “what should I actually do” framing is missing.

Done well, CAPI delivers measurable performance lift. Done badly, it’s a tax on engineering time with no return. The difference is mostly in the details I’ve outlined above.