How to Create Effective Product Funnels with Event Tracking

Regardless of how mature the product is, its owner will always be curious about how it performs, what the conversion rates are, and what areas for improvement there are. One of the most important tools that product owners should get access to at some point in time is an event tracking system.

Table of Contents

1. Why an event tracking system is important.

2. When to implement an event tracking system

3. How to implement an ETS

   1. In-house vs existing solutions

   2. Architecture of event-tracking

   3. Operationalization or Make it work

4. Conclusion

Why an event tracking system is important

Implementation of event tracking will allow businesses to get scientific answers to lots of product-related questions, such as:

• At which stage of the sign-up journey did I lose most of the users?

• What would be the conversion rates if I split users into 3 groups and showed them different checkout buttons?

• Is it true that the performance of my product depends on how it’s been implemented by various clients?

When to implement an event tracking system

In my previous article, I described how to set up an environment to perform experiments with your product. The approach I provided there implied that one can reuse existing information resulting from core data flows as part of backend architecture. Doing so will be especially beneficial for the products at the early stages of development.

At some point in time, the product reaches a stage when it can no longer be sustainably developed without relying on data. Therefore, enhanced event tracking is applicable to more mature products. The table below systemizes the recommended practices for product analytics depending on a stage of maturity:

How to implement an ETS

Decide if in-house implementation works for you

To begin with, you should decide whether it should be an already existing solution or built in-house. When making a decision, one should consider the following 3 factors:

• Availability of resources: From my experience, end-to-end implementation of event tracking (from the beginning until the moment you will see the first events recorded in production) will take around 3 weeks for 1 mid-senior frontend engineer. On top of that, several weeks of dedicated data engineering and analytics teams’ support will be required to turn obtained data tables into nice and insightful dashboards.

• Cost: in-house solution will require an initial one-off cost to implement, but will allow you to achieve good economies of scale in case your product will keep developing. In case your company will later introduce new products and services, it will also benefit from existing solutions almost out of the box.

• Flexibility: if your product is developing at a fast pace, think twice about whether an already existing on-market solution will allow you keep the required degree of flexibility in terms of supporting every change.

To summarise, developing your solution in-house has certain benefits in the long run, however as mentioned in the beginning, it’s highly important to select the right moment for implementation.

Proper timing will allow you to ensure that all factors are considered:

• You have enough resources

• You are confident that this project will yield you a positive return on investment

• You believe that your product and company overall will keep growing and all future projects will benefit from the event tracking

Further parts of this article will be focused on the implementation of in-house solutions. In case you decide that procuring an existing solution works better for you, you should expect that it will provide you with an end-to-end experience.

Architecture of event-tracking

While designing your solution, the most important thing is to decide how you want to see your data.

The most common approach relies on 3 main concepts:

1. Event, which can be defined as a combination of:

   1. Object, e.g. “Order” button

   2. Action performed with the object, e.g. “Shown to user” or “Clicked by user”. Therefore, several events can be associated with the same object within the same user journey.

2. Session, which represents a unique and uninterrupted interaction of the user with your product, where interruption can be either:

   1. achievement of some event

   2. X minutes of a user being idle
      

3. Parameters of events, which can be used to pass any other relevant information and which can be added to your events at any point in time. The most typical parameters you may need are:

   1. Timestamp of event

   2. id of the user (if known)

   3. Device type (iOS, Android, Windows, …)

   4. Experiment-related information. For instance, if you do A/B test, you can pass information on which group user was assigned to. Based on this data you can calculate the performance of each group in terms of conversion and choose the best option.

From a data flow perspective, it is rather straightforward. Whenever the user performs an action you are interested in, your library should call the corresponding endpoint and pass relevant data there within the request payload. For instance, the user presses “Create order” button, which triggers the request (illustrative):

Request URL:

https://eventtracking.yourpoduct.com/WebTracker/RecordWebEvent

Request payload:

• Session_id = abc 

• Event_object = OrderButton 

• Event_action = Clicked 

• Parameter_1 = Value 

• …

Operationalization or Make it work

Fire the first set of events:

Once you’ve got the infrastructure to fire events, it’s time for the most practical step: you have to understand the exhaustive list of events you need to see. Although it takes time, this procedure is necessary if your end goal is achieving visibility on what’s happening with your product.

A suggested approach is the following:

1. Understand all the (sub)-flows your product has (e.g. quick flow for existing users vs long sign-up flow for new users)

2. Refresh your knowledge of the flows by manually going through each and recording screencasts

3. Carefully review your recordings and for each flow prepare a spreadsheet outlining all the events that you need to track. The structure of the spreadsheet can be like this:

   1. Type of flow (e.g. existing users)

   2. Event object

   3. Event action

   4. All parameters with possible values

4. Discuss the spreadsheet with your Frontend engineer and make sure that all the data you need can be tracked. Bear in mind, that you will be able to add some events in subsequent iterations

5. Finally, ask your engineer to start firing the events in a production environment. It’s not necessary to include all possible events in the scope of the first iteration. Focus on the most important ones that are needed to get insights and test hypotheses.

Double-check

Once the first iteration is done, it is crucial to make sure that everything works in the correct way. It is easy to get overwhelmed by the number of events you have and miss the gaps. The most reliable way to double-check is:

1. Repeat the step when you went through all flows and recorded screencasts. However, at this time make sure you also save the session id for each flow you are going through (can be easily copied from the network tab of your browser’s console). You can use session id as a title for each screencast for simplicity.

2. Wait until the data on events recorded can be accessed in the database (usually, it’s not immediately)

3. Query the events tracked for each session you have. The dummy example of the query would be:
   select * from your_product.events_recorded
where session_id = ‘your saved id for each flow’ 

4. Compare the results of your query with your corresponding screencasts and come up with a list of all gaps (most likely you will observe some).

5. Reach out to your Frontend engineer to close the gaps.

6. Repeat this procedure until you are confident that all events are tracked properly.

   Construct first funnels (visualize insights)

   1. Ask a question

Start by asking the main questions you have regarding your product:

• At which stage of the signup flow users are mainly dropping?

• What is the reason for existing users not reaching the end of the journey?

• Which parts of the UI will I most likely experiment with? E.g. titles of the main Call to action buttons

  2. Prepare mock-ups with dummy data

Based on the key questions you have, you can create mock-ups of your funnels and see if those would be sufficient to satisfy your curiosity. It’s always a good idea to visualize what you want to see before reaching out to the data team.

3. Calculate and sense check

Once visuals are sorted out, don’t hurry by jumping straight into making ‘fancy’ funnels. Instead try to calculate all the pieces of data (for a selected period of time), which make up the funnel in a separate spreadsheet to see if the data makes sense.

Try to be as critical as possible:

• Some inconsistencies would immediately get your attention. Make sure that once events are sorted and aligned to user journeys, it’s always a declining trend.

• You can also triangulate against different sources of data. For instance, compare the number of orders created from your database to the number of events when the last screen was shown. Clearly, the number of events should exceed the number of orders created. If it’s not the case, then you are missing some events

Once done, you can proceed to the final step.

4. Construct the funnels you need based on mock-ups and queries you used for sense check

Set up clear procedures for the future

Don’t settle once you are done with covering all key user journeys with your event tracking-based analytics. Most likely, your product will be changing in the future. One should be very cautious in order not to lose the results of great effort that has been put to set up the event tracking. To achieve that, make sure you have an exact procedure in place with all relevant parties following it.

The procedure could be like this:

1. When you or your designer start working on new user journeys, make sure that all changes to the existing product are explicitly highlighted.

2. Communicate the changes to your frontend team that will be updating UI, and make sure all the new events will be sent, while irrelevant events to be deprecated. Having a spreadsheet as a tracker for new/ deprecated events could be useful for you.

3. Aware your analytics team that datable will contain new events, which should be incorporated into subsequent funnels.

4. In the end, you as a product manager should be responsible for results and making sure that  current funnels still make sense. Usually, it should be the case unless you don’t introduce significant updates to your product.

Conclusion

To sum up, the implementation of event tracking will be a significant enhancement of the product owner’s toolkit. However, one should be reasonable when deciding if the product is mature enough for that.

A simple rule of thumb to decide: if you can come up with a substantial “no-brainer” backlog of improvements for your product (which don’t need to be ‘scientifically’ proven), then it’s most likely not yet mature enough for the event tracking, and you have more important things to spend your resources on.

Once the product is ready for implementation of event tracking, its owner should understand that it could take a while to achieve the end state. Be prepared for numerous iterations and attempts to resolve inconsistencies.

Finally, getting to the end state can be tough. However, losing progress is much easier. In order to avoid the loss of fruits of your labor, you should have a strict and precise procedure for updating your event gathering and analytics whenever something is being changed in your product.