Track your App Events using Firebase Analytics

Glitch
5 min readJun 22, 2021

Analytics is one of the important tools that developers should definitely used while building their applications. It is very helpful to target your apps for various audience ranges and to track on which screen the users are spending a long time. So it is one of the important features which one should not miss adding while building any Android Application. Firebase is one of the famous online platforms, a product of Google that offers analytics services for free. This analytics can be integrated inside our app along with Firebase and you can get to see the events of your application and track your audiences very easily. In this article, we will be integrating Google Analytics inside our Android application.

What are the benefits of using Firebase Analytics?

  • Google Analytics provides unlimited reporting with up to 500 different events.
  • With the help of Google analytics, you can define custom audiences based on device data, and custom properties.

Automatically Collected Events

Automatically collected events are triggered by basic interactions with your app. As long as you use the Firebase SDK, you don’t need to write any additional code to collect these events. Below is the list of the event collected automatically.

first_open

when a user opens the app for the first time.

This event is not triggered when a user downloads the app onto a device, but instead when he or she first uses it. To see raw download numbers, look in Google Play Developer Console or iTunesConnect.

in_app_purchase

when a user completes an in-app purchase that is processed by the App Store on iTunes or Google Play. The product ID, product name, currency, and quantity are passed as parameters.

This event is triggered only by versions of your app that include the Firebase SDK. Also, subscription revenue, paid app-purchase revenue, and refunds are not automatically tracked, and so your reported revenue may differ from the values you see in the Google Play Developer Console.

user_engagement

periodically, while the app is in the foreground.session_startwhen a user engages the app for more than the minimum session duration.app_updatewhen the app is updated to a new version and launched again. The previous app version id is passed as a parameter.

app_update

varies from Daily upgrades by device, which is reported by Google Play Developer Console whether or not the app is launched again after the update.

app_remove

when an application package is removed or “uninstalled” from an Android device.

This event is different from the Daily uninstalls by device and Daily uninstalls by user metrics, which are both reported by Google Play Developer Console.

The app_remove

event counts the removal of application packages, regardless of the installation source, and the count changes depending on the date range you are using for the report. The Daily uninstalls by device and Daily uninstalls by user metrics count the removal of application packages only when installed from Google Play and are reported daily.

os_update

when the device operating system is updated to a new version. The previous operating system version id is passed as a parameter.

app_clear_data

when the user resets/clears the app data, removing all settings and sign-in data.

app_exception

when the app crashes or throws an exception.

notification_foreground

when a notification sent by Firebase Cloud Messaging is received while the app is in the foreground.

notification_receive

when a notification sent by Firebase Cloud Messaging is received by a device when the app is in the background. Android apps only.

notification_open

when a user opens a notification sent by Firebase Cloud Messaging.

notification_dismiss

when a user dismisses a notification sent by Firebase Cloud Messaging. Android apps only.

dynamic_link_first_open

when a user opens the app for the first time via a dynamic link. iOS app only.

dynamic_link_app_open

when a user opens the app via a dynamic link. iOS apps only.

dynamic_link_app_update

when the app is updated to a new version via a dynamic link. iOS apps only.

Automatically Collected User Properties

Firebase automatically collects user properties, such as App version, Device model, Gender, Age, Interests, OS version, and New/Established. This information can be seen on the dashboard directly without writing any additional code.

The Steps

Install the Firebase Analytics SDK in our project, then declare the FirebaseAnalytics objects in our Application class (or Activity) and initialize it in the respective onCreate method. And that is all regarding the configuration:

  1. Dependency in app’s build.Gradle
implementation “com.google.firebase:firebase-core:16.0.1”

2. FirebaseAnalytics object:

private static FirebaseAnalytics firebaseAnalytics; (Java)
private lateinit var firebaseAnalytics: FirebaseAnalytics (Kotlin)

3. Getting the instance in onCreate (also you can make it available through a getter xD):

firebaseAnalytics = FirebaseAnalytics.getInstance(this); (Java)
firebaseAnalytics = FirebaseAnalytics.getInstance(this) (Kotlin)

A second step, after the SDK is installed and the instance is gotten, is to Log the events we’d need to track. Then we can either define a Helper class available for your project and define the methods which will track the data or you can locally on each screen do the tracking as you need it. It’s your choice. For example, we need to track every login event within the app:

JAVA

Bundle bundle = new Bundle();
bundle.putString(Param.USERNAME.name(), username);
firebaseAnalytics.logEvent(EventType.LOGIN.name(), bundle);

KOTLIN

val bundle = Bundle()
bundle.putString(FirebaseAnalytics.Param.ITEM_NAME, tvShow.name)
firebaseAnalytics?.logEvent(FirebaseAnalytics.Event.LOGIN.name(), bundle)

Two things to highlight: LogEvent method receives the Key-Value pair as params, where the key is a string identifying the bundle (String key — String value) set as the value.
Let’s see in Kotlin code, that if we are only performing simple tracking, then the predefined events and params should cover our needs. On the other hand, using custom event and param names, such as in Java code, allows us to track events that are specific to our app and will allow for a deeper analytical understanding when it comes to the reports created from our tracking.

Also take into consideration that we can add as many parameters as we need/want, depending on our needs, and if we don’t see anything on the console right away, just be patient, it takes around 24 hours to refresh all the events.

As a last interesting subject, user properties come into action. User properties allow us to track data that is specific to the users who are engaging with our app. This allows us to keep a track of data that is not specifically associated with our application itself but more focused on the users. Just like events, the Firebase SDK automatically tracks a collection of different user properties for use.

That’s it. Keep Coding!!

--

--