On iOS, you no longer see who converted. You do not see what they paid, and you do not see what they are worth over the next twelve months. Since App Tracking Transparency and SKAdNetwork reshaped attribution, user-level truth on paid installs was replaced by aggregated, delayed, and deliberately noised postbacks. Your dashboards still fill with numbers. The numbers are just no longer tied to people.
That loss is why a web-to-app funnel has stopped being a niche checkout tactic and become a primary revenue engine for subscription apps in 2026. Web billing is still a minority of the market in aggregate, roughly 3% of tracked revenue in RevenueCat's State of Subscription Apps 2026, but it is the fastest-growing route to purchase, and the leaders routing new revenue through the web are pulling far above that average. As in-app attribution stays privacy-constrained, the one measurement layer you can still own outright sits on the web, before the App Store handoff. A web-to-app funnel is actually a first-party data-recovery system, not just a checkout workaround, because the pre-install checkpoint on your own domain restores the deterministic identity and revenue signal SKAN structurally cannot give you.
This piece is an operator's read on that idea: what SKAN actually took, what the web checkpoint gives back, how to wire it without overclaiming, and the honest economics underneath, including a 2025 legal shift that changes the usual margin pitch.
What is a web-to-app funnel?
A web-to-app funnel is a flow that begins on a web page you control, a landing page, a quiz, an onboarding sequence, or a checkout, and routes the user into your mobile app afterward. The distinguishing feature is not the creative or the offer. It is that the first meaningful step happens on your own domain, where you own the analytics, rather than inside a store listing you do not.
There are two common variants, and the difference matters for measurement. In the first, the user subscribes on the web and then downloads the app already entitled. In the second, the web page does the storytelling and identity capture, then hands off to a standard App Store install where payment happens in-app. Both are web-to-app funnels. Both put a checkpoint you own in front of the store, which is the part that recovers signal. RevenueCat's overview of web-to-app funnels frames the appeal as control: the storytelling, experimentation, and pricing latitude of the web, connected to the retention of the app.
What SKAN actually took away
SKAdNetwork did not make attribution worse by accident. It removed user-level measurement by design, and understanding exactly what it removed is the whole basis for the recovery argument.
Aggregated, delayed postbacks instead of user-level attribution
Under SKAN, you do not receive an event when a specific user installs and converts. You receive a postback, released on a randomised delay, that tells you a campaign produced installs and some downstream value. The install and the person are severed on purpose. You learn that a cohort did something; you never learn who, which is the input every optimisation and lifecycle decision actually needs.
Coarse conversion values and crowd-anonymity thresholds
The conversion value that rides along with a postback is small and constrained. When volume in a campaign falls below Apple's crowd-anonymity threshold, even that coarse value is withheld or downgraded, so precisely the campaigns you most want to read, the new, the small, the still-scaling, are the ones that return the least signal. This is not a bug you can engineer around; it is the privacy model working as intended.
No user-tied post-install revenue signal
The most expensive loss for a subscription business is revenue. SKAN gives you no durable, user-level view of what someone paid after install, what they renewed, or what they became worth. You can model lifetime value, but you are modelling on top of anonymised cohorts, not measuring it against real identities. Layer this on top of App Tracking Transparency, which already suppresses the IDFA for the large majority of users who decline the prompt, and the practical position is stark: for most of your iOS install base, the person, the payment, and the renewal are three facts you can no longer connect.
By 2026 there is one more thing to keep straight so this reads current rather than dated. Apple has introduced AdAttributionKit as SKAdNetwork's successor, unveiled at WWDC 2024. It adds re-engagement support, creative-type differentiation, and multi-marketplace handling, but as Singular's breakdown of AdAttributionKit versus SKAdNetworkmakes clear, it preserves the same privacy scaffolding: separate postbacks, coarse and fine conversion values, crowd-anonymity thresholds, and randomised delays. Tenjin's comparison notes the two are fully interoperable and that Apple has quietly stopped signalling future SKAN versions. The practical takeaway for this article: "SKAN" is the term everyone still uses, but the structural constraints now live under AdAttributionKit too, and none of them restore the user-level signal you lost.
That gap is where the funnel earns its real name. As Diana Daniuk, UA Manager at Applica, puts it:
SKAN tells you a cohort converted. Web-to-app tells you who, what they paid, and what they're worth. That gap is the whole argument.
© Diana Daniuk, UA Manager at Applica
How a web-to-app funnel recovers first-party data
If SKAN's constraint is that the store handoff severs identity from event, the fix is to do the measurable work before the handoff, on a surface where privacy thresholds and postback delays do not apply. That surface is your own web page, and it recovers three things SKAN took.
The web checkpoint you own
On your landing page you are a first-party. You can fire your own analytics, set first-party cookies, and, most importantly, run server-side events into the ad platforms: Meta's Conversions API and Google's Enhanced Conversions both accept hashed, consented signal sent server-to-server rather than depending on a device identifier. This is the difference between reporting a modelled cohort and reporting a real, timestamped action tied to a session you observed. Applica has argued for years that the events you trust are often wrong when they depend on fragile client-side signal; the web checkpoint is where you get to fix that at the source.
A durable consented identity
The web page is also where you can ask for, and receive, a consented email or account identity. This is the asset SKAN can never return: a first-party identifier that does not depend on the IDFA, that populates a CRM you own, and that you can hash into a matchable audience for Meta CAPI or Advantage+. It is worth being precise here, because the framing matters legally and ethically. This is consented first-party data, collected under a clear opt-in, not a way around App Tracking Transparency or a privacy loophole. The user chooses to give you their identity in exchange for the value on the page. You are recovering measurement you are entitled to, not circumventing a consent framework.
The audiences you can rebuild from it
A consented identity is not only a measurement asset; it is a targeting one. Once the email and the first-party event sit in a CRM you own, you can hash and match them back into the audience tools that ATT and SKAN quietly hollowed out: Meta Custom Audiences and Advantage+ lookalikes, Google Customer Match. In practice a conventional web-to-app flow lets you rebuild the seed and retargeting audiences you used to build routinely before the IDFA went dark, this time from data the user chose to give you rather than from a device identifier. That is the difference between an anonymised SKAN cohort you can only report on and a first-party audience you can actually acquire against. The limit is the same one that governs the rest of the funnel: the match feeds the platforms server-side and improves who you can reach and model, it does not restore user-level iOS post-install attribution.
Deterministic stitching, and its iOS limit
Here is the part most guides overstate, so read it carefully. The web click that starts the funnel carries deterministic parameters. On Android, you can pass those through the install with the Play Install Referrer API and get a genuinely deterministic web-click-to-install join. On iOS, you cannot. Once the user hits the App Store, the post-install measurement is governed by SKAN and AdAttributionKit, and it stays probabilistic and aggregated. A web-to-app funnel recovers the pre-install web layer and makes it deterministic; it does not turn iOS post-install attribution deterministic. Anyone who tells you it does is selling you a version of the mechanism that does not exist. What you gain on iOS is a clean, owned, deterministic record of everything up to the handoff, plus the consented identity, which is a large recovery, just not an unlimited one.
Does web-to-app fix SKAN attribution?
A web-to-app funnel recovers the pre-install web layer as deterministic first-party signal, and delivers deterministic post-install attribution on Android via the Play Install Referrer. It does not make iOS post-install attribution deterministic; that remains SKAN and AdAttributionKit territory. So the honest answer is: it fixes the part of the funnel you can own, and it does not pretend to fix the part Apple governs.
In practice that reframes your optimisation loop rather than restoring the old one. You optimise against a rich, deterministic set of pre-install and identity signals, feed those server-side into the platforms, and treat the iOS post-install postback as a coarse confirmation layer rather than your source of truth. This is exactly the blend RevenueCat describes in its guide to modelling attribution on iOS: deterministic where you own the surface, probabilistic and modelled where Apple governs it, and no pretending the second is the first. This is the same logic behind the direct-app-campaign setup Applica runs when a full web funnel is not the right build: the goal in both cases is to move the decision-grade signal to a surface you control, because SKAN's limits are structural and will not be patched. Web-to-app is one route to that. It is not the only one.
Is web-to-app cheaper than app-install campaigns?
This is where the popular pitch and the real numbers part ways, and where an operator should be most sceptical.
The margin arithmetic is easy to run, which is why everyone runs it. In-app purchases carry Apple's commission, 30% at the standard rate and 15% under the App Store Small Business Program or after the first paid subscription year. A web checkout through a processor like Stripe costs roughly 3% plus per-transaction fees, though a full merchant-of-record setup that handles global tax and compliance costs more. On paper, moving the transaction to the web keeps the double-digit share Apple was taking. That is real, public arithmetic any operator can do. It is not, and should not be presented as, a measured result.
Because the conversion side of the equation usually pushes the other way. A RevenueCat controlled test on a subscription app found web checkout produced meaningfully fewer trial starts than in-app purchase, roughly 18% versus 27%, and that after accounting for the fee savings, web subscriptions generated about $0.93 for every $1.00 earned through IAP. The friction of an extra step, a card entry, and a context switch frequently costs more than the commission saves. Retention and lifetime-value effects cut both ways: the same dataset showed far higher first-month retention on web but a lifetime-value gap in the app's favour over a longer horizon, which tells you the trade is real and specific to each funnel rather than a guaranteed win. The lesson is not that web-to-app loses money; well-built funnels clear the bar, and the break-even web conversion rate is close enough to reach with disciplined testing. The lesson is that margin alone is a weak reason to build one, because the naive "save 30%" model quietly ignores the conversion tax.
| Metric | IAP only | Web only | Honest interpretation |
|---|---|---|---|
| Initial conversion | 27.0% | 18.1% | Web produced approximately one-third fewer initial conversions |
| Conversion to paying | 6.3% | 5.3% | The web flow ultimately produced fewer paying customers |
| Gross revenue per customer | $2.98 | $2.09 | Lower conversion reduced gross revenue per exposed customer |
| Estimated payment costs | 30% store-fee scenario | ~6% blended web-cost assumption | Web retained more of each successfully processed payment |
| Relative take-home revenue | $1.00 | ~$0.93 | Lower fees did not completely offset lower conversion |
| Strategic trade-off | Higher conversion, higher fee | Lower fee, greater checkout friction | Neither route is automatically more profitable |
The legal picture has also moved, and getting it wrong dates a piece instantly. Following a 2025 US injunction in Epic v. Apple, developers could link out to external web purchases without Apple's commission, which is the world most web-to-app margin pitches were written for. That window is now contested. In December 2025 the Ninth Circuit modified the injunction, ruling that Apple may charge a "reasonable commission" on external-link purchases, and sent the case back to the district court to set the rate. Any external-purchase flow still operates under Apple's External Purchase Link Entitlement terms, which carry their own disclosure and reporting requirements. The dispute has continued to escalate toward the Supreme Court into 2026. So the accurate framing is narrow: in the US, following the 2025 ruling and subject to Apple's external-purchase terms, external checkout may reduce or remove commission, but the fee-free version of this story is US-only, still moving, and no longer safe to state flatly. If your entire case for a web-to-app funnel rests on a commission you may not keep, you have built on sand. If it rests on the recovered signal, the legal weather does not change the thesis.
How to wire a web-to-app funnel without losing the signal
The build order is what separates a funnel that recovers data from one that just relocates the checkout.
Build for the checkpoint first
Start by treating the web page as the measurement asset, not the sales page that happens to have a pixel. Own the checkpoint, fire first-party and server-side events into Meta CAPI and Google Enhanced Conversions, capture the consented identity, and only then stitch deterministically where the platform allows, Android through the Play Install Referrer, iOS up to the handoff. If you build the checkout first and bolt measurement on afterward, you tend to recover the transaction and lose the signal, which is the expensive half backwards.
Reconcile the numbers before you trust them
The moment you run a web checkpoint alongside the store, your web analytics, your MMP, and your revenue tooling will disagree, because they count different events at different times under different attribution rules. Decide your source of truth deliberately. Applica has written on why Mixpanel, RevenueCat, and Stripe show different numbers and how to reconcile them; the discipline there is not optional once you own a second surface. Clean, deterministic web signal is only an advantage if you know which system to believe when they diverge.
The payoff shows up in what you can then do downstream. Consider the composite pattern of a subscription app that moved its checkout to the web and captured a consented identity on a share of its installs. It did not suddenly gain user-level iOS post-install attribution, and it did not need to. What it gained was the ability to turn an anonymous SKAN cohort into a matchable first-party audience, feed deterministic conversions server-side into its channels, and read its funnel where it had been flying blind. That recovered signal, not the commission line, is what let it optimise its performance channels in 2026 on evidence rather than modelled guesses, and to weigh web against Apple Search Ads and Meta on the quality of signal each returns rather than on cost alone.
The decision rule
A web-to-app funnel is a first-party data-recovery system, not just a checkout workaround, because the pre-install checkpoint on your own domain restores the deterministic identity and revenue signal SKAN structurally cannot give you. Three things follow from that. First, treat the web checkpoint as a data asset before you treat it as a margin play; the recovered identity outlasts any commission ruling. Second, scope the claim honestly: you recover the pre-install and identity layer, and Android post-install, while iOS post-install stays SKAN and AdAttributionKit governed. Third, if a healthy funnel does free up margin, redeploy it into acquisition, but build the funnel for the signal, because the signal is the part no legal reversal can take back.
If your iOS attribution has quietly gone dark and you are optimising on modelled cohorts, the first move is to map exactly what signal you have lost and where a checkpoint you own could recover it. Explore where a web-to-app funnel fits your acquisition strategy with Applica's performance marketing team, and start with the measurement layer, not the checkout.
