Pixel and CAPI Deduplication: A Practical Guide

Anyone running the Pixel and CAPI together (the setup Meta itself recommends) eventually hits the same question: why does the campaign’s conversion count look higher than it should? Most of the time, the answer is broken Pixel and CAPI deduplication: the same event arriving through two channels and being counted twice. This guide shows the mechanism behind it, how to implement the shared event_id correctly and how to check that it’s working.

If you don’t know yet what CAPI is or why it became necessary in a Telegram funnel, start with the guide to the Facebook Conversions API. This article assumes that context and focuses only on the deduplication mechanism. The quick definition of event deduplication is also in the glossary, if you only need the summary.

Why the Pixel and CAPI duplicate the same event

The Pixel and CAPI don’t know, by default, that they’re reporting the same thing. The Pixel fires in the browser when the script loads on a page; CAPI fires from the server when the backend detects that the event happened. If both are set up to report the same event (say, the Lead from a submitted form or the Purchase from a checkout), each sends its own call to Meta, with no link between them by default.

From Meta’s point of view, two calls with no identifier in common are two distinct events. The result is one real conversion turning into two rows in the campaign report, inflating the reported number without any real gain behind it.

How the event_id fixes it

Meta’s deduplication works on one specific field: the event_id. When the same event_id is attached to both the Pixel call and the CAPI call, Meta recognizes that the two calls describe the same event seen through two different channels, and counts it only once in the report.

For this to work, three conditions must be true at the same time:

• The event_id must be identical in both calls (not similar: identical).
• The event_name must also match between the two calls. An event_id shared between a Lead event and a Purchase event doesn’t deduplicate, even if the identifier is the same.
• Both calls must arrive within the deduplication window Meta applies. It isn’t instantaneous, but it isn’t unlimited in time either.

If any of these three conditions fails, Meta treats the two calls as separate events, and duplication comes back even with an event_id present on both sides.

Pixel and CAPI deduplication, step by step

1. Generate the event_id on the first firing. This usually happens in the Pixel, on the page where the action takes place: a unique identifier is created the moment the script fires (a UUID, for example).
2. Pass that same event_id along to where CAPI fires. In practice, the identifier travels with the action itself (the form submission, the order the checkout records) so it’s available when the server builds the CAPI call for that same event.
3. Use the same event_name in both firings. If the Pixel sends a sign-up as Lead and the server sends the same sign-up as CompleteRegistration, the two events will never deduplicate, even if they share the same event_id.
4. Build the CAPI call with the event_id you received, without generating a new one. The most common mistake here is the backend creating its own identifier instead of reusing the one that came from the page.
5. Validate in Events Manager before you consider the flow done (see the next section).

How to check that deduplication is working

Meta’s Events Manager, on the Test Events tab, shows every event received in real time: which source it came from (Pixel or CAPI) and whether it was recognized as a duplicate of another. A correctly deduplicated event shows both sources grouped under the same event; a misconfigured one shows up as two separate rows, each with its own source.

Before running real budget on a new setup, fire a test event (a real conversion in a controlled environment, like a test sign-up or a test purchase) and visually confirm that the Pixel and CAPI appear grouped as a single event, not two.

Common mistakes that break deduplication

• Generating a new event_id on each side: the most frequent mistake. The backend builds its own CAPI call with its own identifier instead of reusing the event_id the page generated, and the two events never meet.
• A different event_name between the Pixel and CAPI: even with an identical event_id, different event names prevent deduplication.
• Losing the event_id on the way to the CAPI call: if the identifier isn’t sent along with the action on the page (or gets truncated or malformatted), there’s no way to recover it when the server builds the call.
• Assuming deduplication is automatic in your own implementation: running a Pixel and CAPI you built yourself, without sharing the event_id, deduplicates nothing. It just doubles the number of calls.
• Not testing before scaling budget: a deduplication problem doesn’t stop a campaign or throw a visible error. It just inflates a number that looks good until someone compares it with real results.

Deduplication in a Telegram funnel

In a Telegram funnel, the question changes shape. The event that matters most (the channel join, enter_channel, and also the exit, left_channel) happens inside the Telegram app, where no browser is watching. No browser Pixel can see that join, so there’s no client-side copy of the event to deduplicate: it reaches Meta only from the server, once.

That also clears up a common confusion: the click on the page button and the channel join are different events, not the same event seen through two channels. A Lead on the click and an enter_channel on the join shouldn’t deduplicate. Both need to be counted, each under its own name.

That leaves the page events (visit and click). In a hand-built funnel, where the browser Pixel and your server send the same event to the same pixel, the three conditions above apply. In a Track4you funnel, the script itself already sends those events, and the recommendation is not to install a separate Pixel on the pages; the next section explains why. See the Facebook Pixel for Telegram guide for the full funnel flow.

What practical experience shows

In practice, the most common pattern of broken deduplication isn’t a missing event_id altogether. It’s an event_id that exists on both sides but is generated independently on each. That tends to go unnoticed precisely because everything looks configured: the field is filled in, the call is accepted, no error shows up. Only when someone compares the reported conversion count with the real volume (orders, sign-ups), or opens the Test Events tab and sees the same event split into two rows, does the problem become visible.

Where Track4you fits in

Track4you sends one event per step to the pixel chosen in the funnel: ViewContent on the page visit, Lead on the button click, enter_channel on the channel join and left_channel on exit. The two channel events exist only on the server side (no browser Pixel sees the join), so there’s no copy of the join to deduplicate and no event_id for you to configure. What’s left on your side is confirming enter_channel and left_channel, which are custom events: the test event makes both show up in Events Manager, and you confirm them once per pixel.

What about the Meta Pixel on the page? Since the Track4you script already sends ViewContent and Lead to the pixel chosen in the funnel, the recommendation is not to install your own Pixel on the funnel pages: for the funnel’s events, it adds nothing. If it’s already installed (by a theme, a plugin or an old test), there’s no rush to remove it: Meta deduplicates automatically, with no event_id for you to build. For a new funnel, though, the cleanest path is to leave only the script. Plans and terms are at track4you.app.

Frequently asked questions

Terms like event_id, CAPI and Event Match Quality have quick definitions in the glossary, worth a read if any of them is still unfamiliar. To improve event quality once deduplication is sorted, see how to improve Event Match Quality.

Conclusion

Event deduplication isn’t a minor technical detail. It’s the difference between a reliable campaign report and one inflated by events counted twice. The mechanism itself is simple (an identical event_id and event_name in both firings, within the time window Meta accepts), but it requires attention at every point where that identifier has to pass from one system to another. In a Telegram funnel, the channel join doesn’t even enter the equation: it only arrives from the server. With Track4you, the page events also go out through the script, with no separate Pixel to deduplicate. If you build tracking by hand, with the Pixel and your server sending the same event, validate in Events Manager before scaling budget: it’s the step that keeps you from discovering the problem too late.