INSIGHTS: Would you test a feature allowing users to easily switch account?




This is a standard question about whether testing a new feature or not. As usual, the best way to approach this is by firstly looking for proxies for demand of that feature. Are users already doing that despite a convoluted process? If so, by simplifying the process, you can realistically expect that behavior to become more common.

In this case, you can check whether it is common for the same device or ip address to log out/log in into different accounts within a short time frame. Similarly, you can check via the ip address if the same user is, at the same time, connected to different accounts. For instance, one account for the mobile app and one for mobile web, one account on desktop and one on mobile, etc.

Assuming the answer to the above question is yes, you know that demand is there and that, if you made it easier to switch account, that feature is likely to be used. The second part of the question is whether you actually want to incentivize that user behavior. In most cases, you want to facilitate what users are already doing. But that’s not always true. There could be situations in which a given user behavior is actually not beneficial to a company. In product data science terms, the question you want to answer is: if more users do that action, will my target metric go up?

There are obviously very different use cases for this feature: i.e. your mother is a connection and you want to use another account to post pics you don’t want her to see; you are a VIP and you want one account to deal with close friends and one with acquaintances; you might want another account just to have fun, for instance one account is the real one and the other one is a parody account, it could be to scam people, create fake profiles, etc.

As we can see, that feature will have two opposite effects: will most likely improve positive engagement from some users, but it will also most likely incentivize a behavior with a long term negative impact on the platform. Note how this is exactly the same as many other product decisions. Should you require to verify the email when a user creates an account? Should you have two-step authentication when users log-in? Eventually, these features have exactly the same trade-off. If you make it harder to create an account or switch between accounts, you prevent fraud/fake profiles, but you are also losing engagement from some good users.

Therefore, you can approach this just like you approach, say, two-step authentication. For instance, like this. Along the same lines, you could run a test where you try a feature that makes it easier to switch between accounts with just one click. But, behind the scenes, you run a model that predicts whether that’s a legitimate use case or not. If not, you actually still require the user to log-in after clicking the switch-account button, making the feature essentially useless for those people. A more extreme/simplified version of this is offering the feature only to users/accounts with certain characteristics.

A different approach would be go to back to the basics. We often test a new feature to simplify some actions that users are already performing in a convoluted way (assuming we want to incentivize those actions). It is unlikely that “changing account” here is the end goal of the user. That’s most likely just a step in a longer sequence of events. What’s the action that users actually want to do so badly that they go through the hassle of logging in, logging out, and then doing it? We can build a Markov Chain on user actions and find that out.

Say we discover that many people are switching accounts because they want to post pictures that they don’t want their mothers to see. It would be better to test a feature that lets them do that directly from their account with one click, without having to switch account. The advantage of this approach is that this way we are simplifying the entire user pattern, not just the “switching account” step of a longer pattern. So it is going to be more effective. Also, we can specifically choose which use cases we want to incentivize, among the many different reasons why users might want to switch between accounts.



Complete and Continue