Server-side tracking has become essential for any e-commerce merchant who invests in advertising. With growing browser restrictions, ad blockers and privacy regulations, traditional browser-side tracking loses reliability every year.
This guide explains everything you need to know to understand and set up server-side tracking on your store.
Client-side vs server-side tracking: what's the difference?
Client-side tracking (traditional)
This is the tracking you know: a JavaScript script (the "pixel") loads in your visitor's browser. When the visitor takes an action (visit, add to cart, purchase), the script sends the information directly to Meta, Google or TikTok.
The problem: this script runs inside the browser, an environment that's increasingly hostile to tracking:
- Ad blockers: they can stop the Meta or Google pixel from loading. The share of affected traffic depends on your audience; it isn't a fixed percentage.
- Safari ITP: third-party cookies are blocked, and first-party cookies expire quickly when they're set by JavaScript
- iOS ATT: a large share of iOS users opt out of in-app tracking. Measure it on your own traffic; don't copy it from an article.
- Brave, Firefox ETP: increasingly aggressive anti-tracking protections
Server-side tracking
With server-side tracking, conversion events are sent from your server directly to the ad platforms' APIs. The browser is no longer the weak link in the chain.
The flow becomes:
- The visitor takes an action on your site
- Your server detects the event (via a Shopify webhook for purchases, or via a lightweight first-party pixel for browsing events)
- Your server sends the event to each platform's conversion API (Meta CAPI, TikTok Events API, Google Enhanced Conversions)
- The platform matches the event with the original ad click thanks to shared identifiers
How Meta's Conversions API (CAPI) works
CAPI is Meta's official API for receiving server-side conversion events. Here's how it works in detail:
Matching identifiers
For Meta to tie a purchase to the right ad click, you need to send identifiers. The more you send, the better the match rate:
- fbp (Facebook Browser ID): the first-party cookie set by the pixel. Excellent match rate when available.
- fbc (Facebook Click ID): contains the
fbclidfrom the ad click. The most reliable for attribution. - Hashed email (SHA-256): the customer's email, hashed before sending. Very good match rate because most shoppers are logged in to Facebook.
- Hashed phone: the customer's phone number, normalized and hashed.
- IP address + User Agent: allow probabilistic matching as a last resort.
Deduplication
If you use both the client-side pixel and CAPI (which is recommended), Meta may receive the same event twice. Deduplication relies on a unique event_id sent through both channels. Meta then counts the event only once.
This is a crucial point: without proper deduplication, you over-report your conversions and skew the algorithm's optimization.
TikTok Events API and Google Enhanced Conversions
TikTok Events API
The principle is the same as Meta CAPI. TikTok provides an Events API that accepts server-to-server events. The key identifiers are the ttclid (TikTok Click ID) and the hashed email. The match rate is generally good because TikTok links profiles to emails.
Google Enhanced Conversions
Google doesn't receive an event named Purchase. The purchase is sent through Enhanced Conversions: the orderId field carries the numeric ID of the Shopify order, with the hashed email and phone when the visitor has consented. Consent Mode v2 stays on your side: sending from the server doesn't override the person's choice.
Practical setup: your options
Option 1: custom development
You build a server that receives events (via Shopify webhooks and a first-party pixel) and forwards them to each platform's API. It's flexible but extremely time-consuming: expect 40 to 80 hours of development, plus ongoing maintenance.
Option 2: server-side Google Tag Manager
Server-side GTM requires a server container (hosted on Google Cloud Run, around €50 to €100/month), a complex tag setup, and advanced technical expertise. Good for large brands with a dedicated data team.
Option 3: an off-the-shelf solution
With ProfitPilotPro, the pixel is turned on from the Shopify theme editor. The app doesn't write to your theme. Orders, for their part, come from the store connection (API and webhooks), not from a script pasted into the page. The pixel covers browsing. The paid purchase is read on the server, then sent to Meta, TikTok and Google with the same numeric order ID. Today, order sync covers Shopify.
The concrete benefits of server-side tracking
- Purchases read from Shopify: they leave from the server. A browser ad blocker doesn't stop them. The browsing script, however, can still be blocked
- Resilient to ITP/ATT: the data is sent server-side, regardless of browser restrictions
- Better algorithmic optimization: more conversion data = better automated targeting
- More reliable attribution: you see real conversions, not Meta's estimates
- Multi-platform: a single data stream sent to Meta, TikTok and Google at the same time
What server-side tracking doesn't do
Let's be honest: server-side tracking isn't magic. It can't:
- Track users who don't buy (no server interaction, no server event)
- Solve cross-device attribution 100%
- Completely replace the client-side pixel (the two are complementary)
The best approach is to use both in parallel: the client-side pixel for browsing events (page view, add to cart) and server-side tracking for critical events (purchase, checkout started).
The step-by-step guide (pixel, CNAME, event_id) is in Documentation → Tracking. The trial lasts 14 days, no credit card required. Create an account.