Choosing Between Firebase and Google Analytics SDKs for App Tracking/
February 20, 2018
“Should we be using Firebase or Google Analytics?” – we get this question a lot regarding tracking behavior in mobile apps.
Even though the older Google Analytics mobile SDKs have officially been deprecated by Google and the analytics reports in Firebase have been rebranded to “Google Analytics for Firebase,” there is still a lot of confusion out there as to which analytics tool is the right one for the job.
The Google Analytics mobile SDKs are technically still supported, and offer traditional reporting methods you’re more likely to be familiar with – but Google Analytics for Firebase has a lot to offer as well, and is considered to be the future of mobile app tracking.
This post aims to help clarify the important differences between the two and provide some suggestions around using each platform. For the sake of simplicity, I’m going to refer to Google Analytics for Firebase as simply Firebase, and the Google Analytics SDK as Google Analytics.
Let’s start out with some big-picture differences between the two, in no particular order.
1. Mobile Dev Platform vs Analytics-Specific Tool
The Firebase SDK is actually a mobile development platform, not just a standalone analytics tool. I have brought this up before, but it is important to understand that the analytics reports are just one set of tools in the Firebase platform, designed to integrate with other Firebase tools – such as Cloud Messaging, Cloud Functions, Remote Config, etc.
This is one of the biggest ‘pros’ of Firebase as it allows for very useful integrations with other Firebase products. The new opportunities that these integrations present are essentially why the older Google Analytics SDKs have been deprecated. Here are a few examples:
- Send a user a notification after a certain analytics event has been triggered in the app
- Customize an experience in the app using Remote Config based on certain activities (analytics events) in the app
- Perform A/B testing with Optimize & Remote Config
- Improve campaign targeting for notifications by using Firebase Predictions, which applies machine learning to help you understand user behavior and create audience groups (also based on analytics events)
With Firebase, your event logging works harder for you by helping you take advantage of a lot of these other great features.
Google Analytics, on the other hand, is a part of a marketing suite of tools in the Google Marketing Platform. There are some significant integrations there as well, but they are primarily geared towards advertising purposes, such as audience sharing. Firebase takes integrations much farther – check out the available products here.
I think it’s also worth noting that Firebase has partnered with a lot more mobile ad networks than the more traditional Google Analytics for mobile apps has. There are currently 60 ad networks that have agreed to share campaign attribution data for you, along with integrations with products in the Google Marketing Platform, making that process much easier than it has been in the past.
2. Unlimited Event Logging Volume vs GA Hit Volume Limits/Costs
Firebase has NO LIMIT to the volume of events you can log. There are limits to the varieties of event names (up to 500 total), but as of now there are no fees for using Firebase for analytics, specifically.
Note that you can also take advantage of a lot of other Firebase products for free as well. A couple great examples of these include Crashlytics and Dynamic Links in particular can help you easily add further insight into campaign attribution for non-supported ad networks, which is a big deal for any marketer looking to understand the performance of their mobile campaigns!
There are some limitations around the types of parameters you can attach to Firebase events and what you can see in the reports, which differ greatly from the Google Analytics SDK data collection. You will want to be sure that you are aware of these differences before switching to Firebase (see section 4).
Which leads me to my next point…
No fees = no support. If an SLA is important to you, you’re out of luck with Google Analytics for Firebase as of now. If you are a Google Analytics 360 customer, you likely receive support for all properties, regardless of whether they contain web or app data.
That said, there are some resources available out there if you do need help with your Firebase implementation. There is actually a great post about this topic on the Firebase Blog. Additionally, the documentation and help center articles have come a long way and cover a lot of detail.
4. Reporting and the Data Models
Firebase uses an event-based data model, which results in reporting differences compared to those in Google Analytics. Unlike Google Analytics which has many screenview- and session-oriented reports, in Firebase all reports are user- or event-focused. The concept of a ‘session’ as we know it in Google Analytics does not exist within Firebase.
In some ways, this can be a good thing – users interact with apps differently than they do websites, and Firebase is designed with that in mind. Honestly, the more I explore these differences and the impacts they have on the resulting reporting, the more I prefer Firebase over the more web-oriented Google Analytics model. Apart from that, many apps do not really have a strong emphasis on ‘pages’ or ‘screens’ and instead revolve around activities the user can complete. Firebase is ideal for this, yet certain businesses, such as publishers for example, might find it a little more challenging to work with or require some getting used to. Additionally, the fact that the session is cut out of the data model entirely in Firebase can make it easier to work with in BigQuery, for example. All of these are significant differences and require some thought prior to making a decision on which tool to use.
Additionally, there are different schemas for event tracking in Firebase compared to Google Analytics. With Google Analytics, you can send different types of hits – screenviews and events, for example. Google Analytics events are made up of a few key parameters: event category, event action, and event label (plus a couple others, but they aren’t relevant for this discussion). With Firebase, the schema is different – everything is an event (even screenviews are just events) and the schema looks like this instead: event name, plus up to 25 additional key-value pairs of parameters that you can set to add context to the event. That’s a lot more available params than a traditional event hit with Google Analytics. The downside is that you will not see all of this data in the interface by default – you have to go into the Firebase console and “register” them to have them appear in your reports, and you can only register up to 50 custom event parameters per project (40 numeric, 10 text). The data is included in the BigQuery export if you have that enabled though. Make sure you keep this in mind when you plan out your reporting needs prior to implementation.
There are some other considerations as well, such as custom dimensions in Google Analytics – these can be user-, session-, hit- or product-scoped. You can set up to 20 of them for the free version of Google Analytics, or 200 for the 360/enterprise version of Google Analytics. In Firebase, your options are to either use custom parameters attached to events to hold custom data (up to 25, as I mentioned above) or set up user properties. User properties are similar to user-scoped dimensions in Google Analytics, where values set for a given user will automatically persist in all future interactions associated with that user. You have a limit in Firebase of up to 25 user properties per Firebase project (not app).
Because of these significant differences, I highly advise that you plan out your app tracking implementation thoroughly prior to actually setting it up, especially if you do go with Firebase.
There are also a lot of differences in the reporting options between these two tools, such as:
- No ability to create custom reports or dashboards in the Firebase interface
- Limited amount of event parameters (50) can be seen in Firebase reports (plus you have to register them in order to see any, they don’t just appear in your reports). Plus, only ten of those can be text.
- Limit of 15 custom conversion events in Firebase per project (compared to 20 goals per view in legacy Google Analytics for apps)
- Lack of more granular reporting around ‘sessions where certain activities occurred’ in Firebase – this also poses challenges for audience segmentation and retargeting based on session-specific behavior, as is common with Google Analytics
To learn more about the reporting differences between Firebase & Google Analytics, check out my earlier post:
Published: October 12, 2017
Please review this extra carefully if you plan on switching to Firebase 🙂
5. Rolling Up Your Data
In the past, if you had both an iOS and an Android version of your app, the two would be tracked separately for Firebase. This is no longer the case, so I wanted to point this out. Data is now at the project level, not app level, so while you can see data for a specific platform (called a ‘stream’) in Firebase, it is rolled up into one data set now. This means you can see overall metrics such as users across all of the apps in a Firebase project. This is true for the Firebase interface as well as the BigQuery export (this was a recent update).
With Google Analytics, you may choose to send your iOS data to the same or a different property than your Android data, for example. Or you could even send it to the same property as your website traffic, though we don’t usually recommend that. So you have a little more flexibility in the interface with Google Analytics, but those who are using BigQuery won’t find this to be a major issue for Firebase anymore.