Google, please stop hyping Firebase and Web+App Properties like the Garden of Eden!
Over the last year, a client has been rolling out a large online shop’s new website and mobile app. Since the customer is all in on Google’s Analytics and Marketing solutions and the old Google Analytics Mobile App SDK was announced to be sunset, “Google Analytics for Firebase” and the promising “Web+App Properties” seemed like the logical solution for tracking the app. After all, there was no Google event, no Google blog post where Firebase was not hyped as if it were the new Garden of Eden. Maybe the less finished a product is, the more it needs to be hyped.
After the last Google Analytics newsletter had ONLY articles on the “Web+App Properties” (which are basically Firebase Properties), I felt I now finally have to write something about my experiences with the reality behind this Firebase hype. Just my experiences. No claim for objectivity. Maybe I am missing out on something important. Tell me! I will be happy.
I may make a fool out of myself with this
Now that I started this article, I know that it COULD be that Google will publish something next week that makes all these points invalid. After all, they have been promising for some years now (and now promised this to happen 2020) that Firebase and classic GA360 properties will reach “feature parity”, even in “Enhanced E-Commerce”. But hey, I will be happy to put this article into the archive if Google does that and congratulate them on a big achievement.
So let’s start:
1. Don’t sunset a product before offering a replacement
When Google announced about 1 1/2 years ago that the GA Mobile SDK would soon no longer be supported for non-GA360 customers, we (another agency and myself) told the client that Firebase seemed like the only valid choice for tracking his planned app (and various others that are in the pipeline). This client is not able to do changes quickly and has many apps and websites to manage, so going with the old Mobile SDK first as long as it is supported and then moving everything to Firebase-only was not an option.
However, when we started learning how limited “Google Analytics for Firebase” is, we felt startled. Basically nothing a semi-advanced business user likes in the classic GA360 interface exists there. No Enhanced E-Commerce, no Site Search reports. No Marketing Channels. No view filters. Nada. Just some weak logging-style “Event” Reports. It is basically “logging”. That is how a consultant at a “Google Partner” agency full of Google-trusting fanboys aptly described the Firebase “data model”: So many Events X and Y, so many Users. And amazingly useless metrics like “Event Count per User” (yes, that would be “Hits per User” in the classic GA 🙈).
The interface has improved only slightly since mid-last year. Maybe if you have a gaming app or just some content app, that is not so terrible. But for an online shop with thousands of products, that feels like going back to near-zero.
So that was the first time when Google sunset a rather good product (Mobile SDK) without offering anything close to replacement level as an alternative. It felt like: “Just do Firebase now, annoy your business users with an almost useless interface, then wait for a while (1 year? 2 years? 3 years?), and everything will be solved.”
I understand some developers always want to move the next thing, not maintaining “old stuff” for too long. But is that a customer-oriented product strategy, especially one for slow-moving large enterprises (“Enterprise” btw is probably the second-most used term in Google Analytics marketing materials after “Firebase”)? I don’t know…
Next, Google promised to come out with “Web+App Properties” where we would be able to do cross-device and cross-platform analytics as long as the user uses the same ID everywhere. Sounded great. And that even works! Really nice! The problem: You are still in the crippled “Analytics for Firebase” property interface, and everything you used to be able to do in the classic GA interface is gone.
Note that, again, Google is hyping an unfinished product (web+app properties), telling us at every opportunity to abandon our beloved classic GA360 views to settle in for something that can do cross-device and -platform tracking and now some Event Funnel reports (yay…), but nothing of the stuff most business users use every freaking day!
2. Why Firebase Event Parameters don’t replace Custom Dimensions
Custom Dimensions and Custom Metrics? Who needs Custom Dimensions and Custom Metrics? We have the awesome Firebase Event Parameters of which you can send 25 per Event, and you have a total of 100 Parameters “available in the interface”, 50 of them numeric (=> think: Custom Metric) and 50 strings (=> Hit-based Custom Dimension). Ah, and 25 User Properties (=> User-based Custom Dimensions). As there are no Sessions in Firebase’s “data model” aka “logging”, there are also no Session-based Parameters.
Well, 50 Custom Dimensions does not sound so bad. 25 dimensions per Hit is not ideal, but with some prioritization, we were able to work around that even for parameter-heavy Events like transactions.
The main issue is the “50 in the interface” (and this was not specified as clearly as of mid-last year), because:
So if you are an online shop and have a common E-Commerce implementation with parameters like (I am ignoring the official Firebase retail parameters here, so don’t you copy my parameter names!):
- item_id
- item_name
- item_price
- item_stock
- item_brand
- item_category
- item_variant
- item_list
- item_quantity
- transaction_id
- transaction_revenue
- coupon_code
- payment_method
- delivery_type
- etc.
Let’s stop at 14 parameters. Now assume you have the following typical 8
E-Commerce “Events”:
- item_list_click
- item_view (Product Detail View)
- add_to_cart
- remove_from_cart
- begin_checkout
- checkout_progress
- ecommerce_purchase
- ecommerce_item_purchase (btw since Firebase does not allow sending more than one product in one Event Hit (because people never buy one more product in one transaction, right?), you need to send another Hit for each product, which makes things like impression tracking of search result lists with e.g. 100 products quite an “eventful Event” (we don’t do it because of that))
In the rare case that you need all 14 parameters for all 8 Events, you would need not 50, but 14 * 8 =112 Event Parameters in the interface. But you see where I am going. Even 7*8 is already 56, and if most of the parameters are strings (which is usually the case), you are already “breaking the interface”. Add a couple other typical parameters (content_group, search_term, shipping_cost, search_results_count, error_type, error_description etc. etc.) and you are very, very quickly above this 50 parameter threshold.
Moreover, it is unnecessarily tedious that you have to “activate” each parameter for each event individually.
3. The “But You Can Use BigQuery” Running Gag
But hey! Some advanced GA users will think now: But you can use BigQuery, all data is in there! That was also Google’s standard answer: No problem! Just use BigQuery plus Data Studio! I wish they gave this advice to the puzzled client’s business users: “Hey! I know you have been using Enhanced E-Commerce Reports a lot. Our interface is super-limited, but why don’t you learn advanced SQL just to set up some basic reports with BigQuery? Or invest some more money in your Google Partner agency or give even more work to your in-house Analytics girls because they love doing standard reports in Data Studio!”
This feels a bit like going back to asking IT to parse server log files every time you wanted to know how many Pageviews your article had. Of course, BigQuery is awesome. But it is something for techies and advanced Digital Analysts, not for business users. And even advanced Analysts like standard stuff to be easily accessible in an interface.
4. Debugging with Handcuffs
How do you debug whether tracking in an app works as specified? Whether all parameters and events are set correctly? You use your Fiddler or Charles debugger as a proxy for your smartphone, and then you can see all the requests as if they happened in a regular browser.
Not in Firebase. All the data is sent in binary format, so nothing readable to extract there — that’s fine, probably good for privacy. But now you are left to the “Firebase Debug View”. That is a cool feature — but it is the only way to debug anything!
If you want to test on iOS, you need an app developer to deploy the app in a way that it supports the debug mode — which is usually never the case for productive apps, so you can hardly if ever debug the real productive app (and e.g. test campaign tracking). On Android, with some steps you can activate the debug mode for your device by yourself. Have fun doing this for every device you want to test!
Moreover, the debug view has a lag of 15–30 seconds. Just enough time to lose focus. Sometimes Events appear out of order, sometimes they don’t appear until you reload the page. And they disappear after 30 minutes. That’s quite a downgrade from the wealth of debugging possibilities you have with a classic debugger. Since testing is so tedious, we have to do testing days where the developer and the Analyst are in a room together all day just to be able to test efficiently. Who pays for that additional effort? Not Google.
My impression sometimes is that Analytics for Firebase was initially built primarily for app developers. However, tracking is often not debugged by developers, but by Digital Analysts who are not app developers themselves. So it feels like debugging with handcuffs.
So much for the stuff I think you should know before moving everything to Firebase or migrating to an app+web property (I could have added another chapter on the confusing world of Firebase Campaign Tracking (Dynamic Links vs. Ad Networks vs. Universal App Campaigns — so what should we use now, and how?), but that world is just about as confusing for any app framework).
To say something positive to finish it off:
Again, the cross-platform-/cross-device tracking that the Web + App properties offer is a real milestone. Let us hope that Google gets the rest of the features we love into a sensible interface soon. They have promised, so let’s keep our fingers crossed. And of course we want this awful parameter interface limit to get dropped, at least for GA360 customers.
In summary: Don’t let yourself get pulled into a hastened migration by all the hype out there, especially if E-Commerce is your game. My client was forced to because they had to decide for a framework for the future for a new website and a new app. And now they are in pain — hopefully not for too long…
