Meta Pixel and CAPI Deduplication: How event_id Actually Works

One purchase can produce a browser request, a server request, several payment notifications, and a retry after a timeout. Those are delivery attempts, not necessarily separate conversions. Reliable Meta tracking starts by giving the underlying business event a stable identity, then preserving that identity wherever the event travels.

Scope: website events sent through Meta Pixel and the Conversions API (CAPI). Reviewed on September 14, 2026. Payloads, order numbers, and numerical examples below are illustrative, not results from a live advertiser account.

Executive summary

Meta recommends sending overlapping website events through Pixel and CAPI. In that setup, the two channels should describe the same action rather than independently invent two conversions. Matching event names and IDs are the recommended foundation for deduplication. [1]

The engineering requirement is broader: one business occurrence, one stable event identity, multiple possible delivery attempts. Create or assign the identifier at the point where the occurrence becomes authoritative. Save it, share it with the browser, and reuse it for retries. A new real purchase needs a new identity; another notification about an existing purchase does not.

Do not confuse deduplication with user matching, payment-webhook idempotency, or ad attribution. Each answers a different question. An integration can have excellent customer matching and still produce duplicate purchases. It can also receive two raw events for one purchase without counting two advertising conversions.

1. Start with the event, not the HTTP request

For this article's ecommerce example, define Purchase as the business transition to a successfully paid order. This is an implementation choice, not a universal requirement to recognize every business's revenue at the same point. Document the chosen transition before implementing tags.

Suppose order ord_8421 becomes paid. The application creates a canonical purchase record. The confirmation page reads that record and sends a Pixel event. A worker sends its CAPI counterpart. A payment provider later retries its webhook.

There is still one purchase. The webhook is evidence about that purchase, not a reason to create another marketing event.

This distinction also prevents semantic mistakes. A click on Pay, successful submission of payment details, and a confirmed payment are not interchangeable. For delayed payment methods, a completed checkout session may still require later confirmation. Stripe explicitly distinguishes immediate and delayed payments and requires fulfillment logic to tolerate repeated, concurrent calls. [2]

metricfixer's recommendation: write a one-sentence contract for each event: what happened, which system confirms it, and what makes a second occurrence genuinely different.

2. What Meta compares, and where the fields belong

For the recommended event-ID method, corresponding browser and server events need matching names and identifiers, must reach the same Pixel/data source, and must fall within Meta's documented receipt window. Merely belonging to the same business account is not enough. [3]

Meta's Pixel reference places eventID in the fourth argument of fbq('track', ...). Putting an event_id property among ordinary purchase parameters is not equivalent. [4]

On CAPI, event_id belongs to each event object inside data. It is not a request-level identifier and does not belong inside user_data or custom_data. Meta describes it as a string; although optional in the API schema, it is recommended for deduplicating overlapping events. [5]

Treat it as an opaque, case-preserved string. Do not independently trim, lowercase, add prefixes, or convert it to a number downstream. For example, an application that transforms "0008421" into 8421 has changed its identifier before Meta receives it.

Identifiers that answer different questions

external_id represents a person in the advertiser's system. fbp identifies a browser, and fbc carries click-related information. These customer-information parameters serve matching purposes; they should not be mistaken for a unique purchase identity. [6] [7]

Meta also documents an alternative deduplication route involving the event name and fbp and/or external_id. Its limitations include browser-first ordering and no same-source deduplication under that method. Those limitations belong to the alternative method; do not generalize them into a claim that every possible CAPI retry is always counted twice. [3]

Similarly, order_id is not a universal substitute for explicitly supplying event_id. Meta's end-to-end guide describes order-ID deduplication as a capability limited to selected partners. A custom integration should not assume that an order number sitting in custom_data, or a GA4 transaction_id, automatically activates that capability. [8]

3. A correctly paired browser and server event

Create the following record once, after the authoritative purchase transition. Its readable identifier is an example of an internal naming convention, not a Meta-required format.

{
  "eventName": "Purchase",
  "eventId": "prod:store7:purchase:ord_8421",
  "occurredAt": "2026-09-14T10:00:00Z",
  "orderId": "ord_8421",
  "value": 129.00,
  "currency": "USD",
  "sourceUrl": "https://shop.example/checkout/complete"
}

The browser receives a permitted, server-validated representation of this record. Once the relevant consent and firing conditions are satisfied, its Pixel call is:

// purchase is the canonical record returned by your application.
// The Meta Pixel base code must already be initialized.
fbq(
  "track",
  purchase.eventName,
  { value: purchase.value, currency: purchase.currency },
  { eventID: purchase.eventId }
);

The server builds its request from the persisted record, not from a fresh random ID or the webhook's delivery timestamp:

// Run on the server. This example constructs a payload; it does not send it.
const eventTime = Math.floor(Date.parse(purchase.occurredAt) / 1000);
if (!Number.isFinite(eventTime)) {
  throw new Error("Invalid persisted purchase timestamp");
}

const capiRequest = {
  data: [{
    event_name: purchase.eventName,
    event_id: purchase.eventId,
    event_time: eventTime,
    action_source: "website",
    event_source_url: purchase.sourceUrl,
    user_data: permittedCustomerData,
    custom_data: {
      value: purchase.value,
      currency: purchase.currency,
      order_id: purchase.orderId
    }
  }]
};

These snippets explain field placement, not a complete checkout integration. permittedCustomerData must be assembled from legitimately collected, correctly formatted customer information. For website events, Meta requires the applicable website fields, including the customer's client_user_agent, action_source, and event_source_url; follow its current parameter requirements. [9]

Do not substitute the payment provider's webhook IP address or user agent for the customer's browser context. Preserve permitted browser context with the business record when appropriate. Follow Meta's field-specific hashing rules; do not indiscriminately hash the entire payload. [6]

Keep the access token on the server. Validate the order's state and amount against trusted backend data rather than trusting values supplied by a browser.

Where multiple Pixels are initialized, track can address all of them. Use an intentional destination policy; Meta also documents trackSingle for targeting one Pixel. In that call, the event-options object follows the additional Pixel-ID argument. [3]

4. How to choose an ID that survives real traffic

An identifier needs two properties: uniqueness between different occurrences and stability across representations of the same occurrence.

A random UUID can satisfy the first property while completely failing the second. Browser UUID A and webhook-worker UUID B are both unique, but they do not identify the same event. Conversely, a customer ID is stable but is not unique to each purchase.

Meta permits advertiser-chosen unique strings and gives order or transaction identifiers as possible examples. An event without a natural identifier can use a generated value, provided the corresponding channels share it. [5]

Recommended identity contracts

The following are architecture recommendations, not platform-mandated formats.

A product ID is not an add-to-cart occurrence ID. A URL is not a page-view occurrence ID. A subscription ID is not an individual renewal ID. The same entity can participate in many real events.

Namespace identifiers where different stores or environments could produce identical local order numbers. A prefix such as prod:store7:purchase: helps prevent collisions, but a test: prefix does not isolate test traffic from production measurement. Use a separate test data source for synthetic traffic.

Do not embed an email address, phone number, or secret order-access token in event_id. An opaque generated ID or a carefully designed deterministic token is preferable when the original business identifier should not be exposed. Keep a protected internal mapping for reconciliation.

Reject empty identifiers and accidental strings such as "undefined", "null", or "[object Object]" at your validation boundary. A timestamp generated when a tag fires is also a poor substitute for a business-occurrence identity: retries change the time, and independent browser and server clocks do not establish a shared ID.

Backend-first versus browser-first generation

For purchases and accepted leads, backend-first identity is usually easier to reconcile: create the occurrence record and return its ID to the browser. A webhook and a confirmation-page request may race; both should resolve to the same persisted occurrence.

For an interaction that originates only in the browser, generate an ID once when the action occurs, then send that value to both the Pixel path and the collection endpoint. crypto.randomUUID() provides a browser mechanism for generating UUIDs in supported secure contexts; it does not provide persistence or synchronization by itself. [10]

Do not wait for a future webhook ID to become your only browser/server join key. The browser may never receive that notification, and different notifications can describe the same business transition.

5. Why GTM and server-side GTM do not solve identity automatically

In a tag-managed implementation, publish the event data and its existing identifier together:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase_confirmed",
  meta_event_name: purchase.eventName,
  meta_event_id: purchase.eventId,
  order_id: purchase.orderId,
  value: purchase.value,
  currency: purchase.currency
});

Use a Custom Event trigger for purchase_confirmed. Map the data-layer value to the browser tag's Event ID field and preserve it through the route that constructs CAPI events. Google documents ordered data-layer processing and recommends an explicit event when updated values need to be available to the relevant tags. [11]

The internal GTM trigger name does not have to equal Meta's event name. In this example, purchase_confirmed activates the tags; both outgoing Meta events are Purchase.

A server-side container cannot recover an identifier that was never forwarded. Nor should a server tag silently replace an incoming ID with a new UUID. Inspect the final payload after template mappings and transformations, not just the variable visible in web GTM Preview.

For this purchase contract, treat a missing canonical ID as a data-quality failure to resolve, not an invitation for each tag to generate its own fallback. Also test stale state: a single-page application must not accidentally reuse the previous order's value or ID for a later purchase.

An old receipt view is not a new purchase. Define a browser firing policy that prevents routine replay when a customer returns to a historical confirmation page; preserving the old ID is not a substitute for that policy. The payload example above demonstrates field placement, not a complete repeat-firing guard.

Finally, distinguish a browser-relayed server path from an independent backend path. Meta's CAPI Gateway can generate and propagate deduplication keys for its own Pixel-to-Gateway flow. That does not automatically establish the same identity in an unrelated payment-webhook integration. [12]

Choose an owner for each event type and destination. Adding a gateway, ecommerce plugin, custom CAPI worker, and CRM export is not automatically better coverage when several of them report the same purchase independently.

6. The 48-hour rule, the five-minute statement, and late retries

Meta's deduplication guide states that matching browser/server events must arrive within 48 hours of its receipt of the first event with that ID. This is a receipt window, not permission to keep re-emitting a purchase indefinitely. [3]

Consider this hypothetical sequence: Meta receives the browser event on Monday at 10:00. Its matching server event arrives Tuesday at 16:00, 30 hours later. That is within the documented interval. A counterpart arriving Wednesday at 12:00 is 50 hours later and is outside it, even if its event_time still accurately describes Monday's purchase.

Keep three clocks separate:

For the website events discussed here, Meta's API documentation permits event_time up to seven days before submission. That event-age allowance is not a seven-day deduplication window. Do not rewrite an old purchase's timestamp to make a late replay look new. [13]

Does Meta always keep the browser event?

The public documentation uses two formulations. The server-event reference describes favoring the browser/app event when the pair arrives within five minutes. The dedicated deduplication guide says Meta generally prefers the first received event when the content does not differ meaningfully and refers to multiple processing strategies. [5] [3]

The safe implementation conclusion is not to engineer a race between two conflicting payloads. Send both promptly, with consistent purchase details. Neither formulation is a universal promise that the server copy always replaces the browser copy or that all missing fields will be merged exactly as the advertiser expects.

Likewise, resubmitting an existing ID with a changed value is not a documented general-purpose update operation. Model corrections and refunds separately in the business ledger, then evaluate the platform's specifically supported reporting options. Do not use deduplication as an accounting adjustment mechanism.

7. Repeated webhooks require their own idempotency design

Deduplication asks whether two tracking messages represent one event. Idempotency asks whether processing the same operation again changes the result. Your application needs to address both.

Stripe documents that a webhook can arrive more than once, that separate Event objects can represent duplicates, and that live delivery retries can continue for up to three days. Event ordering is not guaranteed. This is why a payment integration must tolerate repeats and out-of-order notifications rather than assuming one callback per purchase. [14]

Protect transport receipt and business meaning separately

At the transport layer, save the provider's event identifier in a durable inbox. Scope it appropriately, including the provider account. This prevents reprocessing the same notification.

At the business layer, several different notifications may still resolve to one paid-order transition. Apply a separate uniqueness rule to that occurrence. Merely deduplicating provider event IDs will not stop two distinct notifications from creating two marketing purchases.

For example, the application might receive checkout.session.completed and payment_intent.succeeded. The recommendation is not to treat those names as interchangeable or assume both always arrive. It is to verify payment state and map the relevant notifications to the correct internal occurrence before deciding whether a new Purchase exists.

An illustrative database contract could enforce:

Inbox uniqueness:
(provider, provider_account_id, provider_event_id)

Business-event uniqueness:
(environment, store_id, business_occurrence_id, event_name)

Destination-delivery uniqueness:
(meta_destination_id, event_name, event_id)

business_occurrence_id must reflect the chosen contract: one order, one renewal invoice, or another explicitly defined transition. These are conceptual keys, not a complete database migration.

Use database-enforced uniqueness and transactions rather than a vulnerable "check, then insert" sequence. Two workers can both pass an application-level check before either writes its result.

Make durable storage precede successful acknowledgement

A robust pattern is to verify the webhook signature, durably store its receipt, and then acknowledge it promptly. A background worker resolves the business transition and commits the canonical event together with an outbox entry. A sender delivers the pending outbox entry to Meta.

The transactional outbox is a stored queue written in the same transaction as the business change. It avoids the failure gap in which an order is saved but its tracking work is lost. AWS also cautions that message delivery can still repeat, so consumers need idempotency. [15]

In this architecture, a repeat notification finds existing work instead of creating a fresh event. A transient CAPI failure creates another delivery attempt, not a new purchase. Record a separate attempt_id for operations while retaining the original event_id, event name, destination, and occurrence time.

A timeout is ambiguous: Meta may have received the request before the response was lost. Retry deliberately with the same identity and bounded backoff. Persist known successful outcomes so they are not routinely resent. Route permanent errors and late, ambiguous replays for investigation instead of endlessly regenerating IDs or timestamps.

The outbox does not make an HTTP destination exactly-once by magic. It improves recoverability and makes the remaining ambiguity visible. Retain the necessary deduplication state for the real webhook-retry and replay lifecycle, subject to your retention policy, not merely for Meta's 48-hour pairing interval.

8. Common causes of double counting and silent undercounting

The table below is a diagnostic model derived from the identity contracts above. It is not a claim about how frequently each problem occurs.

A high ID-presence rate is therefore not enough. Every event can contain an ID while all IDs are wrong, all browser/server pairs disagree, or several orders share one constant value.

Also separate duplicate firing from actual double payment. If two genuine orders were created, a tracking rule that merges them is hiding a checkout defect, not improving measurement.

9. How to verify the implementation without misreading Events Manager

First, follow one known occurrence end to end

Use a controlled purchase in an isolated test setup. Record the internal order ID and canonical event ID. Inspect the actual browser network request and server payload for that same occurrence.

For the browser request, check the destination ID, event name, and event identifier. Meta documents the wire parameter eid for an image Pixel request; browser tools may display equivalent fields in their own UI. An ID visible only among custom parameters is not evidence that the proper event-ID option was supplied. [3]

Check the outgoing CAPI event after server-side templates or transformations. A correct incoming request to a server-side container does not prove that the outgoing Meta request remained correct.

Use a redacted technical log containing the business occurrence, destination, event name, canonical ID, original timestamp, send time, attempt ID, integration owner, and response status. Avoid routine logging of access tokens, raw contact information, or full customer payloads.

Second, distinguish receipt, matching, and deduplication

A successful CAPI response can include events_received, messages, and fbtrace_id. This acknowledges the API interaction; it is not an order-level report proving the final number of deduplicated, attributed conversions. Meta's implementation guide treats sending, verification, and optimization as distinct stages. [8]

Events Manager's Overview can show received events before deduplication, consent filtering, and other processing. Its event details include deduplication-key usage and overlap information. A high Event Match Quality score concerns matching customer information to Meta accounts, not proof of one-purchase-one-event identity. [16]

Use the current interface's equivalent panels for the selected event type and data source. UI labels and access can vary. Pixel Helper or GTM Preview alone cannot validate the entire browser-to-server pair.

Third, test failure paths deliberately

The following are acceptance criteria for the proposed architecture, not claimed observations from a live Meta account.

Testing an arrival delay beyond 48 hours is different from changing event_time. The latter does not simulate the receipt interval. Test late-replay handling locally, and use a separately planned, isolated end-to-end test when platform-side timing must be verified.

Important: Meta's current API documentation warns that events sent with test_event_code are not automatically discarded and can be used for targeting and measurement. Do not treat that field as a production-data sandbox. Use a separate test Pixel/data source for synthetic purchases, and remove the test code from production requests. [13]

10. Why 180 received events can represent 100 purchases

Consider an intentionally simplified example: 100 legitimate purchases, 80 received browser copies, and 100 received server copies. Every browser copy has the matching server identity; there are no retries, collisions, or other processing exclusions.

That produces 180 raw received messages but only 100 distinct business-event identities. The 80 matching pairs account for the difference. The remaining 20 purchases have only a server representation.

For an internal audit, define browser and server sets using distinct (destination, event_name, event_id) tuples. Then:

Distinct observed event identities = |Browser union Server|
                                  = |Browser| + |Server|
                                    - |Browser intersection Server|

This is set arithmetic for your own reconciled logs, not a reconstruction of Meta's proprietary processing or a formula for Ads Manager results. Wrongly assigned IDs also produce misleading set counts, so verify the mapping to actual business records.

Measure completeness against the subset that your business rules and privacy controls legitimately allow you to send. Separate paired website events from valid server-only events. Track missing IDs, one occurrence with multiple IDs, one ID with multiple occurrences, payload disagreement, and delivery lag.

Do not insist that browser and server volumes be identical, or that every server event must have a browser counterpart. Meta explicitly supports server events for actions the Pixel cannot capture. [1]

Finally, do not sum advertising platforms' attributed purchases and compare that total with your order ledger as if it were an identity audit. Start with the canonical business events and raw delivery evidence; investigate attribution separately.

11. Consent, migrations, and safe rollout

Apply the same relevant sharing-consent logic to Pixel and CAPI. Meta's end-to-end guide explicitly recommends aligning those controls. Disabling a browser tag because sharing is not permitted, then sending the same data from the server, is not a deduplication fix. [8]

For implementation changes, begin with an inventory of every sender, its owner, destination, event contract, and ID-generation rule. Remove redundant writers deliberately rather than turning off all browser tracking or all server tracking to make the totals look smaller.

Preserve existing identities for events already in flight. If a new release changes an ID format while an old queue is retrying, the same purchase can acquire two identities. Version the implementation without renaming an occurrence that already exists.

Run the failure-path tests before rollout and reconcile new traffic after deployment. A reduction in reported purchases after removing duplicates may reflect cleaner measurement rather than worse sales; use the order system to determine what actually changed.

Frequently asked questions

Can I use the order number as event_id?

Yes, when it uniquely identifies the purchase occurrence and remains unchanged across the relevant systems. Scope it to avoid store or environment collisions. A persisted opaque ID is also suitable. [5]

Does every event need a UUID?

No. UUID is an ID-generation format, not the deduplication mechanism. A well-scoped stable string can work; independently generated UUIDs cannot identify one shared occurrence. [5]

Will sending the same email on both events fix different event IDs?

Do not rely on that. Customer matching and event identity are different controls. Implement the recommended matching-name-and-ID contract and audit the final payloads. [1] [6]

Does Meta guarantee deduplication of every server-only retry forever?

The documented Pixel/CAPI receipt window is not a permanent application idempotency guarantee. Keep stable retry identities and your own durable occurrence and delivery records. [3]

Will changing the implementation repair earlier double counts?

Treat the fix as prospective unless a separately documented platform process establishes otherwise. Record the deployment boundary and preserve the reconciliation evidence; do not assume that resending old events rewrites previous reports.

The practical takeaway

The most useful question is not "Which random-ID generator should we install?" It is "Where does this business event become real, and how do all of its representations keep the same identity?"

Answer that once for each event type. Preserve the result through tags, APIs, webhooks, and retries. Then verify identity, business uniqueness, and reporting as separate layers.

For a metricfixer review, prepare a redacted browser request, its server counterpart, the internal order or submission reference, destination IDs, and a short delivery timeline. Start with one occurrence that can be followed end to end. Do not send passwords or access tokens with the request.

Methodology and sources

This article synthesizes first-party Meta, Google, Stripe, AWS, and MDN documentation with an original implementation and verification model. The proposed database keys, operational controls, diagnostic tables, and numerical example are engineering recommendations or illustrative reasoning, not published Meta performance benchmarks. No advertiser account was accessed and no live conversion experiment was performed for this article.

Some Meta documentation uses different wording about event selection and specialized deduplication features. Those differences are identified where relevant rather than treated as a universal processing guarantee. Platform interfaces, integrations, and documentation can change after the review date.

1. Meta: Conversions API best practices - redundant events, event identity, and server-only event use cases.
2. Stripe: Fulfill orders - payment-state verification, delayed payment methods, and concurrent fulfillment calls.
3. Meta: Handling duplicate Pixel and Conversions API events - recommended identity matching, destination scope, receipt window, alternative matching limitations, and Pixel examples.
4. Meta Pixel reference - event names, parameters, and the eventID option.
5. Meta: Server event parameters - event name, event ID, occurrence time, and the five-minute selection wording.
6. Meta: Customer information parameters - browser and customer identifiers, formatting, and hashing requirements.
7. Meta: External ID - the distinction between a customer identifier and an event occurrence.
8. Meta: Conversions API end-to-end implementation - consent alignment, selected-partner order-ID deduplication, and verification stages.
9. Meta: Conversions API parameters - website-event requirements and payload structure.
10. MDN: Crypto.randomUUID() - browser UUID generation and secure-context requirements.
11. Google: The data layer - event ordering and data-layer message handling.
12. Meta: Conversions API Gateway - automatic key propagation within the gateway's documented flow.
13. Meta: Using the Conversions API - event-age limits and the warning about test_event_code.
14. Stripe: Receive Stripe events in your webhook endpoint - duplicate deliveries, retries, ordering, signature verification, and acknowledgement.
15. AWS: Transactional outbox pattern - durable messaging, transaction boundaries, and idempotent consumers.
16. Meta: Verifying your setup - raw received events, deduplication monitoring, and Event Match Quality.

This article provides technical and operational information, not legal advice or a guarantee of platform behavior or advertising results. metricfixer is not affiliated with Meta, Google, Stripe, AWS, or Mozilla. Apply the privacy requirements and platform terms relevant to your implementation.