Clarvivo

Free tool by Clarvivo · no login

Check whether Meta can deduplicate your conversion events

Paste a confirmation page. We inspect the Pixel events its browser sends, check for the event_id CAPI needs, and reload once to expose conversions that fire twice before Meta ever sees a server-side copy.

Page to inspect

Use the thank-you or confirmation page where a lead or purchase fires. We inspect the browser Pixel event IDs and reload once to expose tags that count the same conversion twice.

This tool answers: Can Meta deduplicate my Pixel and Conversions API events?

Enable JavaScript to run the check — the diagnosis itself is free and needs no account.

Why this happens

Meta's recommended setup sends a conversion twice: once from the browser Pixel and once from the Conversions API. That is correct only when both copies use the same event_id. Without it, Meta sees two unrelated purchases, reports too much revenue and encourages you to spend against a ROAS number that does not exist.

The usual debugging trap is that nothing appears broken. One browser event can look perfect in Events Manager while its server-side partner carries a different ID. A second failure is even simpler: a thank-you page sends Purchase again when the customer refreshes it.

A browser can prove whether its Pixel event is capable of being paired. It cannot see a CAPI call sent from your server, so this tool is explicit about that boundary: a present event_id is necessary, not proof that your backend used the same value.

Next checks

These answer the questions this one tends to raise.

How this check works

So you can trust the result — and your developer can verify it.

  1. We inspect Pixel event IDs, not only whether the Pixel loads

    The Facebook Pixel library loading is not a conversion. We read the event request itself, including the event name, Pixel ID, value, currency and eid parameter that Meta uses to match a browser event to a CAPI event.

  2. We reload the page once

    A confirmation page should not create a new purchase merely because the customer refreshes it. The scan intentionally reloads the supplied page once, then compares the event IDs and timing from both loads without submitting anything.

  3. We state the server-side limit plainly

    CAPI requests leave from your backend to Meta, beyond a visitor's browser. Missing browser event_id is conclusive; a present one means the browser side is ready, and the result tells you exactly what to verify in Events Manager to prove the pairing.

Common causes and fixes

Pixel and CAPI generate separate IDs
A browser script generates one random identifier while a webhook generates another. Both events arrive, but Meta cannot know they describe the same purchase. Generate the ID once per conversion and pass that exact value to both sides.
A Pixel event has no event_id at all
Standard Pixel installs often send Purchase with value and currency but no eid. That works until CAPI is enabled, at which point every matched server event is counted separately. Add eventID to the Pixel call and event_id to the CAPI payload.
Two browser tags or a refreshable thank-you page
A Shopify app Pixel beside a manual tag, or a purchase trigger that runs on every confirmation-page view, produces inflated browser-side counts before CAPI is involved. Remove the duplicate trigger rather than relying on deduplication to cover an accidental installation.

Frequently asked questions

Can this tool see my Conversions API events?
No. CAPI calls go directly from your server to Meta and do not pass through the visitor's browser. We verify the browser half and tell you how to check Meta's deduplication rate for the end-to-end answer.
What is the difference between event_id and Pixel ID?
The Pixel ID identifies the destination ad account setup. event_id identifies one specific conversion. Meta needs the same event_id on the browser Pixel and server CAPI copy in order to collapse them into one conversion.
Should a Purchase event fire again after refresh?
Usually no. A completed purchase is one business event, even if the customer returns to or refreshes the confirmation page. Repeated firing can inflate browser reporting and may also complicate server-side deduplication.
Why use a thank-you page rather than the homepage?
Deduplication matters for the conversion event that affects ROAS. A homepage normally sends only PageView, so it can confirm the Pixel exists but cannot answer whether Purchase or Lead is correctly identified.

ROAS needs an order behind every claimed conversion.

Clarvivo reconciles the acquisition data Meta reports with the payments your business actually received, so a technically valid event does not become an unchallenged revenue claim.

Connect claimed conversions to actual revenue

What this tool reads, and what it keeps