Events, parameters and user properties

0:00 Events, parameters, user properties

If you learned web analytics years ago, you might still think in page views, sessions and bounce rate. G A four thinks differently. Everything is an event: a page view, a scroll, a purchase, even the start of a session. Sessions and users still exist, but they're built from events. In this lecture you'll learn the event model properly: event names, parameters, user properties, the four families of events, how engagement is defined, and what the same event looks like in the raw BigQuery export.

0:37 Why the model matters

Why does the model matter? Because every report, exploration and export you'll ever use is built from it. If you understand that a purchase is an event with parameters like value, currency and items, you'll know why revenue breaks when currency is missing. If you understand that user properties describe the person, you'll segment correctly. And when a stakeholder asks for a new report, you'll know whether it's a new event, a new parameter, or just a new view of data you already collect.

1:14 The receipt analogy

Here's the core idea with an analogy. Think of a receipt from a coffee shop. The event name is what happened: purchase. The parameters are the lines on the receipt: the items, the price, the currency, the branch. And the user properties are on the loyalty card: gold member, prefers oat milk. The receipt describes one moment. The loyalty card describes the person across every visit. Ask yourself one question every time: does this describe the action, or the person?

1:49 Four families, in priority order

Events come in four families, and there's a priority order. Automatically collected events are sent by the Google tag by default, like first visit, session start and user engagement. Enhanced measurement events are toggled on in the web stream, like page view, scroll, outbound click, file download and site search. Recommended events are ones you implement using Google's predefined names, like sign up, generate lead and purchase. And custom events are your own names for things nothing else covers. Rely on automatic, enable useful enhanced measurement, use recommended wherever it fits, then fill gaps with custom.

2:31 Parameters

Parameters are where the insight lives. An event name alone tells you that something happened. Parameters tell you what, where and how much. On a freight quote calculator, you might send product line, origin country, destination country and a quote band, like one thousand to five thousand, rather than the exact amount, to keep the number of unique values low. And remember: most custom parameters must be registered as custom dimensions before they appear in reports. Collection and reporting are two separate steps.

3:07 Engagement definitions

Now engagement, which replaced the old bounce rate thinking. A session starts with session start and ends after thirty minutes of inactivity by default. An engaged session lasted longer than ten seconds, had a key event, or had at least two page or screen views. Engagement rate is engaged sessions divided by sessions, and G A four's bounce rate is simply the inverse. That's more meaningful than the old single-page bounce. A reader who spends three minutes on one article and leaves is engaged.

3:44 Identity

And identity, briefly. G A four can recognize users with a user id you provide for logged-in users, with device identifiers like the first-party cookie on the web, and with modeled data where consent is denied, depending on your reporting identity setting. So user counts will never exactly match other systems. Explain that to stakeholders early. Chasing perfect reconciliation wastes time. Aim for consistent, directionally reliable data, and document how users are counted.

4:16 Example 1: recipe publisher

First example, a simple one. A recipe publisher sees healthy page views but flat newsletter sign-ups. With the event model, they check three things. Scroll events by page: do readers reach the sign-up box near the bottom? A custom event when the sign-up box enters the viewport, compared with sign ups: is the problem visibility or persuasion? And the method parameter on sign up: do inline forms beat pop-ups? Illustratively, if few readers ever see the box, moving it higher is a better first test than rewriting its copy.

4:55 Example 2: Gulf freight portal

Second example, a business case. A freight portal serving the UAE, Saudi Arabia and Pakistan tracks one calculate quote event with origin, destination, product line and quote band, plus a customer type user property: new, returning or contract. One exploration now answers three questions that used to need three separate custom events. Which lanes are most requested? Which quote bands convert to bookings? And do contract customers behave differently from new ones? Good parameters replaced event sprawl.

5:28 Watch me do it, part 1

Watch me send that event. With the Google tag on the page, I call gtag event, calculate quote, and pass an object with product line freight, origin a e, destination p k, and quote band one thousand to five thousand. I call it after the calculator returns a result, not on the button click. When the user logs in, I set a user property, membership tier pro. And for logged-in users, I pass my own internal, non-personal user id in the config, subject to consent and my privacy notice. Then I open DebugView and confirm the event arrives once with all four parameters.

6:13 Watch me do it, part 2

Now the same event in the raw BigQuery export. Parameters live in a repeated field called event params, a list of key and value pairs. So to read one, I use a small subquery: select the string value from unnest event params where the key equals product line. I count quotes by product line for one day's table and sort them. Seeing that raw structure once makes the model click: every event is a row, and its parameters are a list attached to it.

6:50 Common mistakes

Common mistakes. Treating G A four like its predecessor and looking for category, action and label. That model is gone; use meaningful names and parameters. High-cardinality parameters, like full timestamps, unique ids or free-text search terms in general dimensions, which bloat reports and trigger the other row. Setting user properties once and never updating them. And sending value on non-revenue events, then summing revenue that never happened.

7:19 Quick reference

Here's a quick reference you can keep. Describe the action with the event name, verb then object. Describe the context with event parameters. Describe the person with a user property. Identify a logged-in user with your own internal, non-personal user id. If you remember nothing else from this lecture, remember that four-line map. It answers most design questions in seconds.

7:45 Recap

Recap. G A four collects everything as events, and sessions and users are derived. Use the four families in priority order. Parameters carry the insight, and most need registering before they appear in reports. User properties describe the person. Engagement is defined by time, key events or views. User counts won't match other tools exactly, and that's fine if it's consistent and explained.

8:12 Try this now

Try this now. Pick three events on a site you know. For each, write the event name, three useful parameters and one user property that would help segment the analysis. Then check whether any of your parameters would have high cardinality, and band them if so.