JESSICA DENE EARLEY-CHA: Giving users
a personalized experience is key to building successful actions.
A simple thing, like getting permission
to use your user's name and email, can be a game changer.
With those data points, you can keep
track of that particular user's preferences
and provide them with a richer and more customized experience.
For example, you could save your user's food preferences
when they've signed into your actions
so you could provide better recommendations in the future.
A frictionless way to do this is through what's
called account linking with Google Sign
In for the Assistant.
Actions on Google offers three different account
linking types--
Google Sign In, OAuth only, or OAuth and Google Sign In.
Let's explore the different scenarios for each option
and how to implement them.
For the Google Sign In, your user's ID is managed by Google,
so you don't need to build an account system
or worry about OAuth.
This type of account linking is great for standalone actions,
and if you are already using Google
Sign In for mobile or web.
Google Sign In for Assistant is just
like Google Sign In for any other platform.
As the user is engaging with your action,
you tell Google when to ask a user
if they want to share their basic information
with your action.
If the user agrees to share their information,
the assistant will send an ID token
with each following request.
The ID token is cryptographically
signed by Google.
You'll need to code it using a JWT decoding library
and Google's public key.
You verify it by checking the token's issuer is
the value of your client ID.
Then, you use the JSON that contains a user's name
and email address.
If you're using our client library,
we handle this for you--
pretty sweet.
If the user does not consent to share their profile information
with your action, you should still provide the best service
that you can without associating an identity with the user.
The second account linking type is
OAuth, which supports two industry standards OAuth
two flows--
the Implicit and Authorization Code Flows.
You might want to consider using a [INAUDIBLE] if you have
an existing implementation of an OAuth server,
and you cannot extend the end points to support Google Sign
In protocols.
We do discourage using OAuth only for conversational actions
because it requires transferring the user from voice to screen,
which increases user's friction.
The last account linking type is a combination
of OAuth and Google Sign In.
Imagine you have an existing application
and you allow signups using multiple identity providers,
not just Google.
You may have existing user data if, for example, your users
already have a loyalty card or membership with your service.
You want to allow users to engage with your action
and connect their Google account with your already
existing account that uses a non-Google identity provider
account in your system.
To allow for this, you'll want to implement
OAuth and Google Sign In.
This combines Google Sign In with the standard OAuth
flow used as a fallback.
So during that account linking flow,
you tell Google to prompt the user.
Ask them if they want to share their basic information
with your action.
If their Gmail email isn't in your database,
you'll provide one of two options to the user.
The first option is to support account creation via voice,
which immediately creates a new account using
the data contained in the Google ID token.
The second option is disallowing account creation via voice.
If you choose this option, the Assistant
sends the user to your web log in on their phone.
So you could use your authentication system
to log them in with a different account.
You'll want to use the first option, supporting
account creation via voice, if you
want to minimize friction of the account creation flow.
You want to use a second option, disallowing
account creation via voice, if you
need full control of the account creation flow,
or if you want to maximize the chances that the user will link
to their existing account instead of creating
a new duplicate account.
Connecting their account to a non-Google account
is important in cases where you want
to provide different experience options
or if you're logging their activities that
would affect the user later.
As mentioned before, this is helpful
if you have a loyalty program.
For example, you want to keep track
of any points they earned during their experience
using your action when there are existing accounts.
The OAuth and Google Sign In flow
gives you the highest thinking conversion rate
because your Google users get a streamlined linking experience
while other users that are registered
using another account type can still link their account
and sign into your service.
These are the different ways to implement account
linking so you can create fantastic actions.
Interested in learning more about account linking?
We've added some resources in the description below.
We also have an active community.
So you can ask your questions and share your ideas
with everyone.
Let us know what you build on Twitter by using the hashtag
AoGDevs.
I'm Jessica Dene Earley-Cha.
Thanks for watching.
And I look forward to seeing you use account
linking in your actions.