How to Fix CAPI Duplicate Events: The Browser-Plus-Server Deduplication Problem

Key Takeaways

• Adding a conversions API alongside browser tracking double-counts conversions — each is reported twice (browser and server) unless you deduplicate them.
• The fix is event deduplication using a shared, unique event ID sent with both the browser and server events, so the platform recognizes them as one conversion.
• The critical requirement: the event ID must be shared and consistent between the browser and server reports of the same conversion, and unique to that conversion.
• If the event IDs don't match between browser and server (a common implementation error), deduplication fails and the conversion is double-counted.
• Double-counting silently corrupts both reporting (inflated conversion numbers) and, worse, optimization (the automation learns from double-counted signal).
• Verify deduplication is working by testing the tracking and reconciling conversion counts against actual results — don't assume it works after setup.

Why Browser Plus CAPI Double-Counts

The most common problem advertisers hit when adopting a conversions API is duplicate conversions, and it arises directly from the fact that adding CAPI to an existing browser pixel means the same conversion now gets reported to the platform twice — once by the browser pixel (which fires when the conversion happens in the browser) and once by the server-side conversions API (which reports the conversion from your server). Because both tracking methods report the same conversion, and the platform has no inherent way to know they are the same event, it counts them as two separate conversions — a duplicate. So the very setup that advertisers adopt to improve their signal (running both browser and server tracking, so that if one misses a conversion the other catches it) creates double-counting, because both methods reporting the same conversion means the platform sees two conversions where there was one.

This double-counting is not a flaw in the conversions API or in browser tracking individually; it is an inherent consequence of running both without deduplication, so it is a problem that essentially every advertiser who adds CAPI to browser tracking must solve. The reason advertisers run both is sound — browser tracking is increasingly lossy (blocked pixels, missed conversions), and the conversions API provides more resilient server-side reporting, so running both gives more complete signal than either alone. But the price of running both, without deduplication, is that conversions caught by both methods are counted twice, so the resilience benefit comes with a double-counting problem that has to be addressed for the setup to work correctly.

Understanding that browser-plus-CAPI double-counts by default is essential because it means deduplication is not optional but a required part of a browser-plus-CAPI setup — you cannot run both tracking methods correctly without deduplicating them, or you will systematically double-count. Advertisers who add CAPI without implementing deduplication get the resilience benefit but also the double-counting, which corrupts their measurement, so the deduplication is what makes the dual-tracking setup work as intended: the resilience of both methods, with each conversion counted once. This is why anyone running a conversions API alongside browser tracking must understand and implement deduplication — it is the piece that turns a double-counting problem into a correctly-functioning resilient setup, and its absence is one of the most common CAPI measurement errors. The rest of this guide is how deduplication works and how to implement and verify it correctly.

How Shared Event IDs Deduplicate

The mechanism that solves the browser-plus-CAPI double-counting is event deduplication using a shared event ID, which gives the platform a way to recognize that the browser report and the server report are the same conversion, so it counts them once. The mechanism is straightforward in concept: when a conversion happens, you generate a unique identifier for that specific conversion event, and you send that same identifier with both the browser event and the server-side event that report the conversion. The platform, receiving two reports that carry the same event ID, recognizes them as the same event and deduplicates them — counting the conversion once despite receiving two reports. So the shared event ID is what lets the platform match the two reports of the same conversion and avoid double-counting.

The elegance of this mechanism is that it lets you keep both tracking methods (for their resilience benefit) while ensuring each conversion is counted once (avoiding the double-counting), which is exactly the outcome you want from a browser-plus-CAPI setup. You send the conversion via both the browser and the server (so that if the browser misses it, the server catches it, and vice versa — the resilience benefit), but both carry the same event ID, so the platform counts the conversion once whether it receives one report or both. If only the server report arrives (because the browser pixel was blocked), the platform counts the conversion from the server; if only the browser report arrives, it counts from the browser; if both arrive, the shared event ID lets it deduplicate them to one. This is how deduplication delivers both resilience and accuracy: the conversion is reported redundantly for resilience, but the shared event ID ensures it is counted once.

The key to this mechanism working is entirely in the event ID being shared correctly between the browser and server reports of the same conversion, because the platform's ability to deduplicate depends on recognizing the two reports as the same event via their matching ID. If the browser event and the server event for the same conversion carry the same, unique event ID, the platform can match and deduplicate them; if they do not (because of an implementation error that gives them different IDs), the platform cannot recognize them as the same event and counts both, so the deduplication fails. This is why the implementation of the shared event ID is the crux of deduplication — get it right (matching, unique IDs) and deduplication works; get it wrong (mismatched IDs) and double-counting persists despite the deduplication being nominally in place. The next section covers exactly what the implementation requires to get the event ID right, because that is where deduplication succeeds or fails.

The Implementation Requirements

Implementing event deduplication correctly comes down to getting the shared event ID right, and there are specific requirements that must all be met for the platform to deduplicate reliably. The first requirement is that the event ID is genuinely shared between the browser and server reports of the same conversion — the browser event and the corresponding server event for a single conversion must carry the identical event ID, so the platform can match them. This means your implementation must generate the event ID for a conversion and use that same ID in both the browser event and the server event, which requires coordinating the two tracking methods so they use the same ID for the same conversion — a coordination that is the core implementation challenge, because the browser and server tracking are separate systems that must be made to agree on the ID for each conversion.

The second requirement is that the event ID is unique to each conversion — each distinct conversion has its own distinct ID, so that the platform does not incorrectly deduplicate different conversions as if they were the same. If the same event ID were used for different conversions (a non-unique ID), the platform might deduplicate genuinely different conversions, under-counting them, so uniqueness is essential to ensure that only the two reports of the same conversion share an ID while different conversions have different IDs. Generating a genuinely unique ID for each conversion (rather than a repeated or predictable one) is therefore a requirement, so that the deduplication matches only the two reports of the same conversion and not different conversions.

The third set of requirements concerns the platform's specific deduplication rules, because the platforms typically require not just the matching event ID but also that the events are recognizably the same in other respects (the same event type, and often matching key parameters), so the deduplication must be implemented according to the platform's specifications. The platforms provide detailed requirements for how deduplication must be implemented — what the event ID must be, what other data must match, how to send it — and meeting these exactly is what makes the deduplication work reliably. So implementing deduplication means following the platform's specifications precisely: generating a unique event ID per conversion, sharing it between the browser and server reports of that conversion, and meeting the platform's other matching requirements — all of which together let the platform reliably deduplicate. Because the requirements are specific and must all be met, careful implementation according to the platform's specifications is essential, and this is where deduplication implementations succeed or fail. This precise-implementation discipline is characteristic of sound performance marketing measurement.

Common Mistakes That Break Deduplication

Several common mistakes break event deduplication, causing double-counting to persist despite deduplication being nominally implemented, and recognizing them helps you avoid the errors that silently leave your conversions double-counted. The most common is mismatched event IDs — the browser event and the server event for the same conversion carrying different IDs, because of an implementation error in how the IDs are generated or shared, so the platform cannot recognize them as the same event and counts both. This is the central deduplication failure, and it often happens because coordinating the same ID across the separate browser and server tracking is genuinely tricky, so implementation errors that give the two reports different IDs are common — and they silently break the deduplication, because the setup looks implemented but the IDs do not actually match, so double-counting continues.

A second common mistake is non-unique event IDs — using IDs that are not genuinely unique per conversion (repeated, predictable, or otherwise not distinct), which can cause the platform to incorrectly deduplicate different conversions or fail to deduplicate correctly. If the ID generation does not produce a genuinely unique ID for each conversion, the deduplication can misbehave, so an ID scheme that seems to work but does not guarantee uniqueness is a subtle source of deduplication problems. Ensuring genuinely unique IDs per conversion avoids this, but implementations that use insufficiently-unique IDs can have subtle deduplication errors that are hard to spot.

A third common mistake is failing to meet the platform's other matching requirements — implementing the shared event ID but not the other conditions the platform requires for deduplication (matching event type, matching key parameters, or other specifications), so the platform does not deduplicate despite the matching ID. Because the platforms typically require more than just the event ID to deduplicate, an implementation that gets the ID right but misses the other requirements can still fail to deduplicate, so meeting all the platform's requirements (not just the event ID) is necessary. These three mistakes — mismatched IDs, non-unique IDs, and unmet platform requirements — are the common ways deduplication breaks, and because they can leave the setup looking implemented while double-counting persists, they are insidious. Avoiding them requires implementing the deduplication carefully according to the platform's specifications (matching, unique IDs meeting all requirements) and — crucially — verifying that it actually works rather than assuming it does, because these mistakes silently defeat a nominally-implemented deduplication, which is why verification (covered next) is essential to confirm the deduplication is genuinely working.

Verifying Deduplication Works

Because deduplication can be nominally implemented but silently broken by the common mistakes, verifying that it actually works — that conversions are genuinely being counted once — is an essential step that should never be skipped, since an unverified deduplication might be leaving your conversions double-counted despite appearing to be in place. Verification confirms that the deduplication is genuinely working, catching the silent failures (mismatched IDs, non-unique IDs, unmet requirements) that would otherwise leave double-counting persisting undetected. Given how silently double-counting corrupts your reporting and optimization, and how easily deduplication implementations can be subtly broken, verifying the deduplication is the only way to be confident your conversions are counted once.

The first verification method is testing the tracking directly, using the platforms' event-testing and debugging tools to confirm that a single conversion, reported by both browser and server, is deduplicated to one counted event. By generating a test conversion and observing (through the platform's tools) that the browser and server reports are recognized as the same event and counted once — rather than as two separate events — you directly confirm that the deduplication is working. The platforms provide tools that let you see how events are received and whether they are deduplicated, so using these to verify that your test conversions are correctly deduplicated is a direct confirmation that the shared event ID mechanism is working as intended.

The second verification method is reconciling your conversion counts against your actual results, checking that your tracked conversions match your real conversions (rather than showing the inflation that double-counting causes), because if deduplication is working, your conversion counts should reconcile with reality, while if double-counting persists, your counts will be inflated. Comparing your tracked conversion numbers to your actual business results (your real orders, leads, or conversions) tells you whether the numbers reconcile (deduplication working) or are inflated (double-counting persisting), providing a real-world confirmation of the deduplication. Using both methods — direct testing of the deduplication and reconciliation of the counts against reality — gives you confidence that your conversions are genuinely counted once. And because tracking setups change and new issues can arise, periodically re-verifying (not just once) keeps the deduplication confirmed over time. Verifying deduplication — through direct testing and reconciliation, initially and periodically — is what ensures your browser-plus-CAPI setup delivers the resilient, accurate, single-counted signal it is supposed to, rather than the silently-double-counted signal that a broken deduplication leaves. It is the step that confirms the deduplication is genuinely working, which, given the silent and corrupting nature of double-counting, is essential to getting the browser-plus-CAPI setup right.

Getting the Dual-Tracking Setup Right

Deduplication is the key to a correct browser-plus-CAPI setup, but getting the dual-tracking setup fully right involves implementing deduplication correctly, verifying it, and maintaining it as part of a healthy conversions API — so it fits into the broader discipline of running CAPI well. The immediate task is the deduplication: implementing the shared, unique event ID correctly according to the platform's requirements, and verifying that it genuinely deduplicates, so that your dual-tracking setup delivers the resilience of both methods with each conversion counted once. This is the specific fix for the double-counting that browser-plus-CAPI creates, and getting it right is what makes the dual-tracking setup work as intended rather than double-counting.

Beyond deduplication, a fully healthy browser-plus-CAPI setup also requires the other elements of a good conversions API — good match quality (the conversion data being matchable by the platform), complete and correct signal (events firing correctly with the needed data), and ongoing maintenance — so deduplication, while essential, is one part of running CAPI well. A setup that deduplicates correctly but has poor match quality, or incomplete signal, still underperforms, so getting the dual-tracking setup fully right means addressing deduplication alongside the other aspects of CAPI health. Deduplication solves the specific double-counting problem, while the broader CAPI discipline (match quality, complete signal, maintenance) ensures the whole setup delivers its full value.

The overarching point is that running a conversions API alongside browser tracking — the standard modern setup for resilient conversion measurement — requires deduplication to work correctly, and getting deduplication right (implemented correctly, verified, maintained) is essential to realizing the benefit of the dual-tracking setup rather than corrupting it with double-counting. Advertisers who add CAPI for resilience and implement deduplication correctly get the best of both worlds: the resilient, complete signal of running both browser and server tracking, with each conversion accurately counted once. Advertisers who add CAPI without correct deduplication get the resilience but also the double-counting, which corrupts their reporting and optimization, undermining the very measurement improvement they sought. So deduplication is the piece that makes the modern resilient dual-tracking setup work, and implementing and verifying it correctly — avoiding the common mistakes, confirming it genuinely works — is what turns a double-counting problem into the accurate, resilient conversion measurement that a browser-plus-CAPI setup is supposed to provide. Getting deduplication right is getting the modern conversion-measurement setup right, which is why it deserves the careful implementation and verification this guide describes.

Methodology & Fairness

A note on how to read this. This is an educational guide published by Fluxsy, a performance marketing partner, so weigh our perspective accordingly. Platform mechanics and privacy rules change frequently; verify the specifics described here against the current official documentation before you implement. Where we name tools, platforms or companies we describe them by their genuine public positioning, not as endorsements. We have avoided inventing statistics, benchmarks or results — the durable value here is the framework and the reasoning, which hold even as the specific implementation details move. Measure against your own data before concluding, because your results depend on your stack, your market and your configuration.