I'm creating an app where most users will only use it temporarily, like guests at an event. For this reason I used Firebase Anonymous Login, to where they just supply a name and they're ready to go with a persistent and usable account. This is good enough for probably 80% of users.

However there's a secondary feature that maybe 20% of users will use where users will need to access the our website, in which case they'll need to upgrade to a full email/password account on the app to access the account on the web.

So I'm faced with a dilemma, on one hand it's much more work for me to integrate an anonymous user login screen as well as a email/pass returning users login, as well as an upgrade account screen, and more difficult to explain to a current user why they need to upgrade their account to an email/pass to use this other feature, but for the 80% of users who never need to upgrade their account just supplying a name and not bothering with email is much simpler.

On the other hand, if I just force everyone to sign in with an email and password I can prevent myself from having to create all the extra screens, as well as prevent any confusion of who has what kind of account and how/when/why to upgrade to a full account. But I unnecessarily burden the 80%.

Which direction is better?


You've already identified the tradeoff — neither approach is categorically better than the other. Let's look at two things: weighing the tradeoff in business terms, and alternative sign-in UX.

Putting the tradeoff in equations

To help you frame the tradeoff, you can model it this way:

  • assign a value V1 to a user who only uses your first feature
  • assign a value V2 to a user who uses your second feature
  • assume that there are two kinds of users in your user base: low-motivation users, who would only ever use your own feature (in proportion a); and high-motivation users, who would use both features (in proportion (1-a))
  • assume that 100% of your low-motivation users would be able to use the first feature if they didn't have to register, but only X% of them bother registering if they had to (you can play with X based on your assumption, but I suppose it would be low based on what you're saying, e.g. 20%).
  • assume that 100% of your high-motivation users would use your product regardless of how hard it is to register
  • assume that Y% of your low-motivation users did not initially want to use your second feature but get "tempted" by it now that they've done the hard work of registering (this really depends on your use-case)

Then if you ask for registration upfront, the value you get is

a * X% * (V1 + Y% * V2) + V2 * (1-a)

and if you defer registration until the last moment, the value you get is

a * V1 + V2 * (1-a)

The value of doing registration upfront compared with deferring registration (difference of these two lines) is:

a * ((X% - 1) * V2 + X% * Y% * V2)

What you can see through this exercise is that the value of doing registration upfront depends a lot on the relationship between:

  • how much value will you lose by causing abandonment for low-motivation users ((1 - X%) - V1)

  • how much value will you gain by tempting low-motivation users to use the second feature after they've done the hard work of registering (X% * Y% * V2)

You can see in particular that if you don't have hope or don't want to tempt users to use the second feature just on the basis of them having the "sunk cost" of having already registered, it's always better to defer registration until the last moment.

Alternative sign-in UX

It's a pet peeve of mine that many apps just have an automatic reflex to ask for "email and password" when thinking about how to register users. For the vast majority of apps and sites, this is a dumb way of doing things — chances are the user is going to be really annoyed to come up with a password, so they're going to give you the same password that they use for a bunch of other accounts they don't care about, or give you a strong password that they'll promptly forget. How good is that? Not at all.

If what you want is to enable users to access their data on the web, then consider

  • Asking for an OAuth account to sign in (Sign in with Google / Facebook / etc.)

  • In the app, show a code with short duration validity, generated by the app, that the user can input on the web when challenged to access their data.

  • Let the user register an email address and verify it, but don't ask them to create a password. Instead, when they sign in to the web with that email address, just send them an email that they can click to sign in, or send a mobile notification to the app to ask the user to confirm and take the user's confirmation from their mobile phone as authorization to sign in.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.