Have you ever noticed a banner at the top of your Google Analytics UI? It commonly says something like:
“This property receives hits from the Google Analytics Services SDK, which we will begin sunsetting in January 2020. We suggest migrating to the Firebase SDK, Google’s premier app-analytics solution, prior to January 2020. Learn more about Analytics in Firebase.”
If so, this post is for you! If you haven’t received this notification and you are 1.) sending mobile-app data to Google Analytics using the Analytics SDK and/or 2.) a non-premium Google Analytics user. Either way, you should also take precautions. Doing so will help you avoid potential risks with your data in the future.
Deprecation Is Coming, But What Does That Mean?
Data collection (web and mobile) is done at the Google Analytics (GA) property level. The most common process for sending mobile-app-specific data to Google Analytics is by using the Google Analytics Services SDK for Android or iOS.
With deprecation, this will no longer be possible. In fact, there will be little or no support from Google for those properties once the Google Analytics SDKs are fully turned off.
Another result of the deprecation is that data will no longer be collected or processed from Oct. 31, 2019, and onward. From Nov. 1, 2019, no data in that property will be provided. Historical data will still be accessible until Jan. 31, 2020, which brings me to my next point.
If historical data is important to you, then you need to find a way to pull out that data from Google Analytics before January 2020. Those properties will no longer be available via the Google Analytics interface or the API. Essentially, the data will be removed completely from the Google Analytics server.
Important Note: These changes will not impact Analytics 360 users (for now).
Still Want To Use Google Analytics For Mobile App Reporting?
This decision might seem a bit harsh by Google, especially if you consider the time and effort implementation takes (which is more tasking than web-based implementation). Nonetheless, Google still has you covered with their Firebase SDK, though Firebase SDK is still a mystery to a many people. The aim is to provide a more rich and robust service for mobile analytics than the Google Anlaytics SDK has to offer.
Another option is upgrading to Analytics 360 so that you are covered by SLAs. When you are an Analytics 360 client, your Google Analytics property is not affected; however, there is a possibility of this changing down the road.
For example, Google had mentioned that the Google Tag Manager (GTM) Legacy container will be deprecated. Most Analytics 360 customers still use Legacy GTM for iOS and Android to send data to Google Analytics. If this is your current situation, you might not be getting much support from Google for this platform in a few months. This implies that Analytics 360 customers may have their historical data in tact, but with no support.
Enter Firebase
Firebase is a fully managed backend-as-a-service (BaaS) where applications (mobile and web) can be developed. Firebase is a powerful platform that provides developers’ access to authentication services, analytics, and automatic data synchronization, to mention a few.
Firebase was developed by Firebase, Inc. in 2011 before Google acquired it in 2014. The procurement was sort of a win-win for both parties because Firebase would offer Google’s customers a backend service for building “real-time” apps for iOS, Android, and web. In return, Google would provide access to a massive scaling opportunity in terms of resources and technical infrastructure.
The Firebase platform integrates with some Google products and features such as Google Ads, BigQuery, and AdMob. Over the years, Firebase has grown (and is still on the rise) to accommodate more products and features to make development efforts easier. As of May 2019, it offers 18 services. A few of them include:
- Dynamic Link
- Crashlytics
- Google Analytics For Firebase (Firebase Analytics)
Here we are focusing on Google Analytics For Firebase and integrating it with Google Tag Manager.
Google Analytics For Firebase
As mentioned previously, Google Analytics For Firebase (formally called Firebase Analytics) is one of the many services offered by the platform. It sits at the core of Firebase and integrates across numerous features provided by Firebase SDK.
Analytics is such an important feature in today’s world because it helps businesses better understand their application users better and make data-driven decisions on the best way to interact with their users. The data from Google Analytics For Firebase (if implemented properly) can also show you how your users are interacting with your application (or if your application is having issues).
Benefits of Google Analytics For Firebase:
- It’s free and easy to integrate with your mobile applications (iOS and Android).
- When integrated with your application, the Firebase SDK automatically captures a number of events and user properties.
- It has unlimited reporting capabilities for up to 500 distinct events. This means that you can define your own events and user properties that are most important to you.
- Audience segmentation is another capability; you can build custom audiences based on custom events and user-properties.
- It’s easy to analyze your paid and organic channels to understand which methods are driving high-value customers to your application.
- It can be integrated with BigQuery to perform even more complex analysis and help you better understand your users.
- Google Tag Manager can also be integrated with Google Analytics For Firebase to help manage and control your implementation remotely from a web interface even after you app has gone live.
Google Analytics For Firebase with Google Tag Manager
One of the benefits of Google Analytics For Firebase highlighted above is its integration with Google Tag Manager. This makes the management of tags and events much easier and faster with mobile applications.
Without a tag management system such as Google Tag Manager, developers have to implement new releases or versions of their application to manage their tags, pausing or trigger events. If you consider the development cycle of most companies, that can take a long time and put valuable information at risk of being lost.
In short, having a good implementation strategy, as well as a tag management system in place cannot be over-emphasized.
The Google Tag Manager SDK supports Firebase for Android and iOS, as seen in the screenshot below.
You may also notice the Legacy SDK that will be deprecated very soon (as explained earlier). If you try to chose the Legacy SDK option, you will not be able to create the container.
There are numerous tags available to implement when using when using Firebase (Android or iOS) with GTM. The most common types for Google Analytics include Google Analytics (Firebase) and Google Analytics – Universal Analytics.
Google Analytics (Firebase)
Selecting this type of tag configuration in GTM gives you the ability to manage the events that appear in the Google Analytics for Firebase reports. You have the ability to add, block, or modify an action that is sent to Firebase. See the screenshot below:
Google Analytics – Universal Analytics
Selecting this type of tag gives you the ability to configure and control the type of events being sent to Google Analytics. You can choose a Google Analytics Property (UA-XXXXXX-1) that will collect this data and view this data in a Mobile App View. See the screenshot below:
There are a few more third-party and custom tags available for Firebase GTM containers than for the Legacy; this will likely continue to increase over time.
Why Use the Google Analytics (Firebase) Over the Google Analytics – Universal Tags?
Great question! First, let’s take a look at the basic concept of how this data is being passed to Firebase and to Google Analytics Properties using the illustration below:
Unlike the Legacy GTM, there is no concept of a dataLayer when using Google Analytics for Firebase with GTM. Firebase acts “like” the dataLayer. This might seem a bit odd for those of us that are used to the dataLayer implementation approach.
One major thing to note here is that, as soon as Firebase is integrated with your application, there are automatically-collected events available within the Google Analytics For Firebase console. This is not the same within Google Analytics – Universal Analytics, as you need to manually push all these events to be able to see this information within your mobile view.
Although this can be a bit worrisome and requires some additional development effort, it still has certain benefits currently available within Google Analytics For Firebase. Let’s look at the pros and cons of using one approach over the other.
Pros and Cons: Google Analytics For Firebase and GTM
Pros:
- Google Analytics For Firebase was built specifically to measure app engagements. People who build apps are more concerned about how users interact with their site (events), and how active the users are. This is why the dimensions and metrics within the console are mainly app-related.
- Google Analytics For Firebase allows unlimited and unsampled reporting on up to 500 distinct events.
- Data collection is totally free with no additional cost. The only task you have to do is to create a project and get the dependencies sorted out within your code.
- It requires minimal setup; in fact, setup can be done automatically using Android Studio.
- Some events are automatically tracked out of the box. These include first app open, app_rmoves, app_installs, dynamic_link_first_open, and many more.
- It can integrate well with numerous platforms such as Google BigQuery, AdMob, and many more.
- There is the ability to build audiences for remarketing and segmenting your data for granular reporting.
- If you have integrated Google Analytics For Firebase with Google Tag Manager, you have the ability to control your data even after it has been published to the App Store and/or Play Store.
Cons:
- If you are a Google Analytics Reporting UI fan, prepare to be bored to death. The reporting UI (in my opinion) is not as rich and flexible as that in Google Analytics. For example, the way we can structure our event category, action, and label is very different and restricted within the Google Analytics For Firebase UI. You cannot view the extra parameters that are tracked within the application. Secondly, In Google Analytics for Firebase, the event report does not really show any real granularity to your data.
- Offline data integration is difficult to implement within Google Analytics For Firebase. With Google Analytics, you have the ability to import offline data using data imports or the measurement protocol.
- The fact that Google Analytics for Firebase gives us the ability to collect unlimited data is pretty awesome—with the caveat of only being able to report on 500 unique event types per app per project. When your app starts growing and there becomes a huge demand for additional data collection, you may get to that number unexpectedly fast.
- There is a limit to the number of projects you can create within the Firebase console. This number varies between 5-10 for free accounts, and 30 for paid accounts. There are additional factors that influence the number of projects you can create in the Firebase console, but to be honest, there is not much documentation on this.
- Attribution in Google Analytics For Firebase is available for just a few advertisers. This means that custom attribution has to be handled within the application itself.
- Apart from the DebugView reports meant for testing, Google Analytics For Firebase does not have real-time reports. Reports get populated between 4 and 6 hours.
Pros and Cons of Using Firebase, GTM, and Google Analytics – Universal Analytics
Pros (of sending your app data to Google Analytics):
- Unlimited reporting and SLAs (only if you are a GA360 customer): Free GA users get the usual threshold of hits per month (10 million “hits” per month, per property). Analytics 360 customers can get more hits per month, but pay when those hits pass a certain threshold (usually 500 million). Premium clients have preferential treatment when it comes to decisions such as “sunsetting the Google Analytics for mobile apps”.
- Real-Time Reports: Yes, there is the ability to see your reports in real-time, just like with a web property. Be mindful that it is not as instantaneous as it is with a web property. Mobile app data is sent in batches to conserve the battery life of the phone (and for various other reasons). This timing can vary for both iOS and Android.
- Even if Google decides to deprecate the legacy container in favor of GTM v5 (iOS/Android Firebase SDK), you can still send your data to Google Analytics to access the Classic Mobile view reports (Audience, Acquisition, Behavior, Conversion). This is still the same (for now).
- There are more vendor-templated tags offered within GTM (this applies to Google Analytics For Firebase and Google Analytics) than you had with the Legacy GTM tracking.
- You still have the ability to include offline data in your reports, such as refunds and using the measurement protocol.
- Roll-up reporting is available for premium clients, and you can still send app and web data to the same property.
- It is possible to integrate your analytics data with other Google products (depending on your Analytics 360 status, standard or premium) like Google BigQuery.
- All other Google Analytics features can still exist for apps.
Cons:
- Automatically-tracked events, such as app_ope and app_removed within Google Analytics For Firebase, is not available by default within Google Analytics or Analytics 360. You have to manually send all your events to Google Analytics (including screenviews). So, even if you have more control, this is a major limitation.
- Web-First Concept: You’ll notice that the dimensions and metrics that were used for measuring “Website” performance are now used to measure Mobile applications in a similar way. There is still a concept of sessions, which might not bode well with mobile app experts who are more concerned with how the user engaged with the application when they opened the app.
- There is the issue of hit limits that apply to standard Google Analytics Users. Analytics 360 clients may still have to pay additional costs if they exceed monthly hit limits.
- There is the possibility of unsampled reports even for Analytics 360 clients when they hit the row limit.
- Google Tag Manager no longer has the DataLayer concept. This means that there is no “bucket” to store your information that can be accessed easily in GTM.
- Attribution reporting is not available within the Google Analytics reporting UI; you cannot compare different attribution models like you can on standard web views. This applies to standard Google Analytics and Analytics 360 users.
Our Recommendation:
It’s clear to see that both architectures (Google Analytics For Firebase, and Firebase with GTM and Google Analytics/Analytics 360) have their merits and demerits. We recommend having both of them available.
Google Analytics For Firebase will always be available out of the box as long as the Firebase SDK has been implemented in your Android or iOS app. This has a few limitations, including delay in reporting data getting populated into the UI, which is much better with Google Analytics (especially for Analytics 360 users). Pushing this data to Google Analytics will not happen by default; it requires some additional configuration, but gives numerous benefits (as we outlined earlier).
Your Next Steps
We have outlined clearly that Google is moving from Legacy to Firebase GTM for Android and iOS very soon. We also outlined why you must prepare for this development, as this will affect most businesses, especially complex businesses with numerous mobile analytics running on Legacy. We also illustrated what data gets sent to Google Analytics For Firebase and the standard Google Analytics, as well as how it’s sent. Furthermore, we compared the benefits and limitations between these two architectures. Finally, we recommended going with both approaches as a means to cushion the limitations of one architecture, using the second and vice-versa.
If you’d like to discuss the current and future setup for your mobile application tracking and analytics, reach out to the team at InfoTrust.
