A better approach to improve your prospect insights
When developing a digital app (web or mobile), tracking your audience helps to understand the various use cases of your prospects/users.
However, it’s too often under-estimated and needs lots of corrections: lack of data, non-relevant pieces of information, …
This article is about tracking your users of course but it also introduces a disruptive way to get more information about their journey on your app. Indeed, with this new approach you will be able to make your tracking strategy extensive and provide more data. Moreover, you will be able to use historical hits: meaning that previously unrelevant user actions (hits) could be used now as qualitative data for your reports.
What is tracking ?
Tracking is inspecting the interactions a unique visitor performs when browsing on an application (whether it’s a website or a mobile app).
In other words, it is the fact to follow and log user actions to understand his/her behavior: where your audience clicks, how much time they spend on a page, until where they scroll on the page and so on…
Some libraries and platforms pretend to be able to determine the mood and the personality of the user (such as dotaki) so that you adapt your app to your audience.
Optionally, mixing A/B testing with tracking is a good bet to determine the most appropriate version of a feature or the app visual appearance to trigger a WOW Effect to your customer. If you are not familiar with A/B testing, here is a link to explain this concept:
A/B testing (also known as split testing or bucket testing) is a method of comparing two versions of a webpage or app…
Why do we track prospects?
Tracking is super important to understand how the users react to your app. It allows you to log every actions they perform. Thanks to all these hits (actions), you can:
- Determine the most visited pages
- Discover the most used features
- Analyze the various contexts of your visitors (device, language, location, …)
- Find out new personas, new user experiences
This is the overall concept. Now, we need some data to make it happen. We need to fire and save events when the user interacts with your platform. That is why a tracking strategy must be defined.
Defining a tracking strategy
As we have seen, tracking a visitor is about inspecting his/her behavior. You can use mouse events, keyboard events or record the time spent on a page. Each one of these categories gathers several interactions:
- Mouse events: click type (left/right), number of clicks (single or repeated), scroll moves, mouse moves, highlights, …
- Keyboard events: inputs, arrow navigation, tab navigation, shortcuts usage, …
- Time spent on page: overall reading time, response times, waiting times (how much time the user accepts to wait), …
All these events occur in a specific context. For instance, when the user wants to log in or when he clicks on the BUY button. Therefore a tracking strategy or a tracking plan has to be defined.
The tracking plan consists in a list of contextualized events that will be inspected. Each one of them implies 2 perspectives: the event itself and the data.
The event is of course, the action the user should perform to trigger a tracking event. For example,
when the visitor clicks on the link to the product page.
The data (which is not mandatory) gives a context to the event. For example,
the email of the current visitor.
The couple event + data is a strong bound to understand the event occurrence. According to the previous example, we can determine if the current visitor is logged in when she/he is redirected to the product details page.
Obviously, this is a very basic example but you can get more accurate insights like download mobile app statistics on desktop version, user browsing preferences, the most visited pages, etc…
How to set a smart strategy
From a scoped and narrow plan…
As we have just seen, a tracking strategy is just a list of contextualized events. So, setting such a strategy is simply creating a list of events. The most common way to populate this list is taking advantage of previous projects. You just need to adapt your previous insights or events to get to take profit. Complementarily, you will have to reproduce all the user experiences a visitor might encounter. Each action will be an entry in the list of events. For each event, you will think and specify a dataset which will give a context to the event (an email, the list of previously visited product, …).
As a matter of fact, this approach concerns a set of determined (known) events with their corresponding datasets. We already know what to look for, what to inspect. We may name it the scoped and narrow tracking plan.
With a narrow tracking plan, we already know the features, insights and KPIs that must be monitored ️and then the associated events…
Thus, this scoped plan offers several advantages:
- It’s Focused: all events are defined and each one of them has a unique name, its own dataset. Therefore, no need for extra data. If there are missing data, maintenance is minimal and located,
- Easy to implement: once the connection with the tracking platform set (such as Segment), statements to send data are similar for all events
- Fast to implement: one single statement to send data
This strategy works well if you have a certain amount of insights to monitor. However, it’s not very extensive and it’s a pain to maintain. Amongst its drawbacks:
- Not very evolutive: adding new features implies updating the tracking plan (if tracking feature is planned
- Need frequent updates: maintaining events, dataset updates when there are missing metrics
- No history: if new events need to be tracked, it’s not possible to get their previous occurrences
Fortunately, a different approach exists and it solves all these drawbacks. The thinking process is inverted.
… to the percolation approach
The scoped tracking approach may be seen as a top-to-bottom strategy. As a first step, we define the metrics and analysis. Then, we build a set of relevant events to implement.
The scoped tracking plan is like a top-to-bottom strategy. To the contrary, percolation is the bottom-to-top way.
Yes, percolation is the bottom-to-top way. It consists in tracking all the possible events (clicks, navigation, scrolls, …). Of course, it will result in a huge amount of hits (events) that should be qualified thereafter. That means that every click, every page visited, every scroll movement should be tracked and then qualified ; meaning adding specific properties to make those events relevant and usable in a third-party tracking tool.
Additionally, a single and unique dataset will be attached to these events. This dataset follows the one-fits-all rule and eases updates and fixes. It will contain every relevant contextual data for each event. Therefore, it will provide the user email or the selected language even though it’s not really useful. The goal of it is to make this dataset as most reusable as possible.
The first step is called Data Acquisition. How to catch all these events and distinguish one among others?
As a matter of fact, if we log every click, scroll movement or keystroke ; we will get a bunch of pointless events (with a dataset the values of which may differ). To provide meaning to these user interactions and distinguish an event among all his friends, we need to assign it a unique generated name (an identifier).
I’ve adopted the cascading naming for every click so that it aims a specific element on the UI. Each dasherized part refers to a block of content. For instance:
In the dataset, we will be aware of which item has been deleted from the basket.
DISABLE is an indicator for the button state
Similarly, we can handle keystrokes with
KeyDown-Enter event names.
For now, what did we get? Well, we are able to track every user actions: clicks, scroll, keystrokes and the visited pages. We can also provide a context to these hits thanks to a dataset. This a large dataset, which is the union of the relevant properties of all events. Nevertheless, such an event is like anonymous because it’s just an unreadable name (as mentioned right above) with an unusable dataset. Thus, that’s where Data qualification phase sits in.
The Data Qualification phase allows to give a relevant name to the event. This name has an important role: it makes the difference between a pointless event and a recognized one. A recognized event will be used later in a third-party tracking platform to draw charts, funnels and many other visual tools that help to improve prospect insights.
To achieve this name allocation, a list populating all the relevant events must be maintained as much as the app evolves. In this list, an identifier is matched with the readable name and optionally static properties that can be added to the payload.
You can find right below a technical schema of the percolation solution with the 2 phases:
As mentioned before, in the first step (bottom part), we get has much data as possible. Then, in the Data Qualification phase, if the event is relevant (meaning it is found in recognized events list), we qualify this event: giving it a relevant name + extra properties.
Let’s see now the pros and cons of the solution:
- An exhaustive tracking: since we track every user actions
- History: once an event becomes relevant, it is stored as a recognized event (table in Tracking Middleware in the image above)
- Evolutive : new events or new data sources can be easily added
- Long implementation at the beginning: it requires some works first and then discipline when the product is maintained or evolved
- Defining all relevant events can be annoying at the very first time
How to maintain such a solution?
Well, it’s not that complicated: tech and product need to communicate.
As the product team specifies the new features or the current bug ; they must update the tracking with the event name and the additional static properties related to this event.
Then, tech people must update the events list (snippet in Data Qualification section) and the related template which will provide the identifier.
For further (technical) details, a dedicated article will be provided soon…