What causes the gap between ROAS and actual revenue?
The gap between ROAS and actual revenue exists because ad platforms calculate return using their own attributed revenue figures, while your actual revenue comes from your payment processor, app store, or MMP. These sources use different attribution windows, different event definitions, and different methods for handling refunds, cancellations, and in-app purchase timing.
Several compounding factors make this gap wider than most marketers expect. Ad platforms count a conversion the moment they believe their ad drove it, often using a last-click or view-through model. Your payment processor counts revenue when a transaction clears. Your app store reports net revenue after its commission. None of these happen at the same time or use the same logic.
Refunds and subscription cancellations are a particularly common culprit. A platform may count a subscription signup as full revenue on day one, while your actual revenue only reflects the first billing cycle, or gets reduced when a user cancels within the refund window. This creates an optimistic ROAS figure that simply does not hold up against your finance team’s numbers.
How does attribution affect your ROAS calculation?
Attribution directly determines which ad spend gets credit for which revenue, so the attribution model you use has a significant impact on your ROAS figure. If your platform uses a longer attribution window or a more generous model than your MMP, it will claim credit for more revenue, inflating ROAS beyond what is defensible.
Most ad platforms default to last-click attribution with a window of seven to thirty days. During that window, any purchase a user makes gets assigned to the last ad they clicked, regardless of what else influenced their decision. This means a single user journey can generate revenue that multiple platforms simultaneously claim, a problem known as attribution overlap.
Probabilistic attribution models, which became more common after Apple restricted IDFA access in 2021, add another layer of uncertainty. When a device cannot be matched to a specific ad interaction, platforms use statistical modeling to assign credit. This makes individual attribution less precise and increases the likelihood that your ROAS calculation includes estimated, rather than confirmed, revenue.
Why do ad platform numbers differ from MMP data?
Ad platform numbers differ from MMP data because platforms use self-reported attribution, while an MMP acts as an independent third party that applies consistent rules across all your channels. Platforms have a financial incentive to claim as many conversions as possible; an MMP applies a single, neutral attribution model across every source.
A common scenario is that Google, Meta, and TikTok each report a conversion for the same user install. Each platform saw the user interact with one of its ads within its own attribution window and claimed credit. Your MMP, however, assigns that install to only one source based on a priority rule or last-touch logic. The result is that the sum of platform-reported installs and revenue will almost always exceed what your MMP records.
This is one of the core reasons why tracking numbers do not match across your dashboards. If you are seeing a significant discrepancy, the first question to ask is whether your MMP is the single source of truth you are optimizing toward, or whether you are inadvertently making budget decisions based on platform self-reported data. Using an MMP like Adjust, AppsFlyer, or Branch as your authoritative source is the most reliable way to reduce this noise.
What revenue events should be included in a ROAS calculation?
A ROAS calculation should include only the revenue events that reflect genuine, settled income from users acquired through paid campaigns. This typically means in-app purchases, subscription payments, and any other monetization events that have cleared your payment processor and fall within a defined attribution window tied to the install or first open.
What you should exclude is equally important. Refunded transactions, free trial conversions that have not yet billed, and revenue from organic users who were incorrectly attributed to a paid campaign all distort your ROAS upward. Including them makes your campaigns look more efficient than they are.
For subscription apps specifically, the question of which revenue events to count is more complex. You can calculate ROAS on first payment only, which is conservative and fast to measure, or on predicted lifetime value, which is more accurate but requires a reliable LTV model. Neither approach is wrong, but mixing them across campaigns or time periods makes your ROAS figures incomparable and misleading. Decide on a consistent definition and apply it uniformly.
How can you reconcile ROAS with actual revenue figures?
To reconcile ROAS with actual revenue, establish a single attribution source, align your revenue event definitions, and build a reporting layer that pulls from your MMP rather than from individual platform dashboards. This process will not eliminate all discrepancies, but it will make the remaining gaps explainable and manageable.
A practical reconciliation process looks like this:
- Set your MMP as the single source of truth. All ROAS calculations should use revenue figures from your MMP, not from platform-reported data. This removes overlap and applies consistent attribution logic.
- Align attribution windows across all channels. Use the same window, for example, seven-day click, one-day view, across every platform to ensure you are comparing like with like.
- Define revenue events precisely. Document exactly which in-app events count as revenue in your ROAS formula and make sure your MMP is tracking them correctly, including handling refunds and cancellations.
- Cross-reference with your payment processor monthly. Compare MMP-attributed revenue against your actual payment processor totals. A consistent gap signals a tracking or event configuration issue that needs fixing.
- Account for iOS attribution limitations. On iOS, IDFA restrictions mean a portion of installs will be unattributed. Model this traffic separately and factor it into your overall ROAS assessment rather than ignoring it.
If your app install numbers look wrong or attribution data mismatches keep appearing after following these steps, the issue is often in the technical setup rather than the strategy. Misconfigured SDK events, incorrect postback settings, or misaligned revenue event definitions are the most frequent causes of persistent discrepancies between what your campaigns report and what your revenue actually shows.
At Wuzzon, we help app teams work through exactly these kinds of measurement challenges as part of our app growth services. If your marketing numbers do not add up and you want a clear picture of where the disconnect is, talk to one of our specialists and we will help you get your attribution and reporting aligned.
Frequently Asked Questions
How do I know if my ROAS discrepancy is within an acceptable range or a sign of a real problem?
A discrepancy of 10–20% between platform-reported ROAS and MMP-attributed revenue is common and generally expected due to attribution model differences and timing gaps. If your gap consistently exceeds 20–30%, that is a signal worth investigating — common culprits include misconfigured SDK events, overlapping attribution windows across platforms, or refunds not being passed back to your MMP. Start by auditing your postback settings and comparing platform-claimed installs against MMP-recorded installs for the same date range.
What is the best attribution window to use for mobile app ROAS calculations?
For most mobile apps, a 7-day click, 1-day view attribution window is a widely accepted starting point and aligns with the defaults used by major MMPs and platforms like Meta. However, the right window depends on your app’s typical purchase cycle — subscription apps with long consideration phases may need a longer click window, while impulse-purchase apps may be better served by a shorter one. The most important thing is consistency: use the same window across every channel and every reporting period so your ROAS figures remain comparable.
How does iOS's SKAdNetwork affect ROAS reporting, and what can I do about it?
SKAdNetwork (SKAN) is Apple’s privacy-preserving attribution framework, and it introduces significant limitations: conversion values are coarse, postbacks are delayed by up to 72 hours, and campaign-level granularity is restricted. This means a portion of your iOS installs and revenue will be reported with less precision than Android, which can make ROAS look lower or more volatile than it actually is. The best approach is to configure your SKAN conversion value schema carefully to capture the revenue events most meaningful to your business, and to use your MMP’s modeled or aggregated reporting to fill in the gaps left by device-level attribution loss.
Should I use actual revenue or predicted LTV when calculating ROAS for subscription apps?
For early-stage campaigns or when testing new channels, using first-payment revenue is safer because it is concrete and verifiable — it keeps your ROAS grounded in settled income. Once you have enough cohort data to build a reliable LTV model (typically after 3–6 months of subscription data), incorporating predicted LTV into your ROAS calculation lets you make smarter scaling decisions without waiting for revenue to fully mature. Just make sure you never mix both approaches within the same reporting view, as this makes campaign comparisons meaningless.
Can I use platform-reported ROAS for any purpose, or should I always rely on my MMP?
Platform-reported ROAS is still useful for relative performance comparisons within a single platform — for example, comparing two creatives or two audience segments running on the same channel under the same attribution settings. Where it breaks down is in cross-channel comparisons and in any reporting that needs to align with your actual revenue. Use platform ROAS as a directional signal for in-platform optimization, and always use MMP-attributed ROAS as your authoritative metric for budget allocation and business reporting.
What are the most common technical mistakes that cause persistent ROAS and revenue mismatches?
The most frequent technical issues are: firing revenue events multiple times due to duplicate SDK calls, not passing refund or cancellation events back to the MMP so attributed revenue is never corrected, and mismatched event naming between your backend and your MMP configuration that causes revenue to be logged under the wrong event type. Another common mistake is failing to exclude internal test users or QA installs from your attribution data, which inflates both install counts and attributed revenue. A thorough SDK integration audit, ideally run with your MMP’s testing tools, will surface most of these issues quickly.
How often should I reconcile my MMP data with my payment processor to catch attribution issues early?
A monthly reconciliation is the minimum recommended cadence, but high-spend campaigns or newly launched apps benefit from weekly checks, especially in the first 60–90 days when misconfigurations are most likely to go undetected. The reconciliation process does not need to be complex — comparing total MMP-attributed revenue against net revenue from your payment processor or app store for the same cohort period is often enough to spot a meaningful drift. If you notice the gap widening month over month rather than staying stable, that is a strong indicator that an event configuration or attribution setting has changed and needs to be investigated.
Related Articles
- Branch vs AppsFlyer: app deep linking compared
- How long does it take to see results when you advertise an app?
- How do you advertise an app to build long-term brand awareness?
- How do you advertise an app using Apple Search Ads?
- 8 powerful methods to advertise your app and drive growth
- What are the legal requirements for app advertising in Europe?
- What are in-app review prompts and how do they work?
- How do app store ratings affect rankings?
- 8 best practices for app store keyword optimization
- What are long-tail keywords in app store optimization?
EN 
NL 