Understanding When to Use Web2App and How to Do It Well — Thomas Petit, Independent App Consultant

David Barnard:

Welcome to the Sub Club Podcast, a show dedicated to the best practices for building and growing app businesses. We sit down with the entrepreneurs, investors, and builders behind the most successful apps in the world to learn from their successes and failures.

Sub Club is brought to you by RevenueCat. Thousands of the world's best apps trust RevenueCat to power in-app purchases, manage customers, and grow revenue across iOS, Android and the web. You can learn more at revenuecat.com. Let's get into the show.

Hello, I'm your host, David Barnard, and my guest today is Thomas Petit, an independent consultant focused on subscription app growth across acquisition, activation, and monetization. Over the past decade, Thomas has worked with hundreds of clients and help manage nine digits in ad spend with a positive return. On the podcast, I talked with Thomas about how to find success with web to app, the value and challenges of owning the transaction, and why avoiding App Store fees isn't a great reason to experiment with web to app, but might work out anyway.

Hey Thomas, thanks so much for coming back on the podcast. This is your third or fourth time. We'll just have to make it an annual tradition.

Thomas Petit:

Yeah, my pleasure. Always happy to be back. You have a great audience and I really enjoy the other guests and the rest of the podcast, so I'm really happy to bring my small contribution here.

David Barnard:

Yeah, well, your episodes are some of the more popular, so it's selfish of me to get you back on. People seem to really enjoy your insights.

For those who haven't heard Thomas before, he's been consulting for what? Almost a decade now and worked on multiple subscription apps and worked with so many different teams. What I love about Thomas and other folks who work across a lot of teams, and I've said this a lot on the podcast, so reiterating for those who've heard this, but you just get so much experience and you see what works in one app and then you try it in another and it doesn't work, it really gives you a deeper understanding of some of these topics to be trying these things across so many different apps versus maybe some bias that comes across when you've only ever worked on a single app. And so it's great to get your insights as you work with so many different apps.

So this year, it's 2024, and one of the topics I'm getting asked about a ton and just to see more and more comfort talks about, see more and more tools popping up is web to app. So first, I find that term-confusing. So let's just define what do we mean with web to app because there even are multiple kind of paths that people use under the umbrella of web to app. What is web to app? What do we mean by that?

Thomas Petit:

It's definitely, definitely a wide umbrella. There's lots of sub topics in there. I think the low down is a lot of developers, most of the marketing is driving straight to the App Store regardless if it's paid marketing or else and different channels. I guess web to app is the way developers would bring this traffic first on some kind of web page that can be more or less sophisticated, can be very simple, just a landing page that then drives to the App Store, or can be very sophisticated, have the whole onboarding and maybe the payment, maybe to sign up, maybe even part of the actual app experience, some features on the web, but in the end they still want to drive to the app at some point.

I guess it's a very good place that we start there, because one of the reason that it's becoming such a hot topic, I mean, it's not new, but it's definitely more in the radar of everybody, is that there is big opportunities in driving traffic on the web rather than on the stores that had a number of limitation if only just the layout. You can't show whatever you want to people who interact with whatever content you put out there, whether it's an app or not. So more flexibility, more channels.

But in the end, most of the time, developers are interested to get user in the app because the native experience might be better in a number of case, but also because it offers retention levers that website just don't, in particular being on the home screen. Even if you could put a shortcut, nobody does. Or having the push notification. Even if they exist on websites, it's just not the same power. It's clear that retention, long-term retention, is higher to handle in an app and the experience is great. It doesn't mean that the experience has to start with the app, and I think that's what the web to app encompass.

David Barnard:

Yeah, I like that you started there because one of the things I have heard from a lot of folks is that they feel like they need to build a full-fledged web app to even experiment with web to app. And right off the bat it's like no, it can be as simple as just a landing page like you said, where you're able to collect attribution more deterministically on the web. So I mean, I think for a lot of apps it would be tough to make that funnel work, dropping people onto a web page and then just immediately sending them to the App Store. But for some, maybe that does work. But it does kind of span the gamut from that kind of landing page where you craft your message more directly and specifically, maybe more interactive, maybe video stuff that you just don't get when you drop somebody onto the App Store, and then it goes all the way to providing a much more sophisticated experience or even a full-fledged web app.

One thing to pause here too is that I think it's so contextual. It just depends so much on the app, the experiences, and even some of what you were saying about retention. It's probably not true of every app. Some apps, depending on exactly... Like Photoroom, I've actually been using Photoroom more on the desktop than I do on my phone because I use it specifically for Sub Club. I'd use it for removing backgrounds of guest photos and things like that. And so everything we talk about, everything is so contextual, but I think that's an important thing to bring up even as we're just starting this conversation, is that everything we talk about in web to app is going to be so contextual. That what's working for one app, things we maybe even suggest, may not work for you.

So I think that's a great place to start, of the breadth of context, the breadth of options for web to app. I think that the next place to go with that is why. Why do web to app? And we hinted a little bit, but why don't you list out some of the reasons and we can kind of dig into some of those?

Thomas Petit:

Yeah, I'll intervene back on the breadth before I go to the why. Sort of the context behind it is exactly where I was going to go in the sense that I've seen different apps succeed or fail with completely different setups on web to app.

I know of a gaming company that has one of these very, very simple landing page. And it enables them to do attribution differently, explain also the game in a way that in the store they couldn't because the graphic is full screen and so on. But then this simple landing page scheme didn't work for a number of my other apps. And then you've got the whole... It's not just a landing page or fully developed onboarding. There's many shades of gray in between.

I can remember one project in particular where we're like, "Okay, what if we put the sign-up or we don't? What if we put the payment or we don't?" And the answer was always, it depends. So there's context depending on what your app is doing. For example, Noom as an onboarding on the web, that is 50 screens, I bet if Photoroom was doing that, it wouldn't work at all. So highly depends on what you're doing.

Sometimes you can just showcase the aha moment very fast, and that's typically the case for Photoroom. Sometimes you really, really want to drive to the payment because that's your main reason to go to the web because you want to charge there. It doesn't need be one way or the other. I think it goes way beyond the app itself and the vertical you are in, but actually the context of how that user have heard about my app. And if I take for example Blinkist, which was one of the pioneers in web to app, I remember copying the tactics back in 2016, so eight years ago they were already doing web to app.

Blinkist does a lot of other things, but they particularly cracked presence on Taboola and Outbrain, what I call paid content marketing with those sites. The context of these ads that is placed typically next to news content or similar, they drive to a page that looks like an article and brings a completely different way of doing web to app because they understood how to adjust to the context of how the ad was placed, what are the user expecting when they're clicking on this and what they want to see. And I bet if they were pulling just the full web onboarding that they do have for this context, it wouldn't work. And then when the traffic is coming from Facebook, the experience that you have in the website of Blinkist is completely different from the one if you click on an Outbrain ad.

So the context goes definitely by vertical. What works for gaming wouldn't work for dating or for fitness, but also you have to adjust. And in a perfect world, you have these different tools and experiences of user journeys available and you find out that for this particular ad placement, this journey just works the best.

I think that's where the pioneers ended up in the sense of, of course it's easier to just have one web flow and drive everything to it, but you're probably stalling compared to the opportunity you could have of. If somebody is searching me on Google or if somebody is clicking from a TikTok or if somebody like you is looking for Photoroom desktop experience because it's from Sub Club, you have to offer them something different.

Actually in the case of Photoroom, I think they put at least 10 free tools on the website that are in the app. And at the beginning I was like, "I don't know why they're doing it." I don't have enough internal information about this, but I was like, "Wow, this looks really cannibalization because I'm doing something on the web without any kind of login, anything, just really one-off and I'm lost."

But in the end, if you look, I do believe it's beneficial because they're playing the long game. And see, you memorize it, you know the app is there if you need it, you know there are other features in there. And I think for them it's like a very long game acquisition channel where actually you have experienced the feature on the web, but one day you might need more and you know the app is there with more. It's just they don't need the conversion instantly. I believe it's a long game in this case that not everybody can do that. And not everybody can offer the feature on the web, which they managed to do very nicely, but I think it does reinforce a lot like, yeah, context, context, context of what you're doing, what's your strategy and why is the user landing there and actually adjust to it. It's just like there's many ways of approaching this.

David Barnard:

So let's talk about why people are doing it, why web to app. I mean again, we've already hinted at it, but what are the kind of primary motivations and then how do we see that play out? And then we can kind of take them one by one.

Thomas Petit:

That's a good one because I mean I've said it before, but I believe people are going web to app for the wrong reason, but then eventually on the way they discover that there is an opportunity that is not necessarily the one that they imagine.

Two of the very clear reason that people are doing, "Oh, we want to do web to app. Oh, we need to do web to app" is one, the store fees, the commission that Apple and Google are taking on subscription or IAPs are 15 or 30%, depending the case. And then when you process this payment on the web, you'd pay something around 3% via Stripe or similar. So 3%, 30%, there's a 10X gap. And you see a lot of posts explaining web to app like, "Oh, you can save all of the fees." It's not technically true because there is a fee and the gap is not as big as people think. I believe this reason is not a good one. There is less fees, but actually the whole funnel looks very different. And you can't fully expect the same conversion rate, the same retention rate. Every metric would move. Typically when you're trying to charge on the web, it's much harder to get people to pay because there's not the trust factor of Apple, because you have to pull your credit card. There are many reasons that makes that people will...

Just [inaudible 00:13:56], in the app is just great, like, "Okay, subscribe for trial. Yes, FaceID, whatever and you are in," which is a huge advantage for... But then even after the transaction, a lot of people are like, "Oh, I have a customer acquisition of 50 on the web and 30 in the app or whatever or vice versa." I'm like, "Yeah, but the customers are not worth the exact same, the renewal rates are going to be different. The refund rate is going to be different." The fact that you own the transaction because you are the one processing it, for me, is a big plus of doing web to app, and people are like, "The fee. The fee. The fee." I mean, there is a value in owning the customer relationship rather than delegating it to Apple. So see-

David Barnard:

But there's also a lot of work in owning the transition. I think a lot of people underestimate the involuntary churn because people are incentivized to keep their credit cards updated with Apple. Whereas each customer that you have that individual transaction with, you need dunning. You need to be able to email them and say, "Update your credit card when it expires."

Yeah, there's also a lot of work in owning that transition, but there's value in it, but it's trade-offs. And I think that's where there maybe has been some naivety in the conversation around web to app of like, "Oh yeah, save on fees, save on fees," but then not talking about the practicalities like, "You are here", of like, "Everything's a trade-off. You probably experience lower conversion, but maybe you'll have higher retention. You may save on fees, but you're going to have to implement a lot of infrastructure around dunning and other things." And so it's like everything's a trade-off and you need to really understand the depths of some of that before you go just jump on the web to app trend or whatever.

Thomas Petit:

Absolutely. A lot of people are calling the fear a tax. It's, "The Apple tax is the 30%." I'm not really known for defending the platforms in general, but I do believe there is real value behind the commission, like the visibility that the App Store is giving you, the fact that they're processing the tax for you, the fact that they're processing refunds and the billing errors and so on. There is real value behind it. So maybe some people can argue that this value is not the gap between 30% and 3%. And I would agree. And I think if Apple had lowered the fee to 10%, many less people would be doing less to app because the value is really big. And many people who move to web to app underestimate the amount of work that it is going to represent to maintain this... I mean there is a value in owning this relationship, but it translates into work definitely.

David Barnard:

Yeah. One of the more subtle things too is that both Apple and Google, I think, accept over 200 forms of payment across... So even Stripe or Paddle or a lot of these alternatives that people are using on the web, you don't have 200 different payment options. Somebody in Africa wants to pay with the carrier billing and Apple supports that, and it's like Apple and Google have gone... They understand billing in all these countries both from the retail presence and how big the App Store is at volume, and they, year in, year out, are adding more and more options in those different countries to allow the payment processors and how people like to pay in those countries.

And so even subtle things like that that you think, "Oh, I'll just again save the fee," but it's like, "They do a lot to earn the fee," maybe not 30% like you said. And then if you're a Netflix, it's like you have a big enough team where you can start expanding into all these payment options in those countries and you do it in the order of what the highest value countries are. The US is obviously the easiest. It's just credit card and Stripe and Apple Pay even. But as you get bigger, and the opportunities are bigger in these smaller countries, then 200 different payment options, it's actually really important and very valuable.

Thomas Petit:

Yeah. I think that's the reason Google has put, in particular... I mean, Apple too, but Google has made an incredible effort to expand payments. It's extremely relevant given the penetration of Android in markets where alternative payment system are pretty much the norm rather than an exception.

It's true that from a US perspective or even in some of the Western Europe countries, like, "Yeah, everybody have his credit card, why would I want to support anything? Maybe PayPal, and that's it." But there are many countries where it's not like this at all. Even culturally it's not like this. It's not only banking access but really like, "Oh, I'm used to pay with this system and that's it."

And then every country has their own... I moved to Portugal last year. I was very surprised at the amount of transaction that people are doing through a system that's called MB WAY that I've never heard before or elsewhere. And for them it's just normal, it's just easier. You increase the potential that if you support this, that people are going to pay. But then maybe Netflix can, but which developer can go and say, "Okay, Portugal has MB WAY, and then India has this, and then Spain has Bizum, and then in Argentina they want card billing, and then they have this prepaid card that are very big. It's very hard to get there and it will affect your conversion.

So I do think there is also value. And it's where, again, contextual comes back in terms of the vertical, in terms of the user journey, but also in understanding, "Actually that user, I'm maybe better off converting them in the app because of where they're located because I'm not offering this." You have this situation where you have to decide almost in real time based on tests usually, but like, "Oh, I've identified that this segment of user, I'm actually better off moving them to IAP even if the fee's there. But this particular group of user, probably not, because they can pay with Apple Pay on the website and the friction to the conversion is going to be minimal."

And so for me it's never been too much about should I charge in the app or on the web. The answer is necessarily both, is in which case you're doing it and through his journey, which makes it a lot more complicated obviously to figure out, but that's how you also discover new maximums for different segments.

David Barnard:

Yeah, I think the best advice I've heard on this too is that the absolute highest level way to sort those two is if you have any understanding of the level of intent. And to your point earlier, if somebody is searching your brand on Google, then they probably have pretty high intent and you can funnel that to the web and not expect as high of a dip in conversion.

Promotions. If you're offering 50% off, send those people to the web. They have very high intent, you're offering a huge discount. I think those kind of things at a very high level make a lot of sense. But then like you said, once you then start testing, there's a lot more nuance of who to send where. And then it's contextual. We can give advice, but every app needs to try and see what works in their particular context and for different personas.

So the fact that every app needs to test this on their own actually leads to maybe the next biggest and maybe the most important reason to consider web to app is attribution. It's like, in order to do these tests, you need to be able to understand the users better and you definitely have an advantage on the web for that. Tell me about attribution in web to app.

Thomas Petit:

Yeah, so we started saying the first one is avoid the fee, and I did develop that I don't think it's a good reason, but you still should go on the web. The attribution is definitely the other reason, like people being frustrated by Scale Network or limitation on what I call measurement, I never said tracking, but of tracking. "Yeah, Oh, on the web, we don't have this restriction, let's go on the web." I think this is not entirely true in the sense that it's not as simple as on the web you can do whatever for attribution. And especially the transition from being on a browser on the web and then people would get to the app and you have to reconcile this is not as straightforward as it seems. There are also restrictions that do apply on the web that Safari's blocking third party cookies and that I mean a lot of new restrictions. It's not as straightforward as people think and they often discover like, "Oh, attribution is actually not perfect there either."

Here's the news, attribution is never perfect. So yes, there are things that you can do on the web that have limitations in the app and especially on the Apple side, but it's not as simple and as straightforward as people think. Even though over time things got better, I think the pioneers here had a lot of surprise on the way when they moved to attribution. And even I, sometimes you discover specific setups from people, I'm like, "Oh, wait a second, what do we do in this case?" It's not like it's the easy way of, "Okay, I moved to the web, I have attribution back and we roll." It's kind of a quite complex topic where attribution also becomes not fully comparable, which is a tricky one because then you want to compare your different journeys together. And then attribution is not... There's a lot of progress that has been made, and in particular, ad networks implementing conversion APIs that do cross the barrier between browsers and app a lot better than it used to, but it's not as straightforward as that.

There's always work around. There always have been, but they're not as simple as people think. So for me, going because you're frustrated of Scale Network is not a great reason because you're also going to face restriction. And eventually, it leads people to experiment with web to app. They discover that there are opportunities, that there are obstacles with attribution, but there are opportunities. So it doesn't really matter why people go that route, but for me it's never going to be about the fear or about attribution.

A lot of the reason is exactly what you explained before about contextualities, that that kind of user can be converted on the web at a very high rate because they're coming from brand search or maybe virality or a particular coupon or whatever. But there are also reason that people never go to web to app for initially and that actually have massive benefit. One that I quote quite regularly is audience expansion.

Even on Facebook, Facebook doesn't show to the same people your ads if they're directed to the store or to the web based on how people interacted with the different kind of ads before, based on propensity that the judge, "That at this point of time, that user may convert better here and there. And in the end of the day, I want both. So I'm better off running..." And I know those running web to app at scale, it's never like they're spending 100% on web acquisition or 100% on the app. It's always an and, never an or, because of this kind of mechanics for agents expansion, but also sometimes a specific channel. Like for example, on Google Search, you have to buy it together if you're direct into the store together with some YouTube and display inventory. But maybe you want to manage your own keywords on the web, but then when you buy search-only traffic, you can't be buying it for only iOS, you have to buy the two OS. So you can do that on YouTube specifically for example.

YouTube is a very interesting case, where you have to buy it bundled in the case of the stores, but then you have a lot more granularity if you're buying web inventory from YouTube directly because then you can specify the device, you can block channels, you can say, "Okay, I don't want to be shown on these channels." You can select some audiences that you wouldn't be able to do on Google App ads.

But then Google app ads also work. I have one particular case on YouTube where we're running YouTube ads that go to a web flow and we're running Google app ads, UAC ads. They tend to attract a slightly different audience but also not necessarily be shown the same channel or not be shown at the same time. So here for me is definitely audience expansion.

I had another case that for a while when ATT come up, Pinterest went out completely of the store acquisition. They removed their ad product that was directing to the store because they didn't want to adjust to Apple new systems. So you could only direct to web pages. Eventually, Pinterest has bring back the app product. But for a while, if you wanted to advertise on Pinterest, you had to do it on the web.

Maybe for some people, Pinterest is a bit of a secondary thought and not really big, but actually the audience on Pinterest is very big and extremely valuable. Like majority iOS, very big penetration in the US especially among let's say 30 to 50 years old women, which is a highly sought-after audience for many subscription apps. And so now Pinterest has bring it back. So my case is maybe less convincing than before, but it does talk to audience expansion, whether the network has the two option or not. For me, this is the two reason, the audience expansion but also offering the best journey at the right time to every users, and that can only be done by having different ones. So yeah, it's never going to be zero or 100, but rather a mix of both worlds.

David Barnard:

So before we move on from attribution, I would like to actually talk through some specific examples of how it works and why it works. And I'll go first.

So the example I'd love to give is Greg Stewart was on the podcast, he runs an app called Ladder. Actually, one of our more popular episodes, if you haven't heard that, go back and search for Greg Stewart: Ladder on the podcast. In the way they're using web to app, I think it's one of the great examples of how and why attribution can be improved through web to app.

So what they're doing is they're sending a lot of their traffic, but to your point, not all their traffic, to the web from ads on Instagram and TikTok. What they do is that they do a survey. I think he told me on the podcast that by question 6 of the survey, they have a really good understanding of what persona that is and how likely that persona is to pay. And so by question 6, they're able to send feedback back to the TikTok algorithm, back to the Instagram algorithm to say, "Hey, this is a really high value user, send me more like this." And that quick feedback from the ad being shown to, "Hey, this is a high value user," is really strong in optimizing those algorithms to find more people like that.

But interestingly, and Greg and I were just having drinks a few weeks ago, he lives here in my area, and we're talking about doing a follow-up podcast because they've learned a whole lot more in the year since we did that episode, one of the things he was telling me is most of their revenue is still iOS. So they're not actually charging on the web, but they're doing the survey on the web. And then their attribution is super fuzzy in that they don't have perfect tracking, to your point earlier. They don't have perfect tracking from the web to the actual app installed to the payment. But because that survey is so dialed in and getting that feedback so quickly, that's the leverage for them in web to app. It's not reducing the fees, it's not perfect attribution through the whole funnel. It's not payment on the web. It's just being able to get the feedback to the algorithms more directly and more deterministically in that short window to optimize the algorithm. So.

That's an example of a web to app flow that has a very specific reason and a very specific leverage point that's working really well for them in their context of a fitness app where you can ask a bunch of questions where user intent is high and the ducks are in a row for it to work, but that's why it works.

Do you have any other examples like that of very specific web to app flows and "Here's how they do it. Here's why they do it. Here's why it works"? We've kind of hinted at some of them, but I'd love to get some more concrete, tactical, like, "Here's how it actually works."

Thomas Petit:

Yeah, sure. The example you are giving is very good, because at the end of the day, a lot of acquisition is driven by paid, and a lot of paid is driven by Instagram and TikTok. They have basically only two levers to make acquisition work. One is, get better creative that catch the attention of people and stop them on the feed and make them want to experience whatever you have to for them. And the other one is the quality of the signals that you're sending back. It's not about, "My campaign structure is better and I've got a hack and I've got the..." There's no hack. The hack is sending better signals early, of differentiating quality. Early is really important. That makes me go towards the end of what I had in mind is, when Scale Network came in, a lot of gaming folks in subscription were sort of gifted because a lot of... At least the free trials, but a lot of the subscriptions start on the first day of experience.

So when Scale Network came in, we had this restriction that the signal had to be sent within 24 hours. And for subscription app it was like, "Okay, I've got 70% of my subscription starting on day zero. So actually, it's not a major blocker even though I'm blind on the trial conversion and I'm blind on what I call the late conversion, the ones that don't happen on day zero."

But in the gaming space, it's very rare that the transaction happen on day zero. And you need this day seven or day 30 cohort development to understand the quality. And with this restriction of ATT and a Scale Network, a lot of gaming folks actually redesigned their day zero experience so that they have the signals that they can send back early enough to Facebook. This is a really good case where marketing actually had to tweak, forced tweak the product into, "I need to get a hint." And it's not about making people pay on the first day, it's about qualifying different segments of propensity to pay in the future. So they tweaked a little bit. So I think this was a great example.

But you asked for something very specific, so I'll move there. The fitness space is one of the typical that move to web to app because you have the level of intent where you can ask this very long flow of questions and you can qualify people very well. That's why Noom must like 50 screens and it still work. And in other contexts it doesn't work.

It's a funny case because I work with two apps in the same space. There's sort of a couple therapy app but rather on the premium side of it. So it's pricey but it's very high quality. It's not like gimmicky or anything. And it's the kind of things we're actually moving directly to the store, there is a bit of friction in the sense of< "Do I really need that?" Not only it looks expensive, but also it looks the very serious answers straight on.

What we noticed early on is that in acquisition, that was going to be a major blocker because what they show in the ad is not necessarily super catchy. And then the problem is hard, it's not necessarily something you want to do at any point. So it was a major obstacle. But then they realized they can drive a flow where we can start in a much softer way, more like a mini-game and something that is not so let's say stressful than thinking that your relationship is failing but rather technique on the fun side.

And actually, we brainstorm about, "Oh, let's do another app that would be very simple and much more gamey and we can make fun ads and then it's going to be cheap because everybody's going to click to play." Our monetization scheme is actually that this is a lead provider for the main app where we're going to have a minority of users that were already qualified that we can lead there.

They eventually decided not to build a second app but to do this flow on the web, and it makes a lot of sense because those sort of mini-games, it's very flexible to build them on the way. So some people do quiz, can be a mini-game, it can be sort of a playable game, but it can very often lead us into quiz where instead of the questions of a fitness app, it's sort of a funny quiz and you want to complete it.

So those can be a lot more catchy to put in the ad, but then people complete it at a high rate because it's very easy. And slowly, slowly you move it to where you actually going, that if you had put it in the first place, straight up might not have worked.

I have one success case with this, which was in the brain training space, which eventually become very normal to do this. So the extreme version of it would be sort of this very aggressive ads of, "What's your IQ? Or do you have a higher IQ than your neighbor?' And then they start making very easy question quiz. There is a sort of a mini-game that you start, "Oh, you actually look like you're 5% over everybody, but let's figure it out, or let's train yourself to get to the 20%."and then they lead you to the app where they have all these kind of mini-games and eventually the monetization was there.

In their case, the web to app flow not only doesn't need the payment to be there, but certainly would be counterproductive because the whole thing is about really engagement and about sort of warming up the audience. Like many ads that are directing to the store, they're made for very straightforward funnels where you see the ad, you want it, you get into it, you go to the onboarding and you're going to subscribe straight up after 10 minutes.

But a lot of use case do not fit this journey. And this is where the web offer a much more flexible experience of having a warm-up before you even send to the store where there is a big drop-off in conversion because people are looking at your screenshot and making a decision and they need to confirm and so on. Or maybe in the kids app space for example, you'd have this parental gate to install an app, but maybe you can show the kids the content that you have whether it's videos or games without having this. Once this sort of first touch point has been made and sort of, "Oh yeah, this is really interesting," then bring sort of the friction step. That can be a sign-up. A download is a friction step and obviously a payment is a friction step.

So it can be web to app is a very good way when you have a product that is hard to sell in an instant. "Obviously, I don't know. I see Photoroom, I want to remove my background. I don't know the app, I start the free trial because I want to remove the logo." Perfect case to have direct to store journeys. But some of the harder cases were typically in finance also. There's a lot of friction at many steps or making the decision but also plugging my cards, a lot of things. Some of it just need to be warmed up before they go to these high friction points, and I think those are very good use case to go web to app.

David Barnard:

Yeah, that's really great. One thing you dropped in there, which I hadn't thought about until you mentioned it, is that there's maybe even... And I think it's improved over the last decade, but there's still kind of a perception that apps should be cheap. And so, maybe that's another place where when you do have a very expensive product, you're able to position it better in some ways on the web where people just don't expect an app to be hundreds of dollars or $50 a month or things like that. That may be another great place to experiment with web to app, is being able to better position and better filter for purchase intent of something that is much more expensive.

Thomas Petit:

I have something very specific here, is that not all of them. My couple therapy app actually is not this kind because it is very much something that is personal and B2C, but I have different apps that have somewhere in between B2C and B2B use case, like small teams, SMBs. There is one thing that is very limiting when you're paying in the App Store, is the billing when you're a professional. Even as an employee, like, "Oh yeah, I need this for work, but then it's my account on my phone, how do I build a company?" or, "We're small team."

I'm thinking about one in particular, but I'm sorry I don't want to quote it, where they actually had this restriction because they had lots of small teams that were like, "We want to use your product together and we want to pay for it and we don't care about the price and it can be 10, 50 or a hundred that we still want it, but we need to go through the billing of whatever HR wants, and there is a process and whatever that can be handled on the web but cannot be handled when you use IAPs." This is a very good case to go web to app, not because the fee is lower. Just because, this is what the customer needs. They need to have an invoice that is not in the name and then in the name of the company and so on.

So yes, maybe for pricier product, but I can't see how many pricier product can have this component of, "It's not only for me, but it's in the context of a professional use or semi-professional use because sometimes the lines are very blurred this day of prosumers and so on where billing becomes important and yeah, I don't want it on my App Store account because then I can't deduce the tax or I can't charge it to my client or whatever the situation is.

David Barnard:

Yeah. I mean, I've been bugging Apple for years about this. Apple specifically. I don't think Google handles it any better either. And I run into this all the time. I have a RevenueCat, Apple account specifically because there were two pieces of software that I needed from the Mac App Store and I had to go set up a whole account, put my RevenueCat credit card in. Now it's like orphaned in there. I guess if I ever leave RevenueCat, they'll cancel the card and it'll just stop billing or whatever. But it's so confusing and such a pain in the butt to do that.

And then even on my personal App Store account, there's apps that I buy for work. And for the last 16 years that I've been building apps, it's like this is my profession and I specifically buy apps and subscribe to apps to learn from them. And so man, it's so tricky. I mean, I end up charging a lot of my App Store stuff to my business card because most of what I do on the App Store, but then sometimes the kids purchase a game and then it ends up on that card. It's a freaking disaster trying to manage all that. So yes, exactly right. I wish the App Stores handled this sort of thing better offering, multiple credit cards on a single account and the option to switch between them when you're billing and so many things that they could make better on the B2B use case specifically. So yeah, another really good concrete example of a reason to use web to app.

Thomas Petit:

Yeah. I have one that is not B2B, but maybe it's a good time to also mention it. I started before, like when we mentioned the fee, owning the transaction is important sometimes for the investors or whatever, but sometimes just for optimization purpose.

I remember one case in particular where we were charging a number of subscriptions through the web. We had a mix, some subscription came from IAP and some came on the web. So at some point, people churn. No matter how good your app is, you are going to have a payment churn. Sometimes it's voluntary payment churn, people want to unsubscribe.

So when it was in the App Store, when people want to subscribe, they go to the settings, they are subscribed, which is, there are more problems than that. But with this flow, when people are at pay on the web, that whenever they were going to unsubscribe, we're making it very easy to them, but then there was one screen before they confirm, which was like, "Okay, so you can confirm. It's this button. But here's a counter offer. We refund you half of what you already paid and you keep the subscription live, but we keep the other half."

There was a massive amount of people who were about to churn, they were like, "Oh yeah, that's a great deal. I'll take it." And this is something that I can't do on the App Store because I don't have the flexibility of owning the transaction and doing whatever I want. So I'm not forcing people to own the transaction so that they can do very tricky unsubscribe flows, which I think is terrible. But in this case-

David Barnard:

Well, it's going to be illegal in most countries pretty soon.

Thomas Petit:

Absolutely.

David Barnard:

I mean, the US has even working on laws around that.

Thomas Petit:

But in this case, I think it was a win-win. The users who decided to get half in refund and half as a discount, they were super happy to continue. And us, it was revenue that materialized that would've vanished. So I think everybody was happy in this case.

David Barnard:

Yeah, no, that's a really fantastic example. I'd never heard of anybody actually offering to refund. The whole next year 50% off can be a huge incentive. But then actually refunding, that's bold. But yeah, I can see how that worked.

Thomas Petit:

I haven't seen much, but I remember when we made the math, for us it was beneficial. And also we had really good feedback about it. Not only it was financially interesting, but those people who churned, they kept a very good image of us because we told them, "You want to stop? No problem. Click that button, that's it." But they were surprised positively by it, and eventually we had a quite decent retention on this segment.

David Barnard:

Yeah, that's so cool. So you hinted at it, but one of the other reasons we were going to talk about for trying web to app was channel expansion. So you've hinted at that a little bit, but I wanted to go a little more in depth about why web to app is important when you are expanding channels.

Thomas Petit:

Yeah, I think I mentioned it briefly, but as you scale up advertising, sometimes you just hit plateau. There is a certain volume that depends on every app because of the audience obviously, where it's just a diminishing return on every additional dollar that you're putting in there. I mean, if you're starting and you haven't hit limits like this, I would question if you should put so much effort into expanding towards web to app as you haven't, let's say, exploited all you can in the easier route. But there is a moment where having, even on the same network, campaigns that run on both is beneficial because maybe the user can go to the store, but maybe they need this sort of warm up that we talked before.

For me, it's mainly because it's different users that are going to click on one and the other, but it can perfectly be one user in a different moment of their time. Facebook is actually really good at noticing or predicting like, "Oh, that user at that time is going to convert better on that flow." And this is why when you look at, in Facebook in particular, you look at your potential audience reach, so maybe you've selected, I don't know, "I want to advertise in half the states, only to women. Everybody over 21 years old." Not interest targeting, but simple targeting like this, and it's iOS only. And then you've got like, "Okay, there's 50 million people or there's 20 million people fitting your targeting description." And then you run that campaign for a while, even at very big scale, people are spending five digits a day and you're like, "Oh, over six months, my total reach is 2 million people out of an audience of 20 million."

Just because Facebook doesn't want to show the ad those ads to the rest because they think they're not suitable, they're not going to convert or because of whatever reason, maybe they're preserving the inventory for others, having web ads, even when you run it on similar creative, just the fact that the signal that you're sending back is different is going to trigger Facebook to show it to different people.

Typically, a lot of the apps I work with, we're not using the same creative on the web flow as we're using on the app. The call to action is different. The wording is different, the experience welfare is different. So we also adjust the creative a little bit and we end up having a total reach that is significantly higher than if we're running only the web campaign or only the app campaign. And this is where, for me, it's really a case of I want to do both because the audience expansion is not, "Oh, there's more audience that is going to click on the web than on the app." No, it's just there's more audience when you run the two in parallel.

There are people that never click on app install ads on Meta, and Meta sees it so they stop showing ads to them for installs because after they've seen 50 ads towards this store and they haven't clicked on one, Facebook preserves this inventory for something that is more likely to generate value elsewhere. For me, this is one of the core reason going to web to app, because I'm going to reach more people and because I'm going to have the opportunity to convert users that would never have even seen my ads if I were doing it only on the direct route, or if I was doing it only on the web for that purpose. The exact same logic works on the other side as well.

David Barnard:

Yeah. And then it opens up new channels too, right? Like Blinkist, who talked about Taboola, sending people from Taboola into the App Store probably is... I don't know if it's even possible. Or you were talking about Pinterest for a long time, didn't even have app-install ads. So channel expansion is important too, not just audit expansion on the existing channels, which that's really interesting, I never heard anybody talk about that. But yeah, tell me more about some channels that you're able to experiment with, and even maybe some specific channels you've seen be successful that just wouldn't even work sending them to the App Store.

Thomas Petit:

Yep. So for me, the three very big ones here, they're Google Search, YouTube and Taboola and Outbrain that I grouped together. Actually the merger was canceled. I think they should have merged and they didn't, but doesn't matter. I merged them because let's say the logic is very similar and so on.

So Google Search and YouTube, you just can't buy it the same way on the app side. Those are very good. If you want to separate brand search from competitor search and generic search and actually show them something different, a different USP, you just can't do that on Google app ads. So there is a very good reason also to control your budget a little bit more and so on.

In the case of Outbrain and Taboola, at some point they did add an app product where whenever you were clicking there, it was actually going to the store. To my knowledge, that product didn't work very well at all. I don't know if it even still exists or not, I'm not sure. But I remember perfectly that during a long time, it was just there but nobody was using it. I mean we tried back then. We were a group of three Berlin startups that were very big clients of both Outbrain and Taboola. So that was Blinkist, 8Fit where I was, and Babel, which also has a very significant budget on the web. I'm not sure I should be saying it, but then another client is, Babel is spending the vast majority of their ad spend on web acquisition, even though-

David Barnard:

Actually, I interviewed the senior VP of marketing and he talked very specifically about how much they're doing-

Thomas Petit:

Perfect.

David Barnard:

... not app specific. So that'll be the podcast that precedes this one actually.

Thomas Petit:

Okay, so I'm not revealing anything confidential. Let's go check that podcast. This is perfect.

But yeah, and I remember we were chatting the three of us about, "Oh, have you tried the new product?" And for all of us three, it was like this product just didn't work. Maybe it was the early days. What I strongly believe is that sending to the store just doesn't work in the context of Outbrain and Taboola ads because of the nature of the ads. People are not expecting to land on the store. We're trying to get more and more obvious, like putting screenshot in the creative and saying it's an app and download the app in to text because our conversion rate in the store to install was really low on this. There was no amount of forcing the creative to prepare the user that was going to the store that was going to work. And in this case, it's clear that a web funnel is a lot more suitable than going to straight to the store. It is just the nature of the placement makes it.

There are other smaller cases, but I think there are less relevant one because they're smaller, and two, because over time they did add the app products. So that was the case for Pinterest that bring it back. That's the case for Reddit as well.

I do believe that Reddit is a little bit more like Outbrain and Taboola in the sense of sending the users straight from Reddit to the store, you're going to have to be very creative about what you're putting in the ad for it to work. The context of Reddit is so particular that the ads that work typically don't look like an ad that is going to convert immediately. There, I'm pretty convinced that the flexibility of showing different steps to the user and having sort of a transition between the ad and what you're actually selling is of extreme importance. It's not like I'm on the Instagram feed and seeing something and I'm used to clicking and I know I'm going to go there.

You can see how Facebook grew their ad product really nicely because they managed to have this sort of habit of user of they know... And especially for gaming. Gaming ads were particularly efficient on Facebook and Instagram for a very long time because the context was there. But try putting a gaming ad on Reddit or Pinterest, that's not going to work for sure.

So I think in this case, it's really the context of the ad itself no matter what you do. What you do also matters, but it's really the context of the ad that matters. So yeah, this audience expansion and channel expansion for me is three-fold. Audience reach, that is better doing both. Some channels just don't offer the same product, or the channel doesn't work because of the ad context. Those are three very good reason that I never hear people say they're going web to app for that. It's just they go for the fee, they go for the attribution, and once they have it, they discover that, "Oh, there's also gold over there, let's go grab it."

David Barnard:

So the last topic on web to app I wanted to bring up is cross-platform. A lot of platforms, you can specify that if they're on an Android device, they go to the App Store, I mean to Play Store. If they're on iOS, they go to the App Store, but that's not always the case. And then there's also a lot of cases where maybe the best experience of your product is on a Kindle Fire or a set top box of Roku or Apple TV or whatever. And so I think the cross-platform angle of web to app is another kind of under mentioned reason to build these web to app flows.

Thomas Petit:

Yeah, I guess it's not the biggest one because that's not for everybody. A lot of smaller developers are very focus on the App Store only or App Store and Play Store, and for good reason also, for focus. So maybe a bit more sophisticated. Or edge cases.

I have one app in particular were for us, the Amazon App Store is actually a very important platform. So it's not as big as the App Store for us in terms of running it, but it's not small at all. I was actually very surprised because I never worked with the Amazon App Store before and I was like, "Okay, there's 50 million active users with an Amazon tablet," not even with the phone, just the tablets in the US alone. There are countries where it's actually not very big. In Europe, we're not seeing a lot of those Amazon tablets, but there are countries where it's very big. In Latin America, for example, it's quite significant.

Because it's a bit of an edge case for many like... Many platforms just don't offer this possibility at all of sending to the Amazon App Store. Some, and we discovered that, have the option and it doesn't work because nobody's maintaining it. So it's infuriating.

So obviously in this case, having sort of a browser is interesting. Sometimes a little bit. So it could be specific platforms like this, I mentioned the Amazon store. It could be also with Huawei that has a very big reach. I personally, struggle to monetize anything there, but the reach is so big that for some apps with network effects, it might be of very high importance to be present on the Huawei Store and not sent to the Play Store because some device just cannot have the Play Store at all. And then there are other platforms as well. You mentioned Roku.

But there are also cases where just you can't... So typically for example, on Google App ads, you cannot select the version that you're after. Maybe your app is just not compatible with some device and it's not obvious in the Play Store. And you're going to have traffic that is going to churn at the install stage and it is frustrating. Google says they control device, [inaudible 00:57:30].

But mostly in the subscription space, we do see that older version in Android tend to correlate with lower subscription rate and like, "Oh, if only I could run my campaign only for Android 10 Plus," which you can do on Facebook, but you can't do on Google Ads. And then on the web you have this option. If you advertise on YouTube, you can say, "Okay, I want Android 10 Plus or whatever." Sometimes it's even more than that.

I mean we often say, "Oh yeah, those Android device, they don't convert." But actually if you zoom in, there's big fragmentation. But if you look at the latest Google Pixel phones or the expensive Samsung phones or expensive Xiaomi phones that are now worth 800, 1,000 and more that are really good phones that are competing with the iPhone in terms of quality, if you zoom in on that segment, the conversion rate, they're actually not very different from iPhones, and you're like, "Okay, I want this inventory, but I don't want the rest of the inventory because I don't manage to monetize anything on it." Or, "Just because I want to be differently on it, I can perfectly have a campaign that is bidding."

"Okay, here only for the Google Pixel and, whatever, Samsung that has been published in the last two years, I'm going to be X. And for the rest of the device, I still want that, but I'm going to bid Y." And this is something that a lot of networks don't enable us to do because it doesn't go that granular. I mentioned Google, but they're not the other one.

Facebook does enable pretty good targeting there, but there are many platforms that don't necessarily enable you to do this. So I think it's a bit more of an edge case compared to what we mentioned before. But then sometimes the edge case becomes critical case for a given app because they have a very specific audience or because, I don't know, because your game is so demanding in terms of performance that you know the experience is going to be terrible below a certain level of device.

So we talk about cross-platform, but even within a platform, and I think the topic are a bit related, it can make a lot of sense to go web to app because you have a bit more control on this.

David Barnard:

Yeah. My ignorance, but in the Google, I guess, Google Chrome or whatever browser they would have installed, that the web app or the web experience would be on, are you able to end the browser actually see what version of Android they have, or at least infer it to where then you split that traffic where you send some to... Like in the example of a game, maybe your primary game does have high requirements and you send all the people with a newer device to the Play Store, to that game, and maybe you send the others to a more casual game that doesn't have the requirements. Are you able to get that granularity in the web [inaudible 01:00:14]?

Thomas Petit:

So yes, you are. It's actually a very interesting use case that you are showing there. It's going to make me think about it when you have different product. I think it is a very good tactic rather than... Because you have it twofold. You have it targeting on the network side where you say, "Oh, I only want this device" or, "Oh, those device, I'm going to send them there. And those device, I'm going to send them there." So you would usually have to have two different campaigns. It's not like you can do that within a campaign and tell Facebook, "Send those here and send those there." But you can do it on various levels.

One, you can do it through URL parameters and actually sending this traffic to... So that would be transparent for the user, but you can send the traffic towards the server. The networks they don't like when you do redirect because a lot of scammers are exploiting this, but actually you could do it straight of sending all the device towards a URL that detects the device and actually split the traffic.

What is a lot more common is that once people have landed on your landing page, you have access to the device details. It's not considered as personal information because there's an aggregated... So on Android, the fragmentation is so big that you arrive, there's a longer list of device with one or two people having this device. But yes, absolutely you have this information, it's not a hidden information.

There might be times where in the future where this information gets withheld because it can be, and it is being used, to help the accuracy of fingerprinting. At the moment, this information is still available and you could devise a strategy like you said. Typically, the developers that I work with, what we're doing it is using it on the targeting side of the network, which typically when you're using Instagram, they know which device you have. But there is nothing that prevents you from sending everything and using this information on your webpage because you have access to this information.

David Barnard:

A good place for people to experiment with.

Thomas Petit:

Yeah, sure.

David Barnard:

Well, we had six topics to discuss today. We only got through web to app, but I think this has been one of the more insightful conversations I've had on web to app. You certainly connected a lot of dots that were lingering in the back of my mind and understanding the reasoning, the tactics, what's working, what's not. So I think this has been super helpful, and I guess we'll have to have you back on next year to cover the other five topics we're supposed to cover today.

Thomas Petit:

Yeah, I mean we had lots of topic. I'm usually happier when we take one topic and we dig deeper because we don't stay on the surface. So I think that was very good. And I hope that the listeners will have enjoyed it. And if they're there listening to this, is that they listen to the end. So I guess the vision is done. But the topic is so broad as well. Even here within an hour, or I didn't put the timer, but it's so broad and so deep that it's also a very good one to open the conversation. I hope that this recording is just going to be an entry point that we can discuss more on the Sub Club forum and elsewhere.

None in my LinkedIn request please, but absolutely openly on Slack and forums. I'm always interested to chat about this. And it's also lots of people are experimenting with different things. I mean, I started doing this web two up journey in 2016 and I'm still learning. So yeah, let's hope this was an open door for more conversation about it.

David Barnard:

Yeah, that's great. Anything else you wanted to share as we're wrapping up? I know you're pretty much always booked, so I won't say contact Thomas if you need help with this, but anything else you wanted to share as we wrap up?

Thomas Petit:

No, I'm available on the forum. I prefer to answer a question publicly because then it's one to end. And what I have to say, I mean, I'm not hiding anything. I'm happy to help.

I dedicate part of my time helping openly for free just because I like it and I learn a lot from it. So yeah, if you want to reach out, maybe reach out in a public place where I'm even more happy to do the effort so others can benefit from the answer and I don't have to repeat the same thing 20 times as well. So yeah, join us on Sub Club or you can reach me out. I'm on many open Slacks for app developers, like Mobile Dev Memo, ISO stacks and a bunch of them like this. So yeah, let's get the conversation there.

I'm also hopeful that it's not going to be one-to-end, but end-to-end because there's lots of talent that has grown into this topic that can intervene and lot more experts, the ones that are building tools, the one that have done it for three apps. So I guess we can all learn from having an open conversation about it.

David Barnard:

Yeah, that's great. And yeah, Thomas is really active on the Sub Club community. And we actually post every episode of the podcast to the community. So if you have specific questions on the episode, feel free to just reply to that post and tag Thomas and we can keep the conversation going, or start a whole new topic on this up club community and we'll keep the conversation going.

I mean, there's probably a lot of input from those of you listening that you were shouting into the ether while you were listening in your car or whatever, saying, "No, no, no, no, they should mention this," or like, "I experimented with that and it actually worked really amazing and they were saying it's no good or whatever." So yeah, pop into the Sub Club community and tell us your experiences. He and I both have a ton more to learn, so we'd love to hear from y'all as well.

Awesome. Thomas, this has been so fun, and we'll definitely be doing it again soon.

Thomas Petit:

Yeah, thank you very much. That was great.

David Barnard:

Thanks so much for listening. If you have a minute, please leave a review in your favorite podcast player. You can also stop by chat.subclub.com to join our private community.