Web Shop Attribution Basics as Link-Outs Go Live in the EU

Several of the largest mobile publishers (Supercell and King among them) have been testing web shop and direct-to-consumer purchase flows in EU markets since the Digital Markets Act's gatekeeper obligations took effect last March, using the link-out permissions those rules created. Most commentary on the shift has focused on the commercial upside: avoiding platform commission on purchases completed outside the app. Far less has focused on the measurement gap it opens. Web shop attribution is where a UA team's existing MMP setup is most likely to have a blind spot it hasn't yet had to confront.

Web shop attribution: why in-app logic doesn't carry over

Standard mobile attribution, whether it runs on SKAdNetwork or AdAttributionKit or on a probabilistic model, assumes a single continuous journey: an ad impression, a click, an app store visit, an install, then an in-app event, all observable within the ecosystem the MMP is instrumented for. A web shop flow breaks that chain in two. One journey is an ad click leading to a web checkout; the other, separate, is an app install and in-app session that may happen before or after the web purchase, or with no connection to it at all, and the two need stitching together after the fact.

An MMP instrumented only for the in-app side will see the install and the in-app engagement. It won't see the purchase if that happened on the web shop, so it attributes the associated revenue incorrectly or not at all and understates the true value of the campaign that drove both. Getting web shop attribution basics right means treating the web checkout and the app install as two ends of one journey that somebody has to join deliberately, not assuming one MMP setup covers both by default.

Deep linking is the join, and it is easy to get wrong

The mechanism most MMPs use to bridge this gap is deferred deep linking. If the app is already on the device, the link opens directly into the relevant in-app screen or offer; if it isn't, the link routes through the store, captures the click reference, and opens to the same destination once the app launches for the first time. For a web shop flow this has to work in both directions: from an ad into the web checkout, and separately from the web checkout back into the app, if redeeming the web purchase happens inside the app itself.

The most common failure point is treating the web checkout as a dead end rather than a return trip. Suppose a user completes a purchase on the web shop and the confirmation flow doesn't deep link back into the app with the purchase reference intact. The in-app side of the MMP never learns the purchase happened, that revenue is invisible to any campaign-level ROAS calculation, and the report systematically understates exactly the campaigns a studio has the strongest commercial reason to want measured accurately.

What to check before scaling a web shop test

Before putting meaningful UA budget behind a web shop flow, confirm three things with the MMP vendor directly, since default configurations vary and none of the major MMPs enable full web-to-app stitching automatically. Check that server-to-server postback from the web checkout provider passes a click or campaign reference through to the MMP, not merely a purchase confirmation. Test deferred deep linking end to end for a user without the app installed, since this is the path most likely to break silently. And check that the attribution window for web shop conversions matches the one for in-app conversions; a mismatch here will make web-driven campaigns look artificially better or worse purely on a technical setting rather than actual performance.

A worked scenario

Take a hypothetical mid-core title running a web shop pilot in Germany and France. A user clicks a Meta ad and lands on the web checkout without installing the app first. They complete a purchase, then install the app two days later after seeing a retargeting message. If the deferred deep linking test only covered the in-app-first path, the click reference captured at the web checkout may never reach the eventual app install. The campaign report then shows an organic-looking install with no ad spend attached, while the web purchase revenue sits in the web shop provider's own dashboard, disconnected from any campaign line at all. Both the install and the revenue happened. Both are real. Neither is visible to the UA team in a form that can inform the following budget decision, purely because nobody built and tested the two-directional stitching for this specific order of events before the pilot scaled.

Running this exact scenario as a manual test case, install first versus purchase first, before opening a web shop flow to real ad spend is a cheap way to catch the gap while it costs only a testing budget rather than a quarter's worth of misattributed campaign data.

The reporting decision that matters most

Once the technical stitching checks out, decide explicitly whether web shop revenue gets blended into a single ROAS figure alongside in-app purchase revenue or reported as a separate line the team reviews beside it. Blending is more convenient for a single top-line number. It also risks obscuring which channel is actually driving the commercially preferable web-shop revenue versus standard in-app revenue, a distinction that matters given the commission difference between the two. A separate line, reviewed together rather than folded into one figure, keeps that distinction visible for exactly as long as the platform commission gap between web and in-app purchases continues to make it commercially relevant, which for the moment shows no sign of narrowing.

Related archive reading

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

• Web-to-app funnels for mobile games
• The Web Shop Attribution Blind Spot Nobody Budgets For