AppLovin is incremental for your app only to the extent that switching it off would cost you installs and revenue you would not get anywhere else. No ROAS figure in your MMP or in AppLovin’s dashboard answers that, because those figures show credit, not cause. The test that answers it is a geo holdout: AppLovin off in matched regions and on everywhere else, at the same time, with outcomes read from store and backend data and reported as incremental ROAS with a confidence interval. What changes the answer is whether you can measure the outcome by geography. Countries work for any app, US states and metros only when your data can split the US that way, and if it cannot, the answer is that you do not know yet.
Scope: AppLovin Ads app campaigns (iOS and Android) attributed through an MMP, any region, with AppLovin, Impact, Apple, Google, Meta and Haus pages checked on 1 October 2026. AppLovin’s support pages carry no update dates, so treat the check date as the only date.
I have not published an AppLovin incrementality result. What follows is the method I would run on an account, built from AppLovin’s own documentation and the public experiment tools.
What does AppLovin get credit for in an app account?
For apps, AppLovin does not decide attribution on its own. Its page Set up MMP tracking says that to run campaigns in AppLovin Ads you must configure tracking with a mobile measurement partner (Adjust, AppsFlyer, Kochava, Tenjin, Singular or Branch), and that tracking should be set up before any campaign goes live. AppLovin renamed its platform AppLovin Ads and opened it to all advertisers on 22 June 2026; Axon remains the name of its AI recommendation system.
The partner pages spell out the settings. AppLovin’s AppsFlyer page asks for install and in app event postbacks for “All media sources, including organic”, install view through attribution switched on, a click through window of at least 7 days and a view through window of at least 24 hours. Its Adjust page asks for data from all attribution sources, a click window of at least 7 days and an impression window of at least 24 hours.
So the claim that AppLovin counts clicks only, and is therefore conservative, should not be carried over to apps. It comes from AppLovin’s June 2026 post Different numbers, one channel: making sense of AppLovin through a measurement lens, which is written mainly for ecommerce and consumer brands and says AppLovin’s in platform reporting there captures click through attribution only.
A view through window shows that AppLovin served an ad to that device within the window before the install and that the MMP gave AppLovin the credit. It does not show that the ad caused the install. Someone who saw a playable and would have installed from search that evening is still counted. Organic postbacks do not mean AppLovin gets credit for organic users either. They send AppLovin data on every install and event, while the MMP still decides who is credited.
Attributed revenue can also be wrong before incrementality even comes up. In the $27K Google Ads bid strategy test I ran in February 2026, the account’s revenue event sent $1 instead of $0 when a conversion had no value. That inflated the ROAS Google reported across the board, and most on iOS. So before testing what a network causes, I would check what it is being sent. Attributed numbers also disagree with each other when nothing is broken, and why Google Ads, the MMP and SKAN report different iOS conversions covers which gaps are normal.
What does an incrementality percentage mean?
It depends on the denominator, and two different numbers get the same label.
- Lift over a baseline: the percentage by which the treated regions beat what the control predicts for them. The base is what would have happened without AppLovin.
- Incremental share of attributed revenue: the percentage of the revenue AppLovin was credited with that would not have happened without it. The base is attributed revenue.
Neither is a cost figure. A lift figure says nothing about efficiency until you divide the incremental revenue by the spend that produced it. The number I would report is incremental ROAS, incremental revenue divided by AppLovin spend in the treated regions, next to attributed ROAS for the same regions and dates. Incremental can also come out above attributed: in one account I studied, days with 100 more paid Meta installs on iOS showed about 28 more organic installs in the MMP, a sign that attribution can also undercount paid.
Before acting on anyone’s lift figure, I would want to know which outcome was measured, how much was spent, how long the test ran and how wide the interval is.
Why doesn’t switching AppLovin off and on answer it?
Because the weeks change too. Turning AppLovin off in March and back on in April compares two different months: seasonality, a live ops event, a store feature, a price test and changes on Meta or Google all land in the same comparison, and paid spend carries over into later organic installs. Google’s Meridian page Intro to analysis estimates the counterfactual with time based regression, which needs time series from a pretest period and the test period plus a design and geo assignment fixed before the test. The control group has to run at the same time as the treatment.
How would I design a geo holdout for AppLovin?
Pick a geo unit you can both target and measure. AppLovin’s Campaign Management API targets by country_code. Inside the US only, it also accepts region_codes (states) or metro_names (metro areas), which cannot be combined. I found no geo exclusion field, so a holdout region is simply one you leave untargeted.
Accept that the test breaks AppLovin’s scaling advice for a while. Scale your campaign recommends selecting all the countries you support with one global budget, and a budget for at least 15 to 20 conversions a day across the campaign. A holdout removes regions on purpose, so the treated regions still need enough budget for that conversion volume.
Size it before spending. Meta’s open source GeoLift Methodology combines augmented synthetic control for the estimate with generalized synthetic control for inference, and its power calculators suggest test duration, investment and which and how many markets to use. For the tests it runs with brands, AppLovin’s measurement post says holdouts are typically 20 to 50% of the geo footprint, designed for at least 90% statistical power, and that campaigns should be out of learning and delivering steadily before a test starts. Those are figures for brands, not an app rule, but the power requirement carries over.
Hold everything else constant. Keep AppLovin’s goal, target and creative set unchanged, and do not rebuild campaigns during the test: the API sets goal_type and roas_day_target only at creation. Keep other channels’ budgets, pricing, promotions and live ops the same in treated and control regions, or at least moving together.
Run it past the optimization window. AppLovin’s Setting up your app campaign offers Day 7 and Day 28 targets and says longer windows “generally target highest value users”. If the campaign optimizes to Day 28, cohorts installed during the test need to mature to the same age in both groups before I read revenue.
| Question | What answers it | Where the numbers come from | What it cannot tell you |
|---|---|---|---|
| What did AppLovin get credit for? | MMP attribution, with a click through window of at least 7 days and a view through window of at least 24 hours | MMP reports | Whether those users would have come anyway |
| Which partner touched the order? | Impact Incrementality % | Impact’s attribution model | Anything causal; it has no control group |
| What did AppLovin cause? | Geo holdout, lift and incremental ROAS with an interval | Store consoles by territory, backend revenue | Effects in regions or periods outside the test |
| How does AppLovin compare across the mix over time? | MMM calibrated with experiments | Spend and outcome time series | Cause, unless an experiment anchors it |
Where does the outcome data come from?
Not from AppLovin’s dashboard, and not from MMP attributed installs alone, because those are the numbers under test. App Store Connect Analytics lets you filter app metrics by territory, which Apple determines by the customer’s billing address. Google Play’s View app statistics page lists country/region, the user’s country or region, as a dimension. Revenue comes from your subscription backend or your own ledger, split the same way.
Neither store console lists US states, so a state or metro test needs outcome data that records the state. I would confirm that before choosing the design, because it decides whether the US can be split at all.
How do I read the result?
I would report four numbers: incremental installs, incremental revenue, incremental ROAS and its confidence interval, next to attributed ROAS for the same regions and dates. Meridian’s analysis reports the same shape: lift, percentage lift, confidence intervals, p values and incremental conversions per dollar, which it equates with incremental ROAS when the outcome is revenue.
A result that is not significant is usually inconclusive, not zero: the interval shows how large an effect the test could have missed. If the interval is wide, the next step is a longer or larger test, not a verdict. If it is tight, I would use the ratio of incremental to attributed ROAS as a working factor on AppLovin’s targets, for those regions and that period only. AppLovin’s measurement post describes an incrementality test as a moment in time experiment in which holdout size, budget level, test duration, geo composition and campaign stability all interact, so I would retest once those change.
Where do MMM and lift studies fit?
MMM helps once an experiment anchors it. Meridian’s Calibrate treatment priors page says experiments and MMMs often have different estimands: the MMM counterfactual is zero spend, while some experiments measure against reduced spend, in a specific window, region and setup. It says there is no single formula to translate an experiment into a prior, and its CalibrationBuilder adds uncertainty to older experiments and adjusts for spend scale. An MMM with no experiment behind it gives an estimate of AppLovin’s effect, not a test of it.
The published AppLovin lift results I found are about brands. Haus’s Is AppLovin More Than a Hype Channel? Lessons From Haus Incrementality Tests covers geo holdouts from January 2025 to March 2026. The advertisers in it are DTC and omnichannel brands, so it is useful context but says little about apps or games. If a network offers to run a lift test for you, ask for the design, the outcome source and the interval before the test starts. A network’s team sees one network, which is also why it cannot own the decision across the mix; who should run UA for a mobile game past soft launch covers that.
Why is Impact’s Incrementality % modeled credit, not lift?
This comes up when a partner or affiliate channel sits next to AppLovin and claims the same users. Impact’s Incrementality FAQ defines Incrementality % as total fractional credit from the model divided by total orders the partner participated in. The model is a “U-Shaped Time Decay Attribution Model” with a 7 day time decay that weights first and last interactions most. The same page says a high Incrementality % means the partner is driving “real additional value”.
The score only describes a partner’s position in the paths Impact saw, not what would have happened without it. The Incrementality by Partner Report splits roles into % Introduce, % Influence, % Close and % Solo, defines Adjusted CPA as total action cost divided by incremental actions and Adjusted ROAS as incremental revenue divided by total action cost, and recommends at least 30 days of data. Those incremental inputs are the modeled credit, so the adjusted figures are modeled too. The Incrementality Dashboard Explained page says the feature needs specific editions or add ons. The same holdout logic answers the causal question for a partner.
What comes before the test?
For a game buying on AppLovin next to Meta, mobile game user acquisition covers how the two fit together. Before a test, the growth audit reads what each network is sent and says when a question such as whether AppLovin was incremental cannot be settled by attribution. You can book it on its own at any spend.
Sources
All checked on 1 October 2026.
- AppLovin: Set up MMP tracking, no page date.
- AppLovin: AppsFlyer, no page date.
- AppLovin: Adjust, no page date.
- AppLovin: Scale your campaign, no page date.
- AppLovin: Setting up your app campaign, no page date.
- AppLovin: Campaign Management API, no page date.
- AppLovin: AppLovin Ads is now open to all advertisers, 22 June 2026.
- AppLovin: Different numbers, one channel: making sense of AppLovin through a measurement lens, 16 June 2026.
- Google for Developers: Intro to analysis (Meridian GeoX), last updated 28 August 2026.
- Google for Developers: Calibrate treatment priors (Meridian), last updated 24 September 2026.
- Meta: GeoLift Methodology, no page date.
- Apple Developer: Filters and Dimensions (App Store Connect Analytics), no page date.
- Play Console Help: View app statistics, no page date.
- Haus: Is AppLovin More Than a Hype Channel? Lessons From Haus Incrementality Tests, 18 June 2026.
- Impact: Incrementality FAQ, no page date.
- Impact: Incrementality by Partner Report, no page date.
- Impact: Incrementality Dashboard Explained, no page date.
Questions people ask
Does AppLovin count view through installs for app campaigns?
For app campaigns, attribution runs through your MMP, and AppLovin's setup pages ask for view through windows. Its AppsFlyer page asks for install view through attribution to be on, with a view through window of at least 24 hours next to a click through window of at least 7 days, and its Adjust page asks for an impression window of at least 24 hours. The statement that AppLovin reports clicks only comes from its June 2026 measurement post, written mainly for ecommerce and consumer brands, and describes AppLovin's own in platform reporting.
Does switching AppLovin off and on again prove whether it is incremental?
Not on its own. A before and after comparison mixes the channel with everything else that changed in those weeks: seasonality, live ops events, store featuring, other channels and the carryover of earlier spend. What separates AppLovin from the calendar is a geo holdout: regions without AppLovin measured in the same weeks as regions with it, against a model fitted on the weeks before the test.
Can MMM tell me whether AppLovin works for my app?
It can support the answer, not settle it. Google's Meridian documentation calls incrementality experiments perhaps the strongest basis for setting the model's priors, and warns that experiments and MMM often define ROI differently: the MMM counterfactual is zero spend, while a test may compare against reduced spend, in its own time window, regions and campaign settings. A model with no experiment behind it is an estimate of AppLovin's effect, not proof.
Is Impact's Incrementality % a lift test result?
No. Impact defines it as the total fractional credit from its U shaped, time decay attribution model divided by the total orders the partner took part in, with the first and last touches weighted most. It describes where a partner sits in the conversion path. It does not compare exposed users with a control group, so it cannot tell you what would have happened without the partner.