This article is part of our "How To: Growth" eBook, a comprehensive growth toolkit for founders and builders, which you can download here.
Events form the backbone of web and product analytics. They help product managers decode user behaviour, marketers optimise their campaigns, and sales teams attribute revenue. You will have a very hard time using popular platforms like Google Analytics 4 (GA4), Heap, and MixPanel without first understanding how events work.
Event maps are documents that record all the events deployed in your product, along with definitions, associated parameters, and implementation details. All too often these documents are overlooked, leading to easily avoidable problems down the line.
This guide will explain why you need an event map, how to create one, and some of the most common/ important events by sector. But first, let’s get the concepts of events and parameters nailed down….
What are events and parameters?
An event is simply something of note happening, such as a user viewing a product, making a purchase, or completing a level in a game.
Parameters (sometimes referred to as Properties) are additional data points that describe, and provide context around the event. If the event is making a purchase, the parameters may include price, quantity and product ID, for example.
There are two kinds of parameters to be aware of - event parameters and user parameters:
Event parameters describe the event, as per the example above. If the event is clicking a button, the parameters might describe the button’s text or colour.
User parameters describe the user performing the event - which user segment they belong to for example, or whether or not they’re logged in to your service. User ID is the most common user parameter, as it is used to string sessions together.
In analytics platforms, events become Metrics, while parameters are Dimensions. Say you’re running an A/B test on a landing page where (boringly) A has a red button and B has a blue button. The Event (Metric) is button clicks. To compare A against B, you would apply the colour dimension to see red vs blue.
Why you need an event map
Analytics can get complex. Failing to properly document your events can lead to a whole range of problems, from the suboptimal to the paralysing.
Without a formal event map, team members may develop their own interpretations of key metrics. Does the sign up event fire when a new user clicks the button, or when an actual account is created? Without a source of truth, you can easily have two teams working with two versions of reality, or marketing teams optimising for outcomes that aren’t all that valuable. An event map ensures consistency by providing a shared definition of each event and parameter.
Ambiguity is especially problematic when communicating with developers. Without an event map, developers might not grasp what data needs to be captured and why. They might not realise the importance of capturing the "Product Category" parameter for a "Product Viewed" event, or misunderstand what the "Product Category" actually means, and pull the wrong field. Similarly, when discrepancies arise or tracking errors occur, the absence of documentation can turn troubleshooting into a Sisyphean task.
An event map can clarify these kinds of requirements, helping to bridge the gap between reporting objectives and technical implementation.
If an analytics expert leaves without handing over an event map, their successor will have to guess what the events mean, or painstakingly reverse engineer the implementation. They may even have to start from scratch. Similarly, new team members will have to waste time clarifying definitions, possibly across multiple departments. An event map serves as a reference document that encapsulates the collective knowledge of the team, enabling smoother transitions and continuity.
Failing to Capture Vital Requirements in Planning
Without an event map, it's easy to overlook critical details in planning. The importance of events like "Purchase Completed" or "Sign Up" are obvious, but some are less so, like "Coupon Applied" or "Product Comparison". Similarly with parameters, there may well be some vital contextual information for marketing, that won’t even occur to product or engineering teams. An event map provides a ledger to capture cross-functional requirements, ensuring every team can get the information they need.
Hopefully that’s done enough to convince you. Onto the practicalities.
How to Create an Event Map
To make your life easier, we’ve created a free template for you to populate, complete with examples and the process outlined below. You can access it HERE - copy the doc to complete your own.
Somewhat counterintuitively, it’s best to start at the end, ie. the outcome you’re hoping to achieve. Working with any relevant stakeholders (ie. anyone that needs data to do their job), you’ll first want to define the questions you're trying to answer, the information you’ll need to do that, and a sketch of the reporting dashboards you’ll want to build.
Here's a step-by-step guide through this process:
Step 1: Define Your objectives
Begin by defining the key questions you want to answer. For an e-commerce site, you might want to understand customer behaviour such as "What products do customers frequently view before making a purchase?" or "What's the most common path to purchase?". In a B2B SaaS context, you might be more interested in usage patterns, like "What features are most used by our most engaged customers?" or "Where do users typically drop off in our onboarding process?".
Step 2: Sketch your dashboards
This doesn’t have to be an exhaustive process, but mapping out how you want to visualise data can be helpful:
- If you’re displaying a table, what fields do you need to create it, and where are they coming from? Try not to make them too diffuse, or you’ll have a hard time pulling them together later.
- If you want to display something as a pie or a bar chart, ensure the metric can be split across that dimension (ie. if you want to split purchases by product category, product category should be a parameter for the purchase event).
- If you want to split traffic into logged in and logged out users, ensure you’re assigning a custom user ID at login and sign up.
Sketching can also be a useful way of engaging teams with the process - a picture paints a thousand words, etc. White boarding tools like Miro can be useful:
Step 3: Define Your key events
Using the steps above to guide you, list out the key user interactions that will help to answer these questions. These are your events (don’t worry too much about parameters for now).
Some events will be collected automatically (or via enhanced measurement on GA4). These are typically pretty basic (ie. view or click), although you can layer in tag manager variables to say isolate specific page views or button clicks. Unless you’re doing something along these lines, it’s probably not worth including them in your event map.
For most advanced tracking you will want to use custom (or recommended) events. You can find more detailed information about Google’s event types here - you can use the decision tree below for high level planning:
Thinking in terms of hierarchies can be useful here. Some events will be parent events with numerous children. For example, an e-commerce platform might consider "Purchase" as a parent event, while "Add to Cart", "Enter Shipping Details", and "Payment Method Selection" are child events. A hierarchical structure helps you understand how multiple interactions come together to form a user journey. It can also be useful to review IAs and Figma designs here, to uncover any less obvious steps and interactions that form part of the overall journey.
Step 4: Establish Naming Conventions
Some platforms will provide a suite of predefined event structures with specific naming conventions, like Google’s list of recommended events. It’s best to use these where possible as they cover a range of use-cases, and can even unlock advanced features. The e-commerce section in GA4 for instance, relies on manually setting up events like add to cart and purchase in line with Google’s naming conventions.
For everything else, use custom events and parameters. Decide on a clear and consistent naming convention for your events. Try to keep them simple, descriptive, and unambiguous. Stick to lowercase as custom events are case sensitive, and rogue capitals can cause problems when you set up your tag manager container.
It’s worth noting that you can add custom parameters to recommended events, so don’t feel constrained.
Step 5: Define your parameters
Next, you'll want to define the parameters associated with each event. Remember to split these into user and event parameters, and ensure that the parent/ child events share parameters where possible, as this will make it easier to dig into the details of user journeys by applying dimensions to a series of events.
Depending on the platform you’re using, some parameters are collected automatically, and will be applied to every event:
- Google captures language, page_location, page_referrer, page_title, and screen_resolution - documentation here.
- Mixpanel capture a lot via their SDK
- Heap captures basically everything - you just have to tell it what’s important
Be sure to add any custom or recommended parameter definitions to a separate tab, as this is where a lot of confusion can arise in implementation.
Step 6: Review and evaluate
You should review your event map against the requirements you gathered in stages 1 and 2, making any revisions where necessary.
Finally, you will need to brief developers around the implementation. Send them any documentation (most analytics platforms publish extensive resources), and ask them to review the event map in detail.
The most common issue you’ll run into here is availability of information. Say you want to capture a parameter like “Product ID” - that information has to be present in the code somewhere, otherwise you won’t be able to scrape it. In situations like this you may have to trim back the parameters, or move the events around to ensure you can get everything you need.
A quick note on the data layer. This is often referenced in documentation, and can confuse devs who haven’t worked on analytics systems before. The data layer is just a virtual container where all the data from your website or app is stored in a structured way. This data is what’s used to populate the parameters you specify - for more detail see Google’s documentation.
Key events to track
The events you choose to deploy will be unique to your product or service, however there are a few key events that will be relevant for most businesses operating in a particular sector. Here are a few of the most important:
The core of e-commerce is tracking user journeys from viewing a product, through to purchase. Google provides recommended events with these kinds of use-cases in mind, so use them where possible. Note the use of IDs, and consistent parameters across the user journey, where possible.
event: product viewed | parameter: product id, product category, price
event: add to cart | parameter: product id, quantity, price
event: purchase completed | parameter: total value, product id, quantity
Saas setups will be more bespoke as feature sets will vary between products. You will likely want to lean on custom events more, thinking in terms of comparative feature usage, and deeper events that explore how a user is using the feature.
event: custom feature use | parameter: feature name, user id, usage duration
event: subscription upgrade | parameter: user id, previous plan, new plan
event: login | parameter: user id, sign in method
Video analytics are all about tracking engagement. Google has a great system of presets around YouTube embeds, which you can use if relevant. If you’re using something else (HTML5 player or Vimeo, for example), you can just copy the setup using custom events. This guide by Analyticsmania is very useful.
event: video played | parameter: video id, video genre, user id
event: video completed | parameter: video id, video genre, watch duration, user id
event: ad watched | parameter: ad id, duration, user id
Google also provides a handy list of preset events for games. You can use custom events to fill in any gaps.
event: level completed | parameter: level id, time taken, user id
event: in-game purchase | parameter: item id, price, user id
event: game quit | parameter: level id, user id
As with videos, publishing sites will be interested in on-site engagement (clicks, scrolling, etc), along with more interactive activity like commenting/ sharing, and commercial interactions like signing up for a subscription.
event: article viewed | parameter: article id, category, author
event: subscription started | parameter: subscription type, price, user id
event: comment posted | parameter: article id, user id
After implementing your events, it's essential to validate that they are being captured as expected. Utilise your analytics platform's real-time event reporting features to test and verify the accuracy of event tracking; a bit of rigour can save you major headaches down the line.
Finally it should be stressed that while this guide is enough to get you started, treating your event map as a living document is crucial to maintaining its relevance and utility. As your business evolves, your data needs will change, and just as documenting software should not be an afterthought, any changes you make to your tracking should be reflected in the event map.
Sign up for product, growth and GTM development tips for innovators