¿Cuántas veces has entrado a mirar datos por la tarde, justo antes de irte a casa, y te has dado cuenta de que una de tus tiendas llevaba tres horas quemando presupuesto sin generar un solo pedido?
A mí me pasaron demasiadas. Por eso construí esto.
La métrica que debería estar pegada a tu pantalla
No es el ROAS. No es el CPA. Nosotros usamos el ratio coste/llevamos. Es la inversa del ROAS, realmente. 😉
«Llevamos» es el valor de pedidos acumulado desde que empezó el día. El ratio responde a la pregunta más honesta que le puedes hacer a una campaña o ecommerce en vivo: por cada euro que genero, ¿cuánto me estoy gastando?
- 0.20 → Gasto 20 céntimos por cada euro facturado. Vamos bien.
- 0.40 → Empieza a oler a problema.
- 1.10 → Estás pagando por perder dinero.
Pon arriba tus propios números…
Lo que hace útil a esta métrica no es el número. Es «la curva». El coste de la última hora aislada no dice nada: si a las 14:00 el ratio iba en 0.18 y a las 18:00 marca 0.45, algo se ha roto. El algoritmo de puja salió de fase, entró un competidor, tu hora de corte ha pasado y ya no entregas cuando lo necesitan los clientes en el país en cuestión.. Por alguna razón, los pedidos pararon mientras el gasto seguía corriendo.
Por eso se mira hora a hora. No es microgestión. Es que el dinero no se pausa cuando entras a una reunión.
20 tiendas, un solo par de ojos
Mi equipo gestiona campañas para más de 20 e-commerce en paralelo. Cada uno con su ticket medio, su hora punta, sus transportistas, sus horas de corte, su estacionalidad.
Vigilar eso a mano en Meta y Google Ads es una tortura:
- Cambias de cuenta.
- Esperas a que cargue el reporting de publi o el propio de la empresa.
- Calculas a ojo o miras una tabla.
- Intentas recordar cómo iba la anterior.
- Pierdes el hilo en la tienda número 7.
Durante demasiado tiempo mi rutina fue: exportar un Excel/CSV a mediodía, tirar una tabla dinámica, poner colorines… hacer un VLOOKUP, actualizar un Google Sheet que ya estaba obsoleto antes de terminar de rellenarlo… (dramatización).
El dashboard: heatmap horario, sin fricción
Lo construimos primero en Google Sheets y enganchábamos datos con Supermetrics. Sin frameworks, sin backend, sin infraestructura que mantener. Le dabas a un botón y lo veías todo de golpe.
Con los años lo metimos en reporting interno (Tableau), pero tenía un problema: solo veías una tienda cada vez. Podríamos haber puesto todas, pero era un dolor de construir y de consumir…
Un sábado decidí que no iba a seguir así y monté con Claude Code una visualización sencilla pero muy útil. Algo tosca en su preparación, pero luego muy rápida de consumir.
Tiene dos vistas.
Vista individual: una tienda a fondo. Eje X: las horas del día, de 9:00 a 23:00. Eje Y: los días del periodo. Cada celda es el ratio acumulado en esa hora de ese día, mapeado a color: verde oscuro cuando es eficiente, rojo oscuro cuando estás sangrando.
Un vistazo y ves si los miércoles siempre van peor que los martes, o si las tardes se deterioran en cuanto pasa la hora de corte de almacén.
Vista mosaico: muchas tiendas a la vez. Esta es la joya de la corona. Cada ecommerce es un mini heatmap. En diez segundos veo cuáles están verdes hoy, cuáles tienen una mancha naranja a partir de las 14:00 y cuáles llevan toda la semana en rojo.
Esto cambia la dinámica del trabajo. Ya no reviso tienda por tienda. El problema me salta a la cara.
Tres decisiones de diseño que marcan la diferencia
1. Ratio acumulado, no por hora. El dato hora a hora tiene demasiado ruido. Una hora con tres pedidos distorsiona el número. Se ve en una de las imágenes de arriba. El acumulado desde el arranque del día es estable y accionable:
ratio[h] = Σ(coste de 9:00 a h) / Σ(valor de pedidos de 9:00 a h)2. Escala de color fija, anclada al negocio. Los colores no dependen del dataset. Están atados a umbrales reales:
- < 10% → verde profundo. Rentable sin despeinarse.
- 10–50% → degradado de verde a naranja.
- 50% → vino oscuro. Estás perdiendo dinero.
Una celda roja significa lo mismo ayer, hoy y la semana que viene. Da igual qué tiendas estés filtrando.
3. Cero backend. Cualquiera del equipo exporta el CSV, lo deja en una carpeta, abre el HTML. No hay API que se caiga, no hay cron que se atasque, no hay sincronización que debuguear a las once de la noche. Lo que no existe no puede fallar.
Y un extra: filtros por gestor y por tier. Puedo ver solo las cuentas de un responsable concreto o filtrar por tier de gasto para atacar primero las grandes.
Lo que me llevo de este proyecto
Vanilla JS sigue bastando para dashboards internos como este. Lo que justificaba el tiempo era la lógica del negocio —el ratio acumulado, la escala con umbrales, los tooltips—, no el framework.
Pero la decisión más importante no fue técnica. Fue darme cuenta de que estaba preguntando mal.
«¿Cuál es el ROAS de hoy?» es la pregunta de fin de mes.
«¿A qué hora empieza a deteriorarse el ratio, y en qué tienda?» es la pregunta que te ahorra presupuesto ahora.
Esa pregunta no cabe en un número agregado. Necesita una visualización temporal. Y una vez la tienes, la revisión de mediodía deja de ser una revisión.
Es escanear diez segundos y actuar solo donde hay color. O más bien, dolor.
Stack: HTML5, CSS3, JavaScript ES6+. Cero dependencias, cero backend. Los datos salen de un CSV exportado a mano. A veces la solución más simple también es la más rápida de construir y la más fácil de no tener que mantener.
