Fix Facebook CAPI Deduplication: Stop Duplicate Events (2026)

Prefer a visual breakdown?

If you need a full understanding of exactly how the dual tracking trap inflates your ROAS, and how to map the event_id to verify your payloads, watch the architectural teardown from CreatorOpsMatrix below.

The ROAS Lie: Why Duplicate Events Kill Campaigns

After debugging broken backend setups for scaling agencies, the diagnosis is consistent: if your Facebook CAPI deduplication is broken, your ROAS is unreliable. You might look at Ads Manager and see a highly profitable campaign, but you are scaling spend based on duplicated conversions. When you double-count purchases, the algorithm optimises against corrupted signals and actively erodes your real margins while reporting fictional returns.

The root cause is almost always the same. When operators migrate to server-side tracking, standard practice dictates running dual tracking — firing the Meta Pixel from the browser while simultaneously firing a server-side webhook from the payment processor. This redundancy is correct architecture. It ensures conversions are recorded even when ad blockers strip the browser pixel. The problem is that executing dual tracking without proper event_id matching gives Meta two separate signals for the same purchase, which it counts as two conversions.

The financial consequence is not just reporting inaccuracy. Meta’s algorithm uses conversion data to optimise ad delivery toward audiences most likely to convert. When your conversion data is doubled, the algorithm learns from a distorted dataset — it over-bids on audiences and creative combinations based on inflated performance signals. Campaigns that appear to be performing at 4x ROAS may be running at 2x in reality. The deduplication error corrupts the optimisation loop, not just the dashboard numbers.

The Core Mechanism: How event_id Deduplication Works

According to Meta’s official Conversions API deduplication documentation, the Graph API relies on a primary matching variable called the event_id. When both the browser pixel payload and the server-side CAPI payload carry an identical event_id string, Meta’s deduplication engine recognises them as the same event and discards the redundant signal, recording a single accurate conversion.

Without an explicit event_id in both payloads, Meta falls back to attempting deduplication via fbc and fbp cookie parameters combined with IP address matching. This fallback is unreliable — it fails entirely for users on VPNs, users who have cleared cookies, users in cross-device journeys, and users whose browsers block first-party cookie storage. The event_id is the only deterministic deduplication signal.

The Two Rules Most Setups Get Wrong

There are exactly two conditions Meta checks, and both have to pass. Most broken setups pass one and silently fail the other.

• The event_id string must match byte-for-byte. A trailing space, a different casing convention, or a truncated string breaks the match with no error thrown — the events simply never merge.
• The event_name must match exactly, including capitalization. A Pixel event fired as Purchase will not deduplicate against a CAPI event sent as purchase. Meta treats these as two distinct event types, so even a perfect event_id match will not save you if the names don’t agree.

Both events also have to land inside Meta’s 48-hour deduplication window. If your server-side event fires more than 48 hours after the browser event carrying the same event_id, Meta no longer merges them — both get counted. In practice this only bites you on delayed-fulfillment flows (offline sales synced later, backorder confirmations), but it’s worth checking if your CAPI events are queued rather than sent in real time.

Implementation: The Exact Code for event_id Matching

The event_id must be generated once per conversion event and passed to both the browser pixel and the server-side API payload simultaneously. The value can be any unique string — a transaction ID from your payment processor, a UUID generated at checkout initiation, or a timestamp-based hash. The only requirement is that both payloads carry the exact same string with no variation in casing or formatting, and the same event_name.

1. The Browser Pixel Payload (JavaScript)

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

2. The Server-Side CAPI Payload (JSON)

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1715000000,
      "action_source": "website",
      "event_id": "txn_12345",
      "user_data": {
        "em": ["HASHED_EMAIL_SHA256"],
        "ph": ["HASHED_PHONE_SHA256"],
        "fbc": "fb.1.1715000000.AbCdEfGhIjKlMnOp",
        "fbp": "fb.1.1714000000.1234567890"
      },
      "custom_data": {
        "value": 100.00,
        "currency": "USD"
      }
    }
  ]
}

Note that event_name is "Purchase" in both payloads above, matching the Pixel’s 'Purchase' string exactly. This is the detail that breaks silently. The server payload also includes the user_data object with hashed email and phone fields, required for Event Match Quality scoring — see the full EMQ optimisation guide for the correct SHA-256 normalisation sequence. The fbc and fbp parameters come from the browser cookies set by the Meta pixel and should also be passed server-side when available to maximise match rates.

What Event_id Values Are Valid

Diagnosing 0% Event Coverage

Operators implementing dual tracking frequently check their Events Manager after deployment and find a 0% Event Coverage warning next to their Purchase event. This warning has a specific meaning: Meta is receiving your server-side CAPI events but cannot find any browser pixel events to match them against. The server stream is working. The browser stream is broken, absent, or firing against stale data.

The standard engineering causes of 0% event coverage are:

• Asynchronous Loading Conflict: If your pixel loads via Google Tag Manager and the event_id is generated by a separate script, the pixel may fire before the ID is available, sending a null eventID value to Meta. The pixel fires successfully but without a deduplication key, making it impossible for Meta to match it to the server event.
• Performance Plugin Deferral: WordPress optimisation plugins routinely defer JavaScript execution to improve page load scores. If they defer your Meta pixel script, the browser event fires after the user has already left the purchase confirmation page, or does not fire at all.
• Stale Server Cache: If you enable CAPI on a live site without purging the server-side page cache, cached checkout confirmation pages keep serving the pre-CAPI pixel snippet. The server sends events correctly; the browser is silently running outdated code. Clearing the full-page cache after any CAPI configuration change resolves this immediately.
• Hosted Payment Gateway: If your checkout redirects to a third-party payment page and the user does not return to a confirmed Thank You page on your domain, the pixel has no page environment to fire in. The server catches the payment webhook but no browser event is recorded.
• Ad Blocker Rate: In audiences with high technical literacy — developers, SaaS operators, security professionals — ad blocker penetration can exceed 40%. If your audience skews technical, a meaningful percentage of browser events will never fire regardless of implementation quality, resulting in a non-zero but below-par coverage score.

Recommended CAPI Stack for 2026

To avoid building custom API routing from scratch and risking implementation errors that break deduplication silently, standardise your execution stack across these three layers. The combination covers pixel firing, server-side routing, and managed attribution without redundant tooling.

• Make.com: The primary logic engine for catching Stripe or Shopify payment webhooks, extracting the transaction ID as the event_id, normalising and hashing customer PII, and routing the structured JSON payload to the Meta Graph API endpoint.
• GTM Server-Side: For operators requiring Google Analytics 4 event routing alongside Meta, a server-side GTM container allows a single server-side tag to distribute event data to multiple ad platforms without duplicate frontend pixel implementations.
• Managed Attribution: If your team lacks the engineering bandwidth to maintain custom webhook routing, a managed attribution platform handles the server-side connection automatically. Review the Hyros alternative guide for a cost comparison between managed and self-built attribution infrastructure.

After Deduplication: Low EMQ Scores

Fixing deduplication resolves the double-counting problem but does not automatically improve Event Match Quality. EMQ scores measure how well Meta can match your server-side events to real Facebook user profiles. A score below 6.0 out of 10.0 means a significant proportion of your server events are landing without being attributed to a known user — reducing the optimisation value of the server-side data.

Low EMQ after fixing deduplication almost always indicates a PII normalisation error. Email addresses passed to the Meta API must be lowercased and stripped of whitespace before SHA-256 hashing. Phone numbers must include the country code prefix and contain only digits. If your Make.com scenario is hashing raw email values without normalising them first, the hashes will not match Meta’s stored user data even when the underlying email address is correct. The full normalisation and hashing sequence is documented in the Facebook CAPI match quality optimisation guide.

Related Attribution Guides

Frequently Asked Questions