The Web Shop Attribution Blind Spot Nobody Budgets For

By UA Ledger staff — Archive date: 6 min read

Abstract illustration of a measurement dashboard with a gap where one data stream should connect

The web shop attribution blind spot shows up after launch, not before. Here is what to measure before your link-out flow scales past a pilot.

A US court's decision to hold Apple in contempt over external purchase links has moved web shop building from a niche EU compliance exercise to a mainstream UA priority, more or less overnight. Studios that spent the past year watching DMA-driven link-outs in Europe now want the same build for the US market, on a far shorter timeline than they planned for. Most of the planning conversation has gone to the build itself: payments, entitlements, the link inside the app. Far less has gone to the web shop attribution blind spot that only shows up once the checkout is live and converting.

The blind spot is not that web purchases are hard to measure. They are easy to measure badly, in a way that looks complete on a dashboard while it double-counts some transactions, under-counts others, misattributes a meaningful share of the rest.

Where the web shop attribution blind spot actually sits

An in-app purchase attributes cleanly because the whole transaction happens inside a system, Apple's or Google's, that already ties the purchase to a device and, through the MMP SDK, back to the install and the click that led to it. A web purchase breaks that chain the moment a user leaves the app. The click that sent them to the browser is visible. So is the purchase, if the checkout runs its own tracking. What nobody gets automatically is the link between the two, because the app and the browser are, from a measurement standpoint, two different environments with no shared identity by default.

Studios solve this in one of three common ways. A unique code or token rides along on the link-out URL. Alternatively the web checkout demands a login tied to the same account the player uses in-app. Or the match happens server-side, on device and timing signals. Each of them works. Each of them has a specific failure mode that surfaces at a different point in the funnel.

The specific ways this goes wrong

Token-based matching breaks when a user closes the browser, reopens it later from a bookmark or a history entry, then completes the purchase with the original token no longer attached, which understates attributed revenue. Login-based matching breaks differently. A user completes a purchase without logging in, treating the web checkout as a one-off transaction rather than an extension of the account they already have, which understates attribution too and additionally risks losing the entitlement link entirely if the grant logic depends on that login. Server-side device and timing matching is the most resilient of the three. It is also the easiest to get subtly wrong, since a matching window set too wide creates false positives that inflate attributed revenue, while one set too narrow recreates the token problem in a different form.

As we noted in Web Shop Attribution Basics as Link-Outs Go Live in the EU, none of these methods replaces the clean attribution chain an in-app purchase gets for free. Naming the specific failure modes matters because most teams pick one method, implement it, then stop there, without ever measuring how much of their web revenue that method fails to attribute.

A checklist before scaling past a pilot

Before anyone treats a web shop's reported numbers as reliable enough to inform budget decisions, run through this list.

  • Reconcile total web checkout revenue, taken from the payment processor directly, against total attributed web revenue in your MMP or internal dashboard. Any gap between the two is unattributed revenue, and a gap above five to ten percent deserves investigation before you scale spend against these numbers.
  • Test the failure mode specific to your matching method deliberately: close and reopen a browser mid-session for token matching, complete a purchase logged out for login-based matching, or widen and narrow the matching window for server-side matching, and watch how attribution responds each time.
  • Confirm deduplication logic between app-side and web-side conversion events explicitly. A player who is later re-engaged by an app-install ad after already purchasing on the web can otherwise show up as two separate, contradictory records in the same MMP.
  • Assign one owner for the web shop's attribution stack. Splitting it across an app measurement owner and a web analytics owner, with nobody accountable for the reconciliation between the two, is the most common reason gaps go unnoticed for months.

A worked reconciliation

Take a hypothetical: a mid-size hybrid-casual publisher's payment processor reports $180,000 in web checkout revenue for April, while the MMP dashboard shows $158,000 in attributed web revenue for the same period. That is a gap of roughly twelve percent. Investigating it turns up three contributing causes: a batch of purchases completed through a bookmarked checkout link with no token attached, a small number of logged-out purchases that never matched to an account, plus a handful that fell just outside the server-side matching window during a spell of higher-than-usual checkout latency.

None of those causes is unusual, and none of them needs a different attribution method to fix. What they need is somebody treating the twelve percent gap as a problem to close rather than an acceptable margin of error, then adjusting the matching window, adding a fallback token refresh on return visits, prompting login more assertively at checkout. A team that never runs the reconciliation at all has no way of knowing whether its own gap is twelve percent or forty.

What this means before the next wave of link-outs

The web shop attribution blind spot is manageable, but only for teams who go looking for it before they scale spend on the assumption that reported web revenue is complete. Given the pace external purchase links are moving at in the US now, any team building its first web checkout this quarter should budget the reconciliation work into the launch plan itself. Not into a cleanup project once the numbers already look wrong.

Related archive reading

These articles provide related context and remain subject to their stated review status.

Featured

Related posts

measurement

platforms

·

1 min read

When to turn rewarded ads off for payers (and how to measure the loss)

measurement

platforms

·

1 min read

When custom product pages need their own MMP campaign mapping

measurement

platforms

·

1 min read

Season pass refund rate versus standard IAP refund rate

measurement

platforms

·

1 min read

Pre-reg cohort quality vs post-launch paid cohort quality

More from the Measurement desk

measurement

platforms

·

2 min read

AppLovin Ad Review drops user-level journeys for aggregate-only reporting

measurement

platforms

·

2 min read

Apple adds an EU alternative ATT prompt from iOS 27.2 — mandatory in five markets

measurement

platforms

·

1 min read

Pity-adjusted expected value versus player-facing banner claims

measurement

platforms

·

1 min read

MMP install count vs store first-open: F2P reconciliation lab