For years, the app store has been an impediment that every mobile growth team has had to work around. Picture this: you run an ad, the user lands on a store page you can only partially control, and Apple or Google decides how much data you get back about what happened. Here, a few things happen: attribution is delayed and aggregated, and creative testing is limited to what the store allows. Meanwhile, payment processing takes a 15-30% cut. As such, every team in your organisation, paid, organic, CRM, and creative, is making decisions based on a fragmented view of the user because the app store sits in the middle and blocks the signal.
Web-to-app flows offer a way around this. By routing users through a web experience before they ever reach the app store, teams can own the full journey, from personalised landing pages, complete attribution, session-level tracking, lower payment fees, to onboarding that starts before the install. In a world where ATT consent rates sit as low as 14%, and SKAN has been replaced by AdAttributionKit with its own set of limitations, web-to-app might just be a way to reclaim the data that privacy changes have taken away.
In this article, we’ll cover why web-to-app has become essential for breaking down internal silos, how it opens up entirely new user groups, and what it looks like in practice. We also asked Claudia Trujillo, ASO Specialist at Phiture, to share her perspective throughout the piece. Claudia’s expertise will help ground these concepts in real-world ASO and user acquisition strategy, showing how web-to-app flows can work beyond theory.
How app store dependence creates silos
Would it be an exaggeration to start by saying that the app store is itself a silo? Truthfully, probably not. It’s also something most teams don’t think about explicitly. When every user passes through the same store listing, the data about who they are, where they came from, and what they did next gets filtered through Apple’s or Google’s measurement systems. SKAN (now AdAttributionKit) provides delayed postbacks with limited conversion values, while store analytics gives you aggregate conversion rates but not individual user paths. The result is that each team works with a partial view.
Take this example: The paid team can see which campaigns drove installs, but the attribution is noisy and delayed. The ASO team can see which store page variants convert better, but they can’t connect those conversions to post-install behaviour. The CRM team can see what users do after they open the app, but they often can’t see what brought them there in the first place. Each team has a piece of the puzzle, and the app store is the wall between them.
This matters because, as we explored in our piece on how data silos hold back mobile growth, the less external signal available, the more valuable each team’s first-party data becomes. When that data can’t flow between teams because the app store fragments it, the entire growth system slows down.
From the practitioner: Claudia Trujillo, ASO Specialist at Phiture “One clear example of how app store attribution limitations make it harder for teams to coordinate is LiveOps optimisation. From an organic standpoint, we always try to push for events to be promoted on both app stores, and from a marketing standpoint, we may be more eager to push live event cards for the LiveOps that sound most appealing to our audience. But the silo that the store listings create for tracking the performance funnel makes it difficult to understand the real impact these event cards are having on retention and revenue. This is where web-to-app and other tracking tools come in: they help you understand the user’s entry point, whether the final attribution was paid or organic, and what the complete funnel looked like for each type of traffic. From that analysis, you can understand which types of LiveOps promoted on each store bring better revenue and retention results for paid vs organic users, and use those learnings to build a stronger roadmap while sharing insights across Organic, Paid, CRM, Revenue, and LiveOps teams.”
What web-to-app actually changes
How do web-to-app flows change this? For one, they move the critical conversion moments, onboarding, payment, and even initial engagement, to a web environment that the team fully controls. According to Google and AppsFlyer, advertisers using app landing pages have seen up to 2.8x higher conversion rates from ad clicks compared to sending users directly to the store.
Several things improve at once when this happens:
Attribution becomes clear. On the web, you have access to pixel-based tracking, server-to-server attribution, and UTM parameters. You can see exactly which campaign, which ad, and which landing page variant drove each conversion, without waiting for delayed postbacks or dealing with aggregated data. That clarity is available to every team, not just the one that runs the campaign.
Payment fees drop significantly. App store commissions run between 15% and 30%. Web payment processing typically costs around 2.9% plus a small per-transaction fee, with blended web-to-app fees landing around 5-6%. For subscription apps, that margin difference can be transformative. Since the 2025 Epic v. Apple ruling, US apps can now link to external purchase options directly, making web-to-app payment flows even more viable.
Testing becomes faster and more flexible. Changing a web landing page takes minutes. Changing a store listing requires app store review cycles and limited A/B testing slots. Web-to-app flows give teams the ability to test messaging, pricing, onboarding sequences, and visual approaches at a pace the app stores can’t match.
Data flows across teams naturally. Because the web experience is fully instrumented, every team can access the same data. While the paid team can see what happens after the click, the CRM team can then see where users came from before they opened the app. Lastly, the creative team can see which landing page variants converted best. The silo that the app store creates between these teams dissolves when the journey happens on a surface you own.
From the practitioner: Claudia Trujillo “A great example of how the ASO team can act on web-to-app data is planning the organic experiment roadmap for the store listing. By learning which visual designs and types of copy are performing best for conversion, you can brainstorm and prioritise which elements ASO should be testing on the store listings next. Another tip is to take those learnings and apply them not only to your main store page but also to specific Custom Store Listings on Google Play and Custom Product Pages on iOS, creating store listing landing pages that resonate best with specific audiences and user types based on what you’ve learned from different web-to-app funnels.”
Reaching user groups that never go through the app store
Besides fixing attribution and lowering fees, web-to-app also opens up distribution channels that a store-only approach can’t reach.
It’s worth noting here that not every potential user discovers apps through app store search. For example, someone reading a blog post, watching a YouTube video, scanning a QR code in a physical location, or clicking a link in an email may already be engaged with your brand or content in a web context. In this way, sending them to the app store at that moment introduces friction: they leave the web, land on a generic store page, and have to decide whether to install based on screenshots and a short description that may have nothing to do with what initially caught their attention.
With that in mind, a web-to-app flow keeps them in context. In fact, the landing page can mirror the message that brought them there. Similarly, the onboarding can start immediately, before the install. As such, the user arrives in the app already oriented and activated, rather than starting cold from a store page.
This is particularly valuable for reaching audiences who aren’t actively searching for your category in the app store. Think about users who discover your product through social media, influencer content, podcast ads, partnerships, or offline channels: these users might never have searched for your app, but they’re often highly motivated because they arrived through a personal recommendation or a piece of content that resonated. Web-to-app gives you a way to capture that intent without losing them in the transition to the app store.
From the practitioner: Claudia Trujillo “One example of how web-to-app can open up new distribution channels is through QR codes. The goal is to keep ownership of the user funnel rather than redirecting users to the store listings. By launching a 360 marketing campaign with both online and offline elements, you can make it easy for users to scan a QR code, learn about the campaign through the website, and still maintain the app download process through this new user funnel.”
Making web-to-app work in practice
Web-to-app flows sound simple in theory, but involve real technical and operational complexity. As Gessica Bicego noted at App Growth Annual 2025: “Web funnels may look simple, but several technical layers add complexity.”
A few things that tend to matter most when building these flows:
Shared identity across web and app. The user who converts on the web needs to arrive in the app with their account, purchase, and preferences intact. This requires deep linking, shared login systems, and careful coordination between web and mobile engineering.
Consistent tracking across surfaces. Running both web and app funnels introduces complexity in measurement. RevenueCat recommends consistently tagging users across web and app and bringing the data into a single source of truth, so you can attribute installs and post-install activity back to the original web source.
Start with a test, not a rebuild. You don’t need to move your entire acquisition flow to the web overnight. No-code landing page builders make it possible to test a web-to-app funnel for a specific campaign or audience segment with minimal engineering. If the results justify it, invest in a more robust setup.
Don’t abandon the app store. Web-to-app is a complement, not a replacement. The app store remains the primary discovery and conversion surface for most mobile products. The smartest teams use web-to-app for specific use cases (paid campaigns, partnerships, reactivation, web-native audiences) while continuing to invest in ASO and store page optimisation for organic traffic.
From the practitioner: Claudia Trujillo “Make sure all your other marketing campaigns are redirected through this flow as a way to centralise and optimise data gathering for your product roadmap. Ensure that both paid and organic traffic go through the web-to-app experience, and don’t neglect testing assets on your website the same way you would test through organic experiments on the app stores or through different ad creatives. And of course, make sure all your analytical tools are properly connected so you’re tracking user performance and interaction accurately across the full experience funnel. That way, nothing gets lost between teams, and the learnings can be shared across Organic, Paid, Revenue, CRM, and LiveOps.”
What’s next
Web-to-app is still early for most mobile teams, but the forces pushing in its direction are only getting stronger. Privacy restrictions keep tightening. App store fees remain high. And the gap between what you can measure on the web versus what you can measure through the app stores keeps widening.
For teams that have been feeling trapped by app store data limitations, web-to-app offers a real path out. It won’t solve every problem, and it introduces its own complexities. But it gives growth teams something they haven’t had before: ownership of the full user journey, from first click to payment, on a surface where data flows freely across every team that needs it.
At Phiture, we help mobile teams build connected growth systems that span both app store and web surfaces. Our integrated growth approach brings paid, organic, creative, and CRM together, and tools like PressPlay and Catchbase optimise how teams test and spend across these channels. If you’re exploring web-to-app as part of your growth strategy, get in touch.
FAQ
What is a web-to-app flow?
A web-to-app flow routes users through a web experience (landing page, onboarding, payment) before they install the app. This gives teams full ownership of attribution, lower payment processing fees, faster testing cycles, and the ability to personalise the pre-install experience.
Why does web-to-app help break down data silos?
The app store fragments data by sitting between the user and the app, limiting what each team can see. Web-to-app flows move key conversion moments to a surface the team controls, where every department can access the same data about who users are, where they came from, and what they did.
How much can web-to-app reduce payment processing fees?
App store commissions run between 15-30%. Web payment processing typically costs around 2.9% plus a small per-transaction fee, with blended web-to-app costs landing around 5-6%. For subscription apps, this margin improvement can be significant.
Does web-to-app replace the app store?
No. The app store remains the primary discovery and conversion surface for most apps. Web-to-app works best as a complement, used for specific channels like paid campaigns, partnerships, reactivation flows, or web-native audiences, while the app store continues to handle organic search and browse traffic.
What user groups can web-to-app reach that the app store can’t?
Users who discover your product through web content, social media, influencer recommendations, email campaigns, QR codes, or partnerships are already engaged in a web context. Sending them to the app store introduces friction and a generic experience. Web-to-app lets you meet them where they are and maintain the context that attracted them in the first place.
What’s the first step to testing a web-to-app flow?
Start small. Pick one campaign or audience segment and build a simple landing page that handles the pre-install experience. No-code tools make this possible without heavy engineering. Test whether the web flow converts better than sending users directly to the store, and expand from there.
Table of Contents
