You open Ads Manager on Monday morning. Meta shows you one number of orders from ads, your store's admin shows another, and GA4 a third. It is not your mistake. The gap has several causes, but one is technical and you can reduce it: the browser pixel does not see every order.
Server-side tracking means the store itself sends the events to the ad platforms, without depending only on the visitor's browser. Let us see how it works and where it goes wrong.
How classic tracking works
The pixel is a piece of JavaScript placed on the store's pages. When the visitor opens a product or finishes an order, the script sends an event (for example Purchase) from their browser straight to Meta or TikTok. The platform uses it to link the order to an ad and to learn what kind of people buy from you.
The problem is that the script runs on the visitor's phone or laptop. So it depends on things you do not control:
- the visitor refuses the marketing cookies in the banner;
- an ad blocker or a browser with tracking protection stops the script;
- the person closes the confirmation page before the script loads;
- the order ends elsewhere, for example with a redirect payment or in a phone app.
There is no universal percentage of lost events. It depends on your customers, their devices and how the cookie banner is set. For your store you find out simply: compare the orders from your store platform with those reported by the pixel, over the same period.
What "server-side" means
The event no longer leaves from the browser, but from your server or from a service that receives the orders from the store. When an order is created, the system sends the platform's API the event type, the value, the currency, the products and the customer's data, hashed.
The three APIs you meet most often:
- Meta Conversions API (CAPI): receives events from the server and matches them to Meta accounts.
- TikTok Events API: the same principle, for TikTok.
- GA4 Measurement Protocol: sends events to Google Analytics 4 from the server. Note: it complements the browser data, it does not replace it. On its own it cannot create a browsing session.
Deduplication, where mistakes are most common
The recommended setup uses both channels in parallel: the pixel and the API. The browser sees the browsing, the server sees the orders the browser missed. If both report the same order, the platform would count it twice. That is why events must be deduplicated.
The mechanism is simple. Each event gets an event_id, the same in both places. The pixel sends Purchase with event_id = 12345, the server sends Purchase with event_id = 12345, and the platform keeps only one. Three rules:
- Use an ID that exists in both places, such as the order number.
- The event name is identical on both channels.
Purchaseandpurchasedo not match. - The events arrive at about the same time. If the server sends the next day, deduplication is no longer reliable.
Without deduplication you see more orders in Ads Manager than you have in the store. It is worse than seeing fewer: you think the ads work better than they do and raise their budget right before Black Friday.
What data you send and why matching matters
For the platform to know whose event it is, the server sends matching signals: email, phone, name, city. All of them go out hashed with SHA-256, that is, turned into a string from which the original data cannot be recovered, after normalization (lowercase, no spaces). From the browser you can also add the _fbp cookie and the fbclid parameter for Meta, or ttclid for TikTok. The better the match, the more orders the platform can attribute. Meta shows you the match quality in Events Manager, under the name Event Match Quality. It is worth looking at.
You send only what you have the right to send. A customer's email does not go to an ad platform if they did not agree.
Consent remains
A common misunderstanding: "if I send from the server, I no longer need consent". Wrong. In the EU, GDPR and the ePrivacy directive apply regardless of where the event leaves from. If the visitor refused marketing, your server does not send their personal data to Meta or TikTok.
In practice, the state of consent must reach the server too, together with the order. A correct system sends the full event for whoever accepted. For whoever refused, it either sends nothing, or sends only an event without personal data, as you have set out in your privacy policy. You take the final decision with a lawyer, because it depends on your situation.
How to check that it works
- In Meta Events Manager, open the test tab and place a test order. Check whether the event appears from both sources, browser and server, and whether it is marked as deduplicated.
- In TikTok Events Manager, you check the status of the events and the parameters received in the same way.
- In GA4, you use the real-time report or DebugView and compare purchases with the store's orders, over a week.
- For a few days in a row, compare the store's orders with those in each platform. They will not be equal, because each platform attributes by its own rules. But the gap must not be huge.
How Aopy does server-side tracking
Aopy is built by the team behind Clinica de Marketing, which has worked in e-commerce since 2016.
Aopy receives the orders from the connected store and sends the purchase events to Meta Conversions API, TikTok Events API and GA4, through Measurement Protocol. The server event has the order ID as its identifier. If the browser event uses the same ID, the platform can deduplicate them. Email, phone and name are hashed before sending. Sending takes into account the consent given by the visitor in the store's cookie banner.
We now cover three destinations: Meta, TikTok and GA4. A server-side system does not repair badly set up ads and does not guarantee that the figures in the platform will be identical to those in the store. It gives you a more complete picture of orders, which you use to optimize.
The plans are on the pricing page.