Events are a reflection of how customers interact with our products. It can be anything from a page view to a button click, closing a page or filling out a form, etc. By tracking events, we can monitor these customer interactions.

Why do we need events?

“If you can’t measure it, you can’t improve it.” – Peter Drucker.

As product ninjas, we track events to measure our customers’ interactions so we can identify friction areas, make informed decisions, trigger specific flows based on customer behaviour, and gather early signals on the possibility of achieving business/product goals.

Problems with how we initially tracked events..

We haven’t always had a good grasp of our events, at some point, we had logged almost 1,000 events, but we could barely get one coherent insight or make one informed decision through it. It was the real ghetto. Taking a leaf from Crystal Widjaja, here are the problems we had:

No shared language.

We didn’t have a uniform language regarding how we logged events. Each platform (iOS, Android, and web) and engineer logged events as they felt like it in a way that made sense to them. We were not working as a team with a shared purpose. We didn’t consider how our customers interacted with our products, and we didn’t have a dictionary to guide us so that anyone could easily refer to it to get started or find their bearing.

Inability to act on data.

We couldn’t generate insights from our events data, hence we couldn’t make any decisions with it. We had data, but we were still working blindly. Putting together a simple funnel felt more difficult than climbing Mount Everest.

Distrust of recorded events and difficulty with the tool.

Not having a shared language or purpose trickled down to how much trust we had in the events that we recorded. We constantly had to go into the codebase and reach out to engineers to ask for what events we could work with to get particular insights or visualize a specific funnel. We also didn’t have a tool that was easy to work with. We tried Google Analytics and struggled a lot until we eventually abandoned the entire thing.

Made tracking the goal instead of insight generation.

Tracking events is a means to an end, not an end in itself.

We took it as the ultimate goal, so we erroneously tracked everything as events (I’ll talk about how to log extra data without bloating your events). Focusing on tracking alone is why we had almost 1,000 events but could barely interpret the data.

Wrong level of detail.

We tracked events in a way that was too broad or too specific. For example, we had events like LOGIN_BUTTON_CLICKED_RT to help us tell when an existing customer was attempting to log in. It was way too specific and would eventually impede our ability to visualize the login journey for our customers properly. (I will share how to arrange your data to have the right level of detail later in the article).

How we currently track events.

We are now in a much better place with tracking events, and these are some of the things we did that made a difference.

We developed an events dictionary.

The events dictionary serves as our single source of truth, mapping out and recording events before and after we implement them. It highlights things such as:

The product area. We have onboarding and registration, which cater to our sign-up and login journeys. We also have our savings and investment product areas like Money Duo, which allows couples to conquer money goals together.
The flow. Is it a sign-up flow, a login flow, a creation flow, etc? This is similar to how you have an activity or themes layer when creating user story maps. (Note: This is optional, and we introduced it as we worked on our event tracking process.)
The events which are the names of the key actions a customer performs.
Trigger conditions to indicate when the event should be logged.
The parameters or properties to help us get more details about the event.
An example parameter or property value i.e. a list of possible values that can fall under the property.
An image of the screen showing when the event and property should be logged.
A status column to indicate if the event is in review, ready for implementation, has been implemented or deprecated.

Having a shared language which involves a naming convention for your events, property values, etc. Examples of naming conventions you can choose from are sentence case, camel case, all caps, snake case, etc. We currently use {{SNAKE_CASE for event names, e.g., PRODUCT_SELECTED}}, {{camelCase for our property names, e.g., selectionPoint}}, and {{snake_case for our property values, e.g., home_screen}}.

The event name should describe the customer’s action in a way that they might define their actions or a way that you and your team would typically speak of such an action. Don’t make it too broad or too specific, either. For instance, you will naturally say “Sign up successful”, not “Facebook Sign-up successful”. The former works best.

Focus on the end user.

Who are the end users of your tracked events or metrics? This is super important because if you don’t know them then you cannot accurately build for them. More often than not, you will have a mix of technical and non-technical people as your primary audience, i.e., product managers, marketers, engineers, business folks, and so on. This means you must ensure that whatever process, systems, language, and tools you put in place make the learning curve easy to navigate; otherwise, you’ll find that it doesn’t get adopted. Build your events for your primary audience the same way you build your products with your customers in mind. Your data is a product too.

Consider the goals and connect product experiences.

When mapping out your events, primarily consider your goals from business, product, and marketing perspectives. Tracking for the sake of it is not the key focus; instead, you track because you need to make confident decisions and perform certain activities. Have clarity on the decisions and questions you might have, then map your events to be able to help you with them. For example, suppose we’re interested in growing the number of customers who buy food on a food service app. In that case, we might have questions about what makes a customer not complete their purchase, where they initiate their purchase from, etc. Consider the different experiences that can lead to a customer completing or abandoning the action you need them to take and map your events around that.

Track journeys (success, intent & failure events).

Mapping out your events should be done based on journeys. The aim for you is to tell a complete story of how customers move from point A to B. Three kinds of events you typically want to ensure you cater for are:

Intent Events: The actions a customer takes to indicate their intention. For instance, if you’re tracking your sign-up journey, an intent event would be SIGNUP_SELECTED. This tells you that a potential customer intends to create an account or register with your product. If your focus is perhaps around a search flow, you might have an event titled SEARCH_STARTED or SEARCH_SELECTED, meaning that a customer was possibly looking to start a search. The intent events also serve as a way to know what path customers take to complete an action.
Success Events: These events tell you a customer completed the action they set out to do. For example, we can have our success event as SIGNUP_SUCCESSFUL for our account creation journey.
Failure Events: These events tell you if a customer did not complete the action they set out to do. For example, we can have our failure event as SIGNUP_UNSUCCESSFUL or SIGNUP_FAILED for our account creation journey. In crafting this, consider things that count as indirect failures and direct failures. Indirect failures would be when the customer drops off before completing the action they started, while direct failures would be when something goes wrong with the intended experience customers should have while completing the process. You create events for the direct failures, while the indirect failures can be deduced as you analyze the customer journey from the intent point to the success point.

An example journey for how customers perform search:

SEARCH_SELECTED: triggers when a user selects the search button on a page.

SEARCH_TOPIC_INPUTTED: triggers when a user inputs text in the search field.

SEARCH_SUCCESSFUL: triggers when a user gets an output returned to them based on the search topic they inputted.

SEARCH_FAILED: triggers when a user gets an error response returned to them while attempting a search.

With the above, we can have insights into how many people complete a search flow, where people drop off and what issues they experience when a search action fails.

Go deep with properties.

Properties are helpful data to collect to help make your events more actionable and segment them. You use properties to get more insight from your tracked events. One mistake we made with our past methodology was to track a segment as an event. To segment new customers logging in from existing customers logging in to the app, we had a LOGIN_BUTTON_CLICKED_RT event. We should have had LOGIN_SELECTED and then had a user property such as userState to help us segment between new or existing customers.

You build properties by considering what details you want to associate with an event. What further questions would you need to answer? For instance, with our SEARCH_SELECTED event, we want to know where customers tend to go to begin a search action. Is it by clicking the search menu option on the bottom bar of our app? Is it the search icon at the top of our home page or anywhere else we make the search option available? To help with this, we can have a property tied to our SEARCH_SELECTED event that says “selectionPoint” and collect data for where it was triggered.

Some helpful questions to have in mind when defining your properties are:

How will I segment users and on what conditions do I want to segment them e.g. based on demographics, product behaviour, device, persona, marketing campaigns?
Do I need to identify the paths users take?
Do I need data to compare and contrast between different user types or between users who completed the action from those who dropped off?
What do I want/need to know about a user’s experience on a particular screen or point where an event gets triggered?

Tip: Whatever property you log might need to be logged for each event within a journey so you can carry on the segmentation across the entire flow and not just at one point. For instance, if we logged selectionPoint as a property for the SEARCH_SELECTED event, we should typically log it for the other events within the journey, i.e., SEARCH_TOPIC_INPUTTED, SEARCH_SUCCESSFUL and SEARCH_FAILED.

Conclusion

According to Crystal Widjaja, a pressure test method to apply when tracking events is to always ask yourself, “Imagine I did track this, and 99% of users did it; what would I do about it? What does it tell me?” If you can’t find something actionable from this, then you likely don’t need the event.

Keep in mind that your event dictionary is not one-and-done; it needs to be updated to reflect new paths as you make changes to your product.

As change is constant with your products, you’ll find the same to be true with your event-tracking practice. Don’t stop iterating. Constantly review your methodology and process to ensure it serves you and works well with your reality as an organization. As you look to track events to help you improve your product, also ensure that you pay attention to your process. Remember, what you don’t measure, you can’t improve.

How we analyse events for a better product.