In this context, events document digital processes and can be tracked to uncover insights into how something (in this case, human users) interact with a digital product, device, or content.
Tracking events is how a business becomes data-driven in its approach to improving and optimising its business model, whether that be a B2C retailer selling products via a website, a B2B SaaS company selling software subscriptions or something else.
Events provide information on where users interact with the business and its product or service.
Deciding what events to track is foundational here, as there are hundreds or potentially thousands of possibilities.
Tracking too many events in one project is cumbersome, often unnecessary, and requires large teams with plenty of experience and resources. Tracking a select handful of precise and useful events is much simpler in practice.
Formulate Question for Analysis
Start with questions. Read this post on behavioural data for inspiration of what questions you can raise.
Think of your business model and what you need to improve. Data is there to help understand business problems and discover empirically robust answers that can then be used to optimise products, processes and user experiences. Data helps you understand customers and users without them telling you exactly what’s going through their head when they use your site, or discover your product, etc.
There are more than a few possible questions here, such as:
- How can I increase sales?
- How can I increase activation?
- Which landing page converts the most customers?
- How can I reduce customer churn?
- What types of customers are most likely to leave negative reviews?
- How many signups do I get in an average monthly cycle?
- What is my average customer lifetime value (CLV)
Some of these questions focus more on user properties whereas others focus more on events.
For example, “What types of customers are most likely to leave negative reviews?” is an investigation into what customer demographics and characteristics correlate with negative reviews. This is a relatively simple task, involving an analysis of user properties (e.g. age, location, gender) and correlating those with negative reviews. The findings might then prompt the development of a strategy to keep those most likely customers from leaving a negative review, e.g. via segmentation and targeted emails to that customer group which incentivise them to leave a positive review or discuss any issues directly with the business.
Other questions are likely just too broad, such as “how can I increase sales?” Whilst a cross-analysis of all sales channels, comparing various campaigns, adverts, and all sorts of other variables might provide some insight into how sales can be optimised across the entire business, this sort of question should be narrowed down.
A more focused example that focuses on events would be; “how can I increase sales of my most popular products using social media?”, which might involve tracking sales gained via different social media platforms, testing different content types and ads to compare their marketing ROI. User properties matter little here, it’s all about tracking events as a user is referred to a product from social media. It’s much easier to track single events across channels rather than all channels at once.
Signals and Answers
Each question is divisible into related events and processes. For example:
- Events that show user engagement and keep a user retained, e.g. multiple clicks and swipes across various pages and features within an app or product
- Events that indicate that a user is likely to purchase, e.g. they’re browsing products continually
- Events that indicate forthcoming customer churn, e.g. they haven’t used the product or service much over a given period of time
- Events that show a user is not deriving value from the product, e.g. they’re only using a small selection of features available to them
The basic premise is to take real-world situations and break them down into stages that event data can describe.
Here’s a worked example involving a subscription business model. A burning question many subscription businesses must address is “what can we do to reduce customer churn?”
Customer churn likely sits around 5% to 7% on average and measuring it is simple. All it is the number of customers that leave or cancel the product each month, reflected in a percentage.
The first question would be simply “what is our average customer churn?” which would involve taking a cross-section of customers over a month and dividing the lost customers by the total customers x 100. A business with 250 customers that lose 10 has a churn rate of 10/250 x 100 = 4%.
However, where this gets interesting is working out precisely when most customers churn, and who those customers are. This requires tracking, namely tracking the event data that details when customers leave and their user properties, e.g. their age, location, sign-up date, etc. After tracking when most customers churn each month, this can be cross-checked against the user properties of those churners.
It’d also be possible to dig into what churners did prior to cancelling, which might involve downgrading their membership tier or not using certain products for a period of time. Once those event signals are picked up, automated emails or messages could be set up to deliver deals or discounts to attempt to prevent people from cancelling their subs prior to the moment they’re most likely to churn.
Funnels of Events
Choosing interlinked events that sequence together is the best way to approach tracking in many situations, e.g. product or app analysis, sales or marketing funnel analysis, website analysis, etc.
Pretty much any swipe, click, view or any other interaction or process can be tracked. If we look at the typical sign-up flow, then we have the following:
- The user heads to the page and clicks ‘sign up’. We are ignoring events prior to this, e.g. where they clicked through from (SERPs, social media, ads, etc).
- This creates two events, the viewing of the sign-up page itself, and then click on the sign-up button
- The user then fills in their information and submits, which creates an event when the process is completed, which contains the event properties linked to the sign-up. But, the page view for the ‘sign-up completed’ page could also be tracked, as could the click on the ‘complete/register’ button at the end of the sign-up.
- In this case, it’s likely only sensical to track the event that confirms that the user’s data has been submitted to the database. If the sign-up process fails after the user presses the ‘complete’ button then the data is incorrect. A key example here is when a user hits the ‘finish’ or ‘complete’ button but the system highlights an error in their form submission (e.g. passwords didn’t match).
Client-side vs Server-side Events
It’s also crucial to understand the difference between client-side and server-side events. Events including clicks, swipes and views don’t usually rely on back-end processes, and are therefore client-side. They occur on the client’s device and are also called front-end events.
Contrastingly, server-side events interact with a database and rely on backend processes. They are also called backend events. This might be relevant to teams that require access to the front-end or back-end source and should be noted on the tracking plan.
Defining Events and Properties
Next, it’s time to properly define events and properties. This is where the data tracking plan comes together in a less abstract sense. Once you’ve generated questions, identified data tracking as the potential answers to those questions and have decided on what events intersect with those questions, it’s time to define events and their properties so you can begin tracking.
Data tracking plans conventionally revolve around events and entities. Entities are often users whereas events are actions, or tasks, that are performed by entities. E.g. Simon (entity) signed up (event) to the product. Simon, the user, has his own user properties (e.g. age, name, email address). The event also has its own event properties (or metadata), including timestamp, user IDs, email, etc.
The tracking data engineering process will vary hugely with basic tasks being possible to orchestrate using Google Analytics or natively with social media data platforms combined with website data (in the case of sales or marketing funnel analysis). Otherwise, using a CDP or CDI like Segment, mParticle, Rudder, Mixpanel, Amplitude or Snowplow might be the chief tool required to make sense of complex event data.
Below is a table of event names and corresponding properties and data types for some basic events. Each event is broken down with event properties and the likely data type, all of which should be noted on the data tracking plan.
Summary: How to Decide Which Events to Track
Event tracking involves a good deal of debate and questioning combined with the deduction and distillation of specifically relevant events that can assist in the understanding of that question. From there, it’s about implementing results and findings to optimize products, web design, sales and marketing funnels, user experiences, etc.
Event tracking is a fact-finding mission, hence why it’s called tracking. Once you’ve got a good quantity of high-quality, usable data, you’ll need to decide how to analyse and understand it prior to implementation.
What are events in data?
Events are transient processes or interactions that have a definitive beginning and end. Downloads, link clicks, swipes, form submissions and video plays are all examples of events. Events have event properties that break down the various components to that event, e.g. a form submission might comprise of an email address, name, date of birth, etc.
What events should I track?
Deciding what events to track for your data project is crucial to strike a balance between detail and simplicity. Too many events will crowd your systems (and your mind) and make analysis and implementation tricky. Too few events may fail to capture adequate detail on your subject.
What is data tracking?
Data tracking is the method and act of retrieving data from a system, either hardware or software and tracking the information provided therein. Tracking derives meaning from the data, allowing data points to be analysed and used for a multitude of commercial and non-commercial purposes.