Meta says a campaign produced 1,240 purchases at 4.1x ROAS. Your mobile measurement partner reports 860 purchases at 2.7x, while the billing database records 910 paid orders. An attribution data discrepancy like this can turn a routine budget review into an argument about whose dashboard is broken.
Usually, none of those totals is a simple duplicate of another. The systems observe different signals, apply different credit rules, and group results on different timelines. The practical goal is not to force every number to match. It is to make each number reproducible, explain the residual gap, and use the right source for each decision.
What is an attribution data discrepancy?
An attribution data discrepancy is a difference between supposedly comparable conversion, revenue, or ROAS figures reported by an ad platform, MMP, analytics tool, or first-party system. It can be expected when the systems use different definitions or attribution rules; it becomes a data-quality incident when comparable rules and populations still produce an unexplained gap.
Sort the mismatch into one of four categories before debugging it: measurement, attribution, reporting, or tracking. The split matters because each category has a different owner and a different fix. Google’s app conversion discrepancy guidance shows why the distinction is worth making—it files causes as different as cross-network deduplication, download-versus-first-open definitions, modeled conversions, time zones, processing delay, and lookback windows all under one heading of expected differences. Those need very different responses.
| Discrepancy type | What differs | Typical example | Likely owner |
|---|---|---|---|
| Measurement | The event or counting unit | Store download versus first app open | Product analytics |
| Attribution | The rule that assigns credit | Meta claim versus cross-channel last touch | Growth operations |
| Reporting | The query or presentation | Touch date versus conversion date | Analytics |
| Tracking | The underlying data captured | Purchase postback missing a value | Engineering |
Before debugging, label the mismatch. A reporting discrepancy may disappear when time zones align. A tracking discrepancy will not.
Why an attribution data discrepancy happens
The most important idea is that Meta, an MMP, and your backend do not answer the same question. Meta reports what its measurement system credits to Meta activity. An MMP decides which eligible source receives cross-channel attribution. Your backend confirms that an order, subscription, or other product event occurred, but may not know which marketing touch caused it.
Self-attribution and cross-channel deduplication
Meta is a self-attributing network. It evaluates eligible conversions using information available inside its ecosystem, including signals an independent MMP cannot necessarily observe. The MMP then has to compare claims and measurable touches across partners and award credit according to its own model.
That can produce two valid but incompatible answers. Imagine a user views a Meta ad, later clicks a Google ad, installs the app, and buys. Meta may credit the conversion under its eligible view or click logic, while a last-touch MMP credits Google. The backend records one purchase without either marketing label.
This is why adding each network’s conversions together can exceed the number of real customers. Each network sees only its own relationship with the user; the MMP’s role is to deduplicate across the channels it can measure.
Attribution windows do not match
An attribution window defines how long a touch remains eligible for credit. If Meta accepts a conversion several days after a click but the MMP’s configured window is shorter, Meta can claim a conversion that the MMP marks organic or attributes elsewhere.
AppsFlyer’s current Meta discrepancy guide documents a seven-day Meta click lookback and one-day view lookback in its comparison, while AppsFlyer click windows are configurable. The values in your own accounts are what matter: export or screenshot the effective settings instead of trusting a remembered default.
Windows also apply at different stages. A system may use one period from ad click to install and another from install to purchase. “Seven-day revenue” is ambiguous until you specify whether the seven days begin at the touch, first open, registration, or purchase cohort date.
Touch date and conversion date create different cohorts
Ad platforms often organize conversions around the date of the advertising interaction, while third-party systems may organize them around the date the conversion occurred. A user who clicks on June 28 and purchases on July 2 can appear in June for one report and July for another.
Google’s official app conversion discrepancy guidance recommends comparing a fixed click cohort and extending the third-party conversion range through the applicable conversion window. Comparing two calendar-month dashboard totals can truncate late conversions and manufacture a gap.
Time zones compound the problem. Midnight in an ad account’s local time is a different boundary from midnight UTC. Daily differences that reverse on adjacent dates often point to grouping or freshness, not lost events.
View-through, cross-device, and modeled conversions change the population
A click-only MMP view is not comparable with a platform total that includes eligible view-through conversions. Nor is a device-level match directly comparable with cross-device reporting based on logged-in platform data.
Privacy limits make the gap more visible on iOS. Apple’s AdAttributionKit overview describes privacy-preserving postbacks, data tiers, conversion values, and multiple conversion windows rather than unrestricted user-level journeys. Apple also states that conversion detail can depend on privacy thresholds in its ad attribution documentation. Keep these rows distinct and use a dedicated SKAdNetwork explainer when documenting how privacy-preserving postbacks enter your reports; aggregated postbacks and modeled estimates should not be silently merged with deterministic rows.
Event mapping and revenue definitions drift
Two dashboards can both say “purchase” while counting different events. One may count every callback, another unique transaction IDs, and a third only settled payments. One may report gross revenue including tax, while finance reports net revenue after refunds and store fees.
AppsFlyer lists unmapped events, unsent revenue, incompatible event-value structures, activity-based versus lifetime reporting, and duplicate SDK event delivery among documented Meta and MMP discrepancy causes. These are implementation issues, not philosophical attribution differences.
Write down the exact event name, trigger, required properties, currency, refund treatment, deduplication key, and counting rule on both sides. If those fields differ, ROAS is not yet comparable even when spend matches.
Install, reinstall, and fraud rules change who is counted
An app store can count a download while an MMP records an install at first open. A returning device may be a reinstall in one system, a re-attribution in another, and a new acquisition in the network dashboard. Validation rules can also reject activity that a network still reports.
Google explicitly calls out download-versus-first-open definitions, conversion counting settings, modeled iOS conversions, and reinstall treatment in its discrepancy documentation. AppsFlyer likewise notes that fraud or validation rules may reject a Meta-attributed install that remains visible in Meta. These differences should be classified, not “fixed” by deleting inconvenient rows.
Which attribution number should you trust?
Trust a source for the decision it is designed to support. There is no single dashboard that is simultaneously best for auction optimization, neutral cross-channel credit, financial truth, and causal impact.
| Decision | Primary source | Why | Important limitation |
|---|---|---|---|
| Adjust bids, audiences, and creative inside Meta | Meta Ads Manager | It reflects the signals Meta’s delivery system uses | It is not a neutral cross-channel ledger |
| Compare paid channels on one attribution policy | MMP | It applies a common model and deduplicates measurable sources | It still depends on integrations, consent, and attribution rules |
| Confirm customers and recognized revenue | Backend, billing, or finance system | It records the business outcome | It may not know which channel caused the outcome |
| Estimate whether ads caused incremental conversions | Controlled lift test | It measures the counterfactual against a holdout | It is slower and usually less granular |
For daily campaign operations, use Meta’s trend and diagnostics within Meta. For cross-channel allocation, use an MMP view with a documented attribution model. For board reporting and cash planning, reconcile revenue to first-party systems. For major budget shifts, validate attribution with incrementality rather than assuming assigned credit equals causation.
This hierarchy also prevents a common mistake: calling the MMP ROAS “true ROAS.” It is a more consistent cross-channel attribution view, not proof that the credited ad caused the purchase. A user could have converted without the ad, and only an experimental or credible causal method can estimate that difference.
How to diagnose an attribution data discrepancy step by step
Reconciliation works best as a controlled comparison. Start with one event and a narrow slice, then widen the scope only after the logic is stable. Branch gives similar advice in its Meta Ads discrepancy FAQ: focus on one event at a time before troubleshooting totals.
1. Freeze one comparable slice
Choose one app, operating system, country, campaign ID, conversion event, currency, and mature date range. Use IDs rather than campaign names. Exclude the current day and any period still waiting for privacy postbacks or scheduled revenue imports.
Capture the raw dashboard filters and extraction timestamps. If another analyst cannot recreate the slice, the comparison is not controlled.
Calculate the directional gap with a named baseline:
discrepancy rate = (comparison value − baseline value) / baseline value × 100
If Meta reports 1,100 purchases and the MMP reports 1,000, the Meta-versus-MMP discrepancy is (1,100 − 1,000) / 1,000 = 10%. Reversing the baseline produces a different percentage, so label it explicitly.
2. Build a metric contract
For the metric on each side, record:
- Business definition and technical event name
- Total events or unique users
- Touch date, install date, or conversion date
- Time zone and currency
- Click-through and view-through windows
- Acquisition, re-engagement, and reinstall rules
- Attribution model and cross-channel deduplication
- Identity and transaction deduplication keys
- Refunds, taxes, fees, and rejected traffic
- Freshness, restatement, and retention behavior
Put the two contracts side by side. Every difference is either an intended policy difference, a configuration mismatch, or a question for the system owner.
3. Align settings without erasing useful differences
Align time zones, currencies, event mapping, and comparison windows when you need a like-for-like diagnostic. Do not permanently change a sensible business rule just to make a dashboard match Meta.
For example, you can create a temporary MMP report using Meta-equivalent windows to quantify the window effect. Keep the canonical cross-channel view on the attribution policy chosen for your business. The diagnostic view explains the gap; it does not have to become the source of truth.
4. Segment the gap until a pattern appears
Split the discrepancy by:
- iOS versus Android
- Click-through versus view-through
- User acquisition versus re-engagement
- New install versus reinstall
- Campaign and ad set ID
- Event name and app version
- Country and time zone
- Deterministic versus privacy-preserving or modeled reporting
A gap concentrated on iOS suggests privacy, modeling, or postback logic. A gap isolated to one app version suggests instrumentation. A gap at the edge of each day suggests time zones. A gap limited to purchases while installs match suggests event mapping, revenue properties, or deduplication.
5. Trace records from the product outward
Select a small set of known test or production-safe transaction IDs. Confirm the product event, SDK or server payload, MMP raw record, partner postback status, dashboard aggregation, and finance record in that order.
Meta’s Conversions API documentation explains that server, app, offline, and other business events can provide a direct connection for measurement and optimization. A server connection still needs correct event IDs, values, timestamps, and deduplication; it does not repair a broken event definition automatically.
For teams that want deterministic deep-link routing and install attribution without a broad enterprise stack, Deeplinkly provides raw CSV/API exports and webhooks alongside its lightweight mobile SDKs. Those event-level outputs give developers a traceable path from campaign link to first open and downstream event while keeping unattributable installs labeled as such.
6. Reconcile aggregates to raw data
Use aggregate reports to find where the mismatch lives, then use raw records to explain it. Classify unmatched rows into a fixed reason set: outside window, attributed to another channel, organic or unattributed, delayed, duplicate, rejected, reinstall, missing event value, missing identifier, or unknown.
Do not force-match records with weak keys merely to improve the reconciliation rate. Preserve an “unknown” bucket and track whether it grows. That bucket is a data-quality signal in its own right.
7. Set a baseline-based alert, not a universal threshold
There is no credible discrepancy percentage that is normal for every app. A stable 4% gap in Android purchases might be alarming if it suddenly becomes 18%; a larger iOS gap may be explainable by the chosen privacy and modeling views.
Build a baseline for each platform, event, attribution type, and freshness horizon. Alert on a sustained change outside that historical band or on any absolute financial difference that crosses a business threshold. Record the cause, owner, fix, and whether historical reports will restate.
A fast attribution discrepancy decision tree
Use the shape of the mismatch to choose the first investigation:
| What you see | First check | Then inspect |
|---|---|---|
| Meta conversions exceed MMP conversions | Windows and view-through inclusion | Cross-channel deduplication and modeled claims |
| MMP conversions exceed Meta conversions | Partner postback mapping | Event restrictions, rejected claims, and lifetime/activity views |
| Installs differ but purchases align | Download, first-open, and reinstall definitions | Install referrer and SDK initialization |
| Purchases differ but installs align | Purchase mapping and event values | Duplicate IDs, refunds, currency, app versions |
| Revenue differs but purchase count aligns | Gross/net definitions and currency | Missing values, tax, fees, refunds |
| Daily gaps reverse on adjacent days | Time zone and date basis | Processing delay and restatements |
| iOS diverges while Android aligns | Privacy-preserving versus deterministic views | Conversion values, postback windows, modeling |
| One campaign suddenly breaks | Campaign IDs and integration status | Credentials, mapping, validation, release changes |
The decision tree makes ownership clear. Growth operations handles windows and partner settings; engineering handles event delivery; analytics handles definitions and queries; finance owns recognized revenue rules.
Prevent the next attribution data discrepancy
Reconciliation should become a small operating system, not a monthly emergency.
- Version-control the metric contract and event mapping.
- Log changes to attribution windows, partner integrations, time zones, and currency.
- Run automated checks for event volume, missing properties, duplicate transaction IDs, and delayed exports.
- Keep privacy-preserving, modeled, and deterministic fields separately labeled.
- Review one mature weekly cohort instead of arguing over yesterday’s partial data.
- Reconcile attributed revenue to first-party revenue before executive reporting.
- Use lift tests periodically to calibrate how attribution credit relates to incremental impact.
The goal is not zero difference. The goal is a known difference with a named cause, owner, and decision rule.
Frequently asked questions
Why is Meta ROAS higher than MMP ROAS?
Meta and an MMP may use different attribution windows, view-through eligibility, cross-device signals, modeled conversions, date logic, and cross-channel deduplication. Meta reports credit inside its ecosystem, while the MMP applies its attribution policy across measurable channels, so their ROAS figures need not match.
What percentage of attribution discrepancy is acceptable?
There is no universal acceptable percentage. Establish a historical baseline by platform, event, operating system, attribution type, and data-maturity window, then investigate sustained deviations or financially material gaps.
Should Meta installs and MMP installs match exactly?
No. They can differ because of attribution windows, self-attribution, modeled or cross-device conversions, reinstall definitions, fraud rules, time zones, and data latency. They should become explainably closer after you align a controlled comparison slice.
How do you calculate attribution discrepancy percentage?
Choose and name a baseline, subtract it from the comparison value, divide by the baseline, and multiply by 100. For example, (Meta − MMP) / MMP × 100 measures how far Meta is above or below the MMP baseline.
Is MMP attribution the same as incrementality?
No. MMP attribution assigns credit among eligible measurable touchpoints; incrementality estimates how many outcomes would not have happened without the advertising. Use controlled experiments or another credible causal method for incrementality decisions.
How long should you wait before reconciling attribution data?
Wait until every included source has passed its relevant conversion, postback, and ingestion delays. The correct maturity point depends on your windows and data flows, so document it per report rather than applying one fixed delay to every channel.
Turn mismatched dashboards into a decision system
When Meta and your MMP disagree, do not choose a winner by instinct. First decide whether you are optimizing Meta delivery, comparing channels, confirming booked revenue, or estimating causal lift. Then use the source designed for that question.
Start with one mature campaign and one value event. Write the metric contract, align a diagnostic view, classify the remaining rows, and assign a baseline-based alert. If your team needs a simpler, developer-first path for deep links, install attribution, and event-level exports, evaluate Deeplinkly against that contract using your own campaign data.