TODD KERPELMAN: So how can you use custom user properties
to better understand your results in Google Analytics
or Firebase?
And more importantly, why am I wearing a suit?
Let's find out the answers to these questions
in today's video.
So as we discussed in our last video, which
you should probably watch if you haven't yet,
Google Analytics for Firebase is all about recording events
that happen within your app and sending them over
to the Firebase console so that you can get
some information about them.
And while seeing this data in aggregate is nice,
sometimes you want to break this down into more specific user
segments.
I mean, sure, it's great to see people
are visiting your in-app store.
But who are these people?
Are they tablet owners, new users, Canadians?
Knowing who these people are can make it easier
for you to personalize your app, create better user experiences,
and get better results.
Now, by default, Google Analytics for Firebase
already provides a number of segments for you.
You can filter any particular event
by device type or country, and if you have ad support
enabled, gender and age as well.
But very often your app will have its own specific user
properties that you'll want to use to filter your data.
An exercise app, for instance, might
want to see how users with different fitness goals behave.
For example, do your yoga enthusiasts
subscribe to your newsletter more often than your runners?
Well, that's something you can start
to find out if you filter your data against these custom user
properties.
So let's take a moment to understand
how user properties work.
On the client, you set user properties simply
by defining key value pairs in the code.
Google Analytics for Firebase keeps
track of what user properties you define for this user.
And from that point on, when you fire off an analytics event,
analytics will associate that event
with all the user properties that you defined up until then.
Now, one important thing to know about analytics
is that all those reports and graphs
that you're looking at in the Firebase console,
they're basically calculated for you ahead of time,
including the ones where you're filtering by a user property.
Which means that after setting a user property in code,
you also need to head over to the Firebase console
and tell it which user properties you're
going to want to see filtered in the Firebase console.
Now, once you've done that, Firebase will go ahead and make
sure that when it's generating a report for your button click
or game over event, it breaks up these reports by each
of the values in the user properties it's tracking.
Now, all this has a few implications for you
as a developer.
First, user properties are not retroactive.
Once you set a user property for a particular user,
any and all future events will be
associated with that property.
But don't expect that previous events will be updated.
Those remain unchanged.
Now, on a related note, I would recommend keeping your user
properties to a smallish number of discrete values
if you want to make your life easier.
For instance, imagine I got myself a mobile game.
Creating a user property that's equal to an individual player's
high score is probably not helpful,
at least not in the world of Firebase console.
Think about how many hundreds of checkboxes
you would need to check just to get
some meaningful data together about a group of players.
So instead, I'm probably better off creating a user property
where I can group more users together.
Like maybe I have a user property
with values equal to a range of scores
or maybe I just go with some text descriptions instead.
In fact, you'll see in the API that values for these things
are always stored as strings.
And that's generally to encourage
this type of behavior.
So with that in mind, let's set some user properties for real.
Remember this app from the last video?
The one where we're recording button presses and slider
adjustments?
Well, our marketing team has this theory
that cat people are more likely to adjust that slider than dog
people.
And they want to back up that claim with data.
So let's see how.
So first off, you can see that, in my viewDidAppear,
I've added a method that asks my users if they're a dog or cat
person.
This should look pretty straightforward
if you've ever used a UI alert controller.
So what we want to do in the results
is store that information in a user property.
Now, the code to do this is pretty straightforward.
In my catPersonHandler, I'm going
to set a property by typing analytics,
setUserProperty, cat_person.
forName dog or cat.
Note that you set the value first and then the key name.
I often get that mixed up when I'm first setting these things,
so just remember that this follows the same pattern
as adding values to something like an NS mutable dictionary,
and you'll be OK.
By the way, we have no official recommendation as to whether
or not you should go with, like, camel case or underscores.
Just stay consistent and make sure
that your Android team is using all the same user property
names and values as you are or you
will drive yourself bonkers.
Anyway, now we'll do the same in my dogPersonHandler method.
Analytics, setUserProperty, dog_person.
ForName dog or cat and OK.
That's all we need for code.
Let's test it out.
So I'm going to run my app.
And I'm going to say that I am a cat person.
And you can see that because I still have debug mode enabled
for analytics, there is this line in the Firebase console
that reports that my user property was set.
And that's nice.
But do you remember debug view, that nice panel in the Firebase
console I showed you last video to help with all
of your analytics debugging?
Well, user properties also show up there.
So lets go to my project and open debug view.
And then over here on the right, you
can see that it's listing all the current user properties
for this particular user.
And sure enough, it's showing that I am a cat person.
And if I look far enough back in my timeline of events,
you can see the moment where it recorded
that I was a cat person.
And now let's take a look at some of the events
it recorded since then.
If I click one of these, then click on User properties here
on the right, you can see that it's associated the cat person
property with this event.
And by the way, all this would also
work if I were to go back and decide that, hey, you
know what?
I actually like dogs better.
If I make that change, you can see
that the change to the user property
will appear on my timeline.
My current user properties will change to dog person.
And if I look at user property details for any events that
happen after that change, the new user property
is included there as well.
So everything seems to be working just fine from the code
standpoint.
But remember I also have to register this user property
with a Firebase console so that it
knows to filter future reports based on this value.
So I'll click on User Reports here on the left.
And I'll click Create Your First User Property to create one.
And this is the one place you do need to be extra careful.
You can register up to 25 custom user properties,
but right now you can't delete or rename these things
once you've entered them.
So don't fill this up with a ton of test
cases or experimental user properties.
And do make sure you get the name right
and don't misspell it or anything.
In fact, I really just like to copy and paste the property
name directly from my code just to make sure.
And in fact, that's what I'm doing here.
All right, so I'll add a little description.
I'll double check to make sure this looks good.
And it does.
And so we can create it.
And now at this point, the Firebase console
knows that it should be prepared to filter
all of its analytics reports by this value in the future.
So I'm going to go back and play with my app a little more.
And then I'll wait a few hours and check out my results
in the Firebase console.
OK.
So it's been some time later.
Let's go ahead and take a look at these events.
I'm here at the Firebase console.
And I will click on Events and then select
my adjust_slider event.
And now I can switch the dropdown here
to yesterday to just focus on yesterday's events.
I'll click on this filter button.
Then I'll select user property and pick cat or dog.
And then you can see underneath it's
got some values to choose from.
And I'm going to choose cat person.
And now I'm seeing the events only associated
with users who decided they were cat people.
And I can compare these values with what
I get when I filter by dog person, which
looks like much fewer.
But be careful here.
Don't get fooled by these absolute numbers.
If I had like five times more dog people out there
than cat people, I might see more total adjust slider events
for my dog people.
And that might be misleading.
I really should be looking at these count per user stats
to see which population actually prefers adjusting the slider
more.
But looking at what I have here, it
seems like our marketing folks are right.
Cat people really do like adjusting sliders more
than dog people.
Who knows?
Maybe that little circle looks like a laser pointer
to them or something.
So that should give you enough background
to get started adding user properties to your own apps.
Start thinking about what segments of your audience
you're curious about, because that can start determining
important factors like where you want to prioritize development
or where you want to spend your marketing dollars.
In the meantime, feel free to check out our documentation.
Subscribe to the Firebase channel.
And I will see you soon on the next episode of "Firecasts."
Oh, and why am I wearing a suit?
Because my tuxedo's still at the cleaners.
[LAUGHTER]