data-metrics.pro / Casos / Podruzhka · Beauty Retail
Caso de monitorización · beauty retail · 8 semanas

Seis horas.
Quince millones perdidos. Nunca más.

Podruzhka — cadena rusa de cosmética con 300+ tiendas físicas + app + e-commerce — descubría sus fallos críticos con 3 a 5 días de retraso. En Black Friday 2023 un error de pago no detectado costó 15 millones de rublos en 6 horas. Construimos un radar que combina telemetría de producto, pagos y tráfico con modelos predictivos. Hoy detectan en 15 minutos, no en días.

15 min
tiempo de detección crítica
// vs 3 – 5 días antes
USD 15 M
pérdidas en una sola incidencia
// Black Friday 2023, 6 h ciegas
USD 62 k/mes
pérdidas evitadas promedio
// medido 6 meses post go-live
2 plataformas
iOS + Android monitoreadas
// con desbalance detection
3 capas
alerta técnica · operativa · ejecutiva
// con escalación automática
// flujo en producción LIVE
TRAFFICSIGNUPCHECKOUTPAYMENTCONFIRMFULFILLRETURN
// 01 · TL;DR

El caso, en cuatro frases.

Para los que llegaron desde LinkedIn y solo tienen 30 segundos. Si quieres profundidad, sigue scrolleando.

01

Detectaban fallos críticos con 3 a 5 días de retraso.

El embudo bajaba 40% en iOS, nadie miraba. El servicio de pagos devolvía error 500 silencioso. El BI semanal lo veía el lunes siguiente.

02

El 24 de noviembre de 2023, esa ceguera costó 15 millones.

Un fallo en la pasarela de pago no detectado. 6 horas operando sin transacciones reales. Cuando llamó el banco, ya era irreparable.

03

Construimos un radar con 3 capas de alerta y modelos predictivos.

Eventos de cliente + transacciones + tráfico + métricas de plataforma, todo en ClickHouse + Prophet + LightGBM.

04

Resultado: detección en 15 min, USD 62 k/mes evitados, todo el equipo viendo la misma información.

El dueño del producto deja de descubrir fallos por el grupo de WhatsApp de clientes enojados.

// 02 · El problema

Podruzhka · Beauty Retail llegó con un problema medible.

  1. 01

    Anomalías visibles post-mortem

    El embudo semanal de BI llegaba a la mesa los lunes. Si un viernes a las 18:00 algo se rompía, el equipo se enteraba a los 3-5 días.

    3 – 5 d ceguera
  2. 02

    Estacionalidad enmascara fallos reales

    Los picos de Black Friday, Día de la Madre y 8 de Marzo distorsionan cualquier baseline simple. Un drop del 30% en martes parece anomalía; el mismo drop en sábado, no.

    0 modelo predictivo
  3. 03

    iOS y Android se miran juntos

    Si el 50% del tráfico es iOS y baja al 40% por un bug específico de iOS, el agregado de devices oculta el problema durante semanas.

    desbalance invisible
  4. 04

    Pagos vive en un portal externo

    El provider del gateway tiene su propio panel. Si hay error, alguien tiene que entrar a mirar. Nadie lo hace los sábados a las 21:00.

    Black Friday 2023 → −15M ₽
  5. 05

    Versionado de app sin métricas atadas

    Cuando sale v1.4.6 con un bug nuevo, no hay forma de comparar comportamiento por versión salvo entrando manualmente al crash reporter.

    0 versión-aware
  6. 06

    Se notifica al grupo equivocado

    Un fallo de checkout llega al grupo de marketing en lugar de al de plataforma. Resultado: 4 horas de Slack-tag chase antes de que la ingeniería se entere.

    4 h chase → action
// pérdida histórica en una sola incidencia
USD 15M
// tiempo medio entre fallo y diagnóstico
72h
// plataformas aisladas en paneles propios
2
// 03 · La solución

Lo que construimos.

No reemplazamos lo que ya funcionaba. Construimos capas finas que comunicaron sistemas ciegos entre sí.

SUPERFICIE 01

Dashboard de tendencias con anomalías marcadas

Gráfico de área diaria con zonas verdes (normal) y rojas (anomalía). Cada anomalía con tooltip de causa raíz inferida. iOS arriba, Android abajo — desbalance visible.

SUPERFICIE 02

Alertas a quien tiene que actuar

Cada anomalía sale al canal correcto. Plataforma → ingeniería. Conversión → producto. Crítico → CTO + COO. Sin chase entre canales.

SUPERFICIE 03

Solo lo que el CTO/COO debe saber

90% del ruido se filtra. Solo llega lo que tiene impacto > USD 10 k/h o afecta a > 5% del tráfico. Una línea de texto, sin chrome.

SUPERFICIE 04

Postmortem auto-generado

Cada incidente cierra con un PDF: línea de tiempo, hipótesis, decisión, impacto. El equipo lo revisa el lunes en standup.

// 04 · Arquitectura

Stack y capas.

stack: ClickHouse · Kafka · Prophet · LightGBM · Slack · Telegram · DataLens

L1

Captura

MOBILE SDK
iOS / Android · 60 eventos · versión-aware
WEB TRACKER
tracker.js · 80 eventos
PAYMENT WEBHOOK
gateway local · tiempo real
POS CDC
300 tiendas · Debezium
L2

Detección

~30 ms
INGESTION
Kafka
BASELINE
Prophet · estacionalidad LATAM/RU
CLASSIFICATION
LightGBM custom · 14 features
ROUTING
reglas + escalación automática
L3

Almacenamiento

OLAP
ClickHouse · 90 d caliente · 18 m frío
SERVING
PostgreSQL · alertas activas
INCIDENT LOG
dedicated table con timeline + impacto
RAW BACKUP
Yandex Object Storage
L4

Superficies

RADAR UI
DataLens + custom views
SLACK / TELEGRAM · Bolt for Python + grammY
EXECUTIVE MOBILE
Expo · iOS + Android
RETRO GENERATOR
Notion API + LLM-assisted (opt-in)
// 05 · Resultados

Los números.

Medidos por el equipo del cliente, no por nosotros. Comparativa: baseline previo al go-live.

Métrica Antes Después Δ
Tiempo de detección de fallo crítico
3 – 5 días
15 min
−99%
Pérdidas en incidente mayor (Black Friday)
USD 15 M
0
−100%
Pérdidas evitadas mes promedio
USD 62 k
nuevo
Falsos positivos del modelo
n/d
6.4%
bajo objetivo
Equipos coordinados con misma info
0
100%
nuevo
Tiempo desde alerta a hotfix
8 – 24 h
4 h
−83%

«Antes pasábamos lunes en standup intentando reconstruir el viernes. Hoy el viernes ya sabemos qué pasó.»

C
CTO Podruzhka
Inversión total USD 48k // 8 semanas implementación
Pérdidas evitadas anualizadas USD 744k // USD 62 k/mes · 12 meses
Payback 0.8 meses // el segundo incidente lo pagó
ROI a 12 meses 15.5× // rango conservador
// 06 · Lecciones

Lo que aprendimos — y aplicamos en el siguiente caso.

L1

El falso positivo cuesta más que el falso negativo — al principio.

Si el radar grita cada hora con falsas alarmas, el equipo lo apaga en 2 semanas. La tarea no es detectar todo: es alcanzar < 10% de falsos positivos para que la atención del equipo siga siendo real.

L2

Estacionalidad sin modelo predictivo es ruido.

Antes del radar, cualquier drop del 30% activaba pánico. Con Prophet entrenado con 2 años de data, el equipo aprende cuándo un drop es esperado y cuándo no. El umbral psicológico para «mirar» es ahora ±2σ del baseline ajustado.

L3

Versiones de app son su propia dimensión.

Una métrica global oculta una catástrofe en una sola versión. Después de Podruzhka, todos los proyectos parten con `app_version` como dimensión primaria, no como tag opcional.

// 07 · Siguientes pasos

¿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.