Meta Conversions API consultant: server-side and premium matching

Meta Conversions API (CAPI) is the official server endpoint for sending conversions to Meta — the path that no longer depends on browser cookies, so survives Safari ITP, ad blockers, and Consent Mode v2. A clean CAPI deployment requires three things: events sent from the server (ideally via sGTM), SHA-256 hashing of user data (email, phone, name), and strict event_id dedup with Meta Pixel client-side conversions. Without all three, matching stays mediocre and the Meta algo learns poorly. Meta CAPI standalone fee: €3,800 for ~6 days, or bundled in the full sGTM at €6,500.

Why the Meta Pixel alone is no longer enough

Three forces making the client-side Meta Pixel increasingly unreliable.

Safari ITP. The most important browser on premium mobile (iPhone) blocks Meta third-party cookies and shortens first-party Meta cookie lifetime. On a site with 35% Safari iOS traffic, that’s mechanically 10-15% Meta conversions lost without server-side push.

Ad blockers. uBlock, AdBlock Plus, Ghostery, Brave block requests to facebook.com and connect.facebook.net. Depending on sector (tech: 25%+, generalist: 5-8%), client-side pixel never reaches Meta.

Consent Mode v2 and user refusal. When the user refuses marketing cookies, the Meta Pixel is blocked and the conversion is lost. Server-side CAPI with server data consent (which the user can accept even when refusing front-end cookies) recovers part of the conversions.

Three pillars of clean CAPI deployment

Pillar 1 — Server-side via sGTM

The Meta client pixel still exists (for cookie retargeting, Safari attribution when consent accepted). CAPI server-side is added in parallel for conversion events (Purchase, Lead, InitiateCheckout, AddToCart).

Architecture: browser sends event to sGTM (your own subdomain), sGTM transforms and sends to Meta CAPI. Event carries event_id, event_time, event_source_url, hashed user_data, custom_data (value, currency, items).

Technical detail in sGTM consultant.

Pillar 2 — SHA-256 PII hashing

Meta requires user data (email, phone, first name, last name, city, postal code, country) be SHA-256 hashed before sending. Hashing must happen server-side, never client-side in clear text — otherwise PII transits unhashed and that’s a GDPR violation.

Implementation: browser sends already-computed hash to sGTM, OR sGTM receives email in clear text via HTTPS and hashes itself before transmitting to Meta. The second option is generally simpler and allows re-hashing if Meta changes its spec.

Fields to hash: em (email), ph (phone E.164), fn (first name), ln (last name), ct (city), st (state/region), zp (postal code), country. Plus external_id if you have a stable user identifier.

Pillar 3 — Strict event_id dedup

The Purchase event is sent twice (browser pixel AND server CAPI). Without a common event_id, Meta counts twice. Dedup relies on a unique event_id per transaction, shared between client and server.

Typical implementation: the business transaction_id (Shopify order ID, HubSpot lead ID) serves as event_id. Pushed in dataLayer client-side, read by Meta client pixel (parameter eventID), read by sGTM for CAPI push (parameter event_id). Meta auto-deduplicates when both events share the same event_id.

Validation: Business Manager → Events Manager → your pixel → Test events. You should see the event arrive once “Browser” + once “Server”, marked “Deduplicated”.

Measuring CAPI quality

Meta provides Event Match Quality (EMQ) in Events Manager — a score from 1 to 10 per event. Target: EMQ above 8/10 for good matching and proper algo optimization.

EMQ	Interpretation	Action
9-10	Excellent	Maintain, monitor stability
7-8	Good	OK for most cases, optimization possible
5-6	Fair	Abnormal, audit needed
1-4	Poor	Critical, CAPI is mis-wired

On my missions, the target is EMQ between 8 and 10. If audit reveals Fair or Poor on a site that thought it was OK, it’s typically one of three problems: hashing missing or wrong, dedup absent, or fbc/fbp not transmitted from client to server.

Frequently asked questions

Is CAPI mandatory?

Not legally, but operationally indispensable. Without CAPI, you lose 15-30% Meta conversions in most sectors. Meta algo no longer optimizes, measured CPA explodes, budgets shrink, business loses.

Keep Meta Pixel client-side in parallel?

Yes, for two reasons: the client pixel sends fbc (Facebook Click ID) to sGTM, which transmits to CAPI for matching; and Custom Audiences retargeting cannot be exclusively server-side.

GDPR allows sending this data to Meta?

Yes, with explicit user consent (marketing category) and PII hashing. Meta DPA must be signed. For European sites, also audit international transfers with your DPO.

Other platforms (TikTok, Pinterest, LinkedIn, Microsoft)?

All have server Conversions APIs. TikTok Events API, Pinterest Conversions API, LinkedIn Conversions API, Microsoft UET server-side. Same method: server-side via sGTM, PII hashing, client-side dedup.