# Facebook Server-side Tracking: how to set up the Meta Conversions API Set up the Meta Conversions API alongside the Meta Pixel: deduplication, user data parameters, Event Match Quality and the right server-side route. Source: https://taggrs.io/facebook-server-side-tracking/ Author: Małgorzata Poddębniak, Content Marketer · [LinkedIn](https://www.linkedin.com/in/malgorzatapoddebniak/) Updated: 2026-11-13 --- 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 go wrong at this pairing. Deduplication is not automatic: when the event IDs don't match, Meta counts each purchase twice, and every report and bidding decision after that uses 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? The Conversions API is Meta's server-to-server connection for conversion events. Instead of only the visitor's browser sending an event to Meta, your server sends a copy too, with the confirmed order data attached. A shared event ID tells Meta that both 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](/meta-ga4-and-google-ads-conversions-dont-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 usually matches better when it is sent from the server. ### Conversions that happen outside the browser Phone orders, in-store sales and CRM stage changes never reach the browser, 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 a server container you control, so you decide which fields are forwarded, which are hashed and which are held back. ### Better ad targeting and optimization Meta's delivery system optimizes on the conversions it receives. When part of your purchases never reach it, it learns from a partial sample and favors the audiences whose conversions survive the browser, not the ones that convert most. Server-side events give it more conversions with more customer data attached, so retargeting and lookalike audiences are built from all your buyers. Server-side Tracking can't recover an interaction your site never captured, but it stops the browser from deciding whether a conversion counts. Learn [how Server-side Tracking improves Smart Bidding and automated campaign performance](/improve-smart-bidding-with-server-side-tracking/). ## Pixel, Conversions API or both? Running the Conversions API does not mean switching the Pixel off, and Meta does not recommend 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. | The Meta Pixel sees | The Conversions API sees | | -------------------------------------- | --------------------------------------- | | The referrer and the page URL | The confirmed order value | | The fbp cookie and the fbclid click ID | The customer record behind the order | | What happens during the session | Conversions after the session has ended | | Only what the browser lets through | Phone, in-store and CRM conversions | Server-only setups exist, usually where there is no website to tag, but they give up the browser context that improves matching. For most advertisers with a website, the answer is both sources sending the same events, deduplicated. Step 5 below explains how. ## Choose your server-side route There are three ways to send server-side events to Meta. Which one fits depends on how many platforms you track and how much control you need. | Route | Best for | What to know | | --------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Conversions API through server-side GTM | Sites that also send data to GA4, Google Ads or other platforms | Full control over fields and consent. Needs a server container. | | Meta Conversions API Gateway | Meta-only tracking with minimal setup | Fully hosted, set up in two steps. Meta only. Hosted on Google Cloud in a location you select; Google Cloud falls under the U.S. Cloud Act. | | Built-in platform integration | Stores on a platform with its own Meta integration, such as Shopify | Quick to switch on. Least control over what is sent. | Read more about the [TAGGRS Meta CAPI Gateway](/meta-capi-gateway-hosting/). ## Server-side Tracking and 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 the risk of data reaching destinations you did not choose. With server-side GTM hosting, you choose where your server processes data, including locations within the EU. The Meta CAPI Gateway is hosted on Google Cloud in a location you select. Google Cloud falls under the U.S. Cloud Act, which means U.S. authorities can access the data. If you want to prevent this, set up the Conversions API through server-side GTM. This supports GDPR principles such as 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 comes from the browser or your server, and your consent management platform still has to set consent states before any tag processes advertising data. Read more in [Server-side Tracking and the GDPR](/server-side-tracking/gdpr/) and on our [security page](/security/). > **Expert insight.** When someone clicks a Meta ad, they land on a URL carrying fbclid. If Safari has classified the referring domain as a cross-site tracker, any cookie written by JavaScript on that landing page can be capped at 24 hours instead of the usual seven days. The click and a purchase three days later then become two unconnected events. A cookie set by your own server through the Set-Cookie header is not subject to this cap, as long as the server runs on your own domain (see step 1). ## Set up Facebook Server-side Tracking Our documentation includes step-by-step guides for each part of the setup. Work through them in this order. ### 1. Create a server container in Google Tag Manager A server container is where your events arrive before they are forwarded to Meta. It runs on a first-party tagging URL on your own domain, such as `sending.example.com`. Pointing a subdomain at an external service is not enough on its own, because Safari compares IP addresses before it decides whether to extend a cookie's lifetime. [Docs: Set up Google Tag Manager](https://taggrs.io/docs/server-side-tracking/setup/gtm) ### 2. Install the Meta Pixel The Pixel stays in place. It captures browser context the server cannot see, and in a dual setup it supplies one half of each deduplicated pair. Install it through your web container rather than hard-coding it, so the event ID in step 5 can be passed to both tags from one place. [Docs: Set Meta Pixel](https://taggrs.io/docs/server-side-tracking/facebook/meta-pixel) ### 3. Install the Meta Conversions API The Conversions API tag lives in your server container and sends events to Meta over a direct server-to-server connection. Configure it with the same dataset ID as your Pixel. Sending browser and server events to two different datasets is a common early mistake, and it makes deduplication impossible. [Docs: Install Meta CAPI](https://taggrs.io/docs/server-side-tracking/facebook/meta-capi) ### 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 in your server container. How many parameters you send is what drives the Event Match Quality score covered below. ![The User Data section of a Meta Conversions API tag in a Google Tag Manager server container, mapping email, phone, last name, first name, city, state, zip and country to variables](https://taggrs.io/_astro/capi-user-data-parameters.BTLLvvlC_2tzPew.webp?dpl=dpl_AzPzciij3XxAdVcvxKopSYAzbo1C) [Docs: Improve your EMQ Score](https://taggrs.io/docs/server-side-tracking/facebook/event-match-quality-score) ### 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, which is the most common reason a setup starts double counting. Keep in mind: - 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, 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. [Docs: Meta Events Deduplication](https://taggrs.io/docs/server-side-tracking/facebook/event-deduplication) ## Check your Event Match Quality 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 changes as your setup changes. 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 generally considered good, and the gains between 8 and 10 are small. There is little point trying to raise the score on top-of-funnel events, since the parameters aren't available that early. 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, so use the score as a diagnostic rather than a target. [Docs: Improve your EMQ score](https://taggrs.io/docs/server-side-tracking/facebook/event-match-quality-score) ## Test your setup Open Events Manager, select your dataset and go to Test Events. Trigger a purchase on your site and check 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 step 5 needs checking. Do this before you rely on the numbers for bidding, because an inflated conversion count goes straight into Meta's optimization. ## How TAGGRS helps TAGGRS hosts your server container, so you can run the Conversions API without managing a server yourself. - [Server-side GTM hosting](/gtm-server-side-tagging-hosting/) on your own subdomain, for first-party requests and longer cookie lifetimes. - The [Meta CAPI Gateway](/meta-capi-gateway-hosting/), if you only need Meta and want the fastest setup. - Data Enricher adds non-sensitive context such as city, region and device to events, which raises Event Match Quality. - Cookie Recovery and Click ID Recovery keep fbc and fbp available across long purchase journeys. - Ready-made templates and a GTM copy-paste option to speed up the setup. **Not sure where else your setup is losing data?** Our free website Tracking Checker scans your site and shows which pixels, server-side connections, cookies and consent settings work, each with a recommended fix. - [Check your tracking](/website-tracking-checker/) ## Frequently asked questions **Do I need both the Meta Pixel and the Conversions API?** Yes. The Pixel captures browser context such as the referrer and fbp cookie, and the server sends confirmed order data and conversions that happen outside the browser. Meta recommends running both, deduplicated with a shared event ID. **Why does Meta count my conversions twice?** The most common cause is that the event IDs from the Pixel and the Conversions API don’t match. Generate one event ID from your order ID and pass it to both tags. Also check that both send events to the same dataset. **What is the difference between the Meta CAPI Gateway and the Conversions API through server-side GTM?** The Gateway is a simple, fully hosted option for Meta only. It is hosted on Google Cloud, which falls under the US CLOUD Act. Server-side GTM supports multiple platforms and gives more control over data and where it is processed, but needs more configuration. Read more about the [Meta CAPI Gateway](/meta-capi-gateway-hosting/). **What is a good Event Match Quality score?** Around 6 on the events you optimize for, such as Purchase, is generally considered good. Top-of-funnel events score lower by design, because less customer data is available that early. **Is Facebook Server-side Tracking GDPR compliant?** It supports GDPR by letting you control and minimize what reaches Meta, but it does not replace a lawful basis or consent. Events a visitor declined should not be sent from the browser or the server. Read more in [our guide to Server-side Tracking and the GDPR](/server-side-tracking/gdpr/).