[MUSIC PLAYING]
SEAN MCQUILLAN: Welcome to Lightning Talks.
I'm super excited to be here today and talk to you about how
to welcome your users to your Android app
when they get a new phone.
So why is this important?
So if you think about the Android ecosystem,
it runs on phones, right?
And we all get a new phone every two, maybe three, years.
And when we do this, we reinstall all
of the apps we've installed.
And we do this, and all of our users of our apps
do this as well.
You do a little bit of math, you figure out,
if you buy a new phone every two years,
that means half of your users are going
to get a new phone this year.
If you don't do anything at all with your application,
you're going to give them a cold welcome when they come back.
And you're going to show them an email and a password
form that's going to be like they've never
used your app before.
You're completely disrupting their flow of using your app.
What you want to do instead is offer them a warm welcome.
You want to welcome them back to your application
and create this continuous user experience that
jumps from their old device to their new device,
so you don't have any friction, you
don't have any retention problems,
for these users that are switching devices and using
your application.
There's a couple of products you can use from Google
that help you do this.
So one of them is Google Sign-In.
I think everyone knows what Google Sign-In is, right?
It's a button you press, and you log in.
So it's a button you press, and you log in.
It's amazing for this flow exactly
because it's very simple to do that log-in.
So it's good for your activation originally
because it's easy to log into your app.
But when they get a new phone, it's
also good for reactivating these users, because all they do
is have to click a button.
And on an Android, you can even configure it
so they don't even have to click the button on the new device.
They'll automatically log in.
Google Sign-In works on iOS, Android, as well as the web.
So you can use it everywhere, and it's
a great way to add federated log-in to your application.
Another feature you can use on Android
is Smart Lock for Passwords.
So Smart Lock is-- well, it's a password manager.
It's named quite well.
So it stores usernames and passwords, or even
federated credentials, up in the cloud
when the user confirms that they would like to save the password
after they log in.
So they're going to do this on their old phone.
They're going to save their password.
And then when they get onto their new device,
when they first come into your application,
you're going to give them this warm welcome.
You're going to say, I know who you are.
Do you want to log in with that account you've already
saved for this application?
And it's just going to create that seamless experience
and log that user into your application.
So one of our partners, Netflix, who I believe
is here today, actually-- so Netflix used this,
and they found that they had 20% fewer support requests.
And so if you think about that, maybe every time
a user contacts you to get a username and password fix,
there's probably five users that didn't, and they're just
not going to come back to your application for months
or even years at a time.
They might just become a retention problem.
They may never come back.
So this is a fantastic way to improve your business metrics.
And then Autofill is a new feature
relaunched in Android O. It works
kind of like Smart Lock when it comes
to usernames and passwords.
So it's an autofill system.
Right?
So it autofills text views exactly the way you think.
And one of the most common text views to get autofilled
is usernames and passwords.
So the way this works is, after they
log into your application on their old device,
they'll choose to save it to the Autofill service,
and that's going to go up to the same data store as Smart Lock.
It's a secure data store for passwords.
And then when they come back on their new device,
it's just going to go ahead and autofill.
So there's a couple things you can
do to get your application ready for Autofill.
One of the biggest ones is set up
a digital asset link that links your web and your Android app.
So this is great because Autofill has pluggable password
managers, but all the password managers support this.
And when they do that, what happens
is the user can log in on the web.
And if they're using the same password manager
on their Android device, they're going
to go ahead and get those credentials transferred.
So they log in on the web, install your Android app,
and the password's already saved.
They get the seamless upgrade experience
to your Android application.
Another thing you have to do for Autofill-- well,
you don't have to do it, but if you
want the best experience for users--
you should set up autofillHints.
So you should tell the Autofill service what the username, what
the password field is.
That way, the Autofill service doesn't
have to guess based on your IDs and maybe get it wrong,
which is probably the worst experience
you can give your users.
And then the last thing we're going to talk about
is Auto Backup.
I'm going to hand it over to Jeremy.
JEREMY ORLOW: Yep.
So Auto Backup is a great way to also provide continuity
to your users.
So even if your app syncs to the cloud,
there's still usually device-specific settings
that you can backup.
And there's also-- no user who's been
using your app for a year wants to see a tutorial first thing
when they launch your app when they're on a new phone.
So Auto Backup works by--
when the phone's idle, we backup to the cloud.
Your data is stored securely.
You can have up to 25 megs.
But if you go over that, backups will fail.
On the new phone, when the user installs the app,
it will restore the data before the app runs
for the first time, and the user picks up
where they left off without any friction or churn.
You can also include and exclude specific files.
So, for example, you can exclude OAuth tokens or other things
that shouldn't be backed up.
And with all these tools, it's possible to provide continuity
to your users and keep them engaged
when they switch phones.
We'll be back in the back.
[MUSIC PLAYING]