Ad Platforms · AppLovin

Last Updated: August 11, 2026

Pixel install cookbook

Event-by-event pixel specs for AppLovin Ads (formerly Axon), the install-method decision rules, and a failure-mode debug catalog. Read alongside the playbook for the platform model and vocabulary. Higher-level tracking, KPIs, and attribution live in reporting and tracking; the API and automation in dev.

Verify these specs against AppLovin's current docs before applying older guidance. The parenthetical dates mark when each note was last confirmed.

The Big 5 events

These five events cover the funnel (AppLovin's events and objects doc). "Big 5" is Tierra's shorthand.

Page View

Fires on every page load, on every page of the domain receiving traffic. It carries the standard params (url, referrer, timestamps).

This is the foundation event. Page View is what the model uses to learn org-level traffic patterns, so a page missing Page View is invisible to the model. The pre-2026 rule ("pixel on funnel pages only") is wrong. Install across the full domain.

Quiz-funnel variant (a quiz-funnel client, 2025-11): fire an additional page_view for each question answered in the quiz.

View Item / View Product

Fires on arrival at the product or offer page.

Shopify rule: view_item only fires from /product/ URL paths, not /pages/. One client (2026-04-16) had a page built at /pages/7-reasons-offer that was missing view_item; rebuilding it under /product/7-reasons-offer#offer-section fixed it.

Item ID rule: view_item item IDs must intersect with purchase item IDs. They don't have to be the exact same SKU (upsells flow through), but they must share something. Hardcoding view_item to a stub product while purchase fires the real SKU breaks the model's linkage. One client (May 2026) had view_product item_ids that didn't match purchase item_ids at all, and AppLovin flagged it. The pragmatic fix was a single shared item_id across all events, which satisfies the literal flag but flattens product-level signal.

Firing timing: scroll-depth or in-view firing is preferred over page-load (2026-04-30). Where the product is above the fold on desktop, page-load is equivalent; mobile and below-fold layouts need explicit scroll handling.

Quiz-funnel variant: fire view_item on the "results are ready" page.

Don't over-engineer landers to fire view_item (2025-11-06). The top-converting landing page beats a spec-perfect events implementation. Prioritize conversion rate. view_item is required for the events check, but the model still works fine without perfect coverage on every lander.

Pixel-inferred catalog dependency: for pixel-inferred Dynamic Product Catalogs, view_item (and purchase) must carry item_id and item_variant_id, and view_item must carry image_url. Catalog production detail lives in creative.

Add to Cart

Fires on click of "add to cart" or an equivalent intent signal.

Lead-gen variant (a lead-gen client, 2026-04-10): fire add_to_cart on arrival at the next intent-signaling page. For example, view_item on /obituary/register/ and add_to_cart on arrival at /checkout-bt/.

Fire it early on long funnels: if drop-off before the register step is significant, an intermediate add_to_cart gives the model earlier optimization signal.

Begin Checkout

Fires on the first input on the checkout form, or on arrival at the payment page.

Quiz-funnel variant: fire on click of "get results", or when payment input starts (PayPal or GPay click).

Stacking with Add to Cart (the lead-gen client): on the payment-button click, fire both add_to_cart and begin_checkout if the funnel doesn't have a true add-to-cart step.

Purchase

Fires on conversion completion. Required params (Tierra practice): transaction_id, dedupe_id, user_data (an object), and item details.

user_data is a Tierra-required practice: always send it. AppLovin's schema marks the User Data object as optional/recommended, so a missing user_data shows orange in the Pixel Helper, not red. Tierra sends it anyway because it's load-bearing for identity matching and attribution.

user_data must be an object with sub-fields, not a flat value. A subject-matter expert (SME) corrected this (2026-03-05): a dev might pass user_data = "email@example.com", which is wrong. The correct form is user_data: { email: "...", phone: "...", customer_id: "..." }. Sub-fields are hashed by the pixel (email lowercased, phone digits-only plus country code).

Why user_data matters: Prospecting campaigns rely on it to exclude existing customers from new-customer optimization. An order-history file alone isn't enough (2026-04-23). The order/customer feed biases the model toward new look-alikes, and it's the pixel user_data match that de-prioritizes known buyers.

Upsell pattern: fire a second purchase event with

the same transaction_id (links it to the original purchase),
a different dedupe_id (distinguishes the upsell row),
value set to the upsell-item subtotal only, not the full cart value,
items set to the upsell items only.

The tradeoff: this captures average order value (AOV) correctly but inflates purchase counts. Recommend optimizing toward ROAS rather than CPP when upsells are in play. Confirmed 2026-04-29, a second confirmation of 2026-03-04.

Scope the purchase fire carefully. Firing the purchase pixel on upsell or decline steps produces $0 or tiny-value "purchase" rows and dedupe_id conflicts that AppLovin will flag. Fire purchase on genuine completed conversions and on the deliberate upsell pattern above, nowhere else. A decline click is not a purchase.

Dedupe merge window: two events sharing a dedupe_id are merged only if they arrive within 5 minutes. A later same-dedupe_id event is dropped. This matters for browser-plus-server dual-sends of the same event: pass the same dedupe_id to the pixel, the server-to-server call, and the SDK to dedupe across channels, but within 5 minutes. The upsell pattern is unaffected because it uses a different dedupe_id.

AOV anomaly debugging: if AppLovin-reported AOV is much lower than the product price (say $20 reported on a $99 product), the most common cause is misconfigured upsell-event firing (sending decline events as $20 "purchases"). After the fix, the model needs 2 to 3 days to stabilize.

Funnel shape: give the model room to send signal

The model learns from the SEQUENCE of the Big 5, not just the final purchase. A funnel that spreads those events across steps hands the model a richer, earlier signal than one that collapses them into a single moment. This cuts both ways:

Long funnels: fire an intermediate event early so drop-off before the final step still teaches the model (the add_to_cart note above).
Compressed / single-page funnels: a direct-response lander that does view, select, checkout, and buy all on ONE page tends to fire almost nothing until the purchase. That starves the model of mid-funnel signal, which is especially costly on a low-volume account (few purchases AND few upstream events). Even on a one-page flow you can and should stage the Big 5 to distinct in-page actions: view_item on load, add_to_cart when a package or quantity is selected, begin_checkout when the shipping or payment fields are engaged, purchase on confirm. It is more signal for the model at zero cost to conversion rate. When auditing an account whose destination is a single-page DR funnel, check for this and recommend it (audit skill: section A.2 signal quality).

Install-method decision tree

Shopify-hosted pages

Default to the AppLovin Shopify App (its native pixel: Web Pixel plus Theme Extension plus product sync; the Theme Extension is what attributes orders). Don't hack the App's pixel with manual Google Tag Manager overlays.
If a page is custom or headless on the same domain, install via Google Tag Manager for that page only; the Shopify App still handles the storefront. On a headless checkout, let the Shopify App handle checkout-page tracking, and don't fire the Google Tag Manager pixel on the checkout page.
Headless Shopify on a different domain (a microsite) counts as non-Shopify, so use Google Tag Manager. The model is trained on the main-domain pixel, so microsite signal alone is inferior.

Non-Shopify funnels (Google Tag Manager)

Install via Google Tag Manager (GTM). The pixel is GA4-compatible, so a GA4-format data layer can feed it directly.
Fire events that represent the funnel stage. Don't worry about exotic event names; the Big 5 cover the funnel. Add sign_up or login on ecommerce flows where they apply, since those are documented recommended events.
Follow AppLovin's Google Tag Manager integration doc, specifically the Enhanced User Identification section.
Enhanced User Identification is the recommended cookie setup. Configure it per the doc.

Page builders (Gem, GemPages, Showit, and similar)

Install via the page builder's native pixel integration if it has one.
If the pages route through /pages/ URLs on Shopify, expect view_item not to fire. Rebuild under /product/ if view_item matters (the same pattern as the Shopify rule above).
Verify with the AppLovin Pixel Helper before launch.

Full-domain install rule

The pre-2026 doctrine ("pixel on funnel pages only") is wrong as of 2026. The current rule: install across the full top-level domain receiving traffic.

Why (2026-05-04, for one client): the model uses cross-funnel signal to learn the org-level customer pattern. Even funnels that don't receive AppLovin-paid traffic have to carry the pixel, because the model is learning what your customers look like organically. A fuller pixel also feeds a cleaner pixel-inferred catalog.

Worked example, the canonical recovery case:

Before the fix, the pixel fired only when a UTM was present (a UTM-gated install), so the model saw only AppLovin-sourced traffic.
Result: CPMs went from $70 to over $1,400. Campaign dead.
Fix: un-gate the pixel so it fires on all page views regardless of source. Multi-domain cleanup followed (removed the pixel from the AppLovin-specific microsite, kept it on the main domain).
Outcome: CPM dropped, ROAS doubled, the account ran profitable.
Cost: that client's onboarding lost weeks to the gating, and AppLovin credit-supported the recovery test.

Multi-domain rule: one pixel per top-level domain, one Shopify per account. Don't run a pixel on both clienthome.com and clientpromo.com from the same account. Pick the highest-traffic domain.

.com vs international TLDs: AppLovin controls accounts by top-level domain. All .com clients go in the .com account; a .cz domain requires a separate account (seen with one client).

Pixel Helper interpretation

The AppLovin Pixel Helper (a browser extension) is the tool for verifying installs (AppLovin's validate your pixel doc).

Status colors

The docs define three states, green, orange, and red, plus a separate "uploaded but inert" case. Red is not the same as "didn't fire": red means the event fired but a required field is missing or the payload is malformed.

State	Meaning	Fix
Green	Payload structured correctly; all required and recommended fields present	None needed; it's healthy.
Orange	Structured correctly but missing recommended fields	Usually `user_data` is absent or malformed, or item metadata is missing. Dev-team fix on the payload.
Red	A required field is missing or the payload is improperly structured (the event did fire)	Fix the payload structure or add the missing required field.
Not firing	Event didn't fire at all	Check the URL has the correct path (`/product/` for Shopify `view_item`) and check the pixel install.
"Pixel Uploaded" with no fires	Pixel installed but inert	The link structure needs correcting. Click "Check Availability" in the Pixel Helper and update the URL.

Verification checklist

Open the Pixel Helper on the actual paid-funnel URL with the full UTM string applied, not the bare home or brand domain. Most events legitimately won't fire on a home URL.
Walk the funnel: arrive, view product, add to cart, begin checkout, purchase (use a test discount or test card).
Confirm the Big 5 fire in the expected order.
Spot-check that user_data is present on Purchase (an object with sub-fields, not a flat value).
Spot-check that item IDs in view_item intersect with item IDs in purchase.
Spot-check the axwrt cookie status (in a non-incognito browser session).

Event counts must descend through the funnel

A technique borrowed from account auditing. Pull the raw event counts and read them in funnel order: Page View, then View Item, then Add to Cart, then Begin Checkout, then Purchase. Each step should fire fewer times than the one before it, because people drop off at every stage. The counts should strictly descend.

Any inversion, where a later step fires more than an earlier one, proves an event is wired to the wrong trigger. Add to Cart outrunning View Item, or Purchase outrunning Begin Checkout, means one of those events is firing on a page or action it shouldn't. The model is then optimizing on a broken signal, so treat any inversion as a payload bug to trace back to its trigger, not a data quirk to explain away.

The `axwrt` cookie

axwrt is AppLovin's first-party cookie for cross-device attribution on web campaigns. Without it, the same person across browsers or devices looks like multiple new visitors.

Always set it. It's strongly recommended on every account, with no vertical or funnel type that skips it.

Debugging gotchas:

Incognito QA: axwrt appears unset during incognito sessions, so verify in a clean, non-incognito session.
The "axwrt cookie unset" warning is non-blocking: it's recommended, not required.

Launching a new account

Before any creative goes up on a fresh account, prove the pixel works, then upload in a controlled sequence.

Fund the account and run a test conversion. Verify the pixel fires and the test conversion registers before you upload anything; AppLovin confirms it in about 5 minutes. Don't push creative until this passes.
There's no need to season or pre-feed the pixel first. A correctly installed pixel starts learning on its own, so a clean install plus one confirmed test conversion is enough to launch on.
Upload assets in a PAUSED state so they clear moderation first. Attach them to sets only after they've cleared.
Upload tranche by tranche, roughly 10 sets or 25 to 50 videos at a time, so you can read the approval verdicts on each batch before sending the next one.

Failure-mode catalog

UTM-gated pixel

Symptom: CPMs spike 10 to 20 times with no clear reason, and the model degrades fast. Cause: the pixel is configured to fire only when specific UTM parameters are present. Fix: un-gate it immediately. The pixel must fire on all page views regardless of traffic source. Don't run any campaign while it's gated.

Multi-domain pixel

Symptom: the model can't find quality audiences, and the rep flags data hygiene. Cause: the pixel is installed on both the main domain and an AppLovin-specific microsite. Fix: pick the highest-traffic domain and remove the pixel from secondary domains.

`view_product` / `purchase` item_id mismatch

Symptom: the rep flags broken view-to-buy linkage, and new-customer rate is low despite a Prospecting campaign. Cause: view_product is hardcoded to a stub item_id while purchase fires the real SKU IDs. Fix: make the item_ids intersect. They don't have to be an exact match, but they must share something. Upsells don't need view_product.

Stale pixel registration on a legacy domain

Symptom: an "AppLovin Pixel is already installed" error when trying to install on a domain. Cause: an old or inactive AppLovin account previously registered the pixel on that domain. Fix: ask the rep to release or clean it up via the AppLovin backend.

`user_data` as a flat value

Symptom: an orange Pixel Helper icon on Purchase and a "missing recommended parameters" warning; the Prospecting campaign struggles to identify new customers. Cause: a dev passed user_data = "email@example.com" (a string) instead of user_data: { email: "..." } (an object). Fix: rewrite the payload to use the object structure with email, phone, and customer_id sub-fields.

Upsell event corrupts ROAS

Symptom: AOV is reported far below the product price (say $20 on a $99 product), and ROAS looks wrong. Cause: upsells fired as separate purchase events with the full subtotal but mis-typed, or decline events fired as purchases. Fix: use the same transaction_id, a different dedupe_id, and value set to the upsell subtotal only. Wait 2 to 3 days after the fix for the model to stabilize.

Pixel installed but inert

Symptom: the Pixel Helper shows "Pixel Uploaded" but no events fire. Cause: the link structure isn't activated yet, or the pixel is registered but the JavaScript isn't loading. Fix: click "Check Availability" in the Pixel Helper and correct the link structure, then retry. If it's still inert, have the dev team check the JavaScript load order.

Redirect strips `aleid` / `alart` (attribution-dead)

Symptom: clicks land but conversions don't attribute, with near-zero downfunnel events (one case: 173 clicks, 0 pixel events). Cause: a redirect, rotator, or same-URL landing-page split-test drops the aleid/alart click params before the user reaches the pixel'd page. These two params connect each page load and conversion back to the originating click. Fix: preserve aleid and alart through every redirect hop. Redirects, rotators, and same-URL split-tests are hard-incompatible with AppLovin (see media buying).

Shopify drops UTMs

Symptom: AppLovin click count is far higher than Shopify session count, and UTM-based multi-touch attribution panels under-report AppLovin. Cause: Shopify-side UTM dropping during a redirect or session handling. Fix: a client-side dev fix. AppLovin's land rate is fine; the gap is downstream.

reporting and tracking: KPI definitions, attribution windows, dashboard vs API reads, catalog measurement.
utm templates: the UTM template strings, supported macros, and hierarchy rules.
creative: catalog production and creative specs.
media buying: why redirects and same-URL split-tests break the algorithm.
dev: the API and automation layer.