Choosing Between Firebase and Google Analytics SDKs for App Tracking

/


“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.

Primary Differences

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…

3. SLA?

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:

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.

6. Platform Support

Currently, Google Analytics for Firebase is available for iOS, Android, C++ and Unity, specifically – take a look at the documentation here. This support covers most platforms, but not quite all of them.

Consider OTT or “over the top” apps like Amazon Fire TV or Apple TV, for example. Many of these platforms can be configured for iOS or Android, for example, which Firebase supports. But if you’re working with Roku or Adobe AIR, for example, I’m not sure how much luck you’ll have. Roku, for example, uses its own proprietary software and there is no way that I know of to implement Firebase there.

Google Analytics on the other hand offers a measurement protocol, making it more flexible than Firebase for these situations. Be sure to talk with your development team about this before getting your heart set on anything.

Note: There are certain Firebase products designed for the web (HTML/JS) as well, but analytics is not currently a part of those offerings.

Still Not Sure?

If you’re still not sure which is the right tool for you, I suggest that you start by creating a game plan – outline each activity in your app and various user-related properties you may want to track for analysis purposes. Think about the data you will want and what type of reports you will need. The more you can start to plan for the analysis, the better idea you’ll have on what you’ll need out of your app tracking tool.

If you’re already using the GA SDK in your app, find out how the data you’re collecting could map to the Firebase data model – will it work well? How many custom dimensions are you currently using and how will you collect those with Firebase event parameters or user properties? Make a list of what you’ll need and that will help you understand the level of effort required to make the switch. Also, make note of any existing reporting infrastructure and how much of that will need to be updated to use Firebase data instead.

Some additional considerations:

Make sure you talk with your dev team about your particular apps – make sure there is support for them if you want to try Firebase and find out if any of your apps already have tracking set up with the GA SDK, for example. Switching to the Firebase event logging schema would require some work.

Consider whether you may have a need or interest for other Firebase products, even down the road – take a look at the offerings here (many of them are free). Firebase products are designed to be used together, such as to:

  • send a user a notification with Cloud Messaging to encourage them to re-engage with your app
  • customize an experience in the app using Remote Config based on certain events or actions the user takes in the app
  • perform A/B testing with Remote Config
  • create dynamic user audience lists based on Predictions and machine learning

If you are BigQuery-savvy, or don’t mind doing some additional reporting within Data Studio, I would especially encourage you to give Firebase a shot – the opportunities there are super exciting!

I also want to re-iterate how important it is to have a solid strategy in place before getting into implementation. Even if you are not ready to use Firebase right now, or if you already have the GA SDK installed in your app, it still is worth the effort to map out exactly what matters to you in your app (and how it is being tracked currently). If you do decide to switch to Firebase down the road, it will be a much easier process to consider the changes that would need to be made to map the data points to the appropriate fields for Firebase with this groundwork already complete. This all probably sounds like common sense, but believe me – it’s not very common!

A Little of Both Worlds

There are a lot of benefits to each platform, so why not take advantage of both? We often do just that.

By installing the Firebase SDK and the Google Tag Manager SDK, you can start collecting data in both the Google Analytics for Firebase reports as well as in Google Analytics (no GA SDK needed). This can be very helpful for a number of reasons:

  • Maybe you’re not yet comfortable with the reports in Firebase, so you want to have Google Analytics as your ‘back up’ for reporting purposes while you warm up to the event-based data model in Firebase
  • Maybe the reports you want (custom ones, for example) are simply not yet available in Firebase
  • Maybe you want an easy way to roll up your app & web data to get aggregate totals more easily

Let me be clear that this is a nice temporary solution – not a great long-term plan. Think of it as a short-term option to help your team get most* of the standard reporting they are used to from Google Analytics (with the added benefit of the customization options available in Google Analytics, where Firebase lacks), while working on transitioning to relying solely on Firebase.

*There are a few reasons why I believe this should only be a temporary solution. First, the data will not line up 1:1 between Firebase and Google Analytics – they are simply two totally different tools (you’ll find yourself comparing the data, which usually doesn’t make sense). Second, the significant differences in the data models of these two tools result in significant challenges in campaign attribution. You’re simply not going to be able to accurately send your campaign data from Firebase to Google Analytics (not without some serious hacking, and at that point the situation becomes arguably worse). The primary reason for this has to do with how Google Analytics handles sessionization (and how Firebase doesn’t care about that at all). Third, the two tools offer entirely different perspectives on app user behavior. The lack of a Google Analytics-like ‘session’ concept in Firebase should encourage you to think about app behavior differently, whereas Google Analytics boxes you in to this more traditional expectation from web behavior that often just doesn’t make sense with a mobile application.

Because of these issues, you will likely end up using certain reports out of Google Analytics while you become more comfortable with Firebase, for example. We could talk more about this topic overall, but these are a few of my top reasons for using this approach as a temporary solution to shifting to Firebase strategically, while still getting the reporting interface you’re familiar with out of Google Analytics in the meantime. I’d love to hear your thoughts in the comments about this!

To further simplify the options, here is a table of what you need based on where you want to do your reporting:

If you want reports in: You should install:
Firebase Firebase SDK
Google Analytics GA SDK OR GTM SDK
BOTH Firebase & Google Analytics Firebase SDK + GTM SDK

Amanda Schroeder is a Senior Consultant and comes from the marketing industry where she found a need for accurate, insightful data that could aid in making results-driven decisions. Amanda’s passion for building solid measurement strategies and connecting all the pieces of integrated digital and traditional marketing campaigns has led her to her current role at LunaMetrics.

  • John Wedderburn

    Hi! I’ve currently got a discussion going with the developers working on an app for the organisation I work for. There’s some concerns about development time – which in your opinion is quicker (or least complex) to implement – Firebase or legacy SDK? Thanks very much!

    • Marius Gold

      Least complex for me would be Firebase as there is plenty of videos and support online. But Firebase reports are quite difficult to read and the interface lacks a lot of features that GA has. So i would go for GA SDK if the reports will be consulted by beginners but Firebase SDK if the end users are expert (or understand the data model of Firebase)

  • bluepanda

    As far as I understand, you can only use either one or there’ll be versions conflicts.

    Edit: Oh I didn’t see you weren’t using the GA SDK, my bad.

    • Marius Gold

      You can actually use both but it will mean double tracking for you in your app… It’s funny to test but clearly hard to integrate & maintain for developers

  • Marius Gold

    Hey Amanda! Great article on the subject. I currently use Firebase SDK + GTM SDK but I can notice some differences between the numbers of events or screenviews in the Firebase vs GA reports (about 5 to 20% sometimes). What can be the causes of this phenomenon ? Thanks again for the article

    • Amanda

      Hi Marius,

      Usually the issue has to do with the two tools being tracked slightly differently, in my experience. I’ve even seen cases where the Google Analytics tags were only set up for Android, not also for iOS, for example (even though we were told both were set up identically). Sorry for the late response, been busy writing some new Firebase posts 🙂

  • Jerry Books

    I wanted to share my experience with selecting a mobile backend for my app.So, I used to run my applications (I have several in the app store(s)) on Parse and was pretty happy with the backend until Facebook decided to shut down the service. After that I have evaluated all listed options and was not happy with any of them for various reasons. Firebase was not a good fit because the of their approach with JSON document being a database – I did a stress test with million nodes in the tree and the service was not performing well. AWS and Appery are quite complex and become expensive very quickly while Azure and built.io are quite limited in the capabilities. Kinvey is both limited and super expensive once you start doing something more serious in the app. In the end I chose Backendless (https://backendless.com) for my backend. The service has native SDKs for all major mobile and web platforms. The usability and developer experience is by far the best I have seen. The service has an extremely flexible server-side code model where I can deploy Java and JS server-side code to override default handling of the API and to create my own API services. My apps leverage social (Facebook, Twitter, Google) login, geolocation, file upload/download, push notifications (iOS, Android) and of course data persistence, which has really awesome support for complex relations. Check it out if you are looking for a flexible and very reasonably priced backend.

  • J.Chamberlain

    I have a question that I’m hoping someone can help me answer. My client has an app that is being developed in Firebase. The team in India is not up to date on proper analytics set up so that task/decision has fallen to me. I see that Firebase can be added to GA as one property (and then you can filter iOS and Android via the streams). This makes sense to me. I can see the benefit of having it set up this way. The team in India added a property which generated a UA number for the Android app. They attempted to add a second property for iOS and GA wont let them. When indicating that the property is an “app”, GA is forcing you to connect to Firebase. Instead of digging into the issue, the team in India created an entirely separate GA account so that it could create a one-off UA property for iOS. This made my brain want to explode. Obviously creating an entirely separate GA account cant be the way to go? I know things are rapidly changing. The fact that GA will not let us create an additional UA property for each app…and is forcing the Firebase property means something, right? Are we missing something? Is there a way to create two UA properties under one account for an Android and iOS. Per this articles suggestion I would like to temporarily run GA and Furebase analytics to compare and contrast. Can someone tell me how I can add a second UA property for my iOS without creating an entirely new GA account to do so?

    • Amanda

      Hi J,

      Yes, Google is encouraging folks to use Firebase when attempting to track mobile apps. The process is typically that you go into the Google Analytics interface, try to create a new property for your mobile app data, and you see the instructions to set up Firebase. If you go this route, you will be working with Google Analytics for Firebase (formerly known as simply Firebase Analytics). This is an entirely different perspective on app tracking and an entirely different data model from that of the typical Google Analytics property.

      This also means that any data you see in this ‘property’ in Google Analytics will be Firebase data – you’ll see the Firebase logo when you view the Property Settings and there will be no “UA” number/tracking ID for this property.

      Assuming you have configured your Firebase project to be installed on both an iOS and an Android app, you will receive data for both in the Google Analytics interface as well. The reports will literally match those of the Firebase project (if you were to log in to your Firebase project from the Firebase console at console.firebase.google.com, the reports under Analytics in that interface are the ones that are essentially ported over to your new Google Analytics property. You will be able to filter by stream/platform. The idea is that your analytics/marketing teams do not need to worry about dealing with the Firebase console – they can just stay in the Google Analytics interface for reporting needs.

      There is no reason to create a separate account – in fact, you technically are supposed to link one Firebase project to one Google Analytics property. To be clear, a Firebase project typically includes both your iOS and your Android app (it usually includes each variation of your app by platform and can also contain your test environment apps as well, which would be considered additional ‘streams’). Your developers set up this Firebase project for you during the install process.

      Alternatively, it is still possible to create a new account and add a mobile property the ‘old school’ way – this would allow you to use the more traditional Google Analytics property (which comes with its own UA number/tracking ID and would typically utilize the deprecated GA SDKs rather than Firebase. You could also create a web property (again, it would come with its own UA number/tracking ID) to send data to via the deprecated GA SDKs. It sounds as though this is NOT what you want, however – as you are in the process of installing Firebase.

      I hope this helps!

      • Jillian Chamberlain

        https://uploads.disquscdn.com/images/fb15f40708493b40cb5517b4fb51d83f77f6bb1f0f856d6e21a17c2544851590.png
        Hi Amanda,
        Thank you for the quick response! Yes, I envision using the Firebase analytics as the ideal situation. And yes, the Firebase project has been added as a property so that other people who need to view analytics do not need to log into the Firebase console to see the analytics, they can do so via GA dashboard. The issue that I am still running into is that I want to run both “old school” GA analytics and Firebase analytics temporarily. However GA will not let me add another “old school” UA property to the account. To recap I set up a GA account. We added an app property for Android that generated a UA number, then when we attempted to add a iOS property to the same account it would ONLY let us add the Firebase project. So currently I have a UA property for Android and one Firebase project (for iOS and Android). How can I add one more “old school” property for iOS? The GA interface is only giving me the option to add another Firebase project (see screenshot)

        • Amanda

          Right, if you create a new account that is the only way currently to create a mobile app property the old school way.

          You will need to either create a web property in the same account or create a different account and new mobile app property. You should be able to move the new property to your earlier account though. Either way, you can have mobile app views.

          • Amanda

            Also note that comparing the Firebase data to the Google Analytics data is not an apples to apples comparison. There are many major differences between the two.

  • Carlo Gilieri

    Hi,
    what about the possibility to use, on GA, the advanced segmentation? As far as I know there isn’t this possibility on Firebase, or better, not so complete and advanced
    Thanks

    • Amanda

      Right, one of the reporting limitations is that the segmentation capabilities are not on par with Google Analytics. While you can build audience segments, they are not retroactive – meaning they only work from the date you create them moving forward, unlike segments in Google Analytics which are retroactive.

      • Carlo Gilieri

        I think it’s a big limit. It is a back step. The GA segmentation makes you able to do deep analysis when you find something strange in the data. Is not always possible setting everything at the project starting. It seems when, some years ago, we had to work with GA filters without the segments.

        Many thanks for your answer!
        Best!
        Carlo

        • Amanda

          Right, if you’re not linking your Firebase data to BigQuery, you’re really out of luck with the reporting options in the Firebase interface, unfortunately.

          • Carlo Gilieri

            yes, it’s so…. 🙁

Contact Us.

Follow Us

1.877.220.LUNA

1.412.381.5500

getinfo@lunametrics.com

Questions?
We'll get back to you
in ONE business day.
Our Locations
THE FOUNDRY [map] LunaMetrics

24 S. 18th Street
Suite 100

Pittsburgh, PA 15203

THE STUDIO [map]

4115 N. Ravenswood
Suite 101
Chicago, IL 60613

THE LODGE [map]

2100 Manchester Rd.
Building C, Suite 1750
Wheaton, IL 60187