Google Analytics vs. Firebase Analytics vs. Google Analytics

A Guide for the Slightly Confused

Update! As of October 2020, Google Analytics, the New Hotness Edition has officially been renamed to Google Analytics 4. Which makes things a whole lot clearer.

tl;dr: Google Analytics for Firebase, formerly Firebase Analytics, is now known as Google Analytics. It works great for your mobile apps! Oh, but Google Analytics for Mobile has been deprecated; they recommend you use Firebase Analytics, which, as you’ll recall, is now Google Analytics. In recent news, you’ll be excited to hear that Google Analytics now supports web apps, but don’t confuse that with Google Analytics for the web!

What? You’re still confused? Okay, let’s back up a little bit.

Google Analytics, Classic Edition

The year was 2005. Leeroy Jenkins was learning a valuable lesson about charging into battle unprepared, a young Fergie was extolling the virtues of her humps to a weary nation, and I thought that bleaching the tips of my hair was a smart fashion move for some reason. Amongst all of these other trends, Google announced a new product known as Google Analytics.

As it turns out, GA was really useful as an analytics tool for figuring out how your web site was performing. You could use it to track referral traffic, find out what pages your users were spending the most time on, where they were leaving, and a whole lot more. It’s been around since 2005, and many websites are happily using it today.

Now, for the sake of this blog post, let’s refer to this as Google Analytics Classic. No, that’s not its official name, but that’s probably a good way to think about it; it’s a classic tool that’s been around a while, people still dig it, and it’s aged considerably better than my frosted tips.

Google Analytics, Shoehorn Edition

But somewhere along the way, people started making apps. And it turns out when you’re making an app, it’s also important to know how people are interacting with it, which ad campaigns are giving you the right kinds of users, and where your users need the most help. You know, the kinds of things an analytics tool could help you with.

So the analytics team went and created the Google Analytics for Mobile SDKs. These were libraries for iOS and Android that allowed you to record events that happened inside your app with Google Analytics Classic.

The problem was that these new client SDKs still communicated with a backend that was primarily designed for processing web traffic data. But most of your app activity isn’t really about navigating from page to page, worrying about bounce rates, or knowing what search terms brought people into your app. So while the backend did start supporting arbitrary events in addition to page views, they always felt a little shoehorned in.

I won’t go into too much detail around all the specific issues, since it’s basically a moot point by now. The Google Analytics for Mobile SDKs have been deprecated, and the team is encouraging everybody to move onto the newer SDKs. But just know that if you’ve received any emails about Google Analytics for Mobile being deprecated, this is the version they’re talking about.

Google Analytics, The “You’re Giving Us Money” Edition

One exception to the “GA for Mobile has been deprecated” rule is Google Analytics 360. This is a premium service that is built on top of Google Analytics Classic. It includes a number of advanced features, including custom reports, video analytics, enhanced e-commerce reporting, and more. Additionally, companies who are using the Google Analytics 360 service can continue to use the Google Analytics for Mobile SDKs even though they’ve been deprecated for everybody else.

That said, even if you are a GA 360 customer, I would recommend looking into the new Google Analytics if you’re building a mobile app, because it really does feel more natural. So let’s talk about that.

Firebase Analytics, the “Google Analytics for Firebase, but everybody still calls it Firebase Analytics” Edition

A few years ago, the Google Analytics team took a step back and asked themselves what things might look like if they could start over and design a service that was really centered around apps and the way they behaved, without having to worry about also supporting all of those websites currently using GA Classic.

Their first iteration launched in 2016 as “Firebase Analytics”. Instead of page views and sessions as the main driver of activity within your app, everything was tracked using events and custom user properties.

It was pretty good, and app developers found it more intuitive to work with, although it had a few limitations at first. Audiences were difficult to work with because they weren’t dynamic (once a user joined an audience, they couldn’t leave). You also couldn’t get reports about event parameters, it took a while to view results, and all of the funnels being reported were open funnels instead of closed funnels.

Over the last few years, the team gradually removed a lot of these shortcomings. They added DebugView and StreamView so you could get more real-timey information about your app. They added a Latest Release Report, which let you see how well the latest version of your app was performing. They added custom parameter reports for event parameters, integrated with AdMob, and added automatic screen tracking. They also greatly improved the Audience feature to be much more powerful and dynamic.

Along the way, they changed the official name to Google Analytics for Firebase, as a way to better reflect the fact that underneath the hood, these reports were really being driven by the same folks who brought you Google Analytics. This made for some awkward blog post titles, and I know most of you continued to call it Firebase Analytics, you rebels, you.

Those darned open funnels though? Those were still around.

Google Analytics, The New Hotness Edition

While the backend powering the new GA for Firebase met the needs of the product pretty well, it was put together pretty quickly, and the team knew they’d need to upgrade it after a few years if GA for Firebase was successful as a product. And sure enough, they were right; as GA for Firebase took off in popularity, the Analytics team started running up against some of the limitations of their current infrastructure.

So in 2019, the Analytics team pushed out a pretty significant change. They created a brand new beefier backend that could handle more complex requests while still keeping the “no sampling, supports as many users as you want, no cost to you” requirements of the original infrastructure. Some of the benefits of this newer backend is that you can now generate closed funnel reports (hooray!), you can view reports for different user properties side-by-side in the same graph (double-hooray!), and it’s a lot smarter about how it combines user behavior across different platforms.

But this newer backend is much more tightly tied into infrastructure and services operated by the Google Analytics team. And this explains some of the less intuitive behavior that you might encounter if you’re used to interacting with Analytics as a Firebase product.

For instance, if you want to add Analytics to your Firebase project, your project needs to be associated with a Google Analytics account as a new property (“properties” are what the GA team generally thinks of as projects). And some of those reports I was talking about earlier, like the closed funnels? Those aren’t available directly in the Firebase console. You have to head over to the Google Analytics console to access them.

This also explains why the name was changed from “Google Analytics for Firebase’’ to just “Google Analytics”. It reflects the fact that this latest iteration is powered by Google Analytics, even though, yes, you’re still able to view many of your reports through the Firebase console, and the SDK you’re using is probably named something like FirebaseAnalytics.

Personally, I’m not crazy about this name change — it’s a big upgrade. How about giving it a distinct name, like Google Analytics Premium or 2.0 or something? It’s like when they released the 2018 version of Halloween as just Halloween, even though it was the 11th in the series. Now, when you’re talking about Halloween, you have to be really specific about which version you’re talking about.

That’s why I also suggested renaming the product to Google Analytics: The Michael Myers Is Hiding In Your Closet Edition, but for some reason the marketing team decided that wasn’t consistent with their brand values. Cowards. So I’m going to continue calling this the New Hotness Edition for now.

Update: In October of 2020, the Google Analytics team officially renamed the product to Google Analytics 4. I’m not saying they did this because they read this blog post and heeded my advice, but I’m not saying it didn’t happen, either.

Google Analytics, The New Hotness Edition + Web

This big upgrade also lets us address the web-shaped elephant in the room. See, while it’s true that most apps don’t behave the way websites did in 2005, it’s also true that a lot of websites no longer behave the way they did in 2005, either. You’ve got PWAs that look like apps, and sites like Google Sheets where you can spend hours working on a single document without ever leaving the page. And for a lot of developers, they have websites that so closely mirror the behavior of their apps, it doesn’t really make sense to track them in different systems.

So in October of 2019, the Google Analytics New Hotness Edition team announced a big improvement to GA, which is the ability to track websites using the same backend model that you’re currently using for apps. In other words, one that’s driven primarily by events and users, instead of page views and sessions. This gives web developers the ability to track their websites in a more app-like paradigm, and it lets them take advantage of other Firebase features, like creating audiences that you can target with Firebase Cloud Messaging or Remote Config.

Understanding Google Analytics Terminology as a Firebase User

One other side effect of having the New Hotness Edition more closely tied to Google Analytics is that you will start to see some terminology from the GA side of things sneak into your Firebase projects. Let’s go over a few of these, shall we?

What you think of as a Firebase project is generally known as a property in GA-land. Every project you create in Firebase must be associated with a property in GA, and it’s a 1:1 relationship.

In the same way that you might have iOS, Android, and web versions of your app pointing to the same Firebase project, they will also point to the same GA property. GA refers to these individual apps as streams.

Properties created using Google Analytics Classic are referred to as Web properties, while properties created using the New Hotness Edition are known as Apps and Web properties.

The GA website also lists a third type of property, known as an Apps property, but that is essentially the same thing as the Apps and Web property; it was created before we officially supported the web in the New Hotness Edition and is really just there for historical reasons. I would ignore it if I were you.

A Google Analytics account isn’t an account in the traditional “You need to sign in with a Google account” sense. You can think of it as a folder into which you can place multiple properties. There’s no right or wrong way to organize properties into an account — some developers prefer a “One property per account” rule. Others like to put all of their related apps into the same account. It’s really just a preference thing, so you do you.

What you think of as User Properties in Firebase are known as Dimensions in GA. They allow you to slice and dice your reports by various features of your population. The user properties that you register inside your app via code are known as registered dimensions, while the ones that GA records automatically for you (like device or browser type) are known, appropriately enough, as automatic dimensions. Along those lines, what you call filters in Firebase-land are referred to as comparisons in GA.

To Review…

So let’s review everything we’ve just learned:

Google Analytics for Firebase (formerly Firebase Analytics) is now known as Google Analytics 4, but I still think of it as The New Hotness Edition. It works great for mobile and now the web, too! In the GA world, projects powered by the New Hotness Edition are known as “Apps and Web properties”.

Google Analytics Classic is still around, if you prefer a more classic model of website analytics. In the GA world, projects powered by GA Classic are simply known as “Web properties”

Google Analytics, The Shoehorn Edition, which is the old mobile SDKs talking to GA Classic, is deprecated. You should switch to the New Hotness Edition, unless you’re a GA 360 customer, in which case I still think you should try out the New Hotness Edition, but I guess that’s not a requirement.

So there ya go. Now that you understand the difference between the various flavors of Google Analytics, go give the New Hotness version a try in your latest web or mobile app! The team has made some nice improvements over the last few years, and you’re going to see a lot more exciting features on the horizon.