Skip to content

Proof of pairing

Are your conversions being counted twice?

Sending an event twice is not the bug — it is the design. The pixel fires in the browser, your server sends the same event to the platform’s API, and both carry one shared event ID so the platform collapses them into a single conversion. Double counting happens when that ID does not match, and Dedup Doctor is where you see whether it did.

the mechanism

A shared event ID, and a place to check it

Deduplication is a promise the platform makes only if you give it the right input. The input is one event ID on both copies of the same event.

What you are looking at

One row per copy. Same event, same ID, two sources — and the platform’s trace ID beside each, which is the platform confirming it received that specific send.

Purchase fdf4dd5f-9c31-4e02-9a8d-1c7b2f0e0476 browser ✓ server ✓ Matched
AddToCart 0f2a91c4-77bd-4c19-9f0a-3b6d5e2c8e11 browser ✓ server ✕ unmatched

Example rows in the format Dedup Doctor uses — not data from a live store.

TODO(owner: screenshot)

Dedup Doctor, showing paired browser and server events with their event IDs and platform trace IDs.

how it works

Four steps, one of which is the proof

  1. step 1

    One ID is minted per event

    The event ID is generated once and travels on both the browser copy and the server copy. It is never baked into cacheable HTML, so a cached page cannot hand the same ID to two different visitors.

  2. step 2

    Both copies are recorded as they are sent

    Each send is logged with its event name, its event ID and the platform’s own response, including the trace ID the platform returns.

  3. step 3

    The two copies are compared

    Dedup Doctor puts the browser row and the server row next to each other and compares the actual event IDs — not a checkbox that says deduplication is enabled.

  4. step 4

    You read the verdict

    Matched means the platform received both halves with one ID. A missing half tells you which side failed and what the platform said about it.

documentation

Read the details

The reference pages for this, including the parts that are still being verified.

Questions people ask about this

Short answers. Anything we cannot confirm, we say so.

If both copies are sent, am I not double counting by definition?

Not when the two copies carry the same event ID. That shared ID is what the platform uses to recognise the browser event and the server event as one conversion. Double counting starts when the IDs differ, or when a second plugin fires its own copy with an ID of its own.

What does Dedup Doctor actually compare?

The actual event IDs on the browser copy and the server copy of each event, shown side by side, with the trace IDs the platform returned as evidence that each half arrived.

Does page caching break the shared event ID?

Not here. No per-visitor event ID is baked into cacheable HTML, so byte-identical cached pages still produce unique matched pairs. This has been verified against LiteSpeed Cache and other common page caches, including a multi-layer REST cache bypass.

Can it tell me if another plugin is firing the same pixel?

A second plugin firing its own copy shows up as an event the platform received that PixelCapi did not send. The Conflict Scanner that names the conflicting source is in development — the roadmap badge on this site marks anything not yet shipped.

Stop guessing. Start proving.

Check what your site is sending right now, or see what PixelCapi Pro costs.

Check your tracking — free See pricing