Freelancing for Pale Blue

Looking for flexible work opportunities that fit your schedule?

Firebase Analytics quick start

Android Jun 21, 2020

When building a new app, it's quite common for the creator to be excited. In his head, the user is always happy and knows exactly where to go to use the app as it was designed to be used.

Unfortunately, this is not true most of the time.

You thought that how to use your app is obvious. Probably, it's not.

The only way to verify that the app is used as you intended, is to instrument your app with analytics. But what and how do you log?

There are many mobile analytics solutions out there. One of the most popular  is Firebase Analytics. It's free and provides a quite comprehensive solution. I will cover the basics on how to use it, but check out the documentation for advanced use cases.

Set up

Setting up Firebase Analytics is quite straightforward. You need the core Firebase dependency in your project, and then adding the Analytics dependency:

implementation ''

Log screen views

As soon as you include the Analytics dependency and run your app, some basic events will be recorded automatically. This includes screen views, with a small caveat.

Screen views are logged automatically only if you are using the "one activity per screen" architecture. If you are using a single activity and you are switching fragments (or views) using a library (e.g. using Jetpack Navigation), then you need to track the screens manually.

A common approach is to call the screen tracking method, passing the fragment class name as the screen name on onResume(). If you  have a base fragment class, placing this call in there might be convenient.

private val firebaseAnalytics = FirebaseAnalytics.getInstance(context)


override fun onResume() {
        /* screenName= */ this::class.simpleName.toString(), 
        /* screenClass= */ this::class.simpleName.toString()

Log events

I always start with a hypothesis that a user will use a certain feature in a certain way. Then I try to log specific events to verify that assumption.

The alternative way of blindly logging anything that can be logged, sometimes might yield useful results and uncover unexpected usage patterns, but most of the times will result in just a lot of noise that will hide even the useful conclusions.

So take some time to think what you are trying to uncover with your analytics.

What I usually do is create an enum with all the events I have in my app. Events are just strings, so I want to be sure that no typo will create separate events, no matter how simple the event name.

enum class AnalyticsEvent {


firebaseAnalytics.logEvent(, null)

There is no need to always create your event. Firebase provides some recommended events that you can use. Check the list out before creating your own.

Each event can have a map of key-values that you can add additional details for the event.

enum class AnalyticsParam {


firebaseAnalytics.logEvent( {
    param(AnalyticsParam.TYPE, "image")

Again, there are some recommended parameters predefined in Firebase that you can use before creating your own.

Debug stream

Before releasing your app, make sure to test your instrumentation. Firebase usually does not send the events immediately. Rather it sends them in batches periodically for minimizing battery and network usage.

When developing you can enable a mode that events are sent as soon as they are recorded. You can even see them live in the "Debug View" in the Firebase dashboard.

adb shell setprop package_name
Enable debug mode
adb shell setprop .none.
Disable debug mode

Hopefully by now, you have instrumented your app for the basic events you want to track. Next (optional) steps are to set user ids or set user properties.


Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.