The category, action and label dimensions in legacy versions of Google Analytics made it simple to organize your events, but these variables have been deprecated in the new App + Web properties. Before you start creating App + Web tags you need to do some careful planning to ensure that your reports are set up properly. In this post I will share the best practices that I have gathered when setting up events and parameters so that you can avoid common mistakes.
UPDATE: On September 18, 2020 Google announced the release of event-scoped custom dimensions and metrics for App + Web. Once this feature is available I will update the contents of this article.
Old Events vs. New Events
The concept of an event has changed in the new App + Web properties. Here is a quick summary of the differences:
- The traditional definition of an “event” was any action that you would like to track other than a page view (click, impression, form submit, error, etc). When you created events, you simply set a “category”, “action” and “label” to specify how it should appear in the “Top Events” report. Then, you passed any other context about the event to the “value” parameter or any custom dimensions/metrics you would like.
- The new definition of an “event” is more broad: “…any distinct action occurring at a distinct time associated with a user” (source). To provide further context to the event, the concept of a generic “category”, “action”, and “label” has been replaced by an event name and a list of key-value pairs called “parameters”. On the web, every time you fire an event to an App + Web property you are telling the browser to send data to Google Analytics (mobile apps send events in batches, but the concept is the same).
There is no page view hit in App + Web events. All hits are events, and so to track a page view you need to create an event and give it the name “page_view”. The page title, URL and other dimensions are set as parameters.
Also, the “Top Events” report has been replaced with the “All Events” report in App + Web properties, and the first thing you’ll notice about this report is that events cannot be grouped. When you hover over an event name, you’ll see three dots appear on the right side of the screen where you can modify the options for that event (more about these under “Setting Up Your Events” below). If you click on the event, you will be taken to a special report with details about that specific event.
Why Planning Is More Important for App + Web Properties
In App + Web properties you cannot use view filters to correct mistakes (at least not at this time). Additionally, for native apps, you have a limited ability to modify the data that has been captured in GTM. So, for example, if your developers create an event name called “signUp” instead of “sign_up”, this will probably need to be corrected in the code.
Also, App + Web properties allow you to roll up data across all of your websites and apps now (previously only available to 360 properties). If you choose to do this you will need to ensure that events within each stream use consistent event names, parameter names, and parameter values. Even small mistakes like capital letters can prevent data from merging properly.
Don’t forget that in any version of Google Analytics, once data is collected it cannot be changed.
Best Practices to Avoid Common Mistakes
Okay, so hopefully I scared you a little bit in the section above. Now let me put you at ease. Here are the best practices that I’ve gathered to get you off to a good start:
1) Use the Suggested Events when Possible
This should be obvious, but I am guilty of setting up custom events only to realize later that a suggested event was available (see full list here). There are two reasons why it is important to use the suggested events:
- In many cases, the suggested events unlock new reporting. Take the page view event on a website for example. If you mistakenly create an event called “pageview”, Google will not have any context to understand what this event is tracking. But if you use the standard event name “page_view”, then your tag will automatically capture additional parameters such as the page title and name, and make these available in the reporting interface.
- App + Web properties are brand new and still in beta, so it is important to set yourself up to gain access to new features and integrations that are released as the product is expanded. It’s important that we set up events and parameters properly the first time because making changes down the road can be painful, so using the suggested events might just help you avoid this pain down the road.
2) Use Unique Event Names to Track Conversions
The concept of a “goal” in previous versions of GA has been replaced with events that have been “marked as conversions” in App + Web properties. And although you previously created goals out of an event or page view where certain parameters were set (such as: event category = “lead submitted” or URL matches some regular expression), you now enable an event to be recorded as a conversion by the event name only — no parameter conditions are allowed.
As a result, each event that you would like to track as a conversion must have a unique name. For example, when a user submits a lead form you cannot track the view of the thank you page as a goal any more. Instead, you will want to set an event with the name “sign_up” to fire when the thank you page loads.
3) Avoid Passing the Same Parameter to Multiple Events
In the user interface you can only enable 50 textual and 50 numeric custom event parameters total across all of your events (source), and if you pass the same parameter on two events it counts twice!
NOTE: It’s worth mentioning here that all of your event parameters are available in BigQuery (up to 25 per event).
DO NOT create parameters called “category”, “action”, and “label” with each of your custom events. That’s not helpful because events are not grouped together in the reports like this anymore. Also, if you do that with 5 unique events then you’ve already used up 15 of your custom parameters.
With that limitation in mind, the is one instance where you can ignore this advice: when you have many versions of an asset (such as articles, forms, etc) that you need to track several actions against. For example, if you have online learning app with more than 100 courses, and you need to track the completion rate for each course, I would recommend that you create two separate events called “course_start” and “course_complete” (mark this one as a conversion), and give them each a parameter called “course_name”.
The alternative would be to add the course name to the event, like “course_start_algebra101”, but this is not ideal because you also need to…
4) Be Careful Not to Set Too Many Distinct Event Names
Currently, you are limited to 500 distinct event names (source). As a result, you should keep your event names focused on the actions that users are taking (click, video_play, etc) and use parameters to define the objects being acted upon (‘link_href’, ‘video_name’, etc).
5) Create and Maintain Good Documentation
Good documentation is critical. Even if you’re only setting up a single website, there is no way to validate that your tracking code is doing what it is suppose to do if no one has written that down somewhere along with test instructions. And if you are merging data between multiple streams, this is even more important.
This type of documentation is called a “Solution Design”, and at a minimum it should include:
- The business requirements or questions that you are solving with Google Analytics.
- A list of the events, parameters and user properties that you are using across all of your data streams (with a description for each) to address these business requirements.
- Instructions for testing that your data is setting properly.
- (OPTIONAL) I also like to include instructions for the development team in the same document.
To help get started with good documentation, I’ve created a sample Solution Design template that you can copy and modify.
Setting Up Your Events and Parameters In the Reports
After you start sending data to your App + Web property (or Firebase Analytics), the “All Events” report will create a list of the events received and the parameters attached to those events. The next step is to choose which custom parameters you would like to view in the reports. If you did step 5 above, this should already be planned out before you start capturing data.
For websites, I always go to the “session_start” event and enable the “page_location”.
This will make a new dimension immediately available in Analysis so you can generate a landing page report.
Additionally, you can mark any event as “NPA” from this menu, which stands for “no personalized ads”. When you enable this feature on an event, audiences that are created using the event can only be used within non-advertising products, and cannot be exported to products like Google Ads or Search Ads 360 (more info here).
If you have not set your App + Web property up, take a look at my guide HERE.
If you already have a legacy version of Google Analytics installed on a website, take a look at my article on Translating Website Tags from Universal Analytics to App + Web.