[← Marketing](/category/marketing)

# How to set up the Meta Conversions API without losing signal

[David Pombar](/about-me) · October 21, 2026 · 8 min read

The Meta Conversions API (CAPI) only improves what Meta's bidding sees if it runs next to the pixel, sends the same events with the same `event_id`, and carries enough customer information to be matched. A server feed that duplicates the pixel, arrives hours late or reaches Meta with little more than an IP address adds noise, not signal. By the end of this post you will know which setup option fits your team, what to put in every server event, and the four checks that tell you the setup is working.

## Why a new server feed often makes the signal worse

The failure is rarely the API call. It is what happens between the browser event and the server event.

**Duplicates inflate conversions.** Meta merges a pixel event and a server event only when the pixel's `eventID` matches the server's `event_id` and the event names match. Both have to reach the same pixel ID within 48 hours of the first event with that ID ([Meta, deduplication](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events), as of October 2026). If the server generates its own ID, or the pixel sends `Purchase` while the server sends `purchase`, Meta counts two purchases. Bidding then optimizes toward a conversion rate that does not exist.

**Unmatched events don't count.** Meta says only matched events can be used for attribution and delivery optimization ([Meta, best practices](https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices), as of October 2026). A server event with no email, no phone and no `fbp` cookie is received but may never be tied to a person who saw an ad.

**Late events lose value.** Meta asks for events in real time or within one hour. It warns that delays beyond two hours can hurt performance, and that delays of 24 hours or more can cause serious attribution and delivery problems ([Meta, end-to-end implementation](https://developers.facebook.com/documentation/ads-commerce/conversions-api/guides/end-to-end-implementation), as of October 2026). A nightly batch from the order database is a reporting feed, not a bidding signal.

For example, a store adds a server-side `Purchase` from its order system, keyed on order ID, while the pixel keeps generating a random `eventID` in the browser. Both events are valid and neither is deduplicated. Reported purchases go up, cost per purchase goes down, and nothing changed in the business.

## How to set it up: one event, one ID, two paths

The setup Meta recommends is redundant: the same events sent from both the pixel and the Conversions API ([Meta, best practices](https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices), as of October 2026). The server path recovers events the browser loses to connectivity or page-load failures. The steps below assume that setup.

1.  **Choose the integration path by who will own it.** There are four ways in, and the decision is about maintenance more than features:
    
    -   **Conversions API Gateway.** A self-serve option from Events Manager that runs on a server instance in your own cloud account (Meta names AWS and GCP). Meta says no coding is necessary, generates the `event_id` itself for deduplication, and says the only cost is the cloud resource or partner fees ([Meta, Conversions API Gateway](https://developers.facebook.com/documentation/ads-commerce/gateway-products/conversions-api-gateway), as of October 2026). It mirrors what the pixel sees, so it does not add events the browser never fires.
    -   **Server-side Google Tag Manager (sGTM).** Fits teams that already run a tagging server. Google's default deployment runs on Cloud Run ([Google, server-side tagging](https://developers.google.com/tag-platform/tag-manager/server-side/overview), as of October 2026). The Meta tag in the server container is not a Google product tag, so someone has to own its configuration and updates. Meta writes and maintains the template, called Conversions API Tag by facebookincubator, in the Community Template Gallery ([Meta, server-side GTM](https://developers.facebook.com/docs/marketing-api/conversions-api/guides/gtm-server-side), as of October 2026). It reads events from the GA4 client and does not check consent by itself, so the gate goes in your trigger.
    -   **Partner integration.** Commerce platforms, CDPs and tag managers that ship a Conversions API connector. Meta says partners have their own setup requirements ([Meta, get started](https://developers.facebook.com/docs/marketing-api/conversions-api/get-started), as of October 2026). Check which events and which customer parameters the connector sends before you rely on it.
    -   **Direct integration.** Your developers call the API from your backend. It is the only path that can send events the browser never sees, such as a subscription renewal or a qualified lead from the CRM, with every parameter under your control.
    
    The artifact of this step is a one-line decision with an owner: "CAPI runs through X, owned by Y."
    
2.  **Write the event list before touching the code.** Pick the events Meta's bidding optimizes for: usually `Purchase`, `Lead`, `InitiateCheckout` and `AddToCart`. For each one, write down the trigger, the exact `event_name` (identical on pixel and server) and where the `event_id` comes from. Meta suggests the order or transaction ID when one exists, and otherwise a random value that browser and server both send ([Meta, server event parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event), as of October 2026). This list belongs in the same document as the rest of your tracking specification, not in a ticket.
    
3.  **Generate the `event_id` once and pass it to both paths.** The ID is created where the event happens, usually in the data layer, and read by both the pixel and the server call. On the pixel it goes in the fourth argument, `fbq('track', 'Purchase', {...}, {eventID: '...'})`. On the server it goes in `event_id` ([Meta, deduplication](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events), as of October 2026). If you can't share an ID, Meta also deduplicates on `fbp` or `external_id`. That method only works when the browser event arrives first, so treat it as a fallback.
    
4.  **Fill every server event with the required fields.** Meta marks `event_name`, `event_time`, `user_data` and `action_source` as required, and `event_source_url` as required for website events. `event_time` can't be more than seven days old, or the whole request fails ([Meta, server event parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event), as of October 2026). Meta's best-practice page also lists `client_user_agent` for website events, and `event_id` and `external_id` for all events.
    
5.  **Send as much customer information as you are allowed to.** Meta lists email, IP address, first and last name and phone as the parameters with the most impact. Personal fields such as email and phone are hashed with SHA-256 after normalizing them (email trimmed and lowercased, phone with country code and no symbols). `client_ip_address`, `client_user_agent`, `fbp` and `fbc` are sent unhashed ([Meta, customer information parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters), as of October 2026). Read `fbp` and `fbc` from the `_fbp` and `_fbc` first-party cookies on each request; Meta says they change over time.
    
6.  **Apply the same consent decision to both paths.** Moving an event to the server does not change whether you may send it. Meta's guidance is to apply the consent logic you use for the pixel to the Conversions API data ([Meta, end-to-end implementation](https://developers.facebook.com/documentation/ads-commerce/conversions-api/guides/end-to-end-implementation), as of October 2026). In the browser, the pixel has `fbq('consent', 'revoke')` and `fbq('consent', 'grant')` ([Meta, pixel and GDPR](https://developers.facebook.com/docs/meta-pixel/implementation/gdpr), as of October 2026). The server needs the same consent state, passed from the page with the event, and a rule that drops the event when consent is missing. For US traffic, Meta's Limited Data Use option is set per event with `data_processing_options`, plus country and state fields ([Meta, data processing options](https://developers.facebook.com/docs/marketing-apis/data-processing-options), as of October 2026). Which rule applies to your users is a legal decision, not a tagging one.
    
7.  **Send events as they happen.** Real time, or in small batches close to real time. One request can carry up to 1,000 events ([Meta, using the API](https://developers.facebook.com/docs/marketing-api/conversions-api/using-the-api), as of October 2026), but the limit that matters for bidding is the one-hour delay Meta asks for, not the batch size.
    

## How you know it is working

Four checks, in this order. The first two happen before launch; the last two are a weekly routine.

-   **Test events arrive and deduplicate.** In Events Manager, the Test Events tool gives you a `test_event_code`. Send a test purchase through both paths with the same `event_id` and confirm Meta shows one event, received from both the browser and the server. Remove the code from production payloads. Meta says events sent with a test code are not dropped and are used for measurement and targeting ([Meta, using the API](https://developers.facebook.com/docs/marketing-api/conversions-api/using-the-api), as of October 2026), so test with your own details and keep the volume small.
-   **The overview shows both connection methods.** In the pixel's Overview in Events Manager, each event shows raw, matched and attributed counts and its connection method. Meta says new server events should be visible within 20 minutes ([Meta, using the API](https://developers.facebook.com/docs/marketing-api/conversions-api/using-the-api), as of October 2026). An event that only shows the server, or only the browser, means one path is broken.
-   **Event match quality is stable or rising.** Events Manager scores event match quality out of 10, per web event ([Meta, best practices](https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices), as of October 2026). Watch the score for the events you bid on, and treat a sudden drop as a release that removed a customer parameter.
-   **Purchases reconcile with the backend.** Compare Meta's deduplicated `Purchase` count with orders in your system for the same days. Meta's count should not exceed real orders. If it does, deduplication is failing.

If you lead the paid media team rather than run the implementation, ask for these four checks in a single weekly line: event match quality for the bid events, the deduplicated count versus backend orders, and the share of events received from each path.

## When this setup doesn't apply

-   **Events the browser never sees.** Offline sales, renewals or CRM stages can't be deduplicated against the pixel because there is no pixel event. Send them server-only with the right `action_source`, which decides which campaign objectives they can serve ([Meta, best practices](https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices), as of October 2026).
-   **A site with only a standard pixel and no team to host anything.** Meta offers a Conversions API option managed inside Events Manager, with nothing to host ([Meta, Conversions API Gateway](https://developers.facebook.com/documentation/ads-commerce/gateway-products/conversions-api-gateway), as of October 2026). You give up control over which parameters are sent.
-   **Low conversion volume.** If the account sees few conversions per week, check whether volume, not matching, is what limits bidding before investing in the server path.

Server-side collection is a broader decision than Meta. If you are weighing it for every platform, start with [what server-side tracking does and doesn't solve](/what-is-server-side-tracking). If CAPI runs through sGTM, it inherits the health of your container, so include it in your [Google Tag Manager audit](/optimize-with-confidence-google-tag-manager-audit-essentials). For the wider set of tools that catch broken events after a release, see [how to detect implementation errors in GA4](/the-best-tools-to-detect-implementation-errors-and-audit-google-analytics-4-ga4).

## What to check this week

-   Open Events Manager and confirm that `Purchase` (or your main bid event) shows both browser and server as connection methods.
-   Compare last week's deduplicated purchases in Meta with orders in your backend. If Meta's count is higher, trace where each path creates its `event_id`.
-   Write down who owns the Conversions API path and where its event list lives. If nobody can answer, that is the first fix.

![](/images/about-me/davidpombar_profile.jpg)

Written by [David Pombar](/about-me). Lives in A Coruña, Galicia, and works at Trackingplan.