Using web-to-app to go from 0-1 with your paid user acquisition

As an independent consultant, Marcus helps subscription apps unlock Meta as their primary growth channel. He’s been in the industry for over a decade and has a background in both gaming and consumer tech (Forge of Empires, Blinkist, Tandem…). You’ll find him on LinkedIn sharing practical advice on Meta Ads, Web2App, optimizing paywalls, and improving user onboarding.

In 2019, after 7 years in the games industry, I made a big move. A move from mobile games to subscription apps.

For the next few years, I ran Paid Social, ASA, and ASO for Blinkist, one of the hottest subscription app startups based in Berlin. Metrics, goals, creatives… a lot was different in this new world.

But one thing really stood out to me:

70% of Blinkist’s ad spend was going to web-to-app. A strategy that didn’t really exist in gaming in 2019. I was intrigued when I heard that we saved the App Store commission on first purchases and renewals.

Some of Blinkist’s web-to-app flows had users pay on the web, while others were only meant for tracking or tailoring a pre-store experience to a specific channel.

My personal passion for the topic was born. Yet it would take me a few more years to fully understand how it fits into different marketing strategies. Years during which I mentored and consulted a broad variety of app businesses. Ultimately, the following hypothesis emerged:

Web-to-app is your best vehicle to go from 0-1 as a new subscription app in a post-IDFA environment where mobile attribution creates severe challenges given the lack of device identifiers.

Types of web-to-app flows

On a holistic level, we’re looking at two types of flows: those that try to convert users on the web and those that don’t.

Both of them have a ton of possible sub-categories like:

• Web onboarding/qualification flows
• Product-focused landing pages
• Contextual pages
• Content flows
• Quiz flows
• …

You can really get creative here (compared to what’s possible on the standardized stores).

Let’s dive into a few examples:

Classic product-focused pages

• https://www.reading.com/lp-001-meta-v1/
• A broadly targeted classic landing page similar to a D2C product.

Contextual pages

• https://www.blinkist.com/en/nc/partners/jay-shetty
• Landing pages for specific traffic sources like an influencer collaboration.

Content flows

• https://www.blinkist.com/magazine/posts/app-trending-top-thinkers
• Content marketing pages which present your product with a certain angle to tailor to specific placements/channels.

Web onboarding/quiz flows

• https://www.joinladder.com/quiz
• Engaging format to collect user info, qualify, and nurture traffic for increased likelihood of conversion.

Payment pages

• https://www.paired.com/premium
• Your web paywall restating the most relevant info to make a purchase decision.

All of the above can be used in combination. A popular approach I see is starting on a product-focused page from where users start a quiz. By the end of that page, they’ll be prompted to purchase on the payment page.

The unfair advantage of charging upfront

We’re going to focus on flows that try to convert users on the web. And we want to understand how they could potentially help new apps/advertisers kick off their paid acquisition.

But first, let’s cover some general considerations. Sylvain from Growth Gems put together a wonderful overview of the pros and cons in Growth Gems #96:

Having seen a number of small-to-mid-sized businesses build their paid ads foundation on web-to-app, let’s dig into my observations (and why I think they took the right approach):

1. It separates the purchase decision from your app product.

Converting users becomes a pure marketing task. With conversion rate optimization happening in an isolated space that is independent from the product. You could, so to say, sell a non-existent product on the web.

While this puts a lot of responsibility on the shoulders of marketers, it’s also a fun challenge to work on:

a) Ability to leverage a broad variety of flows fitting the channel.

b) Web pages can be iterated much more quickly than your product.

c) Full autonomy for marketers running experiments using a no-code tool.

2. Marketing can focus on figuring out audience, messaging, and pricing.

Tracking and attribution in this environment is fairly straightforward using pixels and server-to-server tracking. Proven technology.

Sending users to the App Store, on the other hand, means dealing with SKAN, which is a minefield, especially for small and inexperienced developers.

You’ll end up implementing SDKs, setting up a Conversion Schema, and trying to figure out attribution. A backlog of tasks that most product, engineering, and marketing folks aren’t necessarily excited to work on.

Tasks that can quickly eat up resources while you actually have more important stuff to work on. Stuff that differentiates your product and marketing from the tough competition out there.

3. Ad platforms and your team have better signals to learn from.

Mobile attribution is a mess. Aggregated and missing signals from SKAN means less targeted algorithms on your ad platforms of choice.

It also means fewer learnings that you and your team will generate to inform product and marketing strategy. Not so when you’re tracking with web technology.

4. You’re not playing by the App Store rules.

This applies to the UI/UX of your web-to-app flow but more interestingly also to people’s perception of your product.

I’ve seen early-stage apps charge $100+ for a yearly subscription on the web. A price point hard to achieve on the stores.It appears to me that by leading with a web page, you’re not selling an app. You’re selling a service. And if your marketing is good, you’re selling an outcome. A dream. Your app is merely the vehicle of choice to make it happen. Allowing you to challenge the App Store pricing rules.

One could essentially apply the e-commerce playbook: upsells of digital products, money-back guarantee instead of a trial, 10% discount for leaving your email. Endless opportunities.

In the below example, Jumpspeak uses a variety of pricing psychology tactics that are hard or impossible to replicate with in-app subscriptions:

a) Pushing for a $249 lifetime deal (pre-selected)

b) 100-Day Risk-Free Trial (direct purchase with money-back guarantee)

c) $37.00 Masterclass upsell discounted from $179.00

d) Free Gift: Unlimited Text Tutoring value $997

e) Free Gift: 1 Month Free Membership for a friend

f) Users get to keep bonuses when asking for your money back

Downfunnel considerations when going web-to-app

However, charging users on the web has some bigger implications for your downfunnel. And trust me, you want your marketing team to consider these rather sooner than later.

1. Scalability is limited as blended CAC rises quickly.

If all your traffic needs to pass your landing page as well as payment before being sent off to the store… well, then there’s gonna be little traffic on the store.

The only users coming here will be those who started a trial or purchased your product upfront.

You’ll likely see page view to install rates of close to 100% meaning it’s hard to optimize your storefront. And the store algorithm is not gonna pick up on you. Because at low traffic and rating volumes you’re a nobody.

While you’re trying to find PMF, this isn’t a major challenge yet. You most likely will end up with little organic traffic either way. Yet as you scale, you need organic search and browse to scale alongside paid to bring down blended CAC.

2. Upfront payment essentially makes your product a paid product.

If only paying customers make it to the store, only paying customers make it to your app.

This sets a completely different playing field for your product team.Same as on the store you’ll have low traffic volumes to test with. A big challenge if you’re trying to validate your onboarding, UI, and feature set.But even more importantly: you’d only be testing against existing customers meaning you’d purely be focused on retention or winback.

If you’re aiming for a freemium model you need users in the app that haven’t paid. You need to learn how to activate and convert them. Otherwise, this becomes a vicious circle and you’ll never be able to run direct-to-app campaigns.

Let’s sum things up

There’s been a time when going web-to-app has been fancied as the logical and better alternative to dealing with SKAN.

From my point of view, it’s not an either-or decision. Both direct-to-app and web-to-app have their own set of benefits and should be used strategically. It’s about timing, priority, and playing to your strengths.

Ultimately, you need a combined strategy. While charging upfront can generate the cashflow you need to keep the machine running, direct-to-app enables scale.

You’re not moving to the web to save a 30% store fee. You’re moving to the web as it allows you to differentiate yourself, learn fast, and empower marketing no matter what your product roadmap looks like.

It’s one puzzle piece on your way to profitable growth. And for a few apps I’ve seen in recent years, it served as the initial traction they needed.

💡 Find out how RevenueCat Billing makes it easy to offer web subscriptions for your app.