Facebook Server-side Tracking
Facebook Server-side Tracking sends your conversion events to Meta from a server you control, through the Meta Conversions API, instead of relying only on the Meta Pixel in the visitor's browser. Almost every setup runs both: the Pixel keeps reporting from the browser while your server sends a matching copy of each event, and a shared event ID tells Meta the two describe the same purchase so it is counted once.
Most Meta setups break at this pairing. Deduplication is not automatic, and when the event IDs don't match you don't lose data, you double it. Every report and every bidding decision downstream then inherits the inflated number.
This guide covers how to set up both sources, how deduplication works and what breaks it, how your Event Match Quality score is calculated, and which of the three server-side routes to Meta fits your setup.
What is Facebook Server-side Tracking?
Facebook Server-side Tracking sends your conversion events to Meta from a server you control rather than from the visitor's browser. The Meta Pixel still runs on your site, but a second copy of each event travels server-to-server through the Conversions API, and a shared event ID tells Meta that the two copies describe the same action.
The Conversions API (CAPI) has been generally available since 2020. What has changed is how much of the browser-side signal survives long enough to reach Meta, and how much of your optimization now depends on the server copy arriving.
For the wider picture of why browser tracking loses conversions, see why your Meta, GA4 and Google Ads conversions don't match.
Main benefits
-
A higher Event Match Quality score. The Conversions API only ties a conversion to a person when identifying parameters travel with the event. Server-side you take email, phone and address from the order record rather than from whatever the browser happened to be holding, which is why the same Purchase event consistently matches better when it is sent from the server.
-
Conversions that don't need to touch the browser. Phone orders, in-store sales and CRM stage changes never reach the browser at all, so the Pixel has nothing to capture. The Conversions API is the only route that gets them into Meta.
-
Control over what Meta receives. Events pass through infrastructure you own, so you decide which fields are forwarded, which are hashed and which are held back. Meta's hosted options give you no equivalent point to intervene.
Pixel, Conversions API or both?
Running the Conversions API does not mean switching the Pixel off and Meta does not recommend that you do it. The two sources see different things. The Pixel captures browser context such as the referrer, the page URL and the fbp cookie. The server captures what the browser didn't receive: the confirmed order value, the customer record behind it, and conversions that happen after the session has ended.
Server-only setups exist, usually where there is no website to tag at all, but they give up the browser context that improves matching. For most advertisers who run websites, the answer is both sources sending the same events, deduplicated.
That's why deduplication is such a crucial thing to get right. We cover it in step 5 below.
Accurately improve ad targeting and optimization
Meta's delivery system optimizes against the conversions it receives. When a meaningful share of your purchases don't reach it, the algorithm is learning from a partial sample and it optimizes towards whichever audiences happen to survive the browser rather than whichever audiences convert.
Sending conversions server-side changes what the algorithm sees in two ways. More events arrive, and the events that arrive carry more customer data for Meta to match against an account. Both matter for audience building, because retargeting pools and lookalikes are rebuilt from real buyers rather than from the subset the Pixel managed to record before a cookie expired.
However, this doesn't give you immunity from blocking. No setup can recover an interaction your site never captured in the first place. What it does is remove the browser as the thing deciding whether a conversion counts.
Learn how Server-side Tracking improves Smart Bidding and automated campaign performance.
Better aligned with GDPR
Server-side Tracking gives you one place to apply consent decisions and data minimization before anything reaches Meta. With TAGGRS, you decide which information is collected and forwarded, and you can filter or anonymize sensitive fields such as IP addresses or client IDs before they leave TAGGRS servers.
Processing data on TAGGRS infrastructure and keeping tracking IDs off the client side reduces your exposure and the risk of data leaking to destinations you did not choose. TAGGRS provides global servers, including storage within EU borders.
This supports GDPR principles like data minimization and purpose limitation. It does not replace a lawful basis for processing. An event a visitor declined should not be sent at all, whether it travels from the browser or from your server, and your consent management platform still has to set consent states before any tag processes advertising data.
Expert Insight
Set up Facebook Server-side Tracking
Our documentation includes step-by-step guides to setting up Facebook Server-side Tracking, including installing the Meta Pixel in GTM, sending user data parameters, configuring event deduplication and improving your Event Match Quality score. The five steps below are the order to work through them.
1. Create a server container in Google Tag Manager

2. Install the Meta Pixel
3. Install the Meta Conversions API

4. Send your user data parameters
The Conversions API only matches a conversion to a person when identifying parameters travel with the event. Email, phone, name, city and country are hashed with SHA-256 before they leave your server, while the click ID (fbc), browser ID (fbp), IP address and user agent are sent as they are.
The browser adds IP address and user agent automatically. Server events do not, so these have to be mapped explicitly in your server container. How many parameters you send is what drives the Event Match Quality score covered below.

5. Set up event deduplication
Running the Pixel and the Conversions API together means Meta receives two copies of every purchase. Deduplication is what stops it counting them as two sales.
Meta matches on two values: the event name and the event ID. The parameter is called eventID in the browser Pixel and event_id in the server event, and both need to carry the same value. Generate it once from your order or transaction ID and pass it to both tags. An ID generated separately inside each tag will never match, and that is the most common reason a setup starts double-counting.
Keep in mind that:
- Deduplication applies only within 48 hours of the first event carrying a given ID. After that, the second copy counts as a separate conversion.
- When both copies arrive within about five minutes of each other, Meta keeps the browser event.
- If no browser event arrived in the preceding 48 hours, the server event is kept rather than discarded, so a server-only event is never lost to deduplication.
If you cannot pass an event ID, Meta can also deduplicate on event name combined with fbp and/or external_id, provided both are sent consistently from the browser and the server.
Check your Facebook Event Match Quality (EMQ) score
Event Match Quality (EMQ) measures how well the customer data you send matches Meta accounts. Meta scores each event type separately on a scale up to 10 and recalculates it from recent data, so the number moves as your setup changes rather than being fixed.
Scores vary by event by design. Purchase and AddPaymentInfo score highest, because email, phone and address are available by checkout. PageView and ViewContent score lowest, because there is little identifying data to send that early in the journey. A score around 6 on the events you optimize for is widely treated as healthy, and the gains between 8 and 10 are small. Chasing a high score on top-of-funnel events is wasted effort, since the parameters simply are not there.
The score reflects how complete and well formatted your parameters are, not whether the data is correct. Well-formatted but wrong data can still score highly, which is why the score is a diagnostic rather than a target.
Not sure where else your setup is leaking? Use our free website tracking checker to find out.
Test your setup
Open Events Manager, select your dataset and go to Test Events. Trigger a purchase on your site and watch what arrives.
A correctly deduplicated event appears as one event received from two sources, browser and server. If you see two separate entries for the same purchase, or only one source, your event IDs are not matching and the configuration in step 5 needs another look. Check this before you rely on the numbers for bidding, because an inflated conversion count feeds straight into Meta's optimization.
For a broader check across your whole setup, see: How resilient is your tracking setup?