Meta Pixel and the Conversions API: setup, event deduplication, and which events each one sends

Meta’s recommended measurement foundation is a redundant system: Meta Pixel in the browser plus Conversions API on the server, sending the same key events with deduplication so Meta keeps only 1 copy per conversion. This guide walks through what each channel sends, how deduplication works at the field level, and how to implement and verify a working setup. For reconciliation and reporting behavior after events are collected, see where the numbers go after collection.

What Pixel sends that CAPI does not, and what CAPI sends that Pixel does not

The Meta Pixel is a JavaScript snippet that runs in the browser and tracks visitor actions as events for conversion measurement, website custom audiences, and Advantage+ catalog ads, per Meta’s developer documentation. It automatically collects HTTP headers such as IP address, browser, page location, and referrer, along with the Pixel ID, Facebook cookie, and button-click data. Pixel events fire via fbq('track', ...) calls in the browser.

Pixel also observes form field names, but Meta’s documentation states that it does not capture form field values unless you deliberately send those values via Advanced Matching. This corrects a common misconception that the Pixel reads everything users type into forms by default. In practice, the browser path is your source for page context, click behavior, and the Facebook cookie that improves match quality.

The Conversions API (CAPI) sends events server-to-server to a single endpoint and can carry website, app, business messaging, offline, and CRM events, per Meta’s Conversions API documentation. These CAPI events are linked to a dataset ID and are processed the same way as Pixel, SDK, and offline events for targeting, optimization, and measurement. CAPI supports batching multiple events in a single POST request, which is useful when you are sending events from order webhooks or CRM jobs.

This corrects two frequent misconceptions. First, CAPI does not only apply to websites, since Meta’s documentation states that it also carries app, offline, CRM, and business messaging events. Second, CAPI does not replace the Pixel, because Meta’s deduplication documentation explicitly recommends a redundant setup where the same events are sent via both Pixel and CAPI.

Why a redundant Pixel + CAPI setup is recommended

Meta’s deduplication documentation states that the recommended approach is a redundant setup, where you send the same events through both Pixel and Conversions API. This is exactly why deduplication exists in the platform. The goal is to combine browser context from the Pixel with server reliability from CAPI, while keeping each conversion counted once.

This corrects the misconception that the Conversions API replaces the Pixel. If you run CAPI only, you lose browser-side context such as HTTP headers and the Facebook cookie that the Pixel automatically collects, which Meta uses for measurement and targeting. If you run Pixel only, you cannot send app, offline, or CRM events, and you cannot rely on server-side order or lead systems as sources of truth.

Another misconception is that sending the same event through both channels always double-counts conversions. Meta’s deduplication documentation states that when you pass matching event_name and event IDs between browser and server, Meta keeps only 1 copy of the event. Double-counting happens only when you send redundant events without the deduplication keys described in the next sections.

Choosing which events originate in the browser vs the server

Based on the documented behaviors of Pixel and CAPI, a practical framing is to treat pre-transaction context events as browser-first and money or outcome events as server-first. This framing is practice guidance, not a Meta rule, and is built on the fact that Pixel is browser-based while CAPI is server-based.

Browser-appropriate events include PageView, ViewContent, AddToCart, and InitiateCheckout, which are all pre-transaction context events. These are naturally triggered by client-side interactions and benefit from the browser context that Pixel automatically collects. You can still mirror some of these via CAPI if your platform supports it, but the browser is the primary origin.

Server-as-source-of-truth events include Purchase and lead outcomes or CRM stages. Purchase should be fired from the order webhook so it is recorded even if a user abandons or fails to load the thank-you page. Lead outcomes and CRM stage changes are only possible server-side, since they occur after the session and often outside the website.

Meta’s deduplication documentation and the redundant setup recommendation imply that the money events should be sent via both paths, with deduplication. In practice, this means you generate a single event ID at the source system (for example, when the order is created), then send that ID through both Pixel and CAPI for the same Purchase event_name.

How Meta deduplicates browser and server events

Meta’s primary deduplication method uses a combination of event_name and event ID. The server payload includes an event_id field, and the browser Pixel call includes an eventID value as the 4th argument to fbq('track', ...). When Meta receives 2 events with the same event_name and matching event ID values within the deduplication window, it keeps only 1 copy.

The alternate deduplication method uses the same event_name plus the fbp cookie and/or an external_id, according to Meta’s deduplication documentation. This method only works when the browser event arrives first and the server event arrives later, and Meta discards the server event only if its browser twin arrived within the previous 48 hours. This corrects the misconception that deduplication is fully automatic without any configuration.

Meta’s documentation states that the deduplication window is 48 hours per Pixel ID, and that the first-received event generally wins. In practice, this means that if the server Purchase arrives before the browser Purchase with the same event ID, Meta will keep the server copy and discard the later browser copy. If you rely on the alternate method with fbp or external_id, you must ensure the browser event fires first and the server event follows within that 48-hour window.

The misconception that deduplication is automatic is corrected by these requirements. The primary method requires you to generate and pass the same event ID through both paths. The fallback method only works in a browser-then-server order and only within the 48-hour window.

Browser vs server events in one view

Paired code example with a shared event ID

The core of a redundant setup is a shared event ID generated once at the source and passed through both browser and server. Meta’s documentation states that the browser event ID is the 4th argument to fbq('track', ...), and the server event ID is the event_id field in the CAPI payload.

Example browser-side Purchase event using Pixel:

<script>
  // eventId generated on the server and exposed to the page
  var eventId = "ORDER-12345";

  fbq('track', 'Purchase', {
    value: 99.00,
    currency: 'USD'
  }, {
    eventID: eventId
  });
</script>

Example server-side Purchase event using Conversions API with the same event ID:

POST /vX.X/{pixel-id}/events HTTP/1.1
Host: graph.facebook.com
Content-Type: application/json

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1697577600,
      "event_id": "ORDER-12345",
      "user_data": {
        "em": ["<hashed_email>"],
        "ph": ["<hashed_phone>"]
      },
      "custom_data": {
        "value": 99.00,
        "currency": "USD"
      }
    }
  ]
}

Meta’s deduplication documentation states that when event_name and event ID match between browser and server within 48 hours, Meta keeps a single copy of the Purchase. This is the primary way to avoid double-counting when you send money events via both Pixel and CAPI.

Setup order for a working redundant implementation

A practical setup sequence, built from Meta’s Pixel, Conversions API, and deduplication documentation, is as follows. First, implement the Meta Pixel via your tag manager or platform integration and confirm that standard events such as PageView and Purchase fire as expected. Pixel events fire using fbq('track', ...) calls, so verify those calls in your tag manager preview or browser console.

Second, implement Conversions API via your platform integration or a direct build that sends POST requests to Meta’s CAPI endpoint. Meta’s documentation states that CAPI supports batching, so you can send multiple events in a single request if your system emits them in batches. Link your CAPI implementation to the same dataset ID that your Pixel uses so events are processed consistently.

Third, wire a shared event ID through both paths. Generate the event ID once at the source, such as when an order is created or a lead is written to your CRM, then expose it to the browser for the Pixel call and include it as event_id in the CAPI payload. Meta’s deduplication documentation states that this event ID, combined with event_name, is the primary deduplication key.

Fourth, add hashed identifiers such as email and phone to your server payloads via Advanced Matching. Meta’s Pixel documentation states that form field values are only sent when you deliberately include them, and Meta’s CAPI documentation notes that user data is used for matching. Hashing these identifiers in the server payload improves match quality scores that you will see in Events Manager.

Finally, once your Meta setup is stable, you can apply the same architecture to other platforms. For example, you can review a similar Pixel and Conversions API pattern on Reddit if you need consistent multi-channel tracking.

How to verify deduplication and event matching

Meta’s Conversions API documentation states that Events Manager shows each event’s delivery method, which can be browser, server, or both, and whether deduplication has been applied. It also states that server events carry a match quality score. Use these views to confirm that your key events, such as Purchase, appear as “browser and server” with deduplication indicated.

To verify that deduplication is working, inspect individual Purchase events in Events Manager and confirm that the event ID appears for both the browser and server copies. When the event IDs match and the event_name is the same, Meta’s deduplication logic keeps a single counted event. If you see separate browser-only and server-only events with different IDs, deduplication is not configured correctly.

Meta’s deduplication documentation states that the deduplication window is 48 hours per Pixel ID and that the first-received event generally wins. Because server events can arrive later within this 48-hour window, Meta’s documentation recommends reconciling event totals against your order or CRM system over a full week rather than a single day. This weekly reconciliation helps you confirm that the total number of Purchases or leads in Meta aligns with your source-of-truth systems once late-arriving server events have been processed.

This verification process also corrects the misconception that sending the same event through both channels always double-counts conversions. When you see a single counted Purchase with both browser and server delivery methods and a single event ID, you have proof that Meta is deduplicating correctly.