Getting Started with Analytics on iOS #2: User Properties (Firecasts)

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]

Leave a Reply

Your email address will not be published. Required fields are marked *