UI Instrumentation at Pennylane, Part 1

How we designed our event tracking system

At Pennylane, data is at the core of our product and the decisions we make. We collect or produce data in many different ways, with many different goals and needs in mind.

A use case of particular interest to us is enabling our Tech and Product teams to better understand how our users interact with our accounting platform. Many questions arise on a daily basis, and being able to answer them swiftly is key to improving user experience:

• How many users use this feature?
• How do they interact with this feature?
• How long does it take for users to go through this set of steps?
• etc.

To answer such behavioral analytics questions, we typically need to define, collect and analyze actions — sometimes called events — performed by users on our app. While a number of tools on the market solve the event collection and analysis parts very nicely from a technical standpoint, defining what user actions entail and how they should be modeled requires a thorough understanding of the specific needs behind the approach, as well as extensive domain knowledge.

So in order to make sure the actions we track allow us to sharpen our understanding of users, we decided to focus all our efforts on characterizing them correctly — and tell you more about it — while leveraging existing wheels where possible! 🎡

Defining user actions

So how should we go about determining what the actions in our event tracking system should be? To answer this question, let’s take a closer look at our problem. At the end of the day, the aim is to provide insights to quickly answer frequent, high-level behavioral questions. These questions exhibit similar characteristics:

• they are about higher-level trends to support decision-making, not granular precision (coarseness),
• they are spontaneous and part of quick decision cycles (spontaneity),
• they are refined through iterations, and rarely formulated perfectly from the get-go (repeatability),
• they are specific to a part or feature of our app, which tends to be fairly different from one another (specificity),
• they are asked by stakeholders with varying levels of knowledge regarding the whereabouts of existing data (accessibility).

Lastly, on top of the nature of questions asked, as a general practice and requirement, we want data to be owned by the team that produces it because it has the deepest knowledge about it (ownership).

With this lens in mind, we can now start to design the appropriate event tracking system.

Existing approaches

Going through a review of best practices and tools currently available, we found two dominating approaches at the two ends of our spectrum:

1. “auto-tracking” — automatically recording any browsing actions,
2. “precision tracking” — manually recording specific actions.

Here’s where each option stands with regard to our requirements:

This comparison simply demonstrates that precision tracking is a better fit for our needs, and this is what we started with. However, it still comes at the cost of repeatability and spontaneity which combined together mean poor velocity, not an option for a customer-centric tech company, with the aim to maintain the highest possible velocity for our users!

Enter UI instrumentation

As we were thinking hard about the best way to join the benefits of auto and precision tracking, our design and frontend teams were making a lot of progress with putting together our “user interface kit” (UI kit). Simply put, it is a set of interface building blocks meant to standardize our application and offer a consistent user experience: buttons, tables, side bards, etc.

Building a UI kit represents a significant effort, that would probably not be justified by our user tracking needs alone. Once available though, it becomes the perfect instrument to track user actions in a simple, standardized yet customizable way! We’ll get into implementation details in a second article coming soon, until then let’s take a look at our requirements again; without strictly speaking ticking all boxes, this approach is very close to meeting all our requirements:

Yay 🎉!

Conclusion

UI instrumentation has enabled us to move fast and shrink the time it takes for our Product and Design teams to analyze trends and improve user experience, without compromising on data quality. On top of typical use cases such as monitoring the performance of our interface, or following the launch of new product features, it has also unlocked more subtle scenarios at a very low effort, for example easily identifying and routing specific actions to trigger in-app surveys.

Echoing the start of this article, this approach covers only one side of our picture, and still needs to be complemented outside of behavioral analytics — stay tuned for future articles.

Until then, we hope you’ve enjoyed the reading, and can’t wait to tell you more about our practical implementation in the second part of this short series!