Differences between Traditional Google Analytics and App + Web Properties

Since you’re reading this guide, it’s likely that you have spent quite a bit of time working with Google Analytics on a website, and it’s also likely that you’re feeling intimidated by how different App + Web properties appear to be.  The purpose of this post is to introduce you to the new concepts that differentiate App + Web from it’s predecessors, and also give you confidence that the event/parameter approach that Google has introduced is really a big step forward from what you are familiar with.

From Universal Analytics to Google Analytics for Firebase

The Problem that App + Web Solves

If you’ve attempted to use the old Google Analytics mobile SDK or even install traditional Google Analytics on a single page web app, a piece of your heart already knows that these tools sometimes attempted to fit a round peg into a square hole.  The fact is, apps are more variable than traditional websites, and the assumptions that we make about how users experience the web do not always hold true for how users experience a mobile app.  As an example, if you’re a runner you might open a mobile app to track your speed and let it run in the background for hours.  How many sessions should that create?  Should every time you unlock your phone to check your pace be counted as a screen view?

App + Web simplifies the pageview/screenview concept with a more flexible system of events and parameters.  I refer to the new design as an event-driven data schema.

Hit types like custom event and pageview are are consolidated into events

Yes, you can still use pageviews and screenviews where it makes sense, but these are no longer the fundamental building blocks that they used to be.  This is important because mobile apps are made up of a series of “activities” (things you can do) rather than “pages” (things you can see), and it can be unintuitive to try and use the concept of a screen view to describe the experience a user is having within your app.

These benefits may sound unclear at first, but once you start going down this rabbit hole you’ll begin to notice ways that this approach actually works better on traditional websites as well.  Think about the way we would track a purchase with traditional Google Analytics.  The standard approach is to wait for a thank you page to load, set all of the transaction data as dimensions/metrics, and then fire a pageview tag to pass all that data along (as demonstrated below). 

A traditional ecommerce hit

But when you think about it, there are really two events happening in this scenario that are being crammed into one: the purchase event, and the thank you pageview event.  Also, the transaction data really only describes the purchase event, whereas the typical page information (page title, etc) really only describes the pageview event.  Separating this into two events with their own parameters would be a more accurate representation of the actual activity occurring on your website.

Google Analytics for Firebase sets two events where Universal Analytics would have combined them into a single pageview

App + Web properties solves this problem by allowing you to create an event for any activity that you would like to record, and then attach the parameters to that event that are necessary to describe it.  Unlike GA360, there is no cost for sending a high volume of events to App + Web properties, so there is not an incentive to cram multiple actions into a single event.  If you happen to have a checkout flow without a thank you page this is no problem, you just fire the “purchase” event.

As you will see, this event and parameter approach is an improvement for both traditional websites and mobile apps.  And, bonus, since App + Web uses a common data schema on websites and mobile apps you can roll up that data into nice dashboards for reporting purposes!

Key Differences to Keep in Mind

When you get started with App + Web it can be a little overwhelming.  Here are some key differences to be aware of:

  • Firebase is a suite of products that are well integrated with each other.  This means that the tool is more extensible than before, and you might get a lot of value from some of these integrations.
  • Firebase Analytics is free with unlimited event reporting.  There are limits on the number of unique events/parameters you can use, but there is no limit to the volume of data you can send.  Conversely, the free version of Google Analytics is currently limited to 10 million hits per month per property (source), which is why a lot of companies choose to pay $150K per year to upgrade to 360.
  • Reporting in App + Web Properties is More Customized.  At first glance, the App + Web user interface appears to have virtually no built-in reports.  This is because many of the reports are actually generated for each event.  Whereas traditional GA included reports that may or may not show any data for your site unless you set them up (such as “Internal Search” for example”), App + Web suggests that you use certain events (such as “search”).  If you choose to use those suggested events, you can click on them in the “all events” screen and pre-built charts will show up in your interface (NOTE: as I write this App + Web properties are in beta and there are not very many of these pre-built charts, but presumably these will be added over time).  Additionally, you can also create your own custom events and view reports for these as well.
  • Sessions have not completely gone away.  This is the #1 question I get.  The concept of a session with a 30 minute timeout still remains in App + Web properties, but a new metric has been added called “Engaged Sessions” (in the “Behavior” report), which removes bounces. You will also have new metrics for “Engaged Sessions per User” and “Engagement Time”, which have been documented nicely by Krista Seiden.
  • Web streams contain some automatic event tagging.  “Enhanced Measurement” as it is called allows you to track a handful of actions without custom code on your site or in your tag manager.  These include: user scroll tracking, youtube video interactions, clicks to exit the site and more.
  • App + Web can be accurately validated in the user interface.  Analysts who are uncomfortable using browser developer tools can now test and validate that their tracking works properly with the debugging report that shows you a real time stream of events coming from a single user.  There is no need to try and hack this with the real-time reports any more.
  • You filter reports, not views.  App + Web includes very powerful Audience and Build Comparison tools that allow you to select users based on a combination of dimensions, metrics and events.  These can be applied to exclude or include users from your reports the way view filters previously did.

So those are the big items to keep in mind.  But I’m sensing that you have one final question:

Can I just use App + Web properties on my mobile apps and keep traditional GA on the web?

Google sort of forced us all to migrate our mobile apps to Firebase Analytics from the old mobile app SDK back in October 2019, but you still have a choice on the web.  By now you can probably guess that I’m going to recommend that everyone add an App + Web property to your website.  Even if you do not have a mobile app, you should install an App + Web property on your website simply because: it’s free, it’s better, and you’re going to need to familiarize yourself with it because the industry is moving in that direction.

However, you don’t have to pull the plug just yet.  Keep your traditional Google Analytics tracking up and duplicate your data to a new “App + Web” property at first.  Use this guide to help you set up reports and start digging into the data, and send me suggestions on how to improve this content.

Leave a Reply

Your email address will not be published.