#36 Events, events, events – explaining the various GA4 event types

The Measure Pod

#36 Events, events, events - explaining the various GA4 event types

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 41:09

Apple Podcasts RSS Spotify YouTube

RSS Feed

This week Dan and Dara chat through all of the event types Google Analytics 4 has to offer – from automatically collected, to enhanced measurement, to customised.

The new EU data and privacy controls recently released in GA4 – https://bit.ly/38CtxwU.

The newest fields in Google Data Studio for the Google Ads connector for shopping campaign (including custom labels) – https://bit.ly/3rXkAVG.

The full blog post from Dan they mentioned that spurred this topic can be found on Dan’s website at https://bit.ly/3vOiete.

The event types they discussed are:

1. Enhanced Measurement
2. Automatically collected
3. Recommended
4. Custom
5. Customised (although Dara’s suggestion of ‘Dependent events’ is way better right?!)
6. Audience triggered

In other news, Dan decorates up and Dara goes full Viking!

Check out on LinkedIn:

• Dan – https://bit.ly/3JQKHEb
• Dara – https://bit.ly/3vzV0bO
• Measurelab – https://bit.ly/3Ka513y

Music from Confidential, check out more of their lofi beats on Spotify at https://spoti.fi/3JnEdg6 and on Instagram at https://bit.ly/3u3skWp.

Please leave a rating and review in the places one leaves ratings and reviews. If you want to join Dan and Dara on the podcast and talk about something in the analytics industry you have an opinion about (or just want to suggest a topic for them to chit-chat about), email podcast@measurelab.co.uk or find them on LinkedIn and drop them a message.

Transcript

[00:00:00] Dara: Hello, and thanks for joining us in The Measure Pod, a podcast for people in the analytics world. I’m Dara, I’m MD here at Measurelab, and I’m joined as always by Dan, who is an analytics consultant also at Measurelab. Hey Dan, what’s new in the world of analytics?

[00:00:31] Daniel: Hi Dara, so a couple of new things actually, since the last time we spoke the first and probably biggest one is that Google Analytics have released their response to the EU privacy changes and some of the tools that you can now use in GA4, to I suppose quote unquote, be compliant or at least not break the law. So a couple of things we’ll link to the article in the show notes of course, but predominantly it’s around controlling what data gets captured into the Google servers because they’re US-based, or at least owned by Google, which is a US company. And you can now start individually changing these settings per country including capturing things like device information, like operating system version, geographical location down to a city level, browser versions and things like that I believe Google use for their modeling.

[00:01:19] Daniel: Anyone visiting a website in the EU will automatically have their IP address redacted before it gets sent to permanent storage in the US servers. So that’s something that is just going to happen automatically behind the scenes, apparently going to roll out by the end of May. So yeah, hopefully addressing the concerns that came up over the last couple of months with different sort of GDPR representatives across the European Union, finding that this kind of stuff was not quite right.

[00:01:43] Daniel: There are a couple of other things as well, just to kind of reel them off very quickly. GA4 has released a slight update in the events report in the Reports workspace, where you can now mark events as conversions directly from that report, you don’t have to go into the Configure settings. And the last thing with Data Studio this time, the Google Ads connected to Data Studio has updated a bunch of fields for Google Shopping campaigns, specifically things like custom labels that you might apply in your shopping feeds. So you’ll be able to pull that data, that kind of rich data straight out into Data Studio to build dashboards off of, but that’s it really.

[00:02:14] Dara: Quite a big bit of news this week.

[00:02:16] Daniel: Yeah, it comes like buses. I think, you know, everything happens and then you would go silent for maybe two or three weeks, and then they’ll decide to release four or five updates again.

[00:02:23] Dara: Exactly, okay so onto our topic, what are we discussing this week?

[00:02:28] Daniel: Yeah, and this is something that I’ve been thinking about a lot recently writing a bit of content around and helping people to try and understand. But this is the understanding the differences between the different event types in GA4, so what we have heard probably a lot if you’ve been around analytics over the last couple of months or years even is the whole idea that GA4 is different. It’s a different data schema. And it’s the way that they explain that is that it’s event based not session-based. So everything in Google Analytics 4 is an event, which is great. You know, even things like sessions are session_start events and new users are first_visit events and clicks and purchases and all those other things. Everything’s an event and it’s relatively more straightforward to understand than something like Universal Analytics that leans heavily into sessionisation and hits and product and user and session scopes.

[00:03:12] Daniel: That aside that’s quite right, everything in GA4 is an event. However, for the people like us that are responsible for the planning, the implementation and the upkeep of GA4, there’s actually different types of events that can be implemented. And what I wanted to do today is just to go through those see if I can do my job as a trainer, as an educator, to kind of help understand or train you Dara on the different event types and hopefully kind of give a bunch of resources to our listeners who might be listening and kind of pointing people in the right direction on the ways to think about event types within GA4.

[00:03:45] Dara: Sounds good I’m always up for learning. And I know I’m not alone in thinking that it is a little confusing, the different event types in GA4.

[00:03:53] Daniel: It is confusing and actually the whole point of this is because it’s almost contradictory. Google has a lot of collateral that says everything’s an event. It’s like a simple way of thinking about things, but then when it comes to actually doing it, it then throws all these different types of events at you. So we might have heard things like Enhanced Measurement recommended, automatically created, all of these things have slight different definitions and all of a sudden you go from, oh, everything’s an event I’ll just track a bunch of events then. Then Google are like not so fast, you have to go through this process, this thought process, is it an Enhanced Measurement event or is it a recommended event? Is it a customer event? These things are throw up probably more questions than maybe the answers.

[00:04:30] Dara: So by the end of this episode, it’s all going to be crystal clear?

[00:04:33] Daniel: Well, if I do my job well or correctly at all then yes, but I think you will be the judge of that. All right, should we jump in? Should we start? Well, let’s do a bit of preamble and that everything in GA4 is an event 100%. However, not all events are created equally. So the way that I think about event types within GA4 is I start with the most common or the most frequent ones that you might come across and then drill into the more niche. So if anything, if you stop listening halfway through this episode, hopefully you’ve got 90% of the information at very least.

[00:05:05] Daniel: The first one I want to talk about is the Enhanced Measurement events. And you might have heard that or come across that, and that’s because anyone that has implemented GA4 for a website, when you set up a new web Data Stream, these are those automatic events that track things like scroll depth, page views, outbound link clicks, YouTube video interactions. And these are the things that are quote unquote, automatically tracked or all the way to think about it comes out of the box with GA4. And technically for the analytics people listening, technically that’s because the GA4 tag is a GTM container. It’s using the same technology, and if you’re as eagle eyed as I am you go in and you implement, if you were to look up the hard-coded Gtag of GA4 it’s actually a GTM, it’s a tagmanager.com domain.

[00:05:44] Daniel: So GA4 in itself is a GTM container and the way to think about it is that Enhanced Measurement events are prebuilt tags inside of this container. Obviously we don’t have access to that, but these are pre-built tags that will work on, you know, 90 to 95% of all websites that have this tag implemented. So the basic one is page views, right? So we kind of expect or assume that page views will be tracked with a web analytics tool. That’s the only one that you can’t turn off. But the other ones I kind of alluded to already are things like scroll. So this is when someone reaches 90% depth on any page and it’s automatically captured. We’ve got clicks, so these outbound link clicks. We’ve got YouTube video interactions, and we’ve also got things like site search, view_search_results events as well. So all of these things, we call them Enhanced Measurement because it’s basically a mini GTM container with a bunch of tags in there automatically capturing some kind of actions that are occurring on websites.

[00:06:36] Dara: Okay, I get it so Enhanced Measurement events are our first type and what I took away from what you said there is they’re almost like pre-built tags in GTM, so they do a lot of the interaction tracking. So you included obviously page view, you said you can’t turn off, but then you’ve got other optional events, like scroll tracking, interactions with YouTube videos, site search, all that kind of stuff that you would expect to track on a typical website.

[00:07:02] Daniel: Exactly, and this is where I feel that maybe even 9 out of 10 GA4 properties will probably just have this and stop at this point. If you’ve got no access to developers, even if you don’t use GTM itself, you’ll still have access to this kind of rich data. So in a sense, the kind of super baseline, vanilla, out of the box GA4 has these additional events captured, whereas Universal Analytics would just be the page view. So in a sense, it’s putting you a step ahead of vanilla baseline, Universal Analytics. So the way to think about it, is that anything like this, hopefully GA4 will expand this list over time as well, because the more things it can do automatically then the better, I suppose. Not that it will work on every website ever of course, you know, there’s going to be things like single-page applications (SPAs) it might struggle with, or other types of websites, where it’s trying to read and look for certain things like any GTM tag, the trigger might not match and might need to be tweaked, but in the majority of cases this will work out of the box.

[00:07:54] Dara: And can you edit them? Do you have any control over those enhanced events if you need to? So if it is a non-standard website, let’s you’re trying to track site search and the site search doesn’t quite work in the standard way. Can you go in and edit that to configure it for your website?

[00:08:09] Daniel: Yeah to some extent, it’s very basic editing. So the example you just said there around the site search, you can. The way that GA (Google Analytics) tracks site searches is by looking for a query string parameter in the URL that identifies the search term that was made. And that is exactly the same in Universal Analytics as well and it’s the same in GA4. There is a bunch of predefined query parameters it’s looking for. So a lot of the common CMS’s will have like ‘q’ and ‘search’ and things like that, which are kind of standard within the settings for that kind of stuff. But you can also edit it to add to your own query parameter if it is non-standard. So you can do minor edits like that. The things that I would love to see here are things like the scroll depth tracking, which is currently set to 90% depth on a page, it automatically collects. I’d love to be able to configure that percent as well. What if I’ve got a crazy long footer and it’s actually 50% of most pages and it’s just not going to be super, super useful for me to just have 90%. Hopefully those kinds of changes will come in the future but for now it’s super basic stuff. Super basic editing, rather for a couple of the events. I’d love to see some more work and development going on in the area.

[00:09:12] Dara: At the risk of jumping the gun here if you really wanted to customise that at the moment, you could create a separate custom event to do that.

[00:09:21] Daniel: Yeah, absolutely. You can implement whatever you want natively on your website or via GTM. And what’s nice about the Enhanced Measurement events is that you can individually sort of disable them and turn them off and on. So let’s say the scroll depth tracker just isn’t useful for you at all there’s no need capturing it. So you can just turn it off and maybe do your own implementation off that. The page views the exception, but actually this leads nicely into the next one, the next type.

[00:09:44] Daniel: So the first one was Enhanced Measurement events, the next one is something called automatically collected events. And automatically collected is the umbrella term that does include Enhanced Measurement. So I’m slightly cheating here by separating them out, but automatically collected is an umbrella term for anything that is collected, believe it or not Dara, automatically. And the Enhanced Measurement events are automatically collected however, you can disable them and enable them and edit them. So I kind of class them as two separate types of events. You have, your Enhance Measurement events are all kind of customised and edited over in one area of the UI. The automatically collected, you have no control over, they are going to be automatically collected.

[00:10:18] Daniel: So these are actually things like if you think from an app perspective, things like uninstalls or OS updates or in-app purchases. So things like that, so things that are happening to the device that are automatically collected into the data set, but you have no control over what that looks like and how that comes in and you don’t implement code to capture that. From a web perspective, there’s actually two ones that are really, I suppose, focused on when it comes to these automatically collected that aren’t Enhanced Measurement, and these are the first_visit and session_start events. And these two are really important because this dictates what we call or what we count as sessions and what we class as new and returning visitors in GA4. But actually there are no events captured on your website for first_visit in session_start there’s actually two query parameters within the request, the network request on the page_view event that basically identifies that page for you as a first visit or a session start.

[00:11:09] Daniel: So they’re automatically collected in the sense that they are automatically collected off the back of other events or other systems that you can’t control because you have no control at all over whether they’re captured or not, or in what state they’re captured in what event parameters are captured it’s all standardised out of the box, you have no say in the matter. And I think that’s why I differentiate between the Enhanced Measurement events and the automatically collected events, because the Enhanced Measurement events you can edit, you can turn off, you can adjust, you can add different parameters to those events if you wanted to using something like GTM. Whereas the automatically collected are ones where they just happen, you have no control over it, you have no say over it. So things like first_visit and session_start from a web perspective, but also going into the app world, things like in-app purchases, uninstalls, app updates, those kinds of things. Other ways to think about at least the differences between automatically collected and enhanced measurement.

[00:12:02] Dara: Yeah that helps me actually I think that was probably the area previously where I was the least clear. I wasn’t so clear on the distinction between automatically collected and Enhanced Measurement events. And as you sat there, Enhanced Measurement events include automatically collected events, but the automatically collected ones, you don’t have any control over, whereas you can toggle on and off the Enhanced Measurement events. I think it was interesting what you said as well about the first_visit and session_start events they’re not actually events themselves, they’re read from the page_view event. So their query parameters in the page view event.

[00:12:38] Daniel: Yeah and again, I’ll share links to all of this stuff because it’s just going to be more helpful to see this than listen to it. But if you are digging into the network request, using the console in the browser, or even using a Chrome extension to do this. The two parameters you’re looking for on the page view event are _fv for first visit and _ss for session starts. So you’ll see those as flagged as ‘1’ for when they are true and they won’t even appear if they’re not true. So you hopefully identify which page view events will have the first visit event or the session start event generated off the back of it. But actually this ties into a small, hopefully I’m thinking bug, I’m hoping they fix this at some point down the line, but any event parameters, any custom event parameters that you apply to your sort of page and your page_view event, don’t transfer over to the first_visit and the session_start event, which is a real important distinction.

[00:13:28] Daniel: For example, even things like campaign data. Let’s say when someone visits your website via Google CPC. That campaign information will not be attached to the session_start event, which feels odd, right? It feels odd, that’s it’s not attached to the session event. It’s actually attached to the first page_view event so the session_start event and I suppose the first_visit in the same context, they are kind of empty, raw, automatically generated events off the back of that page view. My personal preference and what I’d love to see happen as an, a kind of continuation of this as an advancement of this, I’d love them to inherit all the custom event parameters and all the other parameters that page view that originating page_view event has but for the time being, I think of it as a bug, but I don’t know if it is a bug, but for the time being, just bear in mind that those automatically collected ones. Those session_start first_visit events, they’re pretty empty, pretty basic, and actually probably a lot of the analysis you ended up doing off of the BigQuery data set is off of the page_view events, not off those two events.

[00:14:22] Dara: That does feel like a bug to me as well, but you never know whether sometimes these things are by design and we just don’t, we’re not aware of what the rationale is. You could obviously work around that in BigQuery but that’s not going to be an option for everybody necessarily. So it could be frustrating in certain cases, if you’re lacking that information where you want to see what type of page the session start was on or what type of pages your first visits tend to be too. So is there no way in the interface to do that at the moment?

[00:14:51] Daniel: No, those session_start events and first_visit events you just have to almost ignore in the analysis, which is very odd. So they are useful for kind of counters, how many times has this thing happened. However, it’s not very useful for digging into. So surface level from accounting metric, sure. But digging into the kind of context or the analysis of those events, they’re pretty empty. So especially if you’ve got a pretty mature set up of GA4 and you’re kind of expanding the defaults with a bunch of custom parameters and contextual information that you know is relevant for you and your business. That’s just not going to translate over to the first_visit in session_start events. So in a sense, you have to work off the page_view events. I would love, like I said, I’d love to see them kind of duplicate the event parameters that come the contextual data you’re passing in off of the page view event into the session_start and first_visit events, but it’s just not happening. So yeah, we are working around it with our clients in BigQuery it’s just not ideal and I just don’t, like you said, it’s probably not a bug it’s probably by design and it’s probably just a feature, quote unquote feature, to improve that down the line, but it just feels like it missed the mark slightly that’s all.

[00:15:53] Dara: Yeah okay, so that’s two of our event types covered.

[00:15:58] Daniel: Yeah, so that the next one is actually beyond the kind of automatically collected and I suppose, including within that, the Enhanced Measurement, and this is going into what if it’s not automatically collected. What if it’s not something that I can configure in the Enhanced Measurement events. And this goes into the third category, which is recommended events, what you’ll need to do and let me introduce the next two categories actually, because I have to talk about them in the same breath, and that is recommended events and custom events.

[00:16:22] Daniel: So, if it’s not automatically captured for you in one way or another, you then have to go and manually implement the tracking, whether you’re using the Gtag and hard-coding that on your website or whether you’re using the SDK in the app world, or whether using GTM to do the implementation it doesn’t really matter. The implementation actually doesn’t matter at all what the differentiation between recommended and custom events are, is the naming convention you use. So in a sense, Google have created a table of event and parameter names for you to use. And if you use that, it becomes a recommended event, and if you do not use that, it becomes a custom event. So in a sense, Google have tried to dictate as much as possible the names of all the trackers that are being implemented across every website and app out there. And the reason why this exists full stop is because if Google understands what the data is tracking, it can start doing some pretty clever stuff with it.

[00:17:13] Daniel: A really good example, really obvious example is things like e-commerce, like purchases, purchases have to be standardised, rather than calling them transactions, online shop purchase online visitor, or wherever we call them. These are all different names describing the same action. Whereas Google, for example, right now have a lot of predictive models baked in where they can do predictive purchase, predictive churn, predictive first-time purchases. It can only do that if it knows what a purchase is. And the only way it will know what a purchase is, is if everyone uses the same event name for that. So there is no such thing as Enhanced Ecommerce in GA4 there is no transaction hit type. It’s just an event like I said before, everything’s an event it’s just that some event might be called ‘purchase’ and Google knows to read that as a e-commerce transaction, which it can then put into some special set of reports, but also put through his modeling capabilities for it’s predictive models.

[00:18:05] Daniel: So that’s why it’s relevant, that’s why it’s useful to always use a recommended event if possible. Like I said in the same breath, if you want to track something on your website or app, that doesn’t meet the criteria for one of these recommended events, then just call it whatever you like and it becomes a custom event. There is no obligation to stick to the list that Google provides, it’s just that you might be missing out on some of the more advanced features down the line, but it doesn’t actually change anything.

[00:18:33] Dara: I remember using recommended events right the way back, even when it was Firebase for app tracking and the list at the time was, not saying it was bad, but it was pretty, it was like a first stab almost. If you’re in gaming, this might be the type of events you want to track. If you’re a travel company, this is the kind of event you might want to track. Have they expanded on that since, or is it still a fairly, I guess my question is, and this actually applies to automatically collected events as well. Are they growing these lists? Are they evolving them over time? So there’s more and more recommended events and more and more automatically collected events.

[00:19:05] Daniel: That’s a really good question and not that I’ve noticed. So the recommended events are, I could be wrong here, so don’t take my word as the gospel truth but from what I am aware it’s the same list than when they came out with GA4, they haven’t added onto that at all. But what it does do, it gives us a lot of generic names for things which is actually really handy. So for example, we have all of the e-commerce data. So purchases, refunds, add to cart, add to wishlist, remove from wishlist, remove from cart all those kinds of things are covered as one might expect. But what they also have is things like recommended event called select_content, is generic as hell, right – select_content. And this can be used for anything, this could be used for call to action, clicks on a certain content page. This could be header navigational stuff, we’re selecting content. I mean, everything’s selecting some form of content and then there’ll be an event parameter in there that identifies the type of content you’ve selected.

[00:19:56] Daniel: So they’ve gone super broad with the recommended events. They do have certain industry categories that you said gaming, online shopping. But they try to go broad and kind of cover as many bases as possible, but just give you some, almost some wiggle room within those by kind of keeping the names quite broad. I haven’t seen them change that or update that or improve that in any way since the launch of GA4. But the Enhanced Measurement events, I haven’t seen any change in or the automatically collected. I one would hope that they will down the line start to improve that. My two cents on that is that at the moment, they’re still trying to put fires out and get everyone up to feature parity and get everyone on to GA4 before they start kind of tweaking and improving these features that already work. Maybe we’ll be lucky, we’ll start seeing some improvements in this space going into 2024, 2025, but I probably wouldn’t hold my breath until then.

[00:20:42] Dara: You’d imagine once there’s enough people up and running fully with GA4 they can start to look at how it’s being used and if there’s very common, custom events being used, then they could either make the recommended events or even in some cases automatically collected events.

[00:20:55] Daniel: So those two go together really well right, recommended and custom events, because it’s almost like a checklist. Is it automatically collect? If not, is it recommended? No. If not go to a custom event. And I think that’s a nice workflow, it’s kind of like do as little effort as possible. Is it done for me? No, is there rules to follow? If not, then I create my own rules. When it comes to the custom events like I said before, you can track whatever you want in any which way you want it doesn’t really matter. There are some reserved names. So you can’t start any event with ‘ga’ or ‘firebase’ and you can’t start an event with just an underscore either. So there are some sort of reserved naming conventions that you just have to be aware of it. But again, I think these are so odd or niche that I think if you come across them, you’ll be very quick to find out.

[00:21:38] Dara: So on the recommended events, one reason to use them if it’s applicable, is for some of the, some of Google’s machine learning, some of the modeling, some of the predictions. Are there any other reasons why you would use a recommended event? Is it worth trying to make your events fit the recommended event structure, if possible, without making it, you know, too forced because potentially there’s other features down the line that might come that might also, because you’d have to assume wouldn’t you their recommending them for a reason they’re going to tie in maybe to other features as time goes on as well.

[00:22:13] Daniel: I think you hit the nail on the head with that. It’s about future-proofing potential changes with this down the line. We can see some way that they might be using that already. So in the reports workspace, in some of the reports, you see things like unique scrolls. So it’s identifying the scroll event, which is automatically collected so it knows the name of that. And it’s trying to identify a unique count of that to measure the performance of a campaign or the performance of a piece of content. So in a sense, by using these recommended events, hopefully they’ll integrate more of these unique metrics, don’t dare say KPIs, but they might be KPIs for you, but they’re integrating more of these metrics and these calculations of success because they know what it’s doing.

[00:22:53] Daniel: So we can see very small glimpses of the capabilities that they’re starting to integrate within the reports. Things like unique scrolls and things like that. But I would imagine down the line, there’s always been this talk of integrating a whole sort of e-commerce reporting set in there. At the moment e-commerce reporting doesn’t really exist that well, it’s just a standard report that has, you know, transactional ID or purchases or something like that it’s not very fleshed out as it is in Universal Analytics. So when they come to do the e-commerce reporting, one would expect using these standard events, these recommended event names, it will kind of pull it all into their funnels and do they kind of own pre-built analysis off the back of it.

[00:23:29] Dara: So would you recommend, because you said some of them are quite generic, like select_content, am I right in thinking it’s only the event name that’s recommended, that’s all you have to use to make it recognised as a recommended event. Is that right?

[00:23:42] Daniel: That is right but they do also have recommended event parameters too.

[00:23:45] Dara: So if you don’t, but I guess I’m always looking for the angle. I’m thinking, can you use the recommended event names for all your events and then customise to your heart’s content using event parameters?

[00:23:58] Daniel: Yeah, for sure. Absolutely no reason why not to, so you can use the recommended event names and the recommended event parameters, but then also add in custom event parameters onto that as well. You don’t have to stick to one or the other, you can actually customise the recommended events somewhat. So in a sense the recommended nature of an event is just a guide, a guideline of like, here you go, please why not. There might be some benefit to you immediately, there might be some benefit to you long-term we don’t really know just yet, but why not? If anything, it’s actually taking a lot of the efforts out of thinking about what do we call things? How do we structure things? How do we build queries and BigQuery off the back of data. Whereas now people can share code, people can share queries and reports because most people have a pretty standardised naming convention for most of the go-to events.

[00:24:43] Daniel: I think there’s more benefits there than just the Google might do something clever with it in the future side of things. I think there is a kind of community-based collaboration aspect as well, which can be really useful. But right now you have complete control, and that’s the reason I talk about these two types of events in the same breath is because they’re both implemented in exactly the same way the only difference is the name you’re using. So that the line gets very blurry between custom and recommended if you start doing what we just spoke about recommended event name recommended event parameter, but also add some custom parameters in there too, because where does that sit on the spectrum is somewhere in the middle, I suppose.

[00:25:16] Dara: Okay I’m clear and I’ve surprised myself in that I feel like I didn’t have as many gaps and this is I, as I thought maybe I did.

[00:25:23] Daniel: Awesome well, that’s the easy ones out of the way should we jump into the harder ones?

[00:25:27] Dara: Ah I should have known.

[00:25:30] Daniel: All right, so we’ve done Enhanced Measurement and automatically collected again, can be talked about in the same breath. We’ve got custom and recommended events again in the same breath they can be talked about. So the next one is something called customised events. So the customised a be a different from custom. And this is a brand new feature in Google Analytics 4 never was present or existed within Universal Analytics. But this is a feature where you can create events, fictionally, I suppose, off the back of other events that did happen. So let me try and explain that slightly better. As all of these events come through into the dataset, you can use some simple rules to identify if the event name is page_view and the page equals /blog, I can create another event called blog_page_view and add that to the user timeline, but the user never logged that event in their browser. So this is all completely, I suppose, server-side side in the kind of Google sense of things.

[00:26:22] Daniel: So you can use simple rules off the back of existing events to create brand new events to add as if they were tracked organically on the browser. So, this is a feature within GA4’s UI. You go to the Configure > Events screen, and there’s a big blue button at the top that says ‘create event’, and you go through the workflow there and again, we’ll link off to some resources on how to do that. But actually the use cases are really, really quite useful, but ultimately what a customised event is, is a fictionally created events of the back of some simple rules to create a new event off the back of an existing event or an, or a combination of event name and event parameters.

[00:26:58] Dara: And it has to be based on events, right? You can’t do it based on user property values or anything like that? Can they be any of the other type of events?

[00:27:07] Daniel: They can absolutely, yeah, because once the event gets inside of GA4, it doesn’t, like I said, there’s no context of what the type of event was, it’s just an event name and event parameters by that point. So again, the whole purpose of this kind of conversation and learning them is only from an implementation aspect. Once we’re using the data, including a feature like this they’re all treated exactly the same.

[00:27:26] Dara: I can’t help but think they could’ve come up with a better name. It’s too close to custom isn’t it?

[00:27:32] Daniel: I feel exactly the same.

[00:27:33] Dara: Dependant events or something like that, or, chained events, linked events, something like that.

[00:27:39] Daniel: Oh, I like that, chained events, that’s good.

[00:27:41] Dara: Google, if you’re listening, you can have that one.

[00:27:44] Daniel: There’s a good example I like to go to for this and, or at least justifying why they are important or can be important. Customised events can be really valuable because what you end up doing, especially with the automatically collected events is they’re so generic and broad, and they’re kind of catch all events and the same with a lot of GTM implementations too. It’s like I’m going to implement trackers across all hyperlinks across all forms submissions across all video engagements. And that’s great because you get all of that data come through to GA4, but what if I wanted to identify one specific video that someone engaged with, or one specific form that was submitted, or one specific link that was clicked and identify that as a conversion. And the conversion aspect here is the important part, because rather than going back into GTM and implementing another tag to track or double track I suppose that link or that form as another type of event of like important_form_submission, we don’t need to do that.

[00:28:38] Daniel: Inside of GA4, we can use the existing generic event of form_submission for example, identify the parameter, which might be the form name, imagine that we’ve got form_name as a parameter for that event. And we can then say if the form submission happens or a form_submission event occurs with this form_name then pull that out and create a new event called my_important_form_submission, and then that event itself can be marked as a conversion. And why marking them as a conversion is important is because conversions are what is synced with things like Google Optimize to optimize your AB tests and personalisations to. It’s also synced with Google Ads and Display & Video 360 and Search Ads 360.

[00:29:15] Daniel: So if I wanted to optimise any of my media or AB tests or optimisations to that form submission, there’s a really easy way for me to do that, and I don’t have to go back into the implementation. And that’s the real key important thing here is that I don’t have to change the implementation, which I suppose you think from a web perspective, but GTM (Google Tag Manager) is pretty easy for that kind of thing why not? If I know how to use GTM (Google Tag Manager), why would I not just go in, and sure of course you can. Why the hell not? If you’re comfortable in GTM (Google Tag Manager), go for it. But what about from an app perspective where any change to the tracking requires an app update to be published to the store. People have to download that and actually have to update their apps and start using it. That’s hard, that’s a long process to just get some conversion that you’ve just pushed a campaign live for today you need to quickly optimise to.

[00:29:59] Daniel: This, although has some huge benefits in general, is specifically relevant from an app context where you can quite quickly get conversions off the back of sort of subsets of your events without having to change the source code, which again, I can say from an app perspective is invaluable from a web perspective can be pretty handy.

[00:30:17] Dara: Yeah nice. It gives a bit of flexibility, a bit more control, like you say, just reduces the friction on introducing some of these conversion based events.

[00:30:25] Daniel: This one is number six and this is called or the audience triggered event. Well, this one is actually my favourite and I think it’s because of the possibilities rather than seeing it in practice. I love the idea of this event because what this event is, when you create an Audience in GA4, think of it as almost like a membership card. So a user will kind of hit a bunch of criteria they become a part of this Audience, they’re going to get membership into this Audience. And then after a certain time their membership expires, they might leave the Audience, but they might re-join the Audience if the conditions are hit again.

[00:30:56] Daniel: When someone enters an Audience, you can log an event into their timeline to say that they’ve joined this Audience and that’s the real power behind this type of event, because we think of Audiences, or I suppose from the Universal Analytics perspective, we can think of them as Segments, but we think of them as they can be starting from the kind of simple side of device = mobile. You know, that’s a Segment, that’s an Audience. We can create an Audience for mobile users. Yeah, of course that’s interesting, but what the real power comes in is when we start going a bit more deep into the definitions and the ways that we can identify a membership to these Audiences. So we can create sequences of events or user has to have done this and this and not this, and added this to their basket but not purchased, but they have signed up to our newsletter, but they haven’t visited our blog in the last seven days.

[00:31:41] Daniel: So we can add real, crazy deep combinations of these different criteria to identify membership. When that membership is achieved, then an event is logged into their timeline and that’s something you cannot do in GTM (Google Tag Manager), or at least cannot do easily in GTM (Google Tag Manager) – identify a history of a user, all sorts of things that have happened within a certain timeframe in a sequence of events, and then log an event for that user. It’s just really not feasible to do within something like GTM (Google Tag Manager). So you can now do that in GA4 you can log an event as someone enters membership into an Audience and that’s what the Audience triggered events are.

[00:32:15] Daniel: Well, how about, I’ll give you one example, and that is using the predictive modeling that we mentioned before. So with the predictive modeling that’s available in GA4 right now, actually they take a lot of shape within Audiences. So assuming you’re using the ‘purchase’ event, which are the recommended e-commerce events, you can then lean on to that and then Google automatically calculates things like purchase probability, and they can do their cool modeling. You can create a predictive Audience within GA4 so assuming you’re logging that event, you hit certain thresholds there’s actually, when you click create Audience, there’s the predictive section opens up and it gives you the access to those there’s different predictive models.

[00:32:49] Daniel: Let’s say there’s one model specifically that’s ‘first time seven-day purchasers’. So what is predicting is if this user is likely to purchase for the first time in the next seven days, which is pretty cool, right? When someone is identified as a predicted first-time seven-day purchaser, you could log an event into their timeline. There’s two reasons why this becomes useful, for one, we can export that stuff to BigQuery and see if they’re true and start validating their predictive models, which actually is something that we should probably think about doing rather than just trusting the black box. We can actually start validating this and to see if it is actually worth investing in or at least using.

[00:33:24] Daniel: But the other side is if you think about something that’s maybe a more considered purchase or let’s say the purchase duration, I suppose, from interest to purchase takes like two weeks, a month let’s say. If I run a campaign right now through, let’s say Google Ads, and I need to identify if my campaigns are working quickly because I’m spending thousands of pounds a day or something like that. I could instead of optimising to the purchase event, which has a lag of up to a month there, even though we’re using different attribution models and stuff, there’s still a lag before the first purchase might come in. If I could identify a predicted purchaser and optimise my campaign to that, I can quickly get a sense if I’m attracting the right visitors into the website. And if I’m not, I can maybe change my targeting so that in a sense you can have quicker or more real-time view of the quality of that user before they’ve even made the purchase.

[00:34:13] Daniel: So there’s a lot of faith, a lot of trust into the modeling for this, but you can use that event that we created off the back of a predictive Audience as a conversion and that can be used to optimise your Google Ads campaigns as a more real-time view of whether or not you’re attracting the right types of users before they’ve even made the purchase. Hopefully that makes sense.

[00:34:33] Dara: Yes, absolutely. So yeah as I said, I liked the Audience triggered ones, that’s a nice feature. Okay. I’m going to summarise, and that will be the proof of whether this makes sense, and whether it’s been clear or not and I’ll probably try and do a pretty truncated summary because that was a lot, we went into a fair bit of detail there with examples. So everything is an event in GA4, I think, you know, everyone who’s working with GA4 knows that. The kind of first type of event is Enhanced Measurement events, and these are for things, including page_view, but also additional interactions always web-based. So the things like scroll tracking, things like outbound link tracking, interaction with YouTube video content you’ve got on your site, and these can be configured on or off, except the page view which you wouldn’t really want to switch off. But even if you, for some reason did, you can’t.

[00:35:25] Dara: Within Enhanced Measurement events, you also have automatically collected events. The difference with automatically collected events is you can’t switch them on and off, they are collected automatically. And you have no choice about that. And this could include on the app side, it’ll include things like in app purchases, uninstalls, new app versions being updated and on the web side of things, it’s going to be things like first_visit, session_start.

[00:35:52] Dara: Then we have recommended and custom events, which are very similar. The difference being, if you use the recommended event names, then they are recommended events. If you don’t and if you go off piste completely, then they are custom events. And the reason why you might want to stick to using the recommended events, if you can, is because that’s going to be identified by Google and used in some of their predictive modelling, and potentially some other features down the line as well. But if you have completely unique event use cases and you want to create custom events you can do that, but you should probably try and use the recommended events as much as possible.

[00:36:30] Dara: Then you’ve got customised events, not to be confused with custom events. So customised events are where you can trigger an event based on another event. So if, for example, you wanted to say logging in event every time the blog page was viewed. So you’d use the page_view event with the type of ‘blog’, and then you would trigger another event based on that, to tell you that a blog page was viewed.

[00:36:54] Dara: And then finally we have audience triggered events, and this maybe is my personal favourite one. And this is where you can trigger an event automatically when somebody enters into an Audience that you’ve set up in GA4. So, in your example, you said that if you created an Audience based on people who have a likelihood to purchase, then you could optimise against that with your ad campaigns or even by optimising content on the website through AB testing for example. So that’s the six event types, how did I do?

[00:37:24] Daniel: Yeah very good, all perfect. And I really liked your recommendation or your suggestion to call the customised events, dependent events. I think that’s my favourite thing of this episode so far.

[00:37:32] Dara: All right onto our wind down. So what have you been doing in the last week or so to wind down outside of work?

[00:37:39] Daniel: So it doesn’t sound very exciting, but I suppose when do these ever sound very exciting. I’ve been looking at kitchens. So I mentioned a couple of episodes ago that we’ve recently moved into a new house, bought our first house. I’m currently exploring new kitchen ideas and starting to get into the swing of, oh, we could knock down this wall and paint this room. So we kind of got a paint can sitting ready to paint the bedroom. So that’s the next DIY project and we started to speak to people about a new kitchen as well. So yeah, I think it’s just more broadly DIY and riding this excitement or this high of like, Ooh, I can actually change this house and not get fined for it when I leave, but that’s what I’ve been doing to wind down is just starting, hopefully finishing soon but starting a bunch of different projects within the house.

[00:38:21] Dara: Good, good time of year to be doing it. Spring always feels like a good time for DIY and home improvements.

[00:38:27] Daniel: So I’ve heard, I mean, this is the first and only spring I’ve spent in the house. What about you, Dara? What have you been doing to escape from this world of analytics?

[00:38:35] Dara: Well I went to see The Northman last night at the cinema, the new, very gory Viking film, it was good I feel a bit mixed about it. So I felt a bit shocked coming away from it, it was very violent, which I guess is true to, I guess, historically accurate and I think that’s the point about the film is that they did try to be as historically accurate as they could, which unfortunately meant it’s a very violent film with not a lot of, not a lot of happiness in it. But it was good I thought it was the way it was shot was very stylish and have some amazing scenery, I guess it was all shot in, I know a lot of it was in Iceland and probably other parts of Scandinavia as well. And the soundtrack was really ominous and scary and kind of tribal. So it was dark and violent, but I think really well made and from what I’ve read about it, it was quite well researched and a lot of it is quite close to the reality of how things would have been. It definitely makes me appreciate being around now and not during Viking times.

[00:39:31] Daniel: I actually watched that film the other day as well and I thoroughly enjoyed it, but like you said, it’s not a super happy film. I love, absolutely love the Viking era of history, I’m a bit obsessive I suppose.

[00:39:42] Dara: Okay, so where can people find out more about you Dan?

[00:39:45] Daniel: So LinkedIn, just search my name, links in the show notes and also my website dananalytics.co.uk. Actually the basis of this conversation was a recent post that I did on my blog. So I’ll link off to that as well, which we’ll go into detail on all of the different event types and the examples, some of which we talked about as well.

[00:40:04] Dara: And you can find me on LinkedIn. No daralytics, I’m going to keep threatening this but I should probably get it and then just copy all your blog posts.

[00:40:15] Daniel: I bet you’ll rank higher as well.

[00:40:16] Dara: But yeah, you can find me on LinkedIn. Okay, that’s it from us for this week as always you can find out more about us over at our website measurelab.co.uk, or you can find the previous episodes of The Measure Pod at measurelab.co.uk/podcast.

[00:40:31] Dara: If you want to suggest a topic or come on The Measure Pod and talk to us about that chosen topic, reach out to Dan or myself or both of us on LinkedIn, or you can email podcast@measurelab.co.uk. Our theme music is from Confidential and you can find links to their Spotify and their Instagram in the show notes.

[00:40:51] Dara: I’ve been Dara joined by Dan. So it’s bye from me.

[00:40:54] Daniel: And bye from me.

[00:40:55] Dara: See you next time.