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.