TODD KERPELMAN: So user research studies and focus groups--
they all have their place.
But if you want to find out how people are really interacting
with your app, where they're spending their time,
what they're interacting with, and where they're
getting stuck, you're going to want
to measure that using an analytics library like, say,
Google Analytics for Firebase.
So are you ready to add some analytics into your iOS app?
Stick around and find out how.
[MUSIC PLAYING]
So Google Analytics for Firebase is an analytics system that's
primarily built around events.
As people use your app, it fires off a whole bunch of events
that get tracked, coalesced, and reported to you
in the Firebase Console.
Now, this here, this is my very simple test app.
I've got a button, a switch, and a slider.
And our user research team is dying to know,
what control are people using most often?
Well, we can find out by measuring these events
in Analytics.
Now, before we do anything else, we need to install Firebase.
Now, I've already done that by creating
a project in the Firebase Console,
attaching my iOS app to the project,
adding in a constants file, installing the Firebase Core
Library using CocoaPods, and calling
initialize in my AppDelegate.
Don't know what I'm talking about?
Go watch this setup video first, and then come back.
Now, if you've done all that, then, hey, guess what?
Congratulations.
You already have Firebase Analytics up and running.
It's included in the Firebase/Core library.
In fact, even if you do nothing else at this point,
you would start to see some data about your app in the Firebase
Console--
things like overall usage, user engagement, revenue,
and retention.
That said, if you want to gather app attribution data-- that is,
finding out which ads are responsible for bringing you
users who installed the app or performed
an important conversion event, as well
as some basic demographic information-- you should link
in the Ad Support framework.
You can do this in your project's
build phase's Link Binary With Libraries section.
Keep in mind, this does make use of Apple's IDFA.
And so, yes, before you ask, we do honor the Limit Ad Tracking
setting.
That's something they'll be asking you about when
you submit your app for review.
Now, there are a few events, like Session Start and In-App
Purchase, that the analytics library
is able to track automatically for you.
But for most others, you're going
to need to log them yourselves.
Now, an event consists of a name,
which is simply a string, and then
an optional list of parameters.
These parameters are represented as a dictionary, where
you have strings for the keys and then either strings
or numbers for the value.
For instance, if you had an Exercise Complete event
for your fitness app, you might want
to include the exercise routine as one of the parameters,
and maybe the total amount of time your user spent exercising
or how many calories they burned.
Now, some common events have already
been defined by Google Analytics for Firebase.
You can see a partial list of them here-- things
like level_up, tutorial_begin, add_to_cart, and so on.
If you have the option, I recommend
you use one of these predefined events instead of creating
a custom one, since Firebase understands the context
around these predefined events a little bit better.
For example, if you use Firebase's built-in level_up
event, it will automatically give you
a histogram of all the new levels
that people have reached in your game.
That's something you wouldn't necessarily
get automatically if you created your own level_up event.
Now, it turns out that Firebase Analytics
doesn't have predefined events for adjusted slider
or release the kraken, go figure, which
means we're going to need to submit these as custom events.
So let's jump into our code and start doing that.
Now, submitting these events, it's pretty straightforward.
I'm going to jump into my ViewController here.
And actually, the first thing you'll want to do
is import Firebase.
OK, next, from within my button press handler,
I'm going to call Analytics.logEvent.
Note that this is a class method.
I don't need to bring up a shared instance
or anything like that.
So for this first parameter here,
I'll type in the name of the event.
Now, if I were using a predefined event,
I would be entering a constant here instead of a string.
They all begin with AnalyticsEvent,
as you can see here.
But there isn't any kind of predefined button press
event here.
So I'm going to type in a string instead.
Let's be real original and call it press_button.
Now, this event doesn't really need any parameters.
So I'm just going to leave this parameter list set to nil.
Then I can do the same for these other two.
We'll add in an analytics event for flip_switch,
and then maybe another for adjust_slider.
By the way, when you're dealing with a slider,
make sure you send these on touch_up events.
If you send these on value_changed events, which
is the default in Xcode, you'll be sending down
dozens of analytics events every time somebody adjusts
the slider.
And that's probably not what you want.
And you know what?
Just for fun, let's send along a parameter with this one.
We'll give it a name of new_value.
And then for the value, we'll use the value of our slider.
Now, one note here as you're picking event names
and parameter names is that you probably
want to be using the exact same strings as the ones
in your Android app.
That'll let you see combined event
reports across both platforms.
So if you have an Android team that's
working on adding analytics within their app,
get together with them and make sure
you're coordinated when it comes to all of your string values.
And come to think of it, it's probably
best if you don't hard code these names into your code
directly, like I'm doing.
Go put them into a constants file or something.
So how can I tell if this worked?
So when I run this app, I see this line here
that tells me Analytics has started.
But that's not really much to go on.
I can get a lot more information by turning
on debugging in my project.
Now, in Analytics, if you want to see debug logging,
you have to do it through an argument that
gets passed into your app.
Notice that the console prints out these helpful directions
on how to do it.
So I'm going to go into Product, Schemes, Edit Schemes.
And for my run event, I'll hit the plus sign here.
I'll add a dash-- that's very important--
and copy and paste this FIRAnalyticsDebugEnabled flag.
By the way, this flag does get saved to disk.
So if you ever want to turn off this debugging,
you can either change this flag to no for Analytics Debug
Enabled, or you can disable the flag
and then just make sure you delete and reinstall your app.
So now I can run it.
And I can see that as I'm messing
with these interface elements, Firebase Analytics
is telling me that it is properly logging these events.
And then right here, you can see that it's marking
this event as real time.
And then right below that it's telling me
that my data was uploaded to the server.
And while this is great, I do want
to point out this is not the typical behavior in production.
In order to be respectful of your user's battery,
Google Analytics for Firebase only sends down analytics data
if you've got data that's been sitting around
for more than an hour, your user triggers a conversion event,
or your app goes into the background.
But in our case, because I've got debug mode enabled,
events get sent down nearly right away.
So it sure looks like my events are getting sent down properly
with the right values.
But I can double check by using our handy Debug View feature.
This is basically a panel in the Firebase Console
that will let you know about any events
it receives from debug devices.
So I'm going to jump to the Firebase Console
here, make sure I've got my project selected,
and then head over to Debug View under the Analytics section.
And here, you can see all the events
that are being recorded for debug devices, which, right
now, is just my simulator.
So I can go ahead and play around with my app some more.
And then, about 15 seconds later, those events
will show up right there on the console.
Hey there, events.
Now I can go ahead and click on these events,
like this adjust_slider event.
And here, I can see the event parameters being sent along
with it, including the new value parameter that I recorded
earlier and a few parameters that Firebase
records automatically.
More importantly, if I included any errors,
those would also show up here in the console.
Here, let me show you.
So it turns out event names can't be any longer
than 40 characters long.
So if I replaced my button_pressed event
with "the user has pressed a button
and oh boy am I really excited about that"
and then rerun my app, you can see that this error appears
in the console.
And sure, if I dig through my Xcode log, it's there too.
But it's kind of nice having that info
sort of upfront and center for me in Debug View.
So I'm going to go ahead and revert that change.
OK, so while this debug info is nice
when you're developing, once you get into production, more
likely, you're going to be viewing
aggregate data in other panels, like the Events report here.
Now, generally speaking, it's going
to take a few hours before your data starts
showing up the dashboard here.
And if you're looking for today's data,
be careful, because the default time period generally
doesn't include today.
You'll want to select that from this dropdown over here.
But down here, I can see a general overview
of all the events that I've recorded with this app.
Right now, it's showing me the combined data
for all the apps in this project,
meaning that if I had both iOS and Android
versions of my app associated with this project,
I would see the total values here for both of them.
If I wanted to filter for, say, just the iOS version,
I would pick this filter button, select Stream here,
and then pick my iOS app.
In my case, I don't actually have an Android version.
So this is all I get.
Now, if I click on one of these events,
I can see some more details about them--
their usage over the last few days,
how many users or, I guess, to be more specific,
unique app instances have triggered this event, and where
these users are coming from.
If I've hooked up the Ad Support framework,
I could also view some demographic information
about my users here.
But for privacy reasons, Analytics
won't show you this demographic information
until your app has a critical mass of users.
So during development, this is going to look pretty empty.
But now, let's jump into my adjust_slider event.
Now, you might recall that with that event,
I was passing down a new_value parameter.
But that doesn't seem to be showing
up anywhere in this report.
That's because, if I want to see event parameter reports here
in the console, I need to tell Firebase about them.
Now, I can do that pretty easily by clicking this big, old Add
Event Parameters button here.
And it's listing some parameters that have already
been recorded with this event.
And right over here is my new_value parameter.
So let's pick that.
Now, over here, I have to tell Firebase
whether this parameter is primarily a text
parameter or a numeric one.
Now, if I choose Text, it'll basically
give me a report of each discrete value
and how often it occurs, something like this.
If I choose Number, I'll see things like an average value
or a sum of all values over time.
So in my case, I think I'm better off
seeing the average value of where people
chose to slide their sliders.
So I'll choose Number and pick Standard for my units,
meaning that it's just any old number.
And then basically, from this point forward,
Firebase will start to populate this graph.
It's not retroactive, but it will work in the future.
Now, one big caveat here is that you're
limited to 10 text parameter reports and 40
numeric parameters across your entire project.
So choose these parameters wisely.
And yes, I know that for a lot of you
big developers out there, this won't be nearly enough.
And that's fine.
This is really just to set the surface some of the most
important event parameters to focus on your team who
use the Firebase console.
For those of you doing serious in-depth data analysis,
you're going to want to export your data to BigQuery, where
you can slice and dice your data to your heart's content.
But that is a topic for another video.
So congratulations.
We have tackled the first major API
call of Google Analytics for Firebase,
which is sending an event.
In our next video, we're going to tackle
the second major method, adding custom user properties.
So stay tuned.
In the meantime, feel free to check out our documentation
here.
And hey, don't miss out on any future videos.
Why not subscribe to our YouTube channel?
Thanks, everybody.
And I'll see you soon.
[MUSIC PLAYING]