Metodología: cómo se construyó este análisis.

npm run run-all ejecuta cuatro pasos en orden, con una semilla fija: los mismos datos salen cada vez.

• 01-generate — sesiones, agendamientos y operaciones del día a día (90 días).
• 02-funnel — embudo web y WhatsApp con conversiones por paso e intervalos de confianza.
• 03-experiments — cuatro experimentos A/B simulados (lift, p, IC, guardias, decisiones).
• 04-derive — KPI, cola operativa, backlog priorizado por ICE y plan del siguiente experimento.

npm test verifica 55 invariantes sobre los datos generados (estructura, rangos, coherencia de conversiones, marcado sintético). La página y la API sirven exclusivamente esos archivos: no hay un número recalculado en el navegador.

• OBSERVADO Estructura del embudo público: pasos del formulario (datos personales → celular → correo → elegibilidad → agendamiento), canal de WhatsApp, jerarquía del home.
• SUPUESTO Volúmenes y distribuciones: 86.806 sesiones, ciudades (Medellín, Bogotá, Caldas, Rionegro, Llanogrande), fuentes de tráfico, estratos y dispositivos.
• SIMULADO Resultados de los experimentos, intervalos de confianza, tamaños de muestra, cola operativa y decisiones.
• REQUIERE VALIDACIÓN INTERNA Capacidad de instalación (139/día), tiempos de respuesta de WhatsApp, costo por instalación y por lead.

• MDE — efecto mínimo detectable del 8% sobre la conversión por paso.
• α = 0,05 y poder = 80% — el tamaño muestral se calcula para ambas.
• Intervalos de confianza — cada conversión por paso y por segmento lleva su IC 95% (Wald) calculado en el pipeline, no en el navegador.
• Guardias — cada experimento vigila una métrica de no-degradación (volumen de formularios, teléfonos válidos, minutos hasta la primera respuesta, elegibilidad de los agendados). Si la guardia se rompe, la decisión es NO LANZAR aunque el lift sea positivo.
• Decisiones — SHIP / ITERATE / STOP según significancia, intervalo contra el MDE y estado de las guardias. Todo resultado está etiquetado RESULTADO SIMULADO.

El backlog se ordena con ICE = (Impacto + Confianza + Facilidad) / 3. Impacto y facilidad son mi estimación como candidato; la confianza nace de la evidencia de la simulación. El puntaje sirve para discutir el orden de trabajo, no para describir la operación de Somos.

Los mismos datos que pinta la interfaz se sirven por HTTP, listos para ser consumidos por otra herramienta (dashboard, notificación, análisis):

• GET /api/overview — KPI, resumen operativo y plan del siguiente experimento.
• GET /api/funnel — embudos web y WhatsApp, fricciones y segmentos.
• GET /api/experiments — parámetros y resultados de los experimentos simulados.
• GET /api/operations — serie diaria de demanda, capacidad y cola.
• GET /api/backlog — backlog priorizado por ICE.

Cada respuesta incluye synthetic: true y un aviso warning: el marcado de honestidad viaja con los datos.

Un CRO no trabaja sobre pantallas: trabaja sobre datos. La página demuestra cómo estructuraría el análisis (hipótesis → evidencia → experimento → decisión), y la API demuestra que la estructura es consumible: cualquier equipo puede construir encima sin reescribir la lógica.

• npm run run-all — regenera los datos con la semilla fija (determinista).
• npm test — 55 invariantes sobre estructura, rangos y coherencia.
• npm run web — servidor local en localhost:3000 con la API y las páginas.
• npm run build — empaqueta para Cloudflare Pages (un solo comando de despliegue).

El código completo es público en github.com/LuisAlejandroCR/somos-internet: pipeline de generación, estadística, API, tests y estas páginas.