Ad Platforms · AppLovin

Last Updated: August 11, 2026

Reporting and tracking

Reading AppLovin performance and instrumenting the tracking that feeds it. Read alongside the playbook for the platform model and vocabulary. Which KPI to optimize an account against is in strategy; spend diagnostics during a live incident in media buying; the Reporting API and its join semantics in dev; catalog production in creative and catalog production. This is client-agnostic; per-client KPI choices and attribution stacks live in the client's project.

Why tracking comes first

The pixel is how AppLovin learns. Every event you fire (page view, product view, add to cart, checkout, purchase) is a signal the model uses to figure out who buys, so it can go find more people like them. The numbers you read in reporting are a byproduct of that same event stream.

So tracking isn't a reporting nicety. If the pixel misses events, the model trains on incomplete data and can't find the right audience, which starves the account at the source, well before it ever shows up as a bad chart. Clean, complete tracking is the highest-leverage thing you control here. Get it right first.

The pixel: the Big 5 events

The pixel is the tag on the client's site that reports shopper events back to AppLovin (AppLovin's events and objects doc). It centers on five events that map to the funnel:

Event	Fires on
Page View	Every page load. The foundation; everything builds on it.
View Item / View Product	Arrival at the product or offer page. On Shopify it must fire from `/product/` URLs, not `/pages/`.
Add to Cart	Tap of "add to cart" or equivalent. On lead-gen or quiz funnels, fire it on arrival at the next intent-signaling page.
Begin Checkout	First input on the checkout form, or arrival at the payment page.
Purchase	The conversion. Must include the user_data object and dedupe_id.

Where to install:

Use the Shopify AppLovin App as the default on any Shopify page. It handles the Big 5 natively.
Use GTM only when the page isn't on Shopify. Don't bolt GTM onto a Shopify-app page to force an event to appear.
Install on the full domain, not just the funnel. The model uses signal from across the domain, so every page needs the pixel, even pages that get no AppLovin traffic. Delivery leans on aggregate traffic features from across the whole domain (device and operating-system mix, connection speed, carrier, screen sizes, bounce rate, time on page), so a fuller pixel gives the model more to learn from.
One pixel per top-level domain, one Shopify per account. Mixing domains corrupts training.
Never gate the pixel on a UTM. A pixel that fires only when a UTM is present goes blind to organic, email, and direct traffic on the same domain (and CPMs can spike from around 70 to 1,400 or more). It must fire on every page view.

Firing events correctly:

view_item item IDs must match purchase item IDs. A stub product on view_item while purchase fires the real SKU breaks the model's view-to-buy link. Upsells don't need view_item.
Fire view_item on scroll-into-view, not page load. Moot when the product is above the fold on desktop; mobile and below-fold layouts need explicit scroll handling.
Always send user_data on Purchase. AppLovin's schema marks it optional, but Tierra treats it as required, because it drives identity matching and new-customer optimization. It's an object with sub-fields (email, phone, user_id), not a plain string, so passing user_data = "email@example.com" is wrong. A missing or malformed user_data is the usual cause of the Pixel Helper's orange icon.

Upsells and dedupe:

For an upsell, fire a second purchase with the same transaction_id, a different dedupe_id, and value set to the upsell amount only. This keeps average order value right but inflates purchase counts, so optimize to ROAS, not CPP, when upsells are in play.
Dedupe merges two events with the same dedupe_id only if they arrive within 5 minutes; a later duplicate is dropped. This matters for browser-plus-server dual-sends of the same event. The upsell pattern is unaffected because it uses a different dedupe_id.
If average order value looks artificially low (say $20 reported on a $99 product), the upsell dedupe is usually misconfigured. Worth keeping in mind whenever a tracked AOV looks off.

Don't strip the click params:

aleid and alart are the two query params that tie every page load and conversion back to the click that caused it. If a redirect drops them, conversions can't attribute, and the funnel looks like high bounce with nothing downstream. Never strip them (see the redirect rule under UTMs).

Reading the Pixel Helper:

Green: firing with all required and recommended fields present.
Orange: firing, but missing a recommended field (usually user_data or item metadata). Dev-team fix.
Red: firing, but a required field is missing or the payload is malformed. This is distinct from not firing at all.
"Pixel Uploaded" with no fires: installed but inert, usually a URL-structure problem.
Always check on the live paid-funnel URL with the full UTM string, not the bare domain. Most events legitimately won't fire on a home or brand page.

A "pixel check" or "pixel review": fire the Pixel Helper on the live paid-funnel URL, confirm the Big 5 fire in order, confirm they're green (or log the orange fixes), confirm user_data is on Purchase as an object with sub-fields, confirm view_item and purchase item IDs match, and spot-check the axwrt cookie. This is separate from compliance review.

The axwrt cookie is AppLovin's first-party cookie for cross-device attribution on web. Default to always setting it; the one exception is verticals with low returning-customer rates, where cross-device adds little. It reads as unset in incognito, so verify in a clean, non-incognito session.

UTMs and redirects

Tierra supports several UTM conventions. Pick the one the client's stack needs; don't invent a new template without confirming the client's attribution tool accepts it. Full strings and per-stack rules are in utm templates.

Stack	Template family	When
Northbeam	`nb_platform=axon&nbt=nb:axon::{CAMPAIGN_ID}:{CREATIVE_SET_ID}:{AD_ID}` plus standard `utm_*`	Northbeam-integrated clients
Cake (affiliate)	`a/oc/c/s1-s5` with AppLovin's three required `utm_*` (can be blank, can't be removed)	Affiliate funnels behind Cake
Plain	`utm_source=axon` (the `axon` value is the accepted source string)	Default
Hierarchy	Creative-set UTMs override campaign UTMs; catalog clicks inherit creative-set UTMs	Always (a rule, not a stack)

Rules that don't bend:

utm_campaign, utm_medium, and utm_source must be present as keys in the destination URL. Values can be empty (utm_source=), but the keys can't be missing, or AppLovin-side tracking breaks.
Redirects must preserve AppLovin's auto-appended UTMs and the aleid and alart click params. A redirect that drops them breaks attribution.
The tracking day rolls over at midnight UTC (7pm Eastern / 4pm Pacific in winter, 8pm Eastern / 5pm Pacific in summer). Activity after rollover counts toward the next day in AppLovin's UTM reporting.
Prefer {CREATIVE_SET_ID} over {CREATIVE_SET} (the name) for utm_content. Names break when a set is renamed; IDs don't. The ID value is a hashed string, not a number.
{AD_ID} is not a real macro. Ad-level attribution comes from {CREATIVE_SET_ID} plus separate asset data. The nearest supported ad-level grain is {EVENT_ID} (the ad-request ID).
Supported macros, complete list (AppLovin's tracking URL macros doc): {AD_SIZE}, {AD_TYPE}, {CAMPAIGN_ID}, {CAMPAIGN_NAME}, {CREATIVE_SET_ID}, {CREATIVE_SET}, {EVENT_ID}. No device-level macros.
Cake is an affiliate-tracking platform. When a funnel sits behind it, Cake auto-injects utm_campaign, utm_medium, and utm_source on redirect, so blank the values on AppLovin's side and keep the keys.

Attribution

Attribution is click-through only. Every window counts time after an ad click; AppLovin has no view-through or impression attribution (AppLovin's measurement and attribution doc).

The windows are zero-indexed (D0 is the first day):

D0: within 24 hours of the click. Inside D0, roughly 80% of conversions land within 1 hour and about 90% within 24 hours, so D0 is a meaningful early read, not a truncated one.
D7: within 192 hours (8 calendar days, not 7).
D28: 29 calendar days.
Spend always attributes to the click date, whatever the window.

Don't read the "conversion happened within the first hour" speed as a landing-page signal. That first-hour concentration is normal for the channel and says nothing about whether a landing page deserves more or less budget. Validate any landing-page budget reallocation on D0 ROAS instead.

Maturity matters. D0 stabilizes after about 24 hours. D7 keeps moving for about two weeks (per AppLovin, "D7 only really matures after 2 weeks"), so don't draw scaling conclusions from D7 data less than 14 days old. The standard scale-up read is D0 and D7 side by side, steady-state around 70 to 80% D0 and 20 to 30% D7.

Last-click at the asset level, sequence at the account level. On a single asset, AppLovin credits only the last click before conversion, so top-of-funnel creative looks weak by design. At the account level the model is sequence-based: it knows a shopper saw several ads and treats the early ones as warmers, the late ones as closers. Manage to account-level KPIs, and never quote a per-asset ROAS or CPA as a verdict to a client.

Two divergences to expect, and to name up front so nobody is caught off guard. Platform-reported ROAS and true (incrementality) ROAS can differ by around 30%. AppLovin order counts can read roughly 50% below on-site add-to-cart counts. Both trace back to attribution being last-click, so the platform number and the on-site number are counting different things and won't line up.

Multi-touch tools under-read AppLovin. UTM-based multi-touch tools (Triple Whale, Northbeam, and similar) miss the conversion lag that D7 captures. In geolift incrementality tests, D7-only accounts showed 30 to 40% lower true CPA than their reported D0 CPA, with true CPA close to D28. That upside is real but invisible to multi-touch dashboards, so prove D7 wins through geolift, not a multi-touch panel. The Northbeam-versus-platform ROAS gap widens as the new-visit rate drops; when reconciling, set the in-platform KPI and window to best match the client's multi-touch KPI.

In-app browser conversions often go unclaimed. When a shopper taps an ad inside an app and then converts in that app's in-app browser, the attribution cookie was set on the device's default browser, not the in-app one, so the conversion can't be tied back to the click. The same gap inflates the in-platform new-visitor percentage, because those shoppers look new when they aren't. Don't trust the new-visitor percentage on its own.

Integration notes:

AppLovin has a native Triple Whale integration. It's UTM-based, so sales from before the UTMs were added won't attribute.
Triple Whale's server-side setup (its "Sonar" mode) lifts measured conversion rate to roughly 15 to 17%. Turn it on at least a week before launch so it's seasoned by the time spend starts.
Triple Whale versus platform D0 drift is account-specific. Document the expected drift per account.

KPIs

ROAS: revenue over spend, cohort or real-time, at D0, D7, or D28.
CPP: the cost-per-purchase goal, the bottom line when ROAS is noisy (upsells, subscriptions). AppLovin recommends CPP when average order value swings a lot.
NCPA (also NC CPA): New Customer CPA, acquisition only. Native new-customer variants exist for D0 and D7.
NC%: share of conversions from new customers, from pixel user_data matching rather than Shopify customer state, so it's cookie-limited.

Which to lead with, by campaign:

Discovery: the new-customer flavors (NC D0 CPP, NC D0 ROAS). Discovery already screens out anyone with an AppLovin cookie, so the population is new visitors.
Prospecting: NC D0 CPA / NCPA.
CPP campaigns: cohort D0 CPP, and treat ROAS in that view as incidental.

Reading the numbers

The API is the source of truth, not the browser (AppLovin's Reporting API doc). It ties to the same database AppLovin bills against, so spend should match within 0.5%. A bigger gap is a bug worth reporting.

Real-time versus cohort is a day-bucketing choice, not a different number. Real-time buckets a conversion by the day it happened; cohort buckets it by the click date. Same events, spend always sits on the click date either way. The AppLovin browser and the Tierra dashboard both default to cohort. The Reporting API defaults to real-time, so pass day_column=day to get the cohort view and line it up with the dashboards. Confirm which view you're in before quoting, and don't draw conclusions from the last few days, where the two can differ 10% or more until the data matures.

Normalize time zones before comparing. The API runs in UTC ("All data in the reporting API is in UTC"); the browser defaults to account-local. Recurring gotcha.

Revenue and checkout counts can drift a few percent more than spend when you compare a cohort view to a real-time pull on recent days; put both on the same view to reconcile.

Anchor controls separate platform drift from creative drift (a recommended diagnostic, worth testing on an account before you rely on it). Hold about 20 fixed nodes live for 30 days, spanning every end card, concept, and source, as a stable reference set. If the anchors drift along with the market, the platform changed. If the anchors hold while new nodes drift, the change is in the new creative, not the platform.

Lookback caps:

Reporting API: 90 days on the website-side endpoint (our accounts), effectively about 88. The app-side endpoint caps at 45, so don't quote 90 as universal.
Asset Reporting API: 45 days on both endpoints.
Browser asset view: about 30 days ("last month").
Beyond these, a daily warehouse import is the only way to keep history. Tierra pulls data daily at creative-set level and re-pulls the rolling 30 days to catch delayed attribution.

The {CREATIVE_SET_ID} macro is a hashed string, not a number, and the Reporting API's creative_set_id column shape is undocumented, so don't assume it's numeric. The ID-join and the double-count trap it can cause are handled by the AppLovin MCP overlay (the MCP and the campaign-management browser are the same system, per the playbook); detail is in dev.

New-customer supply

New-customer targeting is a bias mechanic, not an exclusion list. You supply your existing-customer data and AppLovin models it to find new, high-value users who resemble your buyers. Supply it three overlapping ways: a hashed CSV upload, the Shopify integration, or order-history data. It biases delivery toward new customers; it doesn't hard-exclude known buyers, so don't promise a client that existing customers are fully suppressed. Discovery's cookie filter is a separate "new visitor" mechanic, not new-customer. NC% is defined under KPIs, and the full mechanic is in the playbook.

Related setup caution: don't over-narrow the product category when you set up the account or the catalog. Pick a broad category like "pet care," not a hyper-specific one like "CBD pet treats for a single breed." Over-niching starves the model's audience, so it can't find enough new buyers to spend against.

Catalog measurement

The catalog is the third ad unit (the end card shows the catalog, or branding if there's none). Production (types, feeds, tiles) is in creative and catalog production; this covers only how the catalog shows up in the numbers.

Contribution (field-observed): of clicks, video / interactive / catalog is roughly 24% / 65% / 10%; of purchases, roughly 52% / 36% / 12%. The catalog is the smallest lever, since reaching it takes an extra tap, but it's in every impression.
AppLovin cites a roughly 10 to 25% conversion lift from running a catalog; Tierra sees closer to 10 to 15%. Always run one.
Catalog clicks inherit the creative-set UTMs, not the campaign UTMs, the same rule as asset URLs.
A blank tile or banner URL falls back to the creative-set URL, then the campaign URL. Per-tile URLs are optional.
No per-product-within-catalog visibility and no per-asset-type sale split in native reporting. It's on the dashboard wishlist.

Reporting Key and Account Groups

Every AppLovin account has a Reporting API key. Store it with the /update-client Slackbot command. The field masks to the last 4 characters, which trips people up: a filled field can look blank, and a value like 7D under it means the key ends in 7D, not "expires in 7 days." Entering a key the first time backfills full history from account inception. Find the key in the client's AppLovin Slack channel, in the most recent rep message.

Multiple accounts (per geo, per product, per legal entity) aggregate through Account Groups. Onboarding a multi-account client means gathering every Reporting Key, entering each with /update-client, and confirming the Account Group is created. The full procedure is in the dashboard process docs.

Reporting cadence

Weekly is the standard cadence. Above about $10k a day you'll read daily, but the weekly synthesis is the client-facing layer. Don't treat recent unmatured days as final: the last day or two of cohort data and the last two weeks of D7 data will still move. State the lookback window whenever you quote numbers.

For a weekly read at scale, group by video x end card over the trailing 7 days, and sort by spend for winners and by CTR for signal:

Top 3 to 5 spenders: spend, CTR, peak week, and a likely reason for the outcome.
Top 4 to 8 end cards by CTR, same structure.
Bottom 3 as a diagnostic.

Feed this into the monthly relaunch grid (strategy).

A spend-velocity read shows which sets are gaining or losing momentum (a recommended read; validate it on an account before leaning on it). Take the last 7 days of spend, scale it to a 30-day pace (multiply by 30/7), and divide by the last 30 days of spend. Above 1.3 is accelerating, 0.75 to 1.3 is steady, below 0.75 is fading. A value around 4.3 just flags a set that launched inside the last 7 days, so treat it as a sentinel to skip, not a signal to act on.

Hold this benchmark loosely: AppLovin's average CTR runs around 2.7%. A CTR above that paired with weak sales points at the landing page or checkout, not the creative, since the ad is clearly earning the click.

Spend before you judge an ad:

Under $500 a week per ad: don't draw individual-ad conclusions.
Bigger accounts raise the bar: a $10k-a-day account needs $1 to $2k cumulative per asset first.
Below threshold, an ad sits in an "unread" bucket. Apply this to ranking tables.

Placements: interstitial ads run a roughly 22-second median view, rewarded about 56 seconds, and spend splits roughly 50/50. Beyond those confirmed numbers, Tierra's read (not a published AppLovin figure) is that impressions skew interstitial and rewarded costs more per impression. Frame it that way, and don't state a hard impression ratio until a per-placement export from AppLovin settles it.

Known gaps

sign_up, subscribe, and search are documented AppLovin events (recommended, non-Big-5, carrying the Item and User Data objects). Fire them where the funnel warrants; the old "undefined" framing is out of date.
No conversion-by-asset in AppLovin reporting (as of 2026-04-09). The last-click sequence shape means asset-level conversion attribution isn't coming, and the Asset Reporting API carries impressions, clicks, CTR, and cost only.
No asset-level UTMs. Ad-level attribution comes from creative-set ID plus asset-level warehouse exports.
CAPI isn't currently recommended by AppLovin. A dual CAPI-plus-pixel setup is on the roadmap at low priority.
No native new-customer D28 variants (checkouts, %, CPP, ROAS), and Tierra does not compute them anywhere either — not the dashboard, not the daily importer, not the data connection. If a D28 new-customer number is ever needed it has to be derived by hand. (An earlier version of this line claimed the dashboard computes them; that was never true.)

strategy: which KPI to optimize an account against, campaign structure, when to relaunch.
media buying: spend diagnostics, budget moves, pixel troubleshooting during a live incident.
creative and catalog production: catalog production, tile design, feeds.
dev: the Reporting and Campaign Management API join semantics and the creative_set_id double-count.
pixel install cookbook, utm templates: the deep dives on pixel install and full UTM strings.