Improving our frontend tracking with Avo

Mar 17, 2026

Data

Overview

This article explains how we’ve revamped our product analytics frontend tracking at Super using Avo 📊. For a long time, we relied on Google Sheets to document frontend events, which led to unclear ownership, inconsistent schemas, and slow, manual QA in Segment. We’ve since moved to Avo’s Tracking Plan and Inspector, giving us a single source of truth, a proper branching and peer review process with developers, and automated validation.

➡️ The result: cleaner data, faster debugging, and much smoother collaboration between data and engineering ✅.

Introduction

Accurate tracking is essential for reliable data monitoring. It helps us confirm that newly released features work as expected, identify and fix bugs, and optimise key user journeys – for example, the funnel for the Super Credit application.

When tracking goes wrong, the symptoms can vary:

• Missing events
• Missing properties
• Typos in property values
• Duplicate events being sent

But the root cause is almost always the same: poor or missing documentation.

Our previous setup: Google Sheets as a tracking plan 📄

Until recently, our main solution for documenting frontend tracking was Google Sheets. For each new feature, we would either create a new document or add a new tab listing all the events that needed to be tracked.

What worked well:

• It was simple and familiar for everyone.
• The data team could quickly spin up a new sheet and share it.

The data team was responsible for:

• Creating and maintaining the event list
• Sending it to the dev team when new frontend tracking was required

However, the limitations quickly became obvious.

Key pain points ⚠️:

• Poor versioning: It was difficult to see when events had been removed or updated, and why.
• Unclear ownership: Anyone could edit the sheet, and changes often went unnoticed.
• Weak review process: There was no clear “branching” or peer review flow before sending tracking specs to developers.
• No automated validation: We had no way to systematically check that frontend tracking had been implemented correctly. Validating events in Segment’s debugger was manual, time-consuming, and especially painful for complex features like Super Credit with many different paths.
• Little support for harmonisation: There was nothing to enforce reuse of existing properties, ensure consistent property names/values across features, or keep our schema tidy over time.

Because of these limitations, we decided to look for a better solution.

Exploring alternatives and discovering Avo

One option we considered was documenting our tracking events in JSON files and using GitHub for version control, branching, and reviews. This would have been free and would have given us better structure, but it would also have been fairly developer-centric and not very user-friendly for non-engineers.

After some research, we came across Avo, a tool focused on frontend tracking schema management, observability, and monitoring.

Avo offers two main components:

• Tracking Plan
• Inspector

The Tracking Plan: a single source of truth 📘

The Tracking Plan is where we define all the events sent from the frontend via Segment.

In Avo, events can be organised by category – for example:

• App events
• Super Credit
• Merchant checkout

Each event includes:

• A clear definition of when the event is triggered
• The list of properties to send (e.g. brandId, pageName, memberId)
• The allowed values and formats for those properties, where relevant

What Avo improves:

• ✅ Single source of truth: All frontend tracking specs live in one structured place instead of being scattered across multiple Google Sheets.
• ✅ Branching and reviews: Adding or updating events happens via branches, similar to a development workflow. A contributor creates a branch, a peer reviews it, then it’s sent to developers for implementation and finally merged into the main frontend tracking plan once implemented.
• ✅ Better versioning: It’s easy to see when events are created, changed, or archived.
• ✅ Consistency and harmonisation: Avo encourages consistent event naming and property reuse, and helps keep property values aligned across features.

The Inspector: validating implementation automatically 🔎

The second major feature we use is the Inspector.

The Inspector connects Segment to Avo so that Avo can:

• Read the events coming from the frontend
• Compare them against the definitions in the Tracking Plan

This is extremely useful for:

• Checking that events have been implemented correctly 🤝
• Spotting typos in property names or values
• Ensuring that all required properties are being sent as defined
• What used to require manual QA in Segment’s debugger can now be done much more quickly and systematically.

How we are using Avo today

We started using Avo in the context of the Super Credit features. It has already:

• Improved collaboration between the data team and developers
• Made it easier to review and refine frontend tracking specifications
• Helped us identify and fix tracking bugs more quickly and efficiently

At the moment, we’re using the free version of Avo, which comes with some limitations:

• A cap on the volume of events that Inspector can analyse per month (currently 100,000 events)
• Some paid features that we don’t yet have access to

Whether upgrading to the paid version would be worth it is still under review.

We are also in the process of migrating our legacy frontend tracking documentation. Around 80% of event definitions related to frontend checkout and Webflow (including Super Credit) have been moved from Google Sheets to Avo. The next step is to complete the migration for app-related frontend events.

Conclusion 🎯

Overall, our experience with Avo has been extremely positive. It is user-friendly, has saved us significant time, and has improved collaboration both within the data team and between data and development.

By moving away from ad-hoc Google Sheets towards a proper schema management and observability tool, we’ve made our tracking more reliable, our debugging faster, and our analytics more trustworthy – which ultimately helps us build and improve features like Super Credit with much more confidence.

Clément Raul, Data