Meta is showing more purchases than my store

Meta forwarding from Convultra is coming soon, so today any purchases Meta reports come from your own Meta Pixel, from another Conversions API integration, or from Meta’s attribution model rather than from Convultra. When Convultra’s Meta integration launches it will deduplicate against your pixel with shared event IDs, and the checks below are the ones that will keep counts honest. Most of them apply to any server-side setup right now.

The usual causes

1. The pixel and a server-side source both sent the same purchase

If the Meta Pixel fires on your thank-you page and a server-side integration also sends the purchase, Meta receives two events. Unless both carry the same event_id and event_name, Meta counts two purchases.

Fix. Every server-side event must carry the same event_id as the browser event. Convultra generates a unique event ID for each conversion and includes it with the server-side upload; when the browser pixel fires with that same ID, Meta keeps one. This needs your Pixel ID entered in the Meta integration so Convultra knows which pixel to deduplicate against.

2. Meta’s attribution window is wider than your store’s idea of “today”

Meta reports a purchase on the day of the ad interaction it credits, under a 7-day click or 1-day view window by default. Your store reports it on the day the order was placed. Over a week the totals should line up; on any single day they will not.

Fix. Compare over a longer range, and compare against Convultra’s Conversions page rather than Ads Manager, since Convultra dates a conversion when it happened.

3. View-through conversions

Meta counts purchases from people who saw an ad and did not click it. Your store has no idea an ad was involved. This is not a duplicate; it is a different definition.

Fix. In Ads Manager, compare on click-through attribution only, or accept that Meta’s total includes view-through.

4. The same order fires twice on your site

A thank-you page that reloads, a single-page app that re-fires on route change, or a purchase call inside a handler that runs twice will all produce two browser events with different IDs.

Fix. Pass a unique orderId on every purchase call. Convultra deduplicates on it and drops the second event before it is stored or forwarded. See Deduplication.

5. Test purchases and internal orders

Team members placing test orders show up as real purchases in both systems, but your store may cancel or refund them.

Fix. Add your office and home IPs under IP exclusions so test traffic never enters Convultra.

6. Refunds and cancellations

Meta counts the purchase at the time it happened. If the order is later refunded, your store’s total goes down and Meta’s does not.

How Convultra’s deduplication will work with Meta

1. Convultra assigns each conversion a unique event_id.
2. The browser pixel event and the server-side Conversions API event both carry that event_id and the same event_name.
3. Meta uses the pair to keep one and discard the other.

Convultra also deduplicates on its own side before anything is forwarded, with a window for each method: conversion ID such as orderId (24 hours by default), click ID (60 minutes), event ID (5 minutes) and fingerprint (5 minutes). See Deduplication.

A quick reconciliation

1. Pick a closed week, so attribution windows have settled.
2. In Convultra, open Conversions, filter to purchase, and note the count and revenue.
3. In your store, count completed, non-refunded orders for the same week. The two should match closely; Convultra records purchases server-side, so it should be at least as complete as the store.
4. In Ads Manager, switch to click-through attribution only. The remaining gap between Meta and Convultra is Meta’s attribution, not duplication.

If Convultra itself shows more purchases than your store, that is a duplication or test-order problem on your site. Work through causes 4 and 5, then Troubleshooting.