TITLE: [MUSIC]
MARCO CUNQUEIRO: Welcome. In this demo,
I'll be talking about PlayFab's data platform and
its powerful set of features that allow you,
a game developer, to take control of your games data.
Such features include place of events,
telemetry, and analytics.
In this demo, I'll be covering each of
these topics and demoing subsets of these features.
First I'd like to introduce myself.
My name is Marco and I've been working in PlayFab for
the past few years developing some of
the features I will be discussing and demoing today.
With regard to how this presentation work,
first there will be an introduction in which I'll
describe some of the terminology
I mentioned in the previous section,
such as PlayStream and telemetry.
Next, I will demo
a subset of the features that we'll be discussing.
Finally, I'll give links to
resources that you can use to learn
more about the data platform and our features and APIs.
First, an explanation of PlayStream and telemetry.
PlayStream is our event-driven architecture,
which allows for real-time actions to be
taken based on the events emitted by a game.
Actions can include sending
e-mails and push notifications,
banning players, custom logic you define, and much more.
Telemetry is a streamlined ingestion
of events for analytics,
which reports larger event payload than
PlayStream and furthermore,
a couple of new features in our data platform.
First, event sampling,
which allows game developers to choose
exactly the body movements that
they want landing into their titles data store.
This can help with certain things
such as cost reduction.
Recently we have completely
rearchitected our ingestion pipeline
to easily support the scale
for some of our most demanding titles,
such as Forza Horizon 5.
Now I will head into the demo and
demo some of the features that I previously discussed.
Here we find ourselves in the rules
section of the automation section in
the UI where I'll be creating
a rule that bans a player based on logins.
As I previously mentioned,
you can create and make
actions of a real-time events coming into PlayStream.
We'll call this action BanPlayerOnLogin.
We'll search for a player log in event.
Note that you can add conditions based
on any member from the events payload.
But here we're going to do a simple rule
that simply bans any player.
Set the ban duration for three hours and we'll call
this DemoBanPlayer and We'll save.
Now with that action save,
we'll go ahead and create
a player which would also log it in.
Here we are, a new player.
Create and log in this player.
Also note that here we have the
PlayStream Monitor where it actually
allows you to monitor
events as they come in and near real time.
As you can see,
we have this player logged in,
which is the player we just created.
As you can see, this is the player ID,
the same player ID that we find in
this tab for the player that was just created.
You can also note that we have
had some actions executed.
For example, here we see that the player has been
banned for three hours in almost real-time.
If I go back to the player,
look at its bans,
you can see the ban reason,
DemoBanPlayer, which is from our action.
Now the player has in fact been banned for three hours.
Now, if you would like to query
the events that your title has omitted or
the place up has omitted on
your behalf, there are two options.
You can use the Data Explorer Basic tab or
the Data Explorer Advanced tab both found on
the data section in the analyzed portion of the UI.
The basic tab allows you to do simple things.
For example, here we have a 14-day query
which basically just shows you
event volume by event full name.
If you would like to do something more advanced,
we can head over to our Data Explorer advance section
where you can run more customer queries.
For example, here I'm calling
all events for player logged in
instances where the event is greater than six hours old.
I run this or greater than six hours I go in the past.
If I run this,
we can see a player logged in event for a player that I
created a few minutes ago.
If I run this again, we may be able to see
the events for the player that we just logged in.
However, these events usually run within
a few minutes into their title data store.
Now finally, I previously mentioned event sampling.
Event sampling is this feature which allows you to
control the volume of events
that arrive in your data store.
Something like this could be helpful for
reducing costs as the amount
that you pay for data store
is related to the amount of volume that's there.
Here with percentages,
you can control the volume of these events.
For example, we have character
created which is sampled at a rate 100 percent.
In this case, this means that
the event is not removed from
the data store and that it's completely congested.
Here we have an example of client focused change,
which has a sampling rate of 50 percent,
which means half of the events end up in
the type of data store and half do not.
I would also like to note that this is not random.
This is based on editing.
If a batch of events is received
and they contain multiple instances
of the same entity or player,
all those events will be sampled not just at random.
Now, all these features that we
talked about today are intended to
support you through the entire lifecycle
of your game from development,
when you need real time feedback to test
functionality, then to launch.
When you would like to track some
key performance metrics that
allow you to fine tune and
finally watch your game is established,
providing you with the ability to build
advanced analytics on your data store.
I'd like to thank you for taking
the time to watch this demo and seeing
what the PlayFab data platform
can provide you as a game developer.
To get started building with the PlayFab data platform,
you can follow any of the links provided
here to begin learning about our features and APIs.
Thank you once again and goodbye.