Measurement and attribution

Meta Pixel and CAPI deduplication: prove one action stays one event

Deduplication succeeds when the browser and server versions of the same business action carry a consistent event name and shared event identifier, allowing Meta to recognize one conversion rather than two. The safest test begins with a single known action and ends with source-system reconciliation.

By Adwize Editorial TeamReviewed by Adwize Product Team7 min read

Separate duplicate symptoms from real commercial changes

A sudden conversion increase is suspicious only after the store or CRM stays stable. Compare orders, leads and revenue over the same finalised period. Promotions, retries and delayed CRM updates can otherwise look like a technical duplication problem.

Follow the identifier from browser to server

Choose one test action and inspect both payloads. The identifier should describe that action consistently rather than being regenerated independently in each channel. Also confirm that the event names represent the same stage of the customer journey.

  • Same business action and event name
  • Shared, stable event identifier
  • Reasonable event-time proximity
  • No retry path creating a new identifier

Test refreshes, retries and delayed confirmations

Repeat the uncomfortable paths: reload the confirmation page, retry a webhook, delay the server event and cancel a test order. Robust deduplication depends on idempotent business logic, not only a happy-path example in a browser debugger.

Reconcile a closed window before trusting reporting

After the test passes, compare a complete day of source transactions with browser events, server events and processed outcomes. Document expected gaps such as consent choices or rejected payments rather than forcing every system to show an identical total.

Worked example

One completed order fires a browser Purchase and a server Purchase. The team gives both events the same stable event ID, confirms that value and currency agree, then checks the known order rather than assuming similar daily totals prove deduplication.

Common mistakes

  • Generating unrelated event IDs for the browser and server copies.
  • Using aggregate totals as the only evidence that individual events merged.

Editorial next decisions

Use these guides only when their decision becomes the next unresolved constraint in your evidence trail.

Limitations

Matching daily totals does not prove individual events were deduplicated, and different attribution windows can still make Ads Manager revenue diverge from store or analytics revenue.

Questions readers ask next

Can event time alone deduplicate a conversion?

Timing is a useful diagnostic, but a stable event identifier tied to the same named action is the stronger basis for recognizing browser and server copies of one event.

Why test webhook retries?

Payment and CRM systems retry delivery routinely. If each retry creates a fresh event identifier, server-side reliability can accidentally become repeated conversion reporting.

Sources checked

Primary documentation was checked on the date shown. Product interfaces and eligibility can change, so verify the current account state before acting.

Measurement and attributionMeta Event Match Quality: improve the signal without chasing a scoreMeasurement and attributionMeta Ads vs GA4 attribution: compare systems without forcing equalityMeasurement and attributionMeta offline conversions: send the CRM outcomes that matter