AppLovin creative testing

AppLovin decides which creative spends your money, then reports twelve delivery columns and no outcomes. What a creative comparison can and cannot prove.

On AppLovin the engine decides how much each creative spends, so a spend ranking is an output of that decision and not a measurement of creative quality. The asset report gives you twelve delivery columns and no outcome columns, which means AppLovin’s own data cannot tell you whether the asset it funded was the asset that earned.

This page sets out what a creative comparison on AppLovin can legitimately prove, what it cannot, and the guards that keep a decision honest when you did not control the allocation.

AXON is now AppLovin Ads

If you are searching for AXON, you are searching for a name AppLovin has stopped using. The advertising platform was rebranded to AppLovin Ads on June 30, 2026, and the self-serve product opened to all advertisers rather than a referral programme.

Verified on August 15, 2026: AppLovin’s own advertiser page refers to AppLovin Ads throughout and describes the optimiser only as “AppLovin’s AI engine”. The documentation host support.axon.ai returns HTTP 301 to support.applovin.com on every path we tested.

Nothing underneath changed. The engine still buys, still allocates, and still declines to explain itself. Practitioners will keep saying AXON for years, which is fine. Just do not expect current documentation to be filed under that word.

What the engine reports about its own decisions

Nothing.

That is the whole finding, and it is worth being precise about it. As documented on August 15, 2026, AppLovin’s Asset Reporting API exposes exactly these columns:

asset_id, asset_name, asset_url, campaign, campaign_id, campaign_package_name, clicks, cost, creative_set, creative_set_id, ctr, impressions

Two endpoints serve them, and they do not behave the same way:

Endpoint	Date handling	Ceiling
/assetReport	Presets only: yesterday, last_7d, last_month	No custom range
/assetAnalyticsReport	Custom range, YYYY-MM-DD	45 day maximum window

Read the column list again for what is missing. No installs. No revenue. No ROAS, CPI, or CPA. No conversion of any kind at asset grain.

And nothing about the engine. No exploration or exploitation state is documented, nor a learning-phase marker, a per-asset budget allocation, a reason code, or a confidence value. The system that moved your money publishes no field describing why it moved.

That opacity is not accidental, and AppLovin’s leadership has been direct about it. Speaking to AdExchanger in February 2024, chief executive Adam Foroughi said of the model, “We can’t see into a black-box algorithm.” The campaign scaling guidance tells advertisers to upload and test new assets frequently and to diversify formats. It documents no learning period and no ramp timeline.

So the instruction is to keep feeding creatives, and the reporting surface will not tell you which ones worked.

Why this is not a test

A creative test assumes you controlled the exposure. On AppLovin you did not. The engine chooses how much each asset spends, and it chooses continuously.

That produces three confounds you cannot remove with the asset report alone.

Allocation is the treatment. Assets the engine favours receive more spend, more impressions, and therefore more mature outcome data. When you compare them to assets it starved, you are comparing two different levels of statistical power alongside two different creatives.

Selection runs both ways. The engine allocates on its own predicted outcome. An asset that looks strong early attracts budget, which produces the volume that makes it look strong in your report. Rank and cause are entangled from the first day.

The report stops at delivery. Impressions, clicks, cost, and CTR describe what the engine did. Whether it was right is a question about installs and revenue, and those are not in the response.

None of this means the engine is allocating badly. It means the asset report cannot answer the question you are asking it.

What you can and cannot conclude

Question	Evidence it needs	In the asset report?	Do this instead
Which asset did the engine back?	Cost by asset	Yes	Read it directly. This is the one thing the report answers cleanly.
Which asset earned the most?	Revenue by asset	No	Reconstruct from your MMP or warehouse at asset grain
Which asset earned most per dollar?	Revenue and spend, aligned	Partly	Recompute the ratio from aligned components; never average ROAS
Is asset A better than asset B?	Comparable exposure	No	Treat as a ranking hypothesis, then confirm on matured cohorts
Did this creative fatigue?	Rate series with volume floors	Delivery only	Run the fatigue measurement protocol, then check whether the decline is fatigue or the engine shifting delivery
Which creative choice inside the winners worked?	Tagged attributes, with a sample size counted in creatives	No	Run an attribute comparison with the sample counted in creatives and the number of comparisons corrected for
Why did the engine choose it?	Allocation state	No	Not answerable. Stop trying to infer it

The last row is the one teams waste the most time on. There is no field, so every explanation of the engine’s behaviour is a story fitted after the fact.

Guards that survive an allocated test

Four rules keep a conclusion defensible when you did not control delivery.

Set a volume floor before reading, not after. A ranking over assets that never got enough delivery is noise. Set a minimum spend and impression count per asset, and a minimum number of qualifying assets per app, before you read the table; tune both to the variance in your own account. The floor also depends on the column: re-rank the same assets on the odd and even days of one fortnight and count how much of each top quarter reproduces before you trust it. A revenue ranking rests on far fewer events than an install ranking and needs correspondingly more volume before it holds.

Match observation windows. Compare assets over the same calendar range. The 45 day ceiling on /assetAnalyticsReport means longer comparisons must be stitched from multiple pulls, and a stitched window is easy to misalign.

Gate on outcome maturity. D7 ROAS is only readable once every cohort in the window has had seven days. Comparing a mature asset against one still accumulating manufactures a gap that closes on its own. Which horizon is even available depends on the network, and the attribution window comparison sets out what AppLovin anchors its outcomes to and when the figure stops moving.

Split the read by platform before you rank. The Asset Reporting API has no platform dimension, and on iOS the outcome half of the comparison cannot resolve to a creative at all. What Apple’s postbacks return, and what is left to decide on covers which half of an iOS creative comparison still carries evidence.

Keep provenance visible. Any outcome you attach to an AppLovin asset was reconstructed. Label it. The asset-level creative ROAS audit covers the provenance, scope, maturity, and aggregation checks a number should pass before it changes a budget.

Where this leaves the work

Feed the engine variety, because it can only choose among what you give it. Then build the evidence layer it does not provide: join asset-grain delivery to attributed outcomes, keep an unallocated bucket for what will not match, and rank on reconstructed return rather than on spend.

That work is the same whether you do it in a warehouse or in a product. Lemon AI’s creative analytics puts AppLovin’s reported delivery next to reconstructed installs, purchases, revenue, and ROAS for the same asset, with recovered values visually distinct from network-reported ones so the provenance stays legible. The reconciliation rules and limitations are published in full.

For how the AppLovin reporting surfaces fit together once you have decided what to measure, see AppLovin creative reporting.

Primary sources

On this page

AppLovin Creative Testing When the Engine Allocates Budget