Skip to content

Ad Platforms · AppLovin

Last Updated: August 11, 2026

Algorithm mechanics

How AppLovin's algorithm actually spends, sequences, and gets stuck. Read this when reasoning about budget changes, pause decisions, or restructure tactics. Read alongside the playbook for the platform model and vocabulary.

Captured from an AppLovin team call on 2026-04-24, and the consolidated home for AppLovin's own verbatim doctrine from that call. This is the densest single source on how the algorithm operates. The D0/D7 numbers below were dated on purpose because they're expected to change, so treat the mechanics as the current operating model and check against newer AppLovin guidance before a high-stakes call.

The node is the atomic unit

A node (Tierra's term) is one combination of video × interactive pointing at a URL. Every ad runs Video → Interactive → End card. The end card (step 3) shows the catalog, or branding when no catalog is set. Creative sets are human containers: we build them for structure and signal. The system doesn't "see" the creative set. It sees the nodes the set produces.

A creative set with 2 videos and 2 interactives produces 4 nodes per URL. The same node can exist inside several creative sets within one campaign.

The tactical consequence: spend doesn't spread by creative-set ID, it spreads by underlying asset. Pause one creative set and, if its nodes exist in other sets in the campaign, the algorithm keeps spending on them through the other set. Spend control at the creative-set level is an illusion unless every node is unique to that set. (Verified on one account, 2026-04-13.)

Where the model learns

The model learns mostly at the asset level, meaning the node: which node to show, in what order, to which user. It learns secondarily at the campaign level, which is largely the budget pacer and the conversion-rate signal. It learns least at the pixel level, though a brand-new pixel actually learns fast. So when you change something, ask which level you're disturbing. Node-level changes hit the deepest learning; a fresh pixel recovers quickly.

Sequences

The algorithm doesn't just rank ads. It builds sequences of nodes to deliver to a particular customer segment.

Per AppLovin: the median user sees about 10 ads before a first purchase, with a long tail out to about 30. This is a rep claim, and hasn't yet been confirmed by internal testing.

A sequence is the algorithm's plan: show this node first, then this one, then this one, for this user. It has worked out what to show next based on what the user has already seen.

The draft effect

Add a new video into a creative set that's already spending heavily and the new node drafts off the set's existing spend. It gets evaluated faster than the same node would in a cold launch, because it inherits delivery from the set around it. Practical use: when you want a fast read on a new creative, drop it into a high-spend set rather than standing it up cold.

Pause vs disable: the asymmetric consequence

Pause a node in the same campaign across two sets: the algorithm keeps spending against the other set's instance of that node. The node is still alive in the campaign.

Remove a node from a campaign entirely (disable the asset everywhere): the sequence that contained that node likely dies. The algorithm doesn't reliably substitute another node into a learned sequence. It tends to give up on the sequence.

The part that's easy to miss: a hard pause of an asset is more disruptive than it looks. Removing one combination from rotation can kill every sequence that combination was a step in.

When the model gets stuck

Two symptoms:

  • Spend keeps flowing to a dud concept while better creative sits idle.
  • New creative aimed at very different audiences doesn't get spend, because the model has already locked onto a profile the new creative doesn't fit.

Per AppLovin: "I've started to see some advertisers... they get stuck in some sort of local maximum, you know, or like some certain type."

The lever is structure: either creative-set design (disable assets, control spend share) or campaign separation. Iterating harder on the dud concept's family won't work, because the algorithm is already locked. One multi-product account tried within-campaign rebalancing to get its non-dominant products to spend and it just wasn't working. A campaign-separation restructure was needed to break out (see the worked restructure in strategy).

Mass injection to rescue a stuck or broken account

When an account is entrenched on a dud profile or otherwise broken, one rescue play is to launch a large batch of fresh ads, on the order of 100, into a single new campaign. Per AppLovin, this tends to perform well from day one. Unlike Meta or Google, there's usually no multi-day learning-phase dip while the batch ramps. AppLovin prescribes it and it's been observed across accounts. Treat it as a recommended play to test when an account is stuck, not a guaranteed fix. See relaunch playbook for how this fits the wider relaunch sequence.

Network-wide dips

Sometimes every account slumps at once. Per AppLovin, these network-wide dips run in roughly 4 to 5 day windows and hit all accounts together, so a drop that shows up everywhere at the same time is usually the network, not your account. When it's network-wide, hold budgets steady rather than slashing account by account. Cutting into a network dip just locks in lower spend right before the network recovers.

Cloning vs upgrading in place: asymmetric cost

Clone a campaign to test a new structure and it starts from zero learning. AppLovin's rule of thumb is roughly $20k of spend before the clone performs comparably to the original. Per AppLovin: "when you clone a campaign, it's starting fresh. You need roughly 20,000 spend before that new campaign becomes comparable to an existing campaign in terms of learning." Treat the $20k as a rough figure that scales with the account's daily spend, not a fixed cost.

Upgrade an existing campaign in place (for example, switch Universal to Prospecting on the same campaign ID): about 24 hours of volatility, not a full learning reset.

The rule: when the question is "should we test a new campaign type," upgrade in place by default. Clone only when the existing campaign's learnings are themselves the problem (for example, a Universal campaign that's now about 85% retargeting and you want a clean Prospecting surface).

Running two goal types at once

Running a CPP campaign and a ROAS campaign at the same time makes them compete for the same users and impressions, so they trade conversions back and forth. Per AppLovin: "the respective campaign type will maximize that result, but there's a trading back and forth because both campaigns are competing for the same user and the impression." In practice one keeps grabbing the low-hanging fruit from the other.

So don't split budget 50/50 between a CPP and a ROAS campaign; that creates constant trading. Run one clearly dominant campaign with a smaller sidecar instead, around 30/70 or 20/80.

Don't launch a new account fragmented

Launch on one campaign. Hit a baseline of a couple thousand a day (about $2k/day) before considering splits.

Don't do the opposite: five campaigns from day one with different funnels is too fragmented, and the algorithm can't learn.

Once you're baselined, fragment by audience, not by creative. Different campaigns should chase different audience segments (Prospecting, Discovery, retargeting), not different creative pools chasing the same audience.

True Discovery isolation

True Discovery, or any net-new isolation, is stricter than a unique file hash. Every node in the isolated campaign, meaning the video, the end card, and the URL, has to be novel to the account. Re-rendering a video with a microsecond trim changes the file hash but doesn't make the source novel, so it won't count as net-new.

Beyond the individual nodes, source-ID isolation matters. The same production source shouldn't show up in both a main campaign and its Discovery campaign, even as different cuts. If it does, the two campaigns aren't really chasing separate audiences. They're overlapping on the same underlying source, and the isolation is only cosmetic.

Funnel and URL setup

Set up base tracking from day 1: the pixel fires across the full domain (see reporting and tracking) and standard UTM params are in place. Point AppLovin traffic at its own URL, a clone of the client's product page on a distinct slug, so attribution stays clean. Keep the ad platform out of the slug; naming it reads as less professional, so use a neutral slug instead.

Don't build a custom funnel up front. Start by sending traffic straight to the client's product page, establish a baseline, then scale. Only once you have scale and working room is it worth building a dedicated funnel and the advanced tracking that goes with it. Custom tracking a client genuinely needs should go in from day 1, not be bolted on later; what you defer is the custom funnel itself.

If a client insists on a dedicated funnel up front: the pushback is that their existing pixel already sees everything, so you gain little and lose some delivery quality versus a unified pixel plus the product page.

D0/D7 split (dated, expected to evolve)

  • Start a new account on D0 by default.
  • Steady state: about 70 to 80% D0 of an account.
  • D7 is additive for the right audience dynamic, especially when it's incrementality-positive. Two D7-only accounts running geolift incrementality tests showed 30 to 40% lower true CPA than their reported D0 CPA, because D7 captures conversions that multi-touch attribution misses.
  • D7 doesn't show up well on multi-touch attribution or UTM-based attribution tools.

Best D7 candidates: accounts with longer purchase sequences. Poor fits: quick-purchase funnels, and accounts that already have a high new-customer share (for example one account at 80% new customers).

  • parallel campaign tactic: the parallel-campaign force-spend pattern that operationalizes "force the system out via structure."
  • relaunch playbook: the wider relaunch sequence that the mass-injection rescue play feeds into.
  • reporting and tracking: attribution and KPI tradeoffs (D0 vs D7, multi-touch attribution vs cohort).
  • dev: Campaign Management API gotchas when making campaign changes programmatically.