PATRICK MARTIN: I
love to say that games are a dialogue between the
developer and the player. Whether your game is a simple
match three or the latest VR-based, high-octane
esport, you have a story to tell
and gameplay to drive. Your players are more than
happy to tell you what worked, what didn't, and
help you improve your game for your
next group of players-- that is, if you know how to ask. You definitely should engage
your players on social media and in forums, but that will be
a very small and vocal subset of your player population. You can watch for
reviews in the app store, but this is a slow process. By the time you see a complaint
here, it's already too late. What you want to
do is build a game that will tell you how well
the current gameplay is sitting with players, where
they're getting stuck, why players are crashing,
and what features your players want next. This process should be seamless
and encourage participation from your entire player base,
from your newest and most casual players to your most
dedicated and hardcore. This is where many of
Firebase's products come in, the most fundamental
of which is Google Analytics. Let's take a look. [MUSIC PLAYING] If you haven't
done so yet, you'll want to check out this
Getting Started video, with one important addendum. When you're creating
your Firebase project, you'll need to hook it up to
a Google Analytics account. I know that it
may seem confusing that you need a Google Analytics
account and a Firebase account, but Firebase uses Google
Analytics to store and aggregate your game data. This will likely
be the only time you need to know about
this implementation detail, but many power users will find
the integration incredibly useful. A side effect of this
separation of concerns is that there are two slightly
different setup flows based on whether or not you have a Google
Analytics account configured. Here, I'm creating a project. I'll explicitly acknowledge
that I want to use Analytics with my a Then, if I don't
already have a Google Analytics account, I'll be given
a chance to configure Analytics and review and
acknowledge some terms. Otherwise, I'll see this mildly
intimidating dropdown box. If you only see one option
here, it's probably safe to use, but you can always create a
new account if you're unsure. Note that each
game in an account is kept separate, in
what's called an Analytics property, automatically. That means that if
you're a game studio that produces multiple titles, you
can reuse the same account here, since each game will
have its own property. Or you may put each game
in a different account. It's really up to you. In either case, the analytics
data for each Firebase project will still be
collected separately in its own analytics property. For this tutorial,
I'm just going to use the default account. If you're adding Analytics to
an existing Firebase project, you may not have
enabled Analytics when you first set up Firebase. Don't worry. You don't need to
create a new project. Simply navigate over
to the Analytics tab and click Enable Analytics. You can hook it up
and try it out here. Oh, and just in case you
decide Analytics isn't for you, you can unlink it again by
clicking on these three dots, then clicking Unlink. Just like in the
Getting Started video, you'll want to pull in the
Firebase Analytics Unity package. You'll have a Firebase init
script that looks like this. Remember that Analytics
is enabled by default, so you'll immediately
start gathering data such as user
retention numbers and rough geographic distribution. On Android, it's even
initialized automatically. So this call just ensures that
Firebase itself is initialized on iOS and could
be replaced with firebaseapp.defaultinstance. If I jump over to
my Firebase console, I can find my 1, 7, and
30-day active player count, my retention cohorts
for up to five weeks. And here's the geographic
map of my players. I'll also see the breakdown
of iOS versus Android players and how many are crash-free. Of course, this is
relatively empty right now, since this is only a sample. Firebase also automatically
generates event reports. If I go over to Events
under Analytics, I can see events like First
Open and Session Start. Note that these take
some time to populate, so this is something I won't
expect to see until the day after I integrate Analytics. If I click on First
Open, I can see how many times the
event has fired, how many users have fired
it, and how many times they occurred per user. This is pretty useful, but
I have some more specific questions about
my game other than whether or not my players
are sticking around. So let's pull in some built-in,
games-focused Analytics events. You can see what
Firebase has built in by typing
firebaseanalytics.event and waiting for your
ID's autocomplete. Or check out this doc page,
linked in the description below. So I found two super useful
events, event level start and event level end. I already have a pretty fun
idea for how to use these. Let's create a simple
level logging behavior. We'll fire event
level start in Start. Then, fire event level
end in onDestroy. By just throwing this
monobehavior into a scene, I can automatically log
the duration of that scene as a level. Oh, and for those of you who
want to sound cool at a party, this particular pattern is
called Resource Acquisition is Initialization, or
RAII in the C++ world. Go forth and be the
coolest person in the room. Now I went to test
this, so I'll create a script that will change
levels when I click on a button. So I'll create a Change
Level on Click script. Create a serialized field
called Level to Load. Make it an IPointerClickHandler. And then on click, just
call SceneManager.LoadScene. Let me create a main
menu scene here. And have this button load
a level called Level 1. I'll create Level 1. Then, this button will
go back to the main menu so I can test a
whole play through. Let's add this event
logging behavior. And in order for
SceneManager.LoadScene to work, I need to make sure
that all of my scenes are in the Build window. If I click Run
here in the editor, I can go back and forth. But I won't actually
get any analytics. Firebase Analytics just happens
to be one of the Firebase products that does
not work on desktop, so I cannot test
this in the editor. I'll cover both iOS and
Android devices in this video. So let's start with Android. With Android selected
as my build target, I can just click Build
and Run right here. I have my Android
phone plugged in, and I can click into the level
and click out of it again. But the analytics events logged
here still aren't showing up in my dashboard. In fact, it may take up to
an hour to upload events, and up to 24 hours
for them to show up, which could be pretty
problematic to test. So I want some way to
verify this locally. If this is your first time
interacting with the Android SDK directly, I recommend
installing Unity's Android Logcat plugin, which adds
Android Logcat under Window Analysis. I'll need to enter some commands
using the Android Device Bridge, or ADB. This does require some command
line work, but don't worry. Thanks to the
Logcat plugin, I can click Open Terminal
to get a terminal window open to the proper
Android SDK's directory. Note that this may open up
behind the Unity window. I'll also need to know
my games package ID. If I open up Build
Settings, I can find it here under Other Settings. Don't worry about why I called
my game Popsicle Platformer right now. That will make sense later. So with the terminal open,
I'll type adb shell setprop debug.firebase.analytics.app,
then my package name. This command does a few things. The most obvious
is that events sent from this device
for your game will appear in debug view, which
I'll cover in a moment. It also excludes these events
from your overall reporting, so you can feel
free to experiment with the events in this mode. Finally, events are
usually cached and sent up to Firebase in
batches to conserve battery life, typically
every hour on Android or when your game goes
into the background on iOS. With this property set,
events will go out as soon as possible. Now, to actually print analytics
information to the terminal, I need to set the log.tag.FA to
VERBOSE and FA-SVC to VERBOSE. Now if I build and run,
the events we'll be logged but won't show up with
my game's normal events. But I contract the
FA and FA-SVC tags that I just configured by
typing adb logcat dash s FA and then FA-SVC
into my terminal. When you're done debugging,
you can type adb setprop debug.firebase.a
nalytics.app.none to turn your debug mode
back off for your game. Testing on iOS is
a little different, and this section really only
applies if you're on a Mac. You'll need to pass the command
line argument FIRDebugEnabled to enable debugging,
then FIRDebugDisabled when you're done. This is also a sticky setting. To do this, switch to
iOS and click Build. Then, I open the generated
workspace in Xcode, click Edit Scheme, and add
dash FIRDebugEnabled here. Now I can click this big
old Build and Run button to kick things off. Unlike Android, you'll see the
debug logs in the Xcode output screen without any
additional configuration. Oh, and remember that debug view
that I mentioned a moment ago? After I verify that this
is all working locally, I can open up the
Firebase console and click on over to Debug
View under Analytics. Within seconds of my
events getting logged out to the terminal, they
should appear here in this nice timeline. Not only does this let me
verify that my events made it all the way up to the
server, but they're much easier to read in this more
graphical interface, at least for me. Oh, and this has
the added benefit of letting you test your
events, even if a test device isn't currently tethered
to a development machine. Simply set some properties on
a test device, and you're good. So just plain events are
already pretty useful. It's good to know that users
load three levels per game, that they die to a
boss, or whether or not they're purchasing any items. But just knowing that
an event happened is only part of the story. As game developers, designers,
and community managers, it's super useful to know
the context around why an event happened and to use
it to inform more complicated second-order decisions. For example, rather than just
logging that a user purchased an item, maybe I want to log
that the user purchased a time extender in Level 10, or
rather then they die to a boss, that they died to
the Level 3 boss without having tightened
up the graphics. In the case of my simple
level loaded event, I'd like to know which level
was loaded so I can determine if maybe there's
a clear favorite, and I can start basing future
level design decisions off of which levels resonate
with my current players. I can do this with something
called an Event Parameter. If I type
FirebaseAnalytics.Parameter, you can see the list
of built-in parameters. Or you can open this doc page. Link in the description below. ParameterLevel and
ParameterLevelName both looks super handy to
attach to my current event. If you check out their
documentation pages, you'll see that level
is a 64-bit integer, and level name is a string. So let me add these to
my level logging event. In my On Start, I'll cache the
level name and level number from SceneManager as a field. Then I'll add the parameters
to my level start event. Down in onDestroy, I'll
send the cached parameters to my level end event. Next, I'll click Build and Run. I'll just use Android for now,
but this will all work on iOS. I can see that the parameters
appear in Unity console, and they pop up in debug
view on the Firebase console. Note that there is a list of
special games-focused events here, linked in the
description below. Firebase is especially
aware of these events, and by using them,
you may benefit from targeted games reporting. I know what you're thinking. How on Earth did Firebase
manage to come up with every possible
analytics event and parameter that every game
ever made or that ever will be made will use? Well, if you'll let me be
honest with you for a moment, we didn't. There will be some
events that only matter to your individual game. Let's see how those work. I've created this quick
game called Popsicle Runner. That package ID suddenly
makes sense, doesn't it? It's like an infinite
runner, but finite. You see that I have this deadly
spike pit and this really cool pickup. Here's the code where I detect
that I fell into a spike pit. I'll add right here a new
analytics event called Died. This is a custom event,
and the analytics SDK doesn't have a pre-built
constant for the event name. But that's fine. Most of your events
will probably fall into this category. I can just go ahead and
enter this event name as a plain old string. I'll also add a custom
parameter called Type and say spikey_doom. So I died to my spikey doom. If I look at this
pickup, here's where I detect that a player
collects it in code. I'll log another custom
event, got_pickup. I'll also add a parameter
called type and say coin. Some notes about these names. These can be up to
40 characters long and they can only contain
alphanumeric characters or underscores. You're generally best off using
snake case, as I've done here. But whatever you do, do not
use spaces or punctuation. I'll play this game with
the debug view open. I can see these
events coming in, so I know that it's working. If you remember back in the
beginning of this video, I mentioned that these
event reports start getting generated after 24 hours. So let's jump ahead a day. And if I look over there, I can
now see these events coming in, but not my parameters yet. If I were to open up an
event such as my Died event, you won't see that the
cause is spikey_doom yet. To do this, I need to add the
parameter to my event reporting in the Firebase console. So click these three dots
and select Edit Parameter Reporting. The parameter name is the
exact name you had in the code. So let me add Type
and click Add. And then, in the Type field,
I select Text or Number. This changes how you can
filter and sort these. I'll select Text, since
the parameter currently will display spikey_doom,
although I do plan to have a moosey fate later. I'll do this again for
got_pickup and my level start and end events. Remember that I have numeric
values for my levels as well. Now, if I go over
to the event card, I can see my
parameters appearing. Of course, there are limits
to what you can do here. Each event can have up
to 25 custom parameters. You can have up to 100
custom parameter reports in any project, 50
text and 50 numeric. Generally, this should be
enough for basic reporting. But there's no functionality
to raise these limits, so you'll want to be a
little cognizant of them in your design. While I'm here looking
at events in the console, I want to talk about one more
thing, conversion events. These events are what you
may consider Key Performance Indicators, or KPIs. For instance, First Open is an
event that's logged by default and also marked as a
conversion event by default. So what makes a
conversion event special? One benefit of marking an
event as a conversion event is that it keys
Firebase Predictions into looking at the event so
that it can start building up predictive models, associating
player behavior with specified event triggers. Also key to your user
acquisition strategy, these conversions can be
imported into your Google Ads account, for instance,
allowing you to associate an ad click with a specific conversion
to gauge the success of an ad campaign. Since these are
considered important, the events will be logged
in real time as well. Now, if I consider
one of my events a KPI, such as
got_pickup, I can simply toggle this little checkbox. Now this event will
update in real time, allowing me to react if
I made a level too easy. Maybe predictions
will even start to predict if a player is
likely to get this pickup, so I can deliver
them a harder level. There are limits to your
conversion events, though. You'll have a maximum
of 30 for any project. So make sure you really
identify your KPIs. And that about wraps up this
Getting Started tutorial. There's plenty more to cover
with respect to analytics, most importantly
user properties that let you describe
a consistent user state across multiple events,
and even filter events based on the state. There's also a product
in Google Cloud called BigQuery that acts as what we
like to call a data warehouse. You can automatically export
your Google Analytics data to BigQuery to generate
your own custom reports or even correlate Google
Analytics data with data you've ingested from other
products, even those external to Google. Finally, as I
mentioned at the start, Google Analytics for
Firebase is the key to unlocking the full power of
Firebase's other growth tools. You can generate audiences
with analytics data to deliver targeted game content
with Firebase Remote Config, or even use Firebase A/B Testing
to test two different game configurations
against real users, using analytics data to
determine which configuration was the most successful. Analytics can also
drive predictions, such as predicting if a user
will spend money or churn. And the audiences can be used
to deliver targeted messages with Firebase Cloud Messaging. As always, I can't wait to see
what kinds of awesome games you build next. Tell me what you're
building or what you want me to talk about
next, either in the comments below or @pux0r3 on the Twitter. So long, and have
a wonderful time. [MUSIC PLAYING]
