Set up the Meta Conversions API (CAPI) -
GDPR-compliant server-side tracking

The Meta Conversions API is a server-to-server interface that sends conversion events directly from your server to Meta - instead of from the user's browser like the Meta Pixel does. The Pixel is client-side and is routinely blocked by ad blockers, Safari ITP, and iOS privacy controls. CAPI runs server-side and is largely immune to those. In practice you run both in parallel: the Pixel for browser-side signals, CAPI as the robust, blocker-resistant source. Meta reconciles the two sources through deduplication.

Yes. CAPI does not replace the Pixel, it complements it. Meta explicitly recommends running the Pixel and Conversions API in parallel for maximum redundancy and the best match quality. The Pixel provides browser-side signals such as automatic parameters and click IDs, while CAPI provides server-side resilience against blocking. The one critical requirement is that both sources send the same event with an identical event_id, so Meta does not double-count. That deduplication is the single most common point of failure in self-built setups.

CAPI can be operated in a GDPR-compliant way, but it is not compliant automatically. Server-side tracking does not bypass any legal basis: even through CAPI, personal data may only be processed with valid consent. Three things matter: effective cookie consent (coupled to Consent Mode v2), hashing all personal identifiers before they are sent, and a data processing agreement with Meta. We set CAPI up so consent is enforced server-side. This is an engineering assessment, not legal advice.

Yes. A common misconception is that server-side tracking makes the consent banner unnecessary. It does not. Germany's TDDDG requires consent before accessing device information, and the GDPR requires a legal basis for processing personal data - regardless of whether the data is sent from the browser or the server. When a user declines, CAPI must not transmit personal conversion data to Meta. Done correctly, your server setup respects the consent state and only sends what is permitted.

Event Match Quality (EMQ) is Meta's measure of how well your sent events can be matched to a real Meta user account - on a scale of 1 to 10. Scores of 8 to 10 are rated 'Great', 5 to 7 'Good'. A perfect 10 is extremely rare according to Meta; 8 to 9 is the realistic ceiling, achieved by sending eight or more hashed identifiers per event (email, phone, name, IP, click ID, and more). Higher EMQ means better matching and therefore more efficient delivery. Per Meta research cited by WeltPixel, advertisers who improved EMQ saw roughly 15 to 25 percent better cost per action.

Meta deduplicates Pixel and CAPI events that share the same event_name and the same event_id within an approximately five-minute window. When the second event arrives, Meta typically keeps the browser-side Pixel event and discards the duplicate server event. For this to work, both sources must send the identical event_id for the same event. Without a shared event_id, Meta counts every conversion twice, your numbers inflate, and bidding optimizes on false data. Clean deduplication is the technical core of any serious CAPI setup.

There are three common paths. Direct API integration: your backend calls the Conversions API itself - maximum control, highest development effort, ideal for custom stacks. Server-Side GTM (sGTM): a dedicated tag-manager container runs on your infrastructure, receives browser events, and distributes them to Meta, GA4, and more - flexible, multi-channel, our preferred path for data ownership. Gateway solutions (such as Stape): hosted services that make CAPI quick to set up but route data through a third party. The right choice depends on data residency, budget, and your existing stack - we recommend vendor-neutral, not product-driven.

On Shopify there are two paths: the native Meta integration via the Facebook & Instagram sales channel, which enables CAPI without code, or a server-side GTM setup for full control over deduplication, EMQ, and consent. The native option is fast but limited for custom events and match optimization. On WooCommerce you use either the official Facebook for WooCommerce plugin or an sGTM integration. For stores with meaningful ad spend, the server-side route almost always pays off, because it puts EMQ and deduplication in your hands instead of leaving them to a black box.

A native Shopify activation is done in a few hours but only delivers the basics. A clean server-side setup with a dedicated GTM container, correct deduplication, EMQ optimization, Consent Mode coupling, and QA in Events Manager typically takes one to three weeks depending on complexity. Most of the time goes not into sending events but into validation: test events, reconciliation against store orders, and closing double-counting. That is exactly where the difference between 'CAPI is running' and 'CAPI measures correctly' is made.

Yes. As soon as you transmit personal data to Meta - and hashed emails or phone numbers are personal data - a data processing agreement under Article 28 GDPR is required. Meta provides corresponding data processing terms that must be accepted. In addition, processing via the Meta Pixel and CAPI belongs transparently in your privacy policy. This is an engineering assessment, not legal advice - the final evaluation belongs in the hands of your data protection officer or lawyer.