How to prevent from creating an obsolete account for a returning user

Question

There is an application that for many users is a daily driver but just for a short period of time. Then they would probably uninstall it or change their phone before they need to use it again, and return to using it extensively after some period of time. Within the app, they have created some content that they would want to come back to. Let's say it is a vacation planning app.

Or: there is an app people log into and then never need to log in again unless they change their phone.

The following scenario is like this: when using the app for the very first time, they create an account using one of the available options: connect with FB & Google or using their email address.

Regardless the way they logged in previously, the next time they need to sign in once again they again can see the same list of options: FB, Google or email. Let's assume they don't remember the method they logged in previously (but they know they used it before so they do have an account). They could choose to restore access to their email based account but they hit one of the social logins instead. As a result, they end up with another account created.

What would be some nice and efficient way to avoid it?

Answer 1

I think the primary questions are:

1. is there any possibility to use the app without login?
2. does the user remember that he has used the app before?

Assuming the answers are 1)no , 2)yes

So just provide an option: "I've been using this product before and don't know my login" and then provide a short option to check Mail/FB/Google - without creating a new account. Or give hints where they can find their login (e.g. Mailbox Search, Facebook permissions etc)

An keep the communication transparent:

• both sides don't want multiple accounts
• the user want to access the old data

Answer 2

You could store the information of the last successful account creation or login, in local on the user's phone. On next attempts to login, you offer the last used login method. But don't abandon other login methods too.

Answer 3

I will recommend you to use just one OAuth provider along with email/password. The reason behind this suggestion is 80-20 principle.

We recently added support of just Google OAuth on our product by doing an analysis of data we have. It solves for 80% for our users. Instead of making a confusing experience for 100% users, make a world-class experience for 80% users.

In case you want to add support for multiple OAuth providers.

1. See what StackOverflow. When you log in via any provider, it asks you to Confirm and Create an account before sign up. Because I knew that I already made my account on StackOverflow, I canceled and tried to log in via different OAuth provider.

2. Another thing you can do is you can link all the auth information you get from oAuth providers to your user document. Suppose some user sign up via email/password on your app and uses abc@gmail.com. Next time he/she tries to sign in via google. So what you do is connect your user with google account. You can do the same with other OAuth providers.

Answer 4

Hints for where to find login

This is excellent you can directly provide links to gmail app with search term as your app keywords

Other thing you could look at is introducing a memorable confirm shamer

So when he returns to the app he would be reminded of his reaction and would probably be able to judge his own decision as he will react to the sentiment you touched in the confirm-shaming activity.

---

Elaborating my viewpoint to answer how it would help answer the question

About using confirm shaming is what I believe is a little unclear/unaccepted here...

Above image shows how confirm shaming helps you tap into user sentiments which won't change for standard apps and their preference can be streamlined.