DI Slack Chat – When Should Your App Collect Emails?
Our team routinely shares articles in our “Worth Reading” channel on Slack. Recently one sparked an interesting discussion on the use of email collection during onboarding. We thought it would be useful to share the discussion to highlight some of the considerations product teams should be thinking about.
colin (Colin Jones, product): In a nutshell:
“One of the things that fascinates me is the number of products that require a user to hand over their email address in order to use the product — get the email so you can harass a user who hasn’t returned in a while! They must have forgotten how much they loved us! — Is this the best experience we can come up with? If a user doesn’t want to come back no amount of email nagging is going to change their mind. Let’s give them an experience so successful that they return on their own.”
sean (Sean Johnson, product and growth): I don’t totally agree with this (at least based on your nutshell).
Building a product people love is absolutely the goal. But this underestimates the difficulty of behavior change. There are lots of things I want to do in my life – tools I want to use, etc. – that I truly think will be valuable. But I simply haven’t built the ingrained habits to make it stick.
Having a great product, and having a solid onboarding experience that gives users the lightbulb moment (ideally during first use) should be the goal. but once I’ve done that, I still want to make sure I use all of the tools in my toolkit to maximize the likelihood that this new behavior becomes a habit.
BJ Fogg who runs the Stanford Persuasion Lab talks about the three pieces necessary to drive behavior change – motivation, ability, and trigger.
If you have created sufficient motivation (product-market fit coupled with solid marketing) and it’s sufficiently easy to do (usability), you just need to present users with the appropriate trigger at the appropriate time. But all three matter.
jordankatz (Jordan Katz, business development): Email addresses also help create asset value and/or can be monetized.
colin: Don’t disagree with either of you guys, necessarily, but I think the idea behind it was that asking for info from a user up front creates a barrier to the aha-moment such that fewer people actually end up accomplishing what you want them to with your product (including any revenue-generating activity).
Behavior change is hard and sending emails to people can give you more opportunities to get a user’s attention, but if you’re gathering email (or whatever) at the expense of demonstrating value from your product, you’ve got the equation backwards.
Email addresses only represent a monetizable asset to the extent you can convert them in the long run. They don’t represent any value in and of themselves. And what better time to convert someone than when you have them with sufficient motivation (as something has triggered them to want to try onboarding with your product).
Habits aren’t built by drip campaigns. Habits are built by good products that solve problems for people. Drip campaigns are just a way to convince someone that your product might solve a problem for them if you failed to do so the first time around. But your onboarding (which prioritized collecting their email instead of demonstrating value first) could be the reason you failed.
sean: Habits are absolutely built by drip campaigns.
sean: Cleveland clinic wanted to improve patient adherence in taking their medication. They most effective method they found was to ping them every single day reminding them to do it.
apps that leverage push notifications on average have twice the retention rate of those that don’t.
colin: Ok, fair enough, but definitely a different kind of drip campaign. Reminding people to take medication isn’t why you collect emails at onboarding.
That’s more of a notification system. Most of the products I sign up for collect my email address to put me on their never-ending drip marketing campaign long after I’ve lost interest in their product.
sean: I think the author is talking about a very specific type of app.
For example, tools like SalesForce or Quickbooks or whatever – apps that require a pretty significant investment of time to begin reaping the benefits – are unlikely to get users to that aha moment during first use.
Using email as part of new user onboarding (”here’s what to do today” etc) likely can increase the chances they get there.
There are also products (UGC sites) where email becomes the primary mechanism for consumption. Quora would be a good example.
Again, none of this precludes creating a great onboarding experience as well.
colin: Yeah, I think there are definitely counter-examples. And to be clear, she isn’t saying don’t collect email at all during onboarding. She’s just saying don’t prioritize it over giving the user a good experience.
For example, she shows Oscar which does health insurance. You’re coming there because you want a quote. They do that for you first, then ask for information from you after they’ve demonstrated some value.
For me, I do think too many people lean toward “onboarding” being 1) set up an account by giving me some info, then 2) I’ll show you some quick explanations of the product and off you go, good luck, hope you like it. And as we talked about with client name redacted the other day, for example, they should put more effort into getting people bought into the value the product can provide for them up front, rather than what I see as sort of a vanity metric of how many “sign ups” they get.
sean: That is a perfect example though.
The aha moment is going to come once you’ve a) created a community, b) added some tasks, c) invited some friends, and d) one of those friends engages.
There’s a bunch of work to get there, and many people bail, as evidenced by average community size, etc.
The answer is absolutely to improve the onboarding experience to make it more likely they get through 3. But part of that toolkit is likely to leverage triggered emails to people who don’t complete certain steps, etc.
colin: Of course – the only question here is, do you collect their email for that purpose immediately before you’ve even really convinced them to try the product or do you, for instance, help them set up the community first, then ask for their email to “save their progress”?
The tradeoff, of course, is that you might not get as many people who didn’t finish setting up their community (or get to some other point) to give you an email so you can keep marketing to them, but those people may have already not been a good fit.
sean: The real answer is to test it and see. I’d be willing to bet though that the dropoff rate between the two is relatively small, and the value of that email is more than worth it.
We had a similar issue a couple of years ago with client names redacted. In both cases they wanted to increase email subscribes for their ecommerce sites. They were pushing heavily against anything like modals, which they thought seemed spammy. But in both cases when they implemented them the difference in bounce rate was almost negligible, # of subscribers increased, and revenue increased from return visitors.
They believed modals were categorically bad, because they had read a bunch of thinkpieces saying that. UX designers often don’t have the best track record actually looking at their data to validate their positions. and they often advocate for the user at the expense of the business.
matthewm (Matthew Miller, research): This is really interesting. What Jordan said struck me – this is all about value creation – and how quickly in demonstrating the function of a product it can be created.
Thinking back through my most recent downloads, I am always pissed off if I want to try an app and need to give away my email first. If I can imagine what it can do for me (which is a function of good copy or pre-made demo), I want to try it and see if it works for me that way. The volvo on call app comes to mind – you download it and can run in demo mode before creating an account.
I can see the value, experience it myself and imagine myself using it. Same with the M1 app. For something like salesforce or CB insights, which are more wishy-washy in terms of their function since they’re so customizable, I have an idea of what they offer but I expect a demo or guidance beyond a simple onboarding screen – so giving my email up early on is kind of expected as I think the function will best be explained over a series of smaller emails or customer associate interactions that will allow me to create a vision of the value these complex platforms can provide to me.
Id be curious to see if there’s any correlation between cost of the platform to a user and the willingness to provide an email. It’s like how people hesitate to buy things that they consider “too cheap” for fear the price is an indicator of quality.
winston (Winston Fassett, engineering): To require an email is to put a big fence around everything. I think most people get this. I think most people find it off-putting, but you could argue that it creates an air of exclusivity that increases perceived value. Or maybe it’s worth inconveniencing your customers in order to establish a channel to them.
Regardless, usability and timing should be a huge consideration. As someone who tries a lot of online products, I’m quite offended by being asked for an email, largely because it’s invasive and no value has been shown, and also because typing is tedious, especially on mobile. At that point I usually decide it’s not worth my time. However, if I can login with Github or Google in a couple of taps, I’m ok with that.
Some messaging apps I’ve recently tried only require phone number. In terms of app onboarding that requires personal info, those have been my favorite experiences so far. 8 taps and I’m done.
Here’s a dev perspective on this. Back in the 2000s, app developers worked out that the best way to collect your email address was to require it instead of a username. Sure it was longer, but it was unique enough, and it got you a connection back to the user. Suddenly your email was required for everything. It became pretty standard pretty quickly and has stuck throughout the years.
In 2016, however, with all the data breaches over the past few years, along with the newer approaches to authentication, i.e. 2-factor auth, developers are doing things differently. At this point, it’s an antipattern to write your own auth system, because all the breaches involved hand-rolled, insecure authentication solutions. Developers are actively discouraged from writing username/password authentication systems. Most developers are not marketers and thus do not want your personal info, because they don’t want the liability. As a developer, I just need whatever it is you think I need to make it a personal experience, and I’d rather not have to make half of my code worry about it. If I can use a 3rd party library and authenticate users with Google, I get all the info I/we care about, including email. Externalizing authentication like this removes a huge cognitive load from the developer.
I guess that’s to say, if you are willing to give authentication over to Google, you can get their email without blocking the UI to explicitly ask for it.
sean: Many users don’t want to authenticate only with social sign on, as they’ve been burned in the past (most notably from giving access to FB friends and having apps spam their address books.) So at a minimum you’d need it as an addendum to, rather than replacement for, traditional email registration.
Re: usernames, I think companies found that email is almost always better. If you achieve any kind of scale, users end up having to create one off usernames because the one they normally use is taken. Email is guaranteed to be unique. The only times username is helpful is when a) anonymity matters, and b) your app has a concept of a personalized URL (twitter.com/intentionally).
Last point – one other benefit of collecting emails is you can use it, coupled with APIs, to streamline the rest of your onboarding flow. Segment did this to great effect, using the Clearbit API to populate company name, department, role, etc. Useful for lead scoring, and increased registration rate by 20%.
In short, I think the benefits of collecting email vastly outweigh the costs – while I agree it’s a great idea to test different approaches in terms of when you collect it, whether you collect it seems like a no brainer.
Actionable takeaways from this discussion:
- Email is better than username.
- Social sign on can improve conversion rate.
- Look at APIs that can be used to streamline registration furhter
- Using phone number instead of email on mobile is worth exploring.
- Consider the type of application and the number of steps necessary to get to the aha moment. If it can happen during first time use, consider getting them started and asking for email mid-stream or immediately upon a successful onboarding loop. If it takes longer (or requires money to reach aha), prompt for email before they bail.
- As always, itt’s critical to consider the business, technical and user stakeholders simultaneously.