Server-side conversions: Meta CAPI, GA4 and deduplication in your store

You open the ads manager and see 40 purchases. Your store has 60 orders from that campaign. The difference is not a platform error: they are purchases the customer's browser never reported. Ad blockers, browsers that restrict cookies, tabs closed before the confirmation page loads or payments that return from the gateway by another route.

The result is that platforms optimise your campaigns with incomplete data. Server-side measurement sends conversions directly from your store to the platform, without depending on the browser.

Browser versus server

It is not a matter of choosing one: the usual approach is to use both and deduplicate.

Meta: the Conversions API

The Conversions API (CAPI) receives events from your server with a pixel access token. Each event carries:

• event_name (for example Purchase), event_time and action_source (website).
• event_id: the identifier that allows deduplication.
• user_data: customer data hashed with SHA-256 (email, phone, name…), plus the IP, the user agent and the _fbp and _fbc cookies if they exist.
• custom_data: value, currency, products.

Deduplication: if the pixel and the server send the same purchase with the same event_name and the same event_id, Meta counts it only once. Without a shared event_id, you will have double purchases.

GA4: the Measurement Protocol

GA4 accepts events from the server through the Measurement Protocol, with an api_secret created in the data stream and the measurement ID. Important differences from Meta:

• It needs the browser's client_id (taken from the _ga cookie) to join the event to the user's session. Without it, the purchase appears with no traffic source.
• For purchases, deduplication is done with the transaction_id: GA4 discards repeated purchases with the same identifier.
• Events sent with a long delay may not be attributed to the correct session.

When to send the purchase?

• When the order is created: fast, but it includes bank transfer or cash-on-delivery orders that may never be paid.
• When the order is paid (when it moves to a payment-accepted status): more faithful to reality. It is the recommended option for most stores.

It is also worth sending refunds, so that reports reflect net sales.

Consent: it is not optional

Sending from the server does not change the rules. The data you send to Meta or Google for advertising requires the user's consent when cookie and data protection law requires it (in Spain, article 22.2 of the LSSI and the GDPR). In practice:

• If the user has rejected advertising cookies, their identifiers are not sent to those platforms.
• Google Consent Mode v2 lets you communicate the consent status (ad_storage, analytics_storage, ad_user_data, ad_personalization) so that Google processes the data accordingly.
• An explicit refusal must never be overwritten by a default value.
• Send only what is necessary, and hashed; cost prices or margins do not need to leave your store unless you decide so.

Relay: an intermediary between the store and the platforms

One variant is not to send directly from the store but to an intermediate server (a relay) that receives the signed events and takes care of delivering them to each platform, with its retries and credentials. Advantages: the platforms' keys do not live in the store, retries do not load your server and several stores can be managed from one place.

Checklist

1. Pixel and server share the event_id in Meta.
2. GA4 receives the real client_id and a unique, constant transaction_id.
3. The purchase is sent on payment, and refunds are sent too.
4. Consent is respected before loading tags and before sending from the server.
5. Every week you compare store orders with conversions on each platform.
6. You check the event match quality in Meta's events manager.

How to handle it in PrestaShop

RKR API Conversions Pro sends conversions from the server to Meta, GA4, Google Ads, TikTok, Microsoft Ads, Pinterest, Snapchat, LinkedIn and OpenAI / ChatGPT Ads, with the same event_id as the browser tag so that the platform deduplicates, and in GA4 it prevents an event from arriving twice. Purchases can be sent when the order is paid, and it includes partial refunds and cancellations. It applies Consent Mode v2, restores saved consent before loading the tags, has adapters for Cookiebot, CookieYes, Complianz and OneTrust and never overwrites an explicit refusal. In queue mode it makes no network calls while the page is being generated or the payment is being made, and a daily reconciliation compares orders with what was delivered to each platform. It can also send events to a server-side relay, with signed calls and only hashed identifiers; Rekire's relay plans accompany this article.