Last year tons of mobile App owners and developers received an email from Google, which informed us that Google Analytics for Mobile Apps will be deprecated and shut down in the next one and a half year’s time. This will impact any SDKs that collected properties into Google Analytics through the mobile SDK and are not part of the Firebase libraries. If you are a Google Analytics 360 user, you are all safe for now, but maybe a migration plan is advised just for safety.
We want to let you know that in October 2019 we will begin to sunset our Google Analytics for mobile apps reporting and the Google Analytics Services SDK.
Google is trying to focus its resources and also its users on Firebase Analytics, as it’s their new generation solution for mobile app analytics. Sadly, due to the fact that Google Analytics was mostly inspired by the web world, the migration path can cause us a lot of pain. And we are not even talking about Firebase’s parameter and event limitations yet, only the base paradigms. Before we dig down to the “why will this be painful,” let’s see some differences between Google Analytics and Firebase Analytics.
First, Firebase is not an analytics tool, it’s a mobile development platform, containing a growing number of tools for mobile apps on all platforms (like Cloud Messaging, Remote Config, Realtime Database, etc.). Here lies the power of Firebase, because the development platform gives us opportunities to integrate these products with each other, including the Analytics. This will provide some new possibilities for us to reach out to our users and for example:
On the other hand, Google Analytics is part of the marketing suite of tools in the Google Marketing Platform. Most of the customers use this platform for advertising purposes, but it’s worth mentioning that Firebase also has integrations with products in the Google Marketing Platform.
I think we didn’t encounter any painful parts until now, only if you used an integration which is currently not supported for the Firebase platform, but let’s continue…
As I mentioned before Google Analytics is more of a web-oriented solution and therefore it results in session-oriented and/or screenview-oriented reports, as it tracks the users’ unique and normal screenviews throughout the session. On the other hand, Firebase reports are all user or event related, because it uses an event-based data model. This difference will bring up many painful problems, which will manifest in both re-designing the measured metrics of the app’s analytics and developing the new event-based tracking logic replacing the old analytics code in the app.
There’re big differences in how users interact with websites and mobile apps, so I can see the idea behind the event-based methodology in contrast with the screenview-based one. Furthermore, there are even mobile apps, where a unique screenview is hardly identifiable, while it has only a few screens with several screen parts, which change dynamically or just imagine playing a game on the phone.
We need to take a look into the models to fully understand all the limitations. Until now, we were used to sending numerous screenviews, hits and events to Google Analytics from our application. These contained some base parameters like event, category, event label, etc… Now, in Firebase’s event-based model, everything needs to be an event. The structure is pretty straight forward, we have to name our event and we can provide up to 25 key-value parameters to declare a context for it. This gives us seemingly more room for customization than the former Google Analytics. But… There are project-wide limitations in Firebase Analytics for unique parameters; leaving us with a maximum of 50 custom parameters, which can consist of 10 text and 40 numeric types. A project-wide unique parameter means that if you plan to use two events, which both have one text parameter named “type”, you already used 2 text parameters for your project. Also, there is an upper limit for unique custom events for a project, which is currently 500.
Google Analytics had the ability to define custom scoped dimensions. There’s a limit of 20 dimensions in the free version of analytics, but if you used the enterprise/360 version of it, you had 200. Now, this is the point where the 50 parameters of Firebase will start to get a little short. If you want to track the same dimensions for your event, then you need to register these as parameters for the event. Firebase provides another solution for this, called user properties. With this you can define 25 additional custom properties for your Firebase project.
As far as I know, these are the parametrisation limits currently, but there are also other limits. Google Analytics has screenview, event and hit rate limits per session and per time interval as well. On the other hand, Firebase has currently no rate limits for events, other than the maximum number of unique events.
All of these limitations must be taken into account when planning the migration to Firebase Analytics or designing your new app’s tracking, it’s pretty easy to exceed these limits if you don’t watch out.
As we saw earlier, the analytics data collected show pretty decent differences, but let’s check out the reporting capabilities of each tool. Google Analytics has provided us with a bunch of default reports, where we could check and track user/session behavior, and we could also create custom views. Firebase has a lot to improve on this part, as it provides options to create neither custom dashboards, nor custom reports. And you also have to register each custom property by hand to show up on your reports.
Although Firebase Analytics doesn’t give us much room for customization, we can integrate it with other Firebase/Google products, like BigQuery. This way we can transform, join and/or query our analytics data and we can also create custom views using Google Data Studio. This way we can even combine our analytics data with crash reports and other Firebase datasources. Sadly, these functions are not avaliable for free tiers and the cost is calculated according to the processed and stored data.
Also, keep in mind that the custom parameters provided for events can be used as filters, but in this case, you cannot see aggregated metrics of other parameters. Let’s take an example to explore this. Imagine you have an event called “rate” and you defined two custom parameters for it, one numeric called “rating” (1-5) and another numeric called “productId”. With this concept you can’t query the average rating for an exact product identifier. You can only see the overall average rating for all products, and also the total number of ratings for each product identifier.
All these restrictions might sound frightening, but keep in mind that if we keep ourselves to these limits, we will be able to continue using a free tool. If someone is up for migrating to a non-Google product, then there are also tons of good alternatives.
You might also want to check out some alternatives. These can be separated into two groups. There are other cloud-hosted solutions, just like Firebase, but you also have self-hosted possibilities. Both of these solutions have their own pros and cons, but the two biggest ones are the location of the data and the hardware running it, which brings up security and maintenance questions.
If you are looking for alternatives other than Firebase, then you should check out Clicky, Momently or Appsee. If you are looking for some more advanced or enterprise solutions, then Kissmetrics or Mixpanel might be worth a try. Also, if you prefer a self-hosted solution, then I advise you to take a deeper look at Matomo or Snowplow Analytics (both of them have cloud-hosted services too). Self-hosted options are handy when you need full control over your collected data. In this case you are responsible for running, securing and maintaining the service backing your custom analytics service.
What will happen?
What to do?
I really liked the old Google Analytics tool, because most of our previous customers preferred this solution and it was pretty straight forward to implement. Customers liked it mainly because they had other products reporting to the same or separate analytics, and they were used to knowing the functions and capabilities of the tool. We received clear and preciese specifications for the planned tracking. Now, the Firebase dashboard and reports will be new for most of them and it will also be hard to explain the migration to them.
I think Google’s move will give both the customers and developers some hard times during planning and development. But in my opinion, moving away from the old, more of a web-styled analytics solution, to a directly mobile-targeted one will hopefully improve our apps and our tracking data too. This way we will ultimately be able to enhance our end-users’ experience.
This post was powered by Wanari, a custom software development company, established in 2000. We are an agency dedicated to creating software that’s both easy and pleasing to use. We believe in employing the right tools for the job, so we are always on the forefront of looking out for new technologies or -as you saw in this post- preparing for changes in products we use. To learn more about us, visit our website or check out our Instagram and other social media outlets.