Improving our frontend tracking with Avo

Clément Raul — Wed, 03 Dec 2025 14:08:23 +0000

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.

📈 Period-over-Period Measures in Looker: A Simpler, Better Way to Analyze Time Trends

Clément Raul — Tue, 22 Jul 2025 12:50:48 +0000

Tracking change over time—month-over-month, year-over-year—is essential for monitoring performance. Until recently, doing this in Looker meant relying on table calculations, which could be:

Hard to read and maintain
Prone to human error
Limited to visualization-only logic

Looker's new period-over-period measures help bring time-based comparisons into LookML itself - making it easier to build reliable, reusable metrics. (https://cloud.google.com/looker/docs/period-over-period)

🧱 Before: Table Calculations

Previously, getting last year’s value for a metric required a workaround like the following table calculation:
offset(${payment_transactions_fact.count_successful_transactions}, 12)

Limitations we encountered with this approach:

⚠️ Only works in visualizations—can’t be filtered or reused elsewhere
🧩 Logic cannot get duplicated across dashboards
🔍 Harder to QA and understand over time
📉 Fragile if the time grain or sort order changes

✅ Now: LookML Period-over-Period Measures

With the period_over_period measure type, we can now move this logic into our LookML layer.

Example: Last Year’s Value

measure: count_successful_transactions_last_year {
  type: period_over_period
  description: "Successful transactions from the previous year"
  based_on: count_successful_transactions
  based_on_time: created_year
  period: year
  kind: previous
}

Example: Year-over-Year % Change

measure: count_successful_transactions_last_year_relative_change {
  type: period_over_period
  description: "Year-over-year % change in successful transactions"
  based_on: count_successful_transactions
  based_on_time: created_year
  period: year
  kind: relative_change
  value_format_name: percent_0

Example: Looker Explore

Example: Looker Visualisation

🏢 How We Use It

At Super, we’ve started using these measures to track key metrics like:

📦 Sales – Year-over-year trends
🧲 Customer and merchant retention – Month-over-month comparisons
🚀 Feature impact – Week-over-week shifts after a product launch

Because these are built into our LookML layer, they can be reused across different dashboards, which helps ensure consistency and saves time.

🔍 Why This Helps

✅ Cleaner and centralized logic – Easier to review and test
📊 Works across dashboards – Filterable, sortable, and visualization-friendly
🔧 Adaptable – Supports different time periods (week, month, quarter, year)

💡 Final Thoughts

This feature might seem small, but it's been a noticeable improvement for our data team. It reduces repetitive work, helps standardise time-based comparisons, and makes dashboards easier to maintain and trust.

Forem: Clément Raul