Facebook CAPI Deduplication: Fix Duplicate Events (2026)

Affiliate disclosure: The Make.com link is an affiliate link. CreatorOpsMatrix may earn a commission at no additional cost to you.

Prefer a visual walkthrough?

Watch the CreatorOpsMatrix walkthrough showing the Pixel + CAPI event flow and the event_id matching problem.

1. What Meta CAPI Deduplication Actually Does

When you use both the Meta Pixel and Conversions API for the same website event, Meta can receive two representations of one real-world action.

For example, one purchase can produce:

• a browser-side Purchase event from the Meta Pixel; and
• a server-side Purchase event from a payment webhook, CRM, backend or automation platform.

That dual-channel architecture is useful because the two environments see different information and can have different delivery failure modes. Meta’s own Conversions API documentation has recommended browser + server connections for redundant event coverage.

The problem occurs when the two events do not give Meta enough information to recognize that they describe the same event.

2. The Two Primary Deduplication Keys: event_id + event_name

Meta’s documented primary deduplication method compares the browser event and server event using the same event_name and event_id, sent to the same Pixel ID. Events received within 48 hours of one another with those matching values are considered duplicates, and Meta discards the latter of the two.

event_id is the identity of the event, not the visitor

This distinction prevents a large number of implementation errors.

An event_id should identify one specific event instance. For a Purchase event, an order or transaction identifier is usually convenient because the identifier already exists in the business system.

A UUID also works when you generate it once and persist it so both tracking paths use exactly the same value. What you should not do is generate one random ID in the browser and independently generate another random ID in your server webhook.

Preserve the ID across retries

If a server request fails and your automation retries it, the retry should retain the original event ID for that same event. A retry that creates a new ID is no longer an identical replay from Meta’s perspective; it can become a second event.

event_name matters too

The event names need to correspond. For example, the browser event and CAPI event should both represent Purchase, not one side using Purchase and the other using a different event name.

Do not use a naming convention where the browser emits one event name and the server silently renames it during transformation. Treat the event name as part of the deduplication contract.

3. How Pixel + CAPI Should Fit Together

The two payloads do not need to contain identical information. Browser and server environments naturally have different context available to them.

For example, the server event may contain hashed customer information and payment-system data, while the browser event may contain browser-side identifiers. The key requirement for the primary deduplication method is that the event identity used for the two representations matches.

4. Exact event_id Implementation

For a purchase, imagine your commerce system has this order number:

order_18492

That value becomes the shared identity for the browser and server copies of the same Purchase.

Browser Pixel

fbq('track', 'Purchase', {
  value: 100.00,
  currency: 'USD'
}, {
  eventID: 'order_18492'
});

The important part is the fourth argument: the Pixel’s eventID.

Conversions API

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1760000000,
      "action_source": "website",
      "event_id": "order_18492",
      "user_data": {
        "em": ["NORMALIZED_SHA256_EMAIL"],
        "ph": ["NORMALIZED_SHA256_PHONE"],
        "fbp": "fb.1.example",
        "fbc": "fb.1.example"
      },
      "custom_data": {
        "value": 100.00,
        "currency": "USD"
      }
    }
  ]
}

The browser and server examples use the same logical event:

Do not copy the example hashes or IDs into production. They are placeholders illustrating the structure. Your implementation needs the actual values belonging to the event being sent.

Good event_id sources

For a Purchase, an existing order or transaction identifier is often easier to reconcile against your own records than a newly invented identifier.

5. The Most Common Causes of Duplicate Meta CAPI Events

When one purchase appears twice, do not immediately assume Meta’s deduplication system is broken. Work through the event sources.

1. Browser and server use different event IDs

This is the classic failure:

Browser:
eventID = order_18492

Server:
event_id = 6a1a8f4e-new-random-id

Those are different event IDs. Meta cannot treat them as the same event under the primary deduplication method.

2. One side has no event ID

If the browser sends a Purchase without the shared event ID while the server sends a different or independent ID, the two implementations have no deterministic primary deduplication key.

3. Multiple systems are all sending Purchase

This is especially common after adding server-side tracking.

For example, a business might have:

• a native ecommerce-platform Meta integration;
• a Google Tag Manager browser implementation;
• a server-side GTM or CAPI connector; and
• a custom Make.com webhook sending Purchase.

Every individual integration can appear to be working correctly while the combined system sends the same purchase more than once.

4. The event names don’t correspond

Check the browser event name and the CAPI event_name together. Standardize the naming convention before debugging anything else.

5. The CAPI event is delivered too late

Meta’s primary deduplication method uses a 48-hour matching window. A payment event normally should not be sitting in a queue for days before the corresponding CAPI request reaches Meta.

For delayed server processing, inspect the real event timestamps and the time Meta receives the events instead of assuming that the original transaction time tells you whether the deduplication window was met.

6. A retry generates a new event ID

This is a subtle but important failure in custom webhook systems.

Correct:

Attempt 1 → event_id = order_18492
Attempt 2 → event_id = order_18492
Attempt 3 → event_id = order_18492

Dangerous:

Attempt 1 → event_id = order_18492
Attempt 2 → event_id = retry_839221
Attempt 3 → event_id = retry_410882

The retry logic should preserve the event identity. A retry is another delivery attempt for the same event, not a new real-world purchase.

7. The Pixel and CAPI are pointing at different destinations

Verify the Pixel or dataset destination on both sides. The primary method requires the events to be associated with the same Pixel ID.

8. The Purchase fires more than once in the browser

Not every duplicate Purchase problem is Pixel-versus-CAPI duplication. A thank-you page that fires Purchase again after a refresh, multiple tracking plugins, duplicate tag-manager triggers, or a checkout script that initializes twice can produce multiple browser events before CAPI is even considered.

Always establish how many times the browser event itself fires, how many times the server event fires, and how many sources are involved.

6. How to Test Meta CAPI Deduplication

Do not validate a new implementation solely by looking at campaign-level ROAS. Use Meta’s event-testing tools and compare the actual browser and server payloads.

Step 1: Generate a controlled test event

Open Meta Events Manager and use the Test Events area for the relevant data source. Meta’s Conversions API playbook documents using a test event code so server events can appear in the Test Events window.

Step 2: Trigger one test conversion

Use a controlled test purchase or equivalent test event. Do not generate several unrelated test events before you understand what the first one produced.

Step 3: Verify the browser event

Confirm the browser event contains:

• the expected event name;
• the expected event ID; and
• the intended destination Pixel/dataset.

Step 4: Verify the server event

Inspect the server-side request generated by your platform, webhook or Make scenario.

For the same test transaction, confirm:

Browser:
event = Purchase
eventID = order_TEST_001

Server:
event_name = Purchase
event_id = order_TEST_001

Step 5: Check the resulting event information

Meta’s documentation describes Event Overview and Event Deduplication views where you can inspect received, processed and deduplicated events and review deduplication-key coverage.

7. Event Coverage Is Not the Same as Event Deduplication

This distinction is important because Meta now exposes several separate diagnostics, and the terms are easy to mix up.

Meta’s documentation separates these diagnostics: Event Deduplication examines redundant events and their deduplication keys, while Event Coverage and Data Freshness measure different parts of the data connection.

8. Deduplication vs Event Match Quality

Event Match Quality is another separate diagnostic.

Fixing duplicate Purchase events does not automatically make the server events easier for Meta to match to people. Conversely, a server event can have useful customer information while still being incorrectly duplicated.

For that reason, treat these as two separate engineering tasks:

• Deduplication: make the browser/server copies identify the same event using the appropriate deduplication keys.
• Match quality: send accurate customer information in the format Meta expects when that information is legitimately available.

Do not invent customer identifiers simply to increase a score. Use real information collected through the applicable customer journey and handle consent and data-processing requirements appropriately.

For the complete normalization, hashing, fbp, fbc, IP, user-agent and external_id discussion, see the dedicated Facebook CAPI Match Quality guide. That page deliberately treats EMQ as a diagnostic rather than a universal pass/fail number.

9. The Secondary Deduplication Method

Meta’s developer playbook also documents a secondary method that can use event_name together with fbp and/or external_id, plus event timing. The browser event must arrive first for this method, and Meta explicitly recommends the event_name + event_id method instead because the fallback has limitations.

This is why a common explanation that says “Meta deduplicates on fbc, fbp and IP” is misleading.

fbc and fbp are useful customer/browser context, and they can contribute to matching and attribution, but they should not be substituted for a stable shared event_id when you control both event paths.

10. What a Clean CAPI Purchase Architecture Looks Like

A practical implementation can look like:

Customer completes order
        ↓
Order / transaction ID created
        ↓
 ┌───────────────────────┐
 │   Shared event_id     │
 │   order_18492         │
 └───────────────────────┘
        ↓
   ┌───────────────┬───────────────┐
   ↓                               ↓
Browser Pixel                    Server
Purchase                         Purchase
eventID                           event_id
order_18492                       order_18492
   │                               │
   └──────────────┬────────────────┘
                  ↓
             Meta dataset
                  ↓
        Deduplication + processing

11. Where Make.com Fits

Make.com does not perform Meta’s deduplication decision. Its role is to help you move, transform and deliver the event correctly.

A typical Make-based architecture can look like:

Payment / CRM / Application
        ↓
Make Webhook
        ↓
Validate event
        ↓
Map event fields
        ↓
Preserve event_id
        ↓
Normalize / hash eligible customer data
        ↓
HTTP or Meta integration
        ↓
Meta Conversions API

The critical part is not “using Make.” It is preserving the event identity from the originating business event through the entire automation.

If a Stripe webhook contains an order or transaction identifier, that value can be carried into the CAPI event. If your source already contains a browser-generated event ID, the automation should preserve that same ID instead of creating a new one at the webhook stage.

When Make is useful for this architecture

• Payment processors need to send conversion events into Meta.
• CRM events need to be routed into Conversions API.
• You need field transformation before delivery.
• Customer information needs controlled normalization and hashing.
• You want logging and error handling around the API request.
• You need one event source to feed several downstream systems.

Related Meta Tracking Fixes

Frequently Asked Questions

Official Documentation