SPEAKER 1: Want to play the game?
JESSICA EARLEY-CHA: Oh, For one.
SPEAKER 1: Great, let's get started.
JESSICA EARLEY-CHA: Oh, hi, sorry.
I didn't see you there.
I was just playing a game on Google Assistant.
I have lots of fun exploring different experiences
on Google's Assistant, but I love
to create experiences for others even more.
Building conversational Actions allow
you to create unique and amazing experiences for your users.
The best part, is that your Actions
can be available on so many different Assistant-abled
devices.
If you want to build your own unique experience for Google
Assistant, then you'll need to create an Actions Project.
Before you start building, let's go over what
your Actions Project contains.
The Actions Project consists of four major parts.
Project Information and Location Model, Conversation Model
and Web Services and Web App.
First, Project Information defines meta data and resources
for your Project.
Actions Google uses this to publish your Actions
to the Assistant directory, so that users
can discover and invoke them.
Next is the Invocation Model, which
is how your Actions Project can be invoked
through Google Assistant.
Every Actions Project has at least one way of being invoked,
which is based on the display name of the Action Project.
This is called the main invocation.
For example, when a user says, hey, Google,
talk to Fantasy Fate, which is the name of a fictional Action,
Google Assistant will find the Action with that name
and invoke the Action through the main invocation.
You can also provide a deep link invocation.
So when a user says, hey, Google,
talk to Fantasy Fate about my fortune,
it will invoke your Action and go directly
to that particular section of the conversation.
You can think of deep linking invocations as different entry
points to your Actions Project.
The last way to invoke your Action
is through implicit invocation.
When a user says something like, hey, Google,
I want to play a game.
Google Assistant uses different signals
to identify an Action that would best meet the user's request.
And in this example, if your Action is a game
and meets the different signals, your Action
could be invoked through the implicit invocation.
Now that your Action is invoked, let's
go over the Conversation Model.
This is the back and forth between the user
and the Actions Project.
Let's continue using the fictional Action called Fantasy
Fate to walk through the model.
When a user says, hey, Google, talk
to Fantasy Fate, Google Assistant invokes Fantasy Fate
Action.
Then Fantasy Fate's Conversation Model takes over.
The first part of the Conversation Model
is that the user's request is processed.
The second portion of the Conversation Model
is processing the logic of that point of the conversation,
and generating a prompt back to the user.
You can think of the particular point of the conversation
at this point, as a scene.
Similar to a scene in play or a TV show,
it's a place in the conversation.
In this case, the Action generates a greeting message
with a question to the user if they
want to know their fortune.
Let's continue the conversation as the user
and respond to the Action with, yeah.
The user's request of yeah, gets processed and matched
to an intent.
Under the hood of this Project, I have a yes intent.
So when a user says yeah, yes, I do,
or other types of phrases indicating their intention is
yes, my Actions' natural language,
understanding will process and match yeah with my yes intent.
Matching to the yes intent moves a conversation along
to the next scene, where logic is processed
and a prompt is generated and sent to the user.
SPEAKER 1: What do you choose to help you on your quest?
A dragon, a translator or a compass?
JESSICA EARLEY-CHA: The user can respond with, I
want to use a translator.
And the user's request is processed and matched
with an intent.
This time, the Action will treat the user's input differently.
The Action can extract different parts of the user's input
and use that data to influence the next response.
In this case, the scene uses item type
as a way to extract translator, and it
generates a response for users who choose that option.
Then the prompt is sent to the user.
Ah, the translator.
I see.
Your fortune is.
The last part is Web Services and Apps.
This part is optional, but they provide more functionality
and options that build a rich and immersive experiences.
You build web services to handle webhook events.
Let's say your Action needs to make an API call
or do a database query.
Your Action can trigger a webhook event
when needed, which you can handle in a web service.
Let's continue the example of Fantasy Fate.
The Action can further customize prompts
by delegating prompt generation to a web service.
Let's say that that Action wants to provide new daily fortunes.
So when the user says, I want to use a translator,
the user's request is processed and sent
to the scene to build a prompt.
The scene can call a webhook handler,
which can then gather dynamic data to generate the prompt
to be sent to the user.
Lastly, you can return to full screen web apps
as prompts by using Interactive Canvas.
Interactive Canvas allows you to create experiences like this.
[MUSIC PLAYING]
SPEAKER 2: Welcome to Are You Feeling Lucky.
It's five questions for up to six people.
I give it a 10 out of 10.
How many people are playing today?
[DING]
JESSICA EARLEY-CHA: Check out the docs
for more information on how to implement Interactive Canvas.
Now you're more familiar with how Actions Projects work
and their different components, so you could build
your own unique experiences.
Check out our code labs for step-by-step guides
to build your first Action, and of course, the docs,
for more details.
Join our dev community on Reddit,
where you can chat with other Actions on Google devs,
and stay up-to-date by following us on Twitter.
I'm Jessica, thanks for watching,
and I can't wait to see what you build.