Table of content
Your shop records sales that Meta Ads never sees? The Meta Pixel runs in the browser and loses part of its signals to Apple's restrictions, browsers and ad blockers. The result: the algorithm optimises on a partial picture, and you may switch off campaigns that are actually profitable. Here is how we deploy the Meta Conversions API (CAPI) server-side with Google Tag Manager and Stape.
In short
Meta CAPI sends your events from a server, alongside the Pixel, with a shared event_id for deduplication.
A server-side GTM container on your own subdomain (for example data.your-brand.ch) acts as a first-party collection point and filter.
Event Match Quality (EMQ) depends mainly on the customer data you send, hashed with SHA-256.
Server-side is not a workaround: without consent, nothing goes to Meta.
Why the Meta Pixel alone is no longer enough
For years, a simple JavaScript snippet was enough to report purchases and retarget visitors. This client-side tracking, running in Chrome or Safari, now depends on too many factors you do not control.
iOS, ITP and ad blockers: three kinds of signal loss
App Tracking Transparency (iOS 14.5, April 2021): apps, including Facebook and Instagram, must ask permission to track users across apps. Every refusal reduces the signals available for attribution.
Safari's Intelligent Tracking Prevention (ITP): Safari blocks third-party cookies and caps first-party cookies set by JavaScript at 7 days (24 hours in some link-tracking cases). A customer who clicks on Monday and buys ten days later is no longer tied to the ad.
Ad blockers: according to GWI (Q2 2025), 30.9% of Swiss internet users run one. Extensions such as uBlock Origin or browsers such as Brave often prevent
fbevents.js, the Pixel script, from loading.
The cost of incomplete measurement
An algorithm that learns less well: Meta optimises delivery based on the conversions it sees. Fewer signals mean less precise targeting.
Weaker lookalike audiences: Lookalikes are built on your recent buyers. If some are missing, the seed audience is distorted.
Understated ROAS: you may cut a profitable campaign because Ads Manager does not show every sale.
The solution: Meta CAPI server-side with Stape
With the Conversions API, the browser is no longer the only one talking to Meta: your server passes the events on, server to server. We use a server-side Google Tag Manager container (sGTM) hosted with Stape, with a server in Europe.
How it works, in two steps
First-party collection: the browser sends events (page view, add to cart, purchase) to your own subdomain, which points to the server container.
Controlled distribution: the container checks consent, strips unnecessary data, hashes customer data and then passes the event to the Meta API. Without the visitor's consent, the event is not sent.
The custom subdomain
We set up a custom domain (for example data.your-brand.ch). Requests stay on your domain: collection is first-party, more resilient to technical restrictions, and cookies set by your server can escape the 7-day cap on JavaScript cookies. The condition: the server must share the website's IP address, otherwise Safari applies the cap too (WebKit, 2023). A subdomain never legitimises a call the visitor has refused.
CAPI Gateway or server GTM?
Meta also offers the Conversions API Gateway, which Stape can host. It is quick to set up and deduplicates automatically, but it only serves Meta and simply mirrors Pixel events. We prefer server GTM as soon as several platforms are involved: the same container feeds Meta, GA4, Google Ads, TikTok or Klaviyo, with fine control over the data sent. Bundling calls on the server also means fewer third-party scripts on the page, which can lighten loading. One strict rule: a single server source per Meta dataset, never Gateway and sGTM side by side for the same events.
Setup by CMS
Meta CAPI is not a magic button. Meta expects structured data, customer information hashed with SHA-256 and deduplicated events.
1. The universal rule: deduplication
Meta recommends using the Pixel and the Conversions API together (Meta documentation). To avoid counting a purchase twice, we generate a unique event_id in the browser and pass it to both the Pixel and the server, with the same event name. Meta keeps a single event if both arrive within 48 hours.
2. WordPress and WooCommerce
We set up a reliable e-commerce dataLayer on WordPress and WooCommerce (Stape plugin, GTM4WP or a custom build).
Web GTM routes
view_item,add_to_cartandpurchaseto the server subdomain.In sGTM, Stape's Facebook Conversions API tag receives value, currency and product IDs.
3. Shopify
On Shopify, checkout tracking runs through Customer Events, pixels executed in an isolated environment.
We use the Stape app for Shopify or order webhooks: the purchase is sent from the back office, even if the customer closes the browser before the thank-you page.
Watch out: the consent state must travel with the order, so the server knows whether it may send it to Meta.
A detailed comparison is in our article Shopify vs WooCommerce server-side.
4. PrestaShop and custom sites
For PrestaShop or a site built in React, Vue.js or PHP, we standardise the dataLayer with your developers.
Customer data (email, phone, first name, postcode) is collected at checkout and hashed in the server container: this is the main lever for Event Match Quality (EMQ).
5. Wix
Wix's native integrations remain basic and offer little control for compliance. Through GTM and the Stape app for Wix, we take back control of the flow and of the user_data parameters.
The Stape options we enable
Ticking "API" is not enough. Two Stape options make measurement more stable, always within the limits of consent.
Custom Loader: GTM loads from your own domain rather than a third-party one, so collection is first-party end to end. Marketing tags still depend on the visitor's choice: a refusal is still a refusal.
Cookie Keeper: Stape keeps certain first-party identifiers (for example
_fbpand_fbc) and restores them when the browser deletes them, which helps attribution over long sales cycles (real estate, B2B, luxury). It does not work inside Shopify's isolated environment.
FADP and GDPR compliance: the server as a filter
Since 1 September 2023, the revised FADP requires transparency and proportionality; in the EU, the GDPR and the ePrivacy Directive require prior consent for advertising tracking. Transfers to the United States are covered by the Swiss-U.S. Data Privacy Framework since 15 September 2024 (EU-U.S. DPF: 10 July 2023), for certified recipients.
Server-side is not automatic compliance, but a control point:
Consent enforced on the server: the Meta tag in the container only fires with the visitor's marketing consent. Without consent, no event reaches Meta.
Data minimisation: even with consent, the container strips unnecessary parameters (PII in URLs, form fields) before sending.
Hashing: email and phone are hashed with SHA-256 before sending, as Meta requires (Meta customer information parameters). Hashing is not encryption: the data remains personal, pseudonymised data.
Hosting in Europe: useful, but not enough on its own, since Meta is still a recipient. Mention it in your privacy policy.
A-Track tip
Reject everything in the banner, place a test order and follow it in the server container preview. No request should go to Meta. Then accept: the purchase should appear exactly once in Events Manager, with the same event_id on the browser and server side.
The full framework is in our FADP and GDPR compliance guide.
What you can measure after go-live
We do not promise a percentage of "recovered" data: it depends on your audience, consent rate and CMS. We measure before and after, over two to four weeks either side of the deployment, on verifiable indicators:
The gap between back office and Meta: purchases recorded by the shop compared with purchases attributed in Events Manager.
Event Match Quality: the score out of 10 for your purchase events, which rises with the quality of customer data sent.
The deduplication rate: the share of events received twice and correctly merged.
The learning phase: with more complete conversions, ad sets more easily reach the volume Meta needs to exit learning.
Audience stability: abandoned-cart and visitor lists filling up again.
For the basics of the Conversions API in e-commerce, see also our Facebook CAPI guide.
Conclusion: where to start
Measure today's gap between your back office and Meta over 30 days.
Choose the architecture: Gateway if Meta is your only channel, server GTM as soon as several platforms are involved.
Deploy with event_id, a first-party subdomain and a consent filter, then rerun the refusal test after every website update.
Do your Pixel and CAPI report each purchase exactly once?
A-Track measures the gap between your back office and Events Manager, then checks event_id deduplication, EMQ and the consent filter.
Get a free tracking and compliance audit, delivered within 48 hours.