Facebook Pixel and CAPI Event Deduplication: Checking Event IDs

For setup context, see event_id and deduplication, pixel warming, and Facebook CAPI through Keitaro. When browser Pixel and server CAPI report one purchase, those messages need to identify the same action. CAPI event deduplication helps prevent repeated counting, but verify it against the data actually sent.

Start with one conversion: find its identifier in both channels, compare event names, and inspect repeat requests. An aggregate report does not establish where a duplicate originated.

Where Repeated Events Come From

Pixel sends an event from the browser; CAPI sends it from the server. If both messages describe one action, the integration needs consistent data for matching them. Separately check whether the browser tag fires twice or the server creates a new ID when retrying a request.

Meta documents this boundary explicitly: deduplication compares a Pixel event with a Conversions API event. Two consecutive server events with the same information are not discarded, and neither are two consecutive browser events. Retrying a server request is an idempotency task for your own delivery state, not something the event-ID method covers.

Repeated events can distort counts and related metrics, but they do not mean every conversion doubled or CPA fell by exactly half. Compare the report with real actions and delivery logs.

Which Data to Compare

Event Name and Shared Identifier

Pixel uses eventID in the browser call, while CAPI uses event_id. The browser action name should match the server's event_name.

The table's event row denotes the browser event name: in the fbq example, that is Purchase. Do not add an arbitrary request field merely because the table uses that label.

A negative example: the browser sends eventID: "a1b2c3d4" while the server sends event_id: "e5f6a7b8". The key pairs do not match, so Meta discards neither copy; both remain in the data source. When a duplicate appears, first verify that the same value actually travels through both channels.

User Data Does Not Replace an Event ID

fbp represents a browser cookie, while external_id identifies a user in your system. Neither describes a particular purchase. If an integration uses additional matching methods, check their conditions in Meta's current documentation rather than assuming they provide a guaranteed substitute for a shared event ID.

Delivery Time

Send data without unnecessary delay and retain the actual action time. Meta documents that events are only deduplicated if they are received within 48 hours of Meta receiving the first event with a given event_id. The fbp/external_id fallback generally works for a browser-then-server pair; a server event is not discarded when no browser event arrived in the past 48 hours. Server-event age limits and advertising attribution windows serve different purposes; check them separately.

Passing a Shared Identifier

Step 1. Create the Action ID

The example generates a UUID and places it in the data layer. A data-layer entry does not itself send the value to CAPI; configure transport to the server component.

const eventId = crypto.randomUUID();
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ event: 'purchase', eventId: eventId });

Generate the ID for a new action, not separately for each delivery attempt of that event. If an order already has a suitable stable identifier, coordinate its use in both channels.

Step 2. Pass the ID to Pixel

Pass eventId from the previous step in eventID:

fbq('track', 'Purchase', {
  value: 49.99,
  currency: 'USD'
}, { eventID: eventId });

Step 3. Use the Same Value in CAPI

The following is an event-data fragment, not a complete ready-to-send request. Add required fields for your setup, including action_source, and use the actual time, amount, currency, and available user data.

{
  "event_name": "Purchase",
  "event_time": 1721650000,
  "event_id": "<same-uuid-from-step-1>",
  "user_data": { "fbp": "<original_fbp_cookie_value>" },
  "custom_data": { "value": 49.99, "currency": "USD" }
}

Send the stored cookie value in fbp without hashing. Do not copy the example event_time into a production event; it illustrates the field's format.

Step 4. Compare Event Names

Use the same spelling, including case, in both channels. Do not assume that Purchase and purchase match; inspect tag configuration and actual requests.

Step 5. Inspect Delays and Retries

Compare the action time with sending and receipt times. If the queue delays or repeats requests, investigate why and check whether retries retain the original ID.

Errors to Investigate

This table lists troubleshooting directions. Its percentage and secondary-method behavior are not universal outcomes for every integration; inspect actual events and the platform's current requirements.

Checking Results in Events Manager

1. Open Events Manager and select the intended data source.
2. Review available deduplication information in Overview.
3. Perform a controlled action and find the related events in Test Events, if your integration supports that testing method.
4. Compare browser eventID with server event_id and inspect the action name.
5. Check the received data against logs: both channels should describe one conversion rather than two different orders.

A low deduplication share may warrant investigation, but it does not prove that an ID is missing. First establish which events are actually sent through both channels.

What to Include in the Integration Check

• Compare Pixel eventID with CAPI event_id.
• Check that whitespace, type conversion, or regeneration does not alter the ID.
• Compare event_name with the browser event name, labeled event.
• Check delivery time and API responses separately from ad attribution.
• Confirm that fbp and external_id come from appropriate data sources.
• Review available Diagnostics messages and connect them to specific requests.

Interpreting Events Without Confirmed Deduplication

Do not conclude that Meta simultaneously preferred the first event and necessarily counted the second. Request acceptance, deduplication, and attribution represent different processing results. Retain identifiers and responses for a specific conversion so you can check each result separately.

Before Regular Delivery

• Define where event_id is created and how it reaches both channels.
• Establish one spelling of event_name for each action.
• Preserve the original identifier when resending the same conversion.
• Monitor delays and available Events Manager diagnostics.
• Repeat checks after changes to tags or the server handler.

Sources