The easiest login is no login at all. Use cookies, but don’t be creepy.

Does your service really need logging in? You can go pretty far without it.

In our previous authentication article, we wrote how authentication plays a role in three business-critical phases but is often neglected. Now we finally get to dive deeper into the details.

First things first: cookies can be handy, as long as they’re not creepy.

You would be surprised how accurately various cookies can identify users, letting you personalize their views without requiring a login. But beware: Users can creep out when a service identifies them before they have logged in. If they think you don’t know who they are, you can come across as sleazy if you get too familiar with your personalization.

Technology may let you personalize your service for identified but logged-out users, but too much personalization can freak people out.

Here’s an example from the travel industry. Many services always show the same front page aimed at unidentified customers who have not booked a trip yet. Even though it would be much more likely that I’d be interested in buying ancillary services for my upcoming trip instead of booking a new one.

For logged in customers it is clear you should personalise the front page. The situation gets more complicated if our cookies tell us where the customer is headed even though they have not logged into the service. In that situation, it could feel intrusive to offer excessively tailored add-on sales to the customer.

Trivago uses a cookie to show logged-out users a list of their prior searches.

When you have a customer that you know would benefit from logging in, drawing attention to the login function and telling the customer that their trip will be easy to manage after they log in is one solution to this quandary.

Luring the user to log in

Here’s how Danske Bank does it. The content shown on their front page depends on whether the user has been identified or not. Identified users are greeted with the login page to encourage logging in, and the content appears different from that shown to unidentified users.

Danske personalizes its content for logged-out but identified users.

The key to personalized content is knowing your user. If they are already using Apple Pay, no point advertising that any more. Or if they’ve got their ASP loan, it would be strange to keep pushing it.

Deferred deep linking reduces friction between the web and apps

If the user has already logged in through one channel, it is only fair to log them in through the next one too. Back in the day, we tried to sell Tallink the idea of making a mobile app to go with their website.

The product owner was worried about the friction caused by the channel switch, so he required that if the customers installs the app after booking a trip on the web, the app should fetch the trip information automatically without entering any reservation numbers. Further, if the user was logged in on the web, we should log them in in the app, too.

“It’s not possible. You can’t transfer parameters from the web to an app through the App Store, and there are limits to what you can do in Google Play too”, I said.

“Make it happen”, said the product owner.

That’s how I discovered deferred deep linking. Third-party solutions can transmit data to an installed application so that it can react to the data at first launch. Branch is a pioneer in this field but nowadays basic functionality is also available through Google Firebase.

This option is still not widely known, and many services treat users arriving through download links like total strangers.

If a user logs in and buys a trip on the web, the booking confirmation page is a great place to advertise your app. When the application has been installed, it’s only considerate to log the user in and find their booking automatically. But it still feels like most people don’t even know this is possible. The magic word is ”deferred deep linking”.

If nothing else, check your login chain for these

You can do all kinds of things without login. If your service does require logging in, Apple offers a few universal instructions for implementing logins. They are taken from their Sign in with Apple style guide but are generally relevant.

• If you ask someone to log in, offer value in return
• Wait as long as possible before asking for a login
• In an online store app, let the user make the purchase before asking them to log in
• Explain the benefits of logging in

Our next authentication story will delve into the pitfalls of passwords. They are not the only option, and by no means always the best one. The following article will focus on how to make strong customer authentication as tolerable as possible.