Improving our frontend tracking with Avo

Source: Dev.to

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.

➡️ 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

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

Data‑team responsibilities

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

Key pain points ⚠️

• Poor versioning: Hard 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: No clear “branching” or peer‑review flow before sending specs to developers.
• No automated validation: Manual, time‑consuming checks in Segment’s debugger, especially painful for complex features like Super Credit.
• Little support for harmonisation: No enforcement of property reuse or consistent naming, leading to a messy schema.

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

Exploring alternatives and discovering Avo

One option we considered was documenting tracking events in JSON files and using GitHub for version control, branching, and reviews. This would have been free and provided 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 tracking plan.
• ✅ Better versioning: Easy to see when events are created, changed, or archived.
• ✅ Consistency and harmonisation: Encourages consistent event naming and property reuse, keeping property values aligned across features.

The Inspector: validating implementation automatically 🔎

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

Benefits

• Checks that events have been implemented correctly 🤝
• Spots typos in property names or values
• Ensures all required properties are being sent as defined
• Replaces manual QA in Segment’s debugger with a faster, systematic process.

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

We are currently on the free version of Avo, which has some limitations:

• A cap on the volume of events that the Inspector can analyse per month (currently 100,000 events)
• Some paid features are not yet available

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

We are also 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 toward 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.