a.k.a. How not to expect too much and fail miserably with Google Analytics for Firebase
Have you ever wondered how many people use your brand new “Shopping App”? Has anyone actually bought anything? Which country do they live in? Which one is the language most used in your app? Has anyone managed to beat the ULTIMATE SUPER INSANE FINAL BOSS in your “Angry Space Potatoes” game? Or the most crucial question of all: Which one is button pressed most often?
I think these are pretty interesting questions and they can tell you a lot about your product. You can find out which functions are used on a daily basis, measure the server’s response time, and by analyzing the user’s interaction patterns you may get a hint on which functionalities should be implemented. You can find out what people like or dislike about your application.
Think of it as the best kind of survey, because behavior never lies.
So, fasten your seatbelts and grab your space potatoes because I’m about to tell you everything you need to know about Google Analytics for Firebase.
Google Analytics for Firebase is a free app measurement solution for your application. You can use it to track Android, iOS, C++ and Unity apps that have a Firebase project linked to them. It can automatically measure how many people started up your app each day, has a StreamView that shows live details about the current usage, a graph that shows how much revenue your app is making, which Events have occurred in your app, which OS versions are the most common and so on.
(I’ve used it with Android, so my example codes will be written in Java, but they are pretty straight forward.)
In the first part, I’ll be focusing on User Properties, Events and Events Parameters. These are the basic elements that you can be defined in your project and the things that you can “add value to” or “log” in your application. You must choose these based on the events and states that matter in your application otherwise the data gathered will be useless.
User Properties are fields that you can set for each individual user. It’s like a text variable within a “user” class. You can define 25 different User Properties in one project. You can set their value with simply calling the setUserProperty() method.
FirebaseAnalytics firebaseAnalytics = FirebaseAnalytics.getInstance(this);
This is useful if you want to find out things about the individual users. A User Property can be for example the user’s language, their favourite theme, their age, OS version and so on. These property values should be rarely changed (once a day or less). To use these first you must add this parameter in Firebase.
(At the moment you can’t delete User Properties so watch out for typos and choose Properties carefully.
Sometimes it takes more than just one call for Firebase to handle the value changes. Be patient. The more users set to a Property, the sooner it will be visible in the Analytics.)
Events are “signals” for Analytics indicating that something has happened. An Event on its own contains no text or number value. It’s up to you to decide which interactions, processes or outcomes should be signaled. You can have up to 500 different Events in your project. Firebase holds a record of each Event and the number of times they were triggered each day.
Events can help you find out how many errors have been there throughout the last 3 days, how many requests have been sent to the server and which button was the one clicked the most. You can also see the number of users involved in the count.
You send an Event the following way:
FirebaseAnalytics firebaseAnalytics = FirebaseAnalytics.getInstance(this);
It takes time for Events to arrive, because they are usually sent in packages. You might have to wait several minutes for a package to arrive. Also, it takes about a day to process Events before they are visible outside StreamView. Not every part of Analytics is real-time. Be patient!
Events can have Text and Numeric Parameters. These are additional pieces of information to the event. For example, if you have an Event called “navigate_to_screen” that is fired when the user navigates in the app, a Text Parameter could be the name of the screen. For an HTTP request, a useful Numeric Parameter could be the response code.
Event parameters can be added the following way:
FirebaseAnalytics firebaseAnalytics = FirebaseAnalytics.getInstance(this);
Bundle bundle = new Bundle();
You can have a total of 50 Parameters (10 Text, 40 Number parameters) in a single project. An Event can have multiple Parameters. If you create an Event that has 10 Text -and 40 Number parameters, the remaining 499 Events won’t have any.
There is another catch. Firebase Analytics store a processed variant of the Events. Parameters are not linked together even if they are packed and sent up in the same Event. This results in information loss (and a major reason why I find that 50 is simply not enough). Firebase can tell you how many times a value has occurred in a specific Parameter, but you can’t filter a Parameter based on the value of another Parameter. Let me show you why this is a problem.
Imagine an Event called “interaction_happened” which is triggered when a user interacts with a button on a screen. It has 2 Parameters: “screen_name” (Text), “interaction type” (Number). We have 3 screens (A, B, C) and 2 interaction types (1, 2). On screen “A” we can do interaction type 1, on screen “B” we can do 2, and on “C” we can do 1 and 2. With Analytics we can find out how many interactions have happened on each individual screen and in total, the occurrence count of each interaction type, but we won’t know what types of interactions occurred on a specific screen. We have no way to filter out which “interaction type” happened on screen “A” and their count, because we can’t filter on a the “screen_name” Parameter.
You can do 3 things to resolve this:
- Differentiate each interaction on each screen (costs 2 Parameters)
- Create “interaction” Events for each screen (screen count * 1 Parameter)
- Create Event for each “screen_name” + “interaction_type” combination (“a lot” * 1 Event)
Choose your Event Parameters wisely!
I know that 50 sounds plenty, but in one of our projects, I will probably use up 40 of them (and around 100 Events). Imagine a scenario where you have 12 server requests, each having 3 different types of processes. If you want to have any idea about how much time each type of process takes, you must create 12 * 3 Events and each has to have a Number Parameter. I haven’t done anything difficult, and yet I used up 90% of my Numeric Parameter resources.
I’ve came up with a simple suggestion to find out if I should use a Parameter: If an Event has only one Parameter which holds less than 20 different values, you should split the Event into individual Events.
Sidenote: The “Event Parameters” view in Analytics shows how frequently a value occurred in a Parameter, but the “Events” view does not (It has no idea as to which event should be added to the calculation).
Online User Interface
It’s time to go online and check out what “Google Analytics for Firebase” has in store for us. There are 10 different pages in Analytics, but we are only discussing 6 of them. I think these are the most useful parts when it comes to handling and analyzing Events and User Properties. So, let’s get to it!
On the Events page you can see all your Events that have ever occurred in your application. This page has 2 tabs: Events, Parameter Reporting
There’s an Event list On the “Events” tab. You can see how many times these Events have been triggered, the number of users involved in these triggers and the percentage differences of these numbers compared to a date.
You can also see a “Mark as conversion” switch. If you turn this on, the Event will be added to your Conversions, which are visible on the Conversions page. This makes it easier to track the occurrences of Events overtime. (The Conversions page won’t be discussed in this post.)
In the top right corner of the screen you can change the visible time interval and you can see the date of comparison. A custom interval can be set by clicking the “Custom…” item in the dropdown list.
Most pages have a date picker on them. From now on, I will refer to these as “Date Picker”-s.
On the “Parameter Reporting” tab you can see the Events that contained some kind of Parameter when they arrived. If you want Analytics to track a Parameter, you must add it to an Event in this tab. Next to the Events you can see how many Parameters are tracked and their types.
By clicking on an Event, a dialog will pop up. Here you can select the Parameters that you’d like to track, their types, and you can add a description too.
Keep in mind that Parameters will be tracked after adding it to the Event. Previously triggered Events won’t be processed.
If you want to find out more about a specific Event, you can check its statistics.
Upon selecting an Event, you will be navigated to a Dashboard-like screen. You can select which Event’s stats you want to view. You can add filters. Each Event Parameter has its own view. It contains the occurrence count, the users stats and a graph. In the top right corner, you can find the Date Picker. The “Events in the last 30 minutes” view is a smaller version of the StreamView page. You can also find built-in statistics in the “Event demographics”, “Event per session”, “Event location” views.
What if you want to know which users purchased something? Which users subscribed to your application? How many managed to beat the ULTIMATE SUPER INSANE FINAL BOSS or reached level 142.5 with their characters?
By tracking these numbers, you can decide which part of your application you should improve. You could send a notification to a user who bought something to encourage another purchase. Maybe you should add new levels to your game if 80% of users have finished the previous ones. If 63% of users are interested in your “Upper Body Workout Training” you should create a “part 2”. Audiences could help us find these percentages.
Audiences are groups of users who met a specified condition. On the Audience page you can see how many users are in an audience, the date of its creation, the description and the differences. The Date Picker is also present here. Tracking starts after the creation of the audience. Users won’t be added to it if they met the condition before the creation of the audience.
Audiences have names and can have descriptions. A condition can be set on various properties: Streams, Events, User Properties, etc. You can add multiple conditions and exclusion conditions as well. There is also a “Membership duration” field where you can set how long a user stays in the Audience after fulfilling the condition.
When creating an Audience be sure to select the right kind of condition for a Parameter! You must use a Text condition on a Text Parameter and a Number on a Number Parameter or else it won’t work properly.
Also, remember that if a user is added to an Audience, there is no way for them to leave manually. There is no point in making an Audience for something that does not filter the users properly. A condition should neither be too strict nor too permissive.
Funnels are filters which collect data about Event transitions. A simple funnel is an Event sequence which contains two Events. A Funnel’s output tells us how many times an Event followed the previous one in sequence.
For example, we have 3 Events (A, B, C). Let’s say, we create a Funnel (Funnel1) that has two Events in order: A -> B. Funnel1 will tell us how many users triggered Event B right after triggering A. If 5 users trigger Event A and after that 3 users trigger B, 2 trigger C, then the Funnel’s output will be: 5 users triggered Event A and 3 triggered B right after, which is 60% of the users.
This can be useful if we want to measure screen navigations. Funnels can tell us how many users actually clicked the “Order” button after browsing their cart. You can tell if the user quits your application without doing anything.
When you create a Funnel, you have to give it a name and select at least 2 Events. A Funnel can have more than 2 Events and it can also have a description.
Below you can see a Funnel. It measures the transition between “first_open” and “EVENT”. You can filter your data if you want and the Date Picker is present on this page too.
As mentioned previously, a user can have User Properties. These properties can be set on the User Properties page. A property has a name and can have a description. A property will be tracked if you add it to Analytics.
I want to point out again, that currently there is no way to delete a User Property after it has been initialized. You can have 25 properties so watch out for typos!
If you want to see real-time stats about your userbase, you should check out the StreamView page. Here you can see a map, some general information and stats about users and Events. The map will show you where the users are located. Keep in mind that the larger your user base, the higher the chances you can see something in a given minute here, as the information comes in packages. The Event packages have a delay. The more packages delivered, the more “real-time” this view is.
In the bottom left corner, you can see two tabs: “Users”, “Events”. These views show you the active user count and the triggered event count in the last 30 minutes. Also, if you hover on them, you can select the “Trending” and the “Timeline Details” options.
The “Timeline Details” option shows you how these counts changed over the last 30 minutes.
The “Trending” option gives you general information about the Events and users in this time interval. If you open this view from the “Users” tab, it will show you the User Properties with their count and occurrence percentages.
By opening this from the “Events” tab, you can find out similar statistics about the Event Parameters.
If you are interested in the current state of your application, I recommend viewing this page first. It’s not always “real time” but it can give you a good idea about what is happening in your app. Maybe everybody is receiving errors or buying your latest product. You can even find out if somebody hacked your application and uses it from another country. Who knows what could have happened to it?!
The last page we will be looking at is the Dashboard. If you want general information about the performance of your app you will find it here. The Date Picker can be found in the top right corner. Some views have already been discussed, like the “StreamView”, “Active uses”, “What is your audience like?”.
There are a few things that we haven’t talked about regarding the Events. There are automatically collected Events like the “first_open” or the “screen_view”. These Events are managed differently.
For example, the “Where are your users engaged?” view shows you which Activities are visited the most and how much time users usually spend there. You can see that it has an “average time” Parameter, which wouldn’t be available with custom Events.
Analytics also has built-in Events. These Events are: “search”, “add_to_cart”, “level_up”, etc. The usage of these Events is recommended because Analytics can handle them better, and in different ways. For example, the statistics of the “level_up” Event will be visible as a horizontal bar chart on your Dashboard. I think you get the idea.
Sidenote: There is no way for you to customize your Dashboard at the moment.
Big Query and Final Thoughts
Big Query for Analytics
Google Analytics for Firebase is a great free analytics solution, but it has its limits. It would be better if we could send raw data to a server and process it ourselves. It would also be great if the data could be processed real time, without the need to wait a full day. Google has a solution for this.
It is called Big Query. It allows you to send raw data to a server, and you can filter it your own way. Think of these Events and Parameters as Jsons. Events will be converted to tables, rows, columns and values. With Big Query you can run SQL queries on this database. Using this, you can get any kind of data out of your Events. You can create a custom query for anything. Makes life a lot easier.
But Big Query is not free.
For a smaller project Google Analytics for Firebase is enough on its own, but when it comes to bigger apps with many trackable Events and a greater need for feedback, you should consider using Big Query.
Google Analytics for Firebase is a simple and easy solution for tracking apps and user interactions. If you have a project which uses Firebase, some Events will be automatically recorded. Funnels and Audiences can give you a hint on the functionality you should add to your app. Tracking your users based on location, gender, OS or device can come in handy in some scenarios.
Because of the limited number of User Parameters, starting a project definitely requires planning. The “delayed upload of Events” makes it harder to test some functions. Big Query will be a “must” for any larger project.
I think Google Analytics for Firebase is pretty good in many ways and I’ll certainly use it in the future
It’s also free. Give it a go, why not?
We wrote this post at Wanari, a custom software development company from Budapest. Don’t forget to follow us on LinkedIn or like us on Facebook if you are interested in the up and coming tech blog posts like this.
Got feedback? Share your experiences with Google Analytics & Firebase in the comment section!