Introduction
Firebase is one of the popular products from the Google Analytics 360 product family that has rapidly gained an affinity as a go-to tool for App development & analytics. Firebase SDK provides a bagful of features to make the end-to-end process of mobile app development run as smoothly as a hot knife through butter. After its acquisition by Google Analytics, Firebase is now a wholesome platform for your app development & app data analytics requirements. Today we are going to focus on Firebase Analytics and the limitations we face while using the tool for data analysis & insights. In this blog, we will also look at workarounds for each of the major limitations & discover how swiftly we can overcome them.
Why we love Firebase Analytics
- No additional cost for analytics data collection – yes it is totally free of cost.
- Unlimited data collection – can collect up to 500 unique events.
- Crucial events’ data collection is done automatically. This includes events like App installs, App uninstalls, In-app purchases, App updates, etc.
There are quite a few other bundled-up features of Firebase Analytics such as Crash Reports, Notifications Setup that targets the Audience generated by Analytics, and diverse sets of events.
Firebase Analytics Limitations: Our wishlist for Firebase Analytics & a few basic workarounds to overcome the limitations and achieve better reporting
- Restricted Reporting :
- Firebase reporting console barely offers any course of action to view data in diverse ways. We have the one and only “Events” Report to view all the tracked events at once. Elaborating further, the Events Report provides no major cardinality on reporting apart from the option to apply a basic filter on either “Event Name” or “User Property”.
- Another major limitation of the Event Report worth highlighting is the inability to view the extra parameters tracked with one single event in the said report. Note: Firebase Analytics can report data only on 10 text parameters and 40 numeric parameters in the Event Report.
Image 1 : Setting Up Parameter – Limitation. - Firebase also falls short of API support so as to access the collected analytical data.
Workaround: Your best bet to access the raw analytics data is to link your Firebase Analytics data with BigQuery. And when it comes to BigQuery, performing analysis on massive datasets is simply more straightforward. This will solve a major issue of limited data access, and, at the same time, we also gain the liberty to perform analysis on diverse datasets in a single pane.
Note: Linking to BigQuery will cost us a few pence!
- Event Limitations :
- Despite the fact that Firebase offers unlimited event collection for each event type for your App, it has confined us to the range of the said event types. This means we can only have 500 unique events for an individual app in the Firebase project. To begin with, this limit does not seem much of a hurdle, but if we revamp our app tracking or if we keep updating the event tracking process, without a doubt we are going to meet the dead end of the reporting platform.
Thus, precautionary steps to manage the event limitations are:
- To wisely design the event names before they are implemented.
- To define a standard structure, identify the events and the required parameters for event tracking in an app.
For Example:
- Navigation Event: This event is templatized for all the navigations that a user can perform within an app.
“navigation_<from_to>” – here “from” and “to” are navigation sections defined in-app.
Parameter1 – intermediate of navigations to be tracked in this parameter.
Eg. navigation_home_help, navigation_home_mens-shirt. - Product Interactions: This event is templatized for user interaction with the product.
“product_<interaction>” – various product actions(i.e. View, click, addtocart) can be tracked.
Parameter1: “Category”
Parameter2: “product name”
Eg. product_view, product_detailed. - For Articles: This event is templatized for tracking articles.
“article_<action>” – various article actions (i.e. viewed, click, read_began, read_incomplete) can be tracked. Eg. article_clicked, article_read_began,article_read_complete.
- Campaign Attribution :
- The attribution of Install referrers in Firebase is controlled by Firebase SDK itself. Currently, Firebase tracks attribution for a limited number of Advertisers which are defined in this link. For any other platform or source/medium attribution, other than the listed Advertisers, the default attribution of source/medium will be done to direct.
Workaround: Knowing the fact that we are missing out on a major custom campaign attribution, we need a quick fix on it. For this, we have worked out a solution which I shall share with you as a separate blog post. Our custom solution includes tracking both; install referrers and custom campaign data. Below is a glimpse of the Attribution Report for Custom Attributions.
Image 2: Attribution Report with custom “source” value.
Conclusion
Here, we have discussed how data can be analyzed in a better way by linking BigQuery as compared to normal reporting. Also, for reporting it is necessary that we collect meaningful data and as mentioned in point 2 above, do not reach the limitation of the event type that is getting tracked. We have already seen a few examples of how to structure and design the events in this blog, and we hope you find them resourceful.
Quick Tip: If using Firebase Analytics, do plan out the tracking approach and efficiently design the events for the same. This will yield absolute data in reports and help you analyze it.
The limitations discussed above cover a large ground of Firebase Analytics. However, if we have missed out on any titbits on the same, do comment in the below section and we will be happy to acknowledge it!
