Why Google Firebase/GA4 is Not Ready for Prime Time

By now, you've undoubtedly seen Google's announcement about the public release of Google Analytics 4, Google's latest iteration that replaces "App+Web". 

Personally, I'm still not a fan of their App+Web property rolled out last year. I agree it's important these days to be able to combine website and mobile app behavior data, but the flexibility that comes from custom Events and the limited standard Event reporting in this new version of Google Analytics still leaves a lot to be desired, compared to Google Analytics "Universal Analytics" version (GA UA).

This past summer, I worked with my client on implement tracking using Google Firebase for a new mobile app, which also led us to setting it up as a Google Analytics "Web+App" property. At the time, that in turn led us to using a different version of Google Analytics than GA UA that some called Google Analytics for Firebase (GA4FB), which is pretty much GA4 now. If all these crazy "Google Analytics" names are confusing to you, you're not alone!

Google says GA4 is the future and will eventually deprecate the current GA UA version. So I was quite excited about learning more about Firebase and GA4FB. Based on my hands-on experience the past few months, Google still has a lot of work to do on GA4 to even get it to parity in terms of standard reporting features and functionality, not to mention ease of use, with GA UA. 

I'm going to share some of my learnings with Firebase and GA4.

Validating Tags for Mobile Apps 

I prefer to validate mobile app tags with actual physical iOS and Android devices, not emulators. I commend Google for creating a way to validate custom Event (and Parameters) tags in real-time on mobile apps within Firebase. In the past, this was very difficult to do, compared to QA'ing website tags with browser extensions. In Firebase, there are 2 ways to go about this.

1. DebugView - From the left panel in Firebase, you'll see DebugView. First, you'll need to follow these directions to put your device into Debug mode and then select your device Debug Device from the drop-down list in upper left. This is a nice precise timelime-driven way to watch events as they fire. You can check parameters on the right. Annoyingly, this was very unstable and unreliable -- often my iOS and Android devices didn't even show up on the Debug Device list. Events also didn't always show up after waiting for 30 minutes. That leads me to the second option.

DebugView Event Timeline

2. StreamView (since renamed to Realtime) - StreamView was a little bit more reliable if you are able to isolate your device by OS and city. In a Staging environment, this wasn't hard to do, especially if you were 1 of the few testers online or tested outside regular business hours (which I often did). Unlike DebugView that had detailed timestamps for events, StreamView does not have such precision and just lists all the events that fired in the past 30 minutes:

StreamView Events List

StreamView would sometimes frustrate me too when events did not show up after 30 minutes, albeit less than my DebugView issues. So that would force me to re-test again and hope that the data showed up.

Also, both methods above do not let you validate data stored in arrays, such as the standard e-commerce parameter Items. This meant one can not QA things like what products users viewed, added to cart, or bought. The only solution was to build some custom queries in Google BigQuery and then some tables in Google Data Studio that mimicked enhanced ecommerce reports in GA UA. 

I also discovered this great YouTube video to help install ADB on Windows for validating Android tags. You can run ADB from a command prompt to get very detailed logs for troubleshooting. From c:\adb folder, run these commands:

adb devices

adb shell setprop debug.firebase.analytics.app com.skechers.android

adb shell setprop log.tag.FA VERBOSE

adb shell setprop log.tag.FA-SVC VERBOSE

adb logcat -v time -s FA FA-SVC

Here's what a log snippet looks like:

name=inbox_view,params=Bundle[{user_id=207067, ga_event_origin(_o)=app, ga_screen_class(_sc)=Shop, ga_screen_id(_si)=8545328432333857419, ga_screen(_sn)=Home]

To stop listening, run: adb shell setprop debug.firebase.analytics.app .none.

Custom Events on Steriods

One of the major benefits of Firebase is the flexibility for custom event tracking. While GA UA has 3 standard parameters for custom events, namely Event Category, Event Action, and Event Label, Firebase lets you name Events and Parameters anything you want. However, this requires more tag planning and work for developers. I like to create a tagging document like this for developers, as well as marketers, so everyone is on the same page:

Firebase Tagging Document

Note there are limits on the number of custom events and parameters you can have in GA4/Firebase. Another reason why it's good to create a data dictionary like the tagging document above so you can try to re-purpose parameter names and minimize the use of custom events by leveraging standard events from Google. For example, here's some standard events.

Data is collected differently so you really have to rethink your data model, especially Parameters for Event tracking. 

Limited Reporting and Data Stuck in GA4/Firebase

The reporting interface takes a little bit of getting used to from GA UA and not all standard GA UA reports are in GA4 yet. For example, enhanced ecommerce reporting took months (back when it was App+Web) to show up. 

There is also a new self-service custom reporting tool called Analysis Hub that reminds me a lot of Tableau that lets you select your own dimensions and metrics to build tables. Note: Analysis hub still won't let you report on arrays!

GA4 Analysis Hub

But would I really need and miss is a way to get data out of Firebase and GA4 to create custom dashboards elsewhere, especially in Google Sheets. I ❤️ Google Analytics add-on in Google Sheets! But unfortunately, Google has not released a GA4 add-on for Google Sheets.

The only option is via BigQuery if you're up for writing SQL. And then you can connect to Google Data Studio or any other environment that works with BigQuery.

At the time of this post, third-party data connectors, such as Supermetrics and Funnel.io, that I spoke to said they were working on a GA4 connector and hope to release a beta product soon. My money is on these guys instead of Google and Google Sheets.

Summary

GA4 feels like a premature product that was released way too early. But while familiarizing oneself with GA4 can be frustrating, it's time to go kicking and screaming into the future with Google. 

##