Javier Rodeiro

OmniZenit: el depurador de analítica que nadie me pidió construir

Casos5 min#Analítica#Producto

En este artículo

OmniZenit es una extensión de Chrome que muestra, valida y explica los eventos de analítica que una página envía a Zenit, la herramienta de analítica propia de Inditex. Nadie me la pidió. La empecé en junio de 2025 porque revisar eventos a mano era la parte más lenta de mi trabajo, y la llevé como un producto hasta que me fui en febrero de 2026: un solo responsable, usuarios reales, versiones y funcionalidades que decidí no sacar.

El problema

Trabajaba en Ayesa como analista de datos digitales para PULL&BEAR. Cada release exigía confirmar que la web seguía enviando los eventos correctos con los campos correctos. El único instrumento era la pestaña de red del navegador: buscar la petición, desplegar el payload y compararlo con la especificación a ojo.

Eso funciona para un evento. No funciona para un flujo de compra, en varios mercados, el día antes de una release. Los errores se encontraban tarde, y reportar uno significaba pegar JSON en bruto en un ticket y explicar dónde mirar.

Para quién es

El mercado es pequeño y lo conozco por nombres: los analistas digitales que implementan y revisan la analítica de las webs del grupo. Eso condicionó cada decisión. Una herramienta para un equipo de especialistas no necesita onboarding ni landing page. Necesita ser correcta, ser rápida y estar donde ya trabajan, que es Chrome DevTools.

Qué hace

OmniZenit añade un panel a DevTools. Mientras navegas:

  • Lista cada evento según se envía, agrupado en secciones legibles en lugar de JSON en bruto.
  • Valida cada evento contra la especificación y marca lo que falta o está mal.
  • Sugiere la corrección, para que quien lee el error no tenga que saberse la especificación de memoria.
  • Compara dos eventos lado a lado, para ver qué cambió entre dos páginas o dos releases.
  • Graba un recorrido, para poder repetir una secuencia de pasos y comprobarla de nuevo más adelante.
  • Exporta un evento como JSON o como captura completa, listo para adjuntar a un ticket.

La herramienta es interna, así que no puedo enseñar el panel real. Esta es la idea con eventos y nombres de campo inventados: llegan los eventos, cada uno se comprueba contra la especificación y, al hacer clic en uno, aparece qué está mal y la corrección sugerida.

Funciona en el navegador de quien está probando. No hay nada que desplegar ni nada que pedir.

Cómo creció

  • Junio de 2025. Primer commit. Solo entendía PULL&BEAR.
  • Agosto de 2025. Versión 1.4.0, la primera etiquetada como oficial: copiar y pegar eventos y el comparador lado a lado.
  • Noviembre de 2025. Grabación de recorridos y una pestaña que muestra cómo se atribuye una visita.
  • Diciembre de 2025. Un rediseño y un extractor de informes para Power BI y Looker Studio.
  • Enero de 2026. Capturas con el payload completo y errores de validación que llegan con la corrección sugerida.

Analistas de otras marcas empezaron a pedirla, y cada marca tenía sus propios dominios y pequeñas diferencias. Reescribí la detección para que una sola extensión cubriera las ocho marcas del grupo.

Cuatro decisiones de producto

La distribución es una funcionalidad. Las primeras versiones eran un zip que cada persona cargaba a mano, lo que significaba que la mayoría usaba una versión antigua. La pasé a la Chrome Web Store como extensión no listada: no aparece en las búsquedas, cualquiera con el enlace la instala en un clic y las actualizaciones llegan solas. La adopción dejó de depender de que yo mandara ficheros.

Recorté la funcionalidad que más me gustaba. Construí un asistente sobre el modelo de IA integrado de Chrome para explicar los eventos en lenguaje llano. En mi máquina funcionaba. Pero también exigía activar un flag del navegador, unos 22 GB de disco libre para descargar el modelo y un portátil reciente. En hardware corporativo es una barrera que casi nadie cruzaría, así que la oculté en vez de lanzar algo que la mayoría no podía activar. Archivé el código para el día en que bajen los requisitos.

Las funcionalidades salieron de conversaciones, no de un roadmap. Preguntaba a quienes la usaban qué los frenaba, y empezaron a preguntarme ellos: ¿podría hacer esto?, ¿sería posible aquello? Cada petición recibía una respuesta honesta sobre su viabilidad, y las viables entraban en la siguiente release. Si no sabía decir para qué persona era una funcionalidad, no la construía.

Sin ruido. No había proyecto, ni presupuesto, ni reunión que lo aprobara. La necesidad era obvia, así que lo construí por mi cuenta, sin molestar a nadie, y dejé que lo juzgara si la gente la instalaba o no.

Adopción

Mientras la llevé yo, OmniZenit llegó a 19 usuarios semanales. Sus únicos usuarios son los analistas digitales del grupo, así que esa cifra se mide contra un equipo, no contra un mercado: la mayoría del equipo la abría cada semana.

También me superó. Antes de irme, equipos dedicados se habían sumado para pulir la extensión. Lo que un analista construyó solo para cubrir un hueco evidente se convirtió en la semilla de una herramienta que equipos dedicados hicieron suya.

Qué cambió

  • La validación ocurre mientras se prueba, no cuando los datos ya están en un informe.
  • Todos los analistas miran el mismo panel, así que un reporte de bug es una captura en lugar de una discusión sobre un payload.
  • La gente nueva es productiva antes, porque la herramienta lleva la especificación por ellos.
  • Una sola herramienta para todas las marcas, en vez de que cada equipo mantenga su propia checklist.

Lo que me llevé

Empieza por un problema que tengas cada semana: eres el primer usuario y el primer tester. Trata la instalación y las actualizaciones como parte del producto, porque una herramienta que nadie puede actualizar es una herramienta de la que nadie se fía. Y cuenta el coste de una funcionalidad para el usuario con el peor portátil, no para ti.

El código es interno de Inditex y seguirá siendo privado.

Seguir leyendo