Tres definiciones de GMV.
Una capa semántica.
Sber MegaMarket — marketplace de e-commerce a gran escala con 50 000 vendedores, 10 millones de SKUs y 5 millones de compradores activos — operaba sobre más de 200 archivos Excel sin metodología común. Categorías, marketing, operaciones, finanzas y vendedores discutían cifras antes de discutir decisiones. Construimos una plataforma BI unificada con LookML como capa semántica: un diccionario único de métricas, dashboards por área y self-service para los 50 k vendedores.
El caso, en cuatro frases.
Para los que llegaron desde LinkedIn y solo tienen 30 segundos. Si quieres profundidad, sigue scrolleando.
Doscientos Excels, seis áreas, cero acuerdo en una sola métrica.
Marketing decía «GMV w41: ₽ 1.2 mil M». Finanzas decía 1.1. Operaciones 1.4. Cada uno tenía razón en su SQL. Ninguno en la realidad.
Construimos LookML como diccionario maestro.
Cada métrica con definición única, owner asignado, lógica reutilizable. Si alguien quiere cambiar «margen bruto» — lo discute en PR, no en Slack.
Seis áreas, seis dashboards, una sola verdad.
Vendedores, categorías, marketing, ops, finanzas y gestión tienen su panel — pero la lógica subyacente es la misma.
50 000 vendedores con sus propias analytics, sin pedirle nada al equipo de datos.
Y el equipo de analítica dejó de ser cuello de botella — pasó a ser curador del modelo.
Sber MegaMarket llegó con un problema medible.
- 01
Tres definiciones de GMV, una sola realidad
Marketing contaba GMV con devoluciones netas. Operaciones lo contaba bruto. Finanzas con costos. Mismo número, tres respuestas.
3 GMVs - 02
200+ Excels con copy-paste de queries
Cada analista mantenía su Excel con su SQL pegado. Cuando el equipo cambiaba la tabla source, 60 Excels se rompían en silencio durante semanas.
212 Excels frágiles - 03
Vendedores ciegos a su propio rendimiento
Los 50 000 vendedores no tenían acceso a métricas en tiempo real. Pedían PDFs al equipo de datos. Cola de 3 semanas.
0 self-service - 04
Tiempo de decisión: días por reconciliación
El comité semanal empezaba con 90 min discutiendo cifras antes de discutir acciones. Las decisiones del lunes salían el viernes.
4 d por decisión - 05
Métricas cambiadas sin avisar
Alguien rediseñaba «margen contributivo» en su Excel sin discutir. Dos meses después, 3 reportes ejecutivos mostraban tendencias divergentes.
0 governance - 06
Categorías y vendedores hablan idiomas distintos
Categorías llamaba un SKU «activo» si tenía ventas en 30d. Vendedores lo llamaban «activo» si tenía catálogo subido. Discusiones eternas.
1 palabra · N significados - 07
Soporte a vendedores: 80% pidiendo cifras
El equipo de relación con vendedores pasaba el 80% del tiempo respondiendo «¿cuántas ventas tuve en X categoría?». No quedaba tiempo para asesoría real.
80% tiempo en cifras
Lo que construimos.
No reemplazamos lo que ya funcionaba. Construimos capas finas que comunicaron sistemas ciegos entre sí.
Capa semántica · diccionario único
Cada métrica vivienda como modelo LookML versionado en git, con owner asignado, lógica reutilizable y test automatizado. Cambiar `margen_contributivo` = abrir un PR, no editar un Excel.
Vendor self-service dashboard
Dashboard pre-baked filtrado por `seller_id`. Acceso desde el panel del vendedor en MegaMarket. Sin pedir nada al equipo de datos.
Executive top KPIs
Los 5 KPIs del comité (GMV semanal, margen contributivo, NPS, velocidad pickup, CAC pagado). Mismo número para todos los presentes.
Governance console · PR por cambio
El analista que quiere cambiar «margen contributivo» abre un PR en LookML. Owner revisa. Approvers de finanzas y producto deben firmar. Historial completo.
Stack y capas.
stack: Looker · LookML · ClickHouse · dbt Core · Apache Airflow · Postgres · Redis
Ingesta
Transform + governance
Almacenamiento
Superficies
Los números.
Medidos por el equipo del cliente, no por nosotros. Comparativa: baseline previo al go-live.
«Las decisiones se discuten sobre números reales, no sobre versiones de Excel.»
Lo que aprendimos — y aplicamos en el siguiente caso.
El diccionario maestro vive en git, no en Confluence.
Documentar métricas en Confluence es necesario pero insuficiente. La única forma de garantizar consistencia es que la definición sea ejecutable (LookML), versionada (git) y revisada (PR). Si no es código, se desincroniza.
El primer dashboard no es para el CEO — es para el operador.
Construimos primero el panel del vendedor y del analista de operaciones. La adopción ejecutiva subió cuando vieron que su equipo ya usaba el sistema. El ejecutivo es el último en sumarse, no el primero.
La gobernanza fricciona — y debe friccionar.
Que un cambio de métrica tome 2 días de PR review es el feature, no el bug. La fricción evita que aparezcan 3 GMVs en 3 meses. Vendedores y dirección lo aceptan cuando entienden el costo de no friccionar.
¿Te suena familiar? Hablemos.
No vendemos software de plantilla. Empezamos siempre con una auditoría gratis de 4 semanas: nos sentamos con tu equipo, mapeamos sistemas y dolores, y entregamos un PDF con 3–5 quick wins concretas.