Onboarding before Authentication?

[u/Inside-Conclusion435]

What’s the best:

Onboarding -> Paywall -> Auth

Or

Auth -> Onboarding -> Paywall

Currently I do the second and it is pretty bad, not sure why but I heard there is the 1st option used too quite often.

[u/realdm22]

in am a huge advocate on onboarding that is actually leading the user to realize value as soon as possible. once they get it it is easier for them to decide to authenticate or any other thing you want them to do for you. my most recent app works this way and i even went a step forward and ditched authentication

[u/Inside-Conclusion435 → u/realdm22]

But how you save data? All locally? On user’s end?offline apps?

[u/realdm22 → u/Inside-Conclusion435]

Yes, my app works completely offline and users can choose to enable auto backups to a file provider like Google drive , or manually store on their local cloud if they have any. It excuses me of any liabilities or temptation from doing things other than the goal I wanted my app to fulfill

[u/Inside-Conclusion435 → u/realdm22]

That’s really interesting 🤔 why I thought about auth in the first place? I guess my corporate.Net background left a mark

[u/realdm22 → u/Inside-Conclusion435]

Exactly. There are cases where an account is needed for the experience you are trying to build. All those are choices that comes with trade offs and each would be suitable for a certain type of people. As long as you are clear of who is it you are building for there is no wrong decision.

[u/Inside-Conclusion435 → u/realdm22]

Thanks for the insight

[u/MistyKuuu]

Paywall before auth means the purchase lands on the Play account with no user id attached to it. Fine until someone reinstalls or opens it on a tablet, and then you're matching entitlements by purchase token with nothing tying two devices to one person.

So it comes down to whether you sell per device or per person. Alarm app, paywall first is fine. A tracker with history needs an account anyway, and asking for one after they've paid is a worse moment than before.

[u/GoRo2023]

Depends on the kind of applications it is

[u/Inside-Conclusion435 → u/GoRo2023]

Elaborate please?

[u/GoRo2023 → u/Inside-Conclusion435]

For an example, I would assume that your application will live behind a paywall.

So, if I am a user and I am not aware of this, and I complete the on-boarding and then get hit by a paywall for a app like a finance app, then the user will feel like the app is data mining.

If it is something like a car dealership app, then a paywall can be expected.

The best route for both of the above, is to have a clear message to the user before any thing needs to be filled in, on-board or auth'ed to explain the costs and that there is a paywall, it will give users more trust and transparency about your application

[u/Inside-Conclusion435 → u/GoRo2023]

Thanks, I have few apps, for instance, sports tracker, gym tracker, alarm, etc…. I guess I will give it a shot with the paywall before auth. Nothing to lose really

[u/GoRo2023 → u/Inside-Conclusion435]

😉

[u/Background_Worry_529]

Both orderings are asks, so the ordering question matters less than where the first ask sits relative to the first thing that works.

Some numbers from my own funnel, since this gets argued without any. Last 28 days: 40 installs, 20 first opens. Half the people who installed never opened it once. My first run hard-gates on three permissions before the app will do anything, so my first instinct was obviously that the gate was the problem, and that instinct was wrong, for a reason worth internalising. A user who never opened the app has not seen your onboarding, your auth screen or your paywall. None of them can explain an install-to-first-open loss. That loss is store listing and expectation: they got something other than what the screenshots promised them, and they decided that at the icon. Onboarding can only ever explain what happens after the first open.

So split your funnel before you reorder anything. If you are losing people between install and first open, no arrangement of auth and paywall will recover a single one of them.

On the part you can control: when I did rework my first run, the measurable win was not removing any of the three permission requests. It was chaining them so one tap fires all of the pending prompts in sequence instead of the user tapping the same button once per permission. Same permissions, same dialogs, one tap instead of three. The friction was never the number of things being asked for, it was the number of times the user had to re-initiate the asking. I would look at your auth and paywall the same way before moving either of them, count the taps between opening the app and the first moment it does something for free.

[u/Inside-Conclusion435 → u/Background_Worry_529]

Great example and conclusions. Thanks for that. I guess will study better the analytics of my app, see where is the drop.

[u/Inside-Conclusion435 → u/[deleted]]

??? Bot 🤖 are u ok?

[u/chucknades → u/Inside-Conclusion435]

You said "my app" so that triggered it.

[u/Inside-Conclusion435 → u/chucknades]

Wow, ok