No rocket science here. The Firebase documentation does a good job at outlining how to integrate Firebase into your project. For Android, after creating a Firebase project and adding an app, the Firebase console generates a

google-services.json

file for you. Note that if the app you’re developing has multiple application id’s (if different build variants have

applicationIdSuffix

set up in android), you will have to add an app for each id that your app uses. 

Also of note is that you need a Google Analytics account to connect to the Firebase project to enable analytics. I like to make two Firebase projects for each app: one for development and debugging and one for production. I make a dummy GA account to connect to the dev accounts, once the analytics had passed QA and everything is up to scratch on the development account, I connect the clients GA account to a new, production Firebase project and reconfigure the app with that project (you simply have to replace the

google-services.json

files with the ones generated by the new production Firebase project). That way any defects in the development project don’t pollute the production account -- a typo in an event name for example.

Connecting the production Firebase account to the client’s GA account is important because it allows them to see the Firebase data both in the Firebase console AND in their GA console as well as an App + Web property.

See below for how to route different build variants to different firebase accounts.

If you have used Google Analytics before, you will be familiar with how events are divided into categories, actions and labels. Firebase has no concept of categories, actions and labels. Instead, you just have the events name and its custom parameters. Note that both event names and custom parameter names cannot contain any spaces, and you are limited to  25 custom parameters per event AND/OR 100 in the project (50 text parameters and 50 number parameters). There’s also a maximum of 500 events per project.

For this reason, moving an app from Google Analytics to Firebase might require some restructuring of the analytics strategy. Many times, you can concatenate the GA category, action and label to get your event name (e.g GA event

{category: App, action: Launch, label: Initial}

becomes firebase event

AppLaunchInitial

). For some GA events, it may make more sense to combine them into one Firebase event. For example, if you have an event

{category: Store, action: Purchase, Label: <id of store item>}

, it would make sense to have a Firebase event

StorePurchase

and instead using a custom parameter

ItemId

associated with that event.

The Firebase blog gives more guidance on how you might do the translation: https://firebase.googleblog.com/2017/02/how-do-i-add-firebase-analytics-to-app.html?m=1

There’s a couple ways to configure analytics for different build variants in Android. If you have

applicatoinIdSuffix

’s for your uat and dev product flavours, then you can just register each flavour as a separate app with their respective

applicationId

and then filter by app in the Firebase console. For the reasons outlined above, however, it might be preferred to have a separate Firebase project for development and production. You can do this by putting the

google-services.json

files from the development account in your development and uat source sets and your production

google-services.json

file in the production source set. This firebase blog article does a really good job of outlining the different ways you can configure your builds with Firebase.

Firebase provides a useful ‘debug view’ to test that your events are coming through. You need to follow these instructions in the documentation and then you can see the events appear in real time in the debug view of the Firebase console.