# OmniZenit: the analytics debugger nobody asked me to build

Javier Rodeiro · 2026-10-07

OmniZenit is a Chrome extension that shows, validates and explains the analytics events a page sends to Zenit, Inditex's in-house analytics tool. Nobody asked for it. I started it in June 2025 because checking events by hand was the slowest part of my job, and I ran it as a product until I left in February 2026: one owner, real users, releases, and features I decided not to ship.

## The problem

I was working at Ayesa as a digital data analyst for PULL&BEAR. Every release meant confirming that the site still sent the right events with the right fields. The only instrument was the browser's network tab: find the request, expand the payload, and compare it against the specification by eye.

That works for one event. It does not work for a checkout flow, on several markets, the day before a release. Mistakes were found late, and reporting one meant pasting raw JSON into a ticket and explaining where to look.

## Who it is for

The market is small and I know it by name: the digital analysts who implement and check analytics on the group's sites. That shaped every decision. A tool for one team of specialists does not need onboarding flows or a landing page. It needs to be correct, to be fast, and to be in the place where they already work, which is Chrome DevTools.

## What it does

OmniZenit adds a panel to DevTools. While you browse, it:

- **Lists every event as it is sent**, grouped into readable sections instead of raw JSON.
- **Validates each event against the specification** and marks what is missing or wrong.
- **Suggests the fix**, so the person reading the error does not need to know the specification by heart.
- **Compares two events side by side**, to see what changed between two pages or two releases.
- **Records a journey**, so a sequence of steps can be replayed and checked again later.
- **Exports** an event as JSON or as a full screenshot, ready to attach to a ticket.

It runs in the browser of whoever is testing. There is nothing to deploy and nothing to ask for.

## How it grew

- **June 2025.** First commit. It only understood PULL&BEAR.
- **August 2025.** Version 1.4.0, the first release labelled official: copy and paste of events, and the side-by-side comparator.
- **November 2025.** Journey recording and a tab that shows how a visit is attributed.
- **December 2025.** A redesign, and a report extractor for Power BI and Looker Studio.
- **January 2026.** Full-payload screenshots and validation errors that come with the suggested fix.

Analysts from other brands started asking for it, and each brand had its own domains and small differences. I rewrote the detection so one extension covers all eight brands of the group.

## Four product decisions

**Distribution is a feature.** The first versions were a zip file that each person loaded by hand, which meant most people ran an old version. I moved it to the Chrome Web Store as an unlisted extension: it does not appear in search, anyone with the link installs it in one click, and updates arrive on their own. Adoption stopped depending on me sending files.

**I cut the feature I liked most.** I built an assistant on Chrome's built-in AI model to explain events in plain language. It worked on my machine. It also required a browser flag, about 22 GB of free disk for the model download and a recent laptop. On corporate hardware that is a barrier almost nobody would cross, so I hid it instead of shipping something most users could not turn on. I archived the code for the day the requirements drop.

**Features came from conversations, not from a roadmap.** I asked the people using it what slowed them down, and they started asking me: could it do this, would that be possible. Each request got an honest answer about whether it was viable, and the ones that were went into the next release. If I could not name the person a feature was for, I did not build it.

**No noise.** There was no project, no budget and no meeting to approve it. The need was obvious, so I built it on my own, kept it out of everyone's way, and let it be judged by whether people installed it.

## Adoption

While I ran it, OmniZenit reached 19 weekly users. Its only users are the group's digital analysts, so that figure is measured against one team, not against a market: most of the team opened it every week.

It also outgrew me. Before I left, dedicated teams had joined in to refine the extension. What one analyst built alone to cover an obvious gap became the seed of a tool that dedicated teams took on.

## What changed

- **Validation happens while testing**, not after the data is already in a report.
- **Every analyst looks at the same panel**, so a bug report is a screenshot instead of an argument about a payload.
- **New people are productive sooner**, because the tool carries the specification for them.
- **One tool for every brand**, instead of each team keeping its own checklist.

## What I took from it

Start with a problem you have every week; you are the first user and the first tester. Treat installation and updates as part of the product, because a tool nobody can update is a tool nobody trusts. And count the cost of a feature for the user with the worst laptop, not for yourself.

The code is internal to Inditex and stays private.

Source: https://javierrodeiro.com/blog/omnizenit-the-analytics-debugger-i-built-on-my-own/