The Analyst’s Guide to Google Analytics App + Web Properties

About This Blog

If you’ve been following Google Analytics for a while, you’ll remember that there have been two major overhauls of the platform since it was acquired: 

  • 2009: Transition from Urchin to classic Google Analytics (ga.js)
  • 2013: Transition from classic Google Analytics to Universal Analytics (analytics.js)

Now, we are in the middle of a third major overhaul from Universal Analytics to Google Analytics App + Web.

Google Analytics overhaul timeline

This started back in 2017, but became official in July 2019 when Google launched the beta version of the “App + Web Property”, which give you the ability to install Google Analytics for Firebase (also known as “GA4F”) on a website.

Despite the name, you do not need an app to use App + Web.  This is a brand new version of GA.

As I write this in early 2020, many of the most knowledgeable and experienced digital Analysts I know have not been paying attention to App + Web.

App + Web properties are completely different from the Google Analytics we know and love.  Data is collected differently, it is stored and filtered differently, and even the way we create reports has changed.  Familiarizing yourself with App + Web can be overwhelming, but the time has come to start learning.

If you’re an Analyst who is ramping up on App + Web properties, this guide is for you. 

This content is constantly updated, and is intended to provide the latest tips, best practices, and FAQ’s to support our colleagues.  But before we jump into the weeds, let’s start at the beginning: Why App + Web?

What Makes App + Web Properties so Special?

If you’re here you probably already have an answer to that question, but let me give you one more: it’s the future.  

In the early days of web analytics (say mid-2000’s) websites were built out of pages that loaded every time they were viewed, and we all agreed that it was a good idea to group these page views into sessions every time we noticed a break for longer than 30 minutes.  Then mobile and single page apps came along, and the concepts of page views and sessions didn’t always apply any more.

As an example, consider how important the page view is to web analytics.  It is used to calculate bounce rate, time on site, time on page, pages per session and more (not to mention the importance we place on “landing page”).  Apps do not always have page views.  Apps that simply load and run long processes (like play a video or record audio) cannot meaningfully describe user behavior with the traditional page view approach.

The fundamental building block of a session was traditionally a page view.

Solution: The Event Driven Data Model

Mobile app Analysts solved this problem by discarding the notion that the fundamental building block of a session is a page view, and replacing it with a flexible system of events, parameters and user properties.  These new concepts can be flexibly applied to any new application, and as you’ll see below they can also be applied nicely to a traditional website.  For more info, read my post on Differences Between Traditional Analytics and App + Web Properties.

Google did not invent the event driven data model, and it’s not new — it has been the core of Google Analytics for Firebase since it was acquired in 2014.  It is a tested and proven approach that has been around for years, but it has rarely been applied to traditional websites before the App + Web property came along.

So How Will My Business Benefit From This New Approach?

App + Web provides a better representation of user behavior, while allowing you to spend less time collecting and aggregating data.  In the rest of this series I will explain how, but here are my top 4 highlights:

  1. For web, a variety of commonly tracked activities can be enabled without any code change (a feature called Enhanced Measurement).
  2. If you communicate with customers across multiple platforms (such as web, iOS, Android), you will now have dramatically better tools for rolling up that data into a single view of the customer.
  3. The old dashboards and custom reports have been replaced by new powerful tools for conducting analysis and sharing findings (many tools previously reserved for GA360 users are now free for everyone).
  4. Everyone can now leverage the BigQuery integration to access your complete and unsampled data (also previously only available to GA360 users).

Before You Get Started, Let’s Clear Up Some Confusion

Many of my clients have been confused by the numerous and changing names for the Firebase and Analytics products that are floating around.  Here is the short summary that you should be aware of before using this guide:

  • The old Google Analytics Services SDKs (which basically gave you Universal Analytics in a mobile app) were deprecated in October 2019.
  • “Firebase” is a family of products for mobile app development, and one of those products is “Firebase Analytics”.  As of July 2019, you can now use Firebase Analytics to track websites as well as mobile apps (source).
  • If you choose, you can link a Firebase project with Google Analytics which unlocks new reports above what is available in Firebase Analytics and creates a new type of GA property called an “App + Web” property.
  • “Google Analytics for Firebase” == “GA4F” == “Google Analytics V2”

Now Let’s Dive In!

First of all, sign up for my monthly Google Analytics Newsletter to get the latest product updates, tips, and best practices delivered to you inbox monthly.

If you’re still evaluating if this is a good time to migrate from traditional Google Analytics to Google Analytics for Firebase, take a look at my post that explains how they differ. 

However, if you’ve made up your mind and are ready to get started, jump straight into How to Set Up a Google Analytics App + Web Property.