When Meta sales don't match store revenue, the difference can come from tracking errors, attribution/reporting logic, or both.
The store records real orders. Meta reports conversions according to the event data it receives and its own attribution/reporting rules. That means the two systems do not have to show identical numbers. The right diagnostic question is not “Which dashboard is correct?” It is “Can each real order be reconciled to the events that should represent it, and can the remaining difference be explained?”
Start by defining what each system is counting
Before comparing totals, define the job of each number.
Your store is the source of truth for completed transactions.
It should tell you which orders actually happened, their order IDs, values, currencies, timestamps, refunds or status changes according to the store's own transaction model.
Meta is not the order database.
It receives conversion signals and reports them through its advertising measurement system.
That distinction sounds basic, but it changes how you diagnose the gap.
If the store shows 100 completed orders and Meta shows a different number, you still do not know whether anything is broken.
You first need to know:
- which of those orders generated the expected purchase event;
- whether the event was sent through browser, server, or both;
- whether the value and currency matched the order;
- whether the same order was represented more than once;
- whether Meta received the event;
- which reporting period and attribution logic you are comparing.
Do not begin by forcing the totals to match.
Begin by making sure you are comparing the same population of transactions over a clearly defined period.
The strongest unit of analysis is one real order with a traceable event path.
Attribution can create legitimate reporting differences
Even with healthy tracking, Meta and the store can report different sales totals.
The store answers:
What transactions happened?
An advertising platform also has to answer:
Which advertising interactions should receive credit for those transactions?
Those are different questions.
Attribution rules can change which conversions appear in a campaign or ad account report, and reporting timing can affect when they appear.
The exact current Meta attribution settings, windows, and reporting behavior should be verified from the account and Meta's current official documentation before making a platform-specific claim.
For diagnosis, the important principle is simpler.
A difference caused by attribution is not the same as a missing event.
Suppose the source order exists, the purchase event is correct, delivery is confirmed, and Meta has received the event.
If the store and Meta still show different attributed revenue, that remaining gap may be reporting or attribution rather than transport failure.
This is why changing the tracking implementation before validating the event path can solve the wrong problem.
You may rebuild a healthy delivery system because the team expected two systems with different jobs to display the same total.
Missing purchase events can create a tracking gap
Some differences are not attribution.
A real order can exist in the store while the expected purchase event never makes it through the measurement path.
That can happen at several stages.
The event may never be created at the source.
The browser implementation may fail.
A server-side workflow may not process the event.
The outgoing delivery may fail.
Or the destination may not receive or process it as intended.
When that happens, Meta has less conversion data than the store has transactions.
The correct response is not to look only at the percentage gap between the two dashboards.
Trace actual orders.
Take a sample of completed transactions and ask:
Was a purchase event created for each one?
Then move down the path:
Did it contain the correct value and currency?
Was it sent?
What was the destination outcome?
This changes the investigation from “Meta is underreporting” to a testable technical question.
If ten source orders have no corresponding event because the source implementation failed, you have evidence of a tracking issue.
If the events are all present and delivered, the investigation moves to a different layer.
Duplicate events can inflate reported conversions
The opposite problem can also happen.
One real purchase can be represented more than once.
A browser tag may send a purchase event.
A server workflow may send the same purchase.
A legacy tag or plugin may still be active.
Two server-side workflows may both deliver the same transaction.
If those representations are not coordinated correctly, the reported conversion count or value can become inflated.
That is why a Meta total that is higher than store revenue is not automatically an attribution issue.
It may be duplication.
Again, diagnose by transaction.
For one completed order, identify every purchase event created across browser and server paths.
Compare the event or order IDs, values, currency, and timestamps.
Then determine whether those events are intentional overlapping representations with working deduplication, or separate events being treated as separate conversions.
Do not diagnose duplicates from matching values alone.
Two different customers can place orders for the same amount.
Order identity and event identity are much stronger evidence.
The business question is simple:
Did one transaction create one coherent conversion trail, or several unrelated-looking events?
How to reconcile Meta with your store data
A useful reconciliation does not start with two revenue totals and a calculator.
It starts with a transaction-level sample.
Choose a defined date range and use the store as the transaction source of truth.
Then compare the tracking evidence order by order.
Order IDs
Start with unique orders.
For each completed order, determine whether you can connect the transaction to the expected technical event or events.
An order ID is useful because it anchors the investigation to a real transaction rather than a dashboard aggregate.
If your implementation uses a separate event ID for destination matching or deduplication, record that too.
The exact Meta-specific identifier requirements should be verified from current official documentation.
Revenue and currency
Compare the purchase value in the event with the final source transaction.
Check currency at the same time.
A delivered purchase event with an incorrect value will create a revenue discrepancy even if the event count looks healthy.
If browser and server both represent the same purchase, compare their values as well.
They should not disagree about what the underlying transaction was.
Event counts
Count business transactions first.
Then count the technical representations for those transactions.
You are looking for three broad patterns:
a source order with no expected event;
a source order with one coherent event path;
or a source order represented multiple times without clear coordination.
Those patterns tell you more than a top-line percentage difference.
Date and time window
Make sure the systems are being compared over a defensible period.
Check source transaction timestamps, event timestamps, and the reporting period you are viewing.
Do not assume every system assigns a conversion to the same reporting date or period.
This is also where current Meta attribution/reporting configuration matters, so account-specific settings should be verified rather than assumed.
The final reconciliation should let you separate four categories:
confirmed source transactions, confirmed delivered events, confirmed tracking failures, and remaining reporting/attribution differences.
That is the point where the Meta-versus-store gap becomes useful instead of confusing.
If the event path is healthy, do not invent a tracking problem just because the dashboards differ.
If orders are missing, duplicated, carrying wrong values, or failing in delivery, you now have evidence of a measurement problem that deserves repair.
And if the failure point is still unclear after transaction-level reconciliation, that is when a Tracking Health Audit becomes useful.
The audit should not promise to make every dashboard identical.
It should identify which part of the difference is caused by tracking, show the evidence, and recommend the smallest appropriate fix.
Related guides
Frequently Asked Questions
Are Meta and the store measuring the same thing?
Not necessarily; the store records actual orders while the platform applies its own attribution/reporting logic.
Can attribution create legitimate differences?
Yes; attribution windows and rules can credit orders differently. Exact Meta behavior needs current official verification.
Can missing events reduce platform revenue?
Yes; real purchases not created or delivered as events can leave the platform with fewer conversions.
Can duplicates inflate platform sales?
Yes; one real order represented multiple times can inflate counts/value.
What should be reconciled?
Order IDs, counts, revenue/value, currency, timing/windows, event IDs and delivery outcomes.