cohort-analysis · diff
git:20260702.b8fb11d to git:20261011.3fb211c
179 added, 102 removed. Audit A to A.
---
# machine-translated to es from skills/cohort-analysis/SKILL.md — review: pending. Native fixes welcome via PR.
name: cohort-analysis
- description: "Estructura un análisis de cohortes para retención, LTV o patrones de comportamiento. Úsalo cuando te pidan ejecutar un análisis de cohortes, analizar retención por cohorte, segmentar usuarios por comportamiento en el tiempo, o calcular el valor de vida del cliente por período de adquisición. Produce un marco de análisis de cohortes completo con metodología, definiciones de cohortes, curvas de retención e intervenciones priorizadas."
+ description: "Estructura un análisis de cohortes para retención, LTV o patrones de comportamiento. Úsalo cuando se te pida ejecutar un análisis de cohortes, analizar retención por cohorte, segmentar usuarios por comportamiento en el tiempo, o calcular valor de vida útil por período de adquisición. Produce un marco completo de análisis de cohortes con metodología, definiciones de cohortes, curvas de retención e intervenciones priorizadas."
---
# Skill de Análisis de Cohortes
- Este skill produce un análisis de cohortes estructurado que cubre curvas de retención, estimación de LTV, segmentación por comportamiento e intervenciones accionables. El resultado está listo para presentar a la dirección de producto o compartir con equipos de crecimiento y datos.
+ Produce un análisis de cohortes estructurado que cubre curvas de retención, estimación de LTV, segmentación comportamental, indicadores principales de churn y intervenciones priorizadas. El resultado está listo para presentar a liderazgo de producto o compartir con equipos de growth y datos.
- ## Inputs Necesarios
+ ---
- Pide al usuario estos datos si no están disponibles:
- - **Objetivo del análisis** (mejora de retención / modelado de LTV / segmentación por comportamiento / predicción de churn)
- - **Producto o feature que se analiza**
- - **Definición de cohorte** — ¿qué agrupa a los usuarios? (mes de adquisición, canal de signup, tier de plan, adopción de feature)
- - **Ventana de observación** — ¿cuántos períodos rastrear? (p. ej. 12 meses, 8 semanas)
- - **Métrica clave** — ¿qué mides por cohorte? (tasa de retención, ingresos, engagement score, uso de feature)
- - **Datos disponibles** — ¿qué tablas/métricas hay disponibles? (pega el esquema o describe)
- - **Baseline** — ¿hay benchmarks o metas de retención existentes?
+ ## Entradas Requeridas
- ## Estructura del Output
+ **Solicita cualquiera de estas que falte antes de empezar. No inventes números, benchmarks ni detalles de esquema.**
+ | Entrada | Qué preguntar si falta |
+ |---|---|
+ | **Objetivo del análisis** | Mejora de retención / modelado de LTV / segmentación comportamental / predicción de churn — elige un objetivo principal |
+ | **Producto o feature** | ¿Qué se está analizando? |
+ | **Definición de cohorte** | ¿Qué agrupa a los usuarios en una cohorte? (mes de adquisición, canal de registro, tier de plan, fecha de adopción de feature) |
+ | **Ventana de observación** | ¿Cuántos períodos seguir? (p. ej. 12 meses, 8 semanas) |
+ | **Métrica clave** | ¿Qué se mide por cohorte? (tasa de retención, ingresos, puntuación de engagement, uso de features) |
+ | **Datos disponibles** | Pega esquema, nombres de tablas, o describe qué métricas existen — no asumas |
+ | **Baseline o meta** | ¿Hay benchmarks de retención existentes o metas para comparar? |
+
+ Si el usuario no puede suministrar datos reales, produce el marco con placeholders claramente marcados (`[X%]`, `[£X]`, `[N usuarios]`) y nota qué secciones requieren datos reales para completarse.
+
---
+ ## Proceso
+
+ Sigue estos pasos en orden:
+
+ 1. **Confirma entradas** — surfacea cualquier ambigüedad antes de producir output (p. ej. definiciones de cohorte conflictivas, ventana de observación faltante).
+ 2. **Define cohortes** — establece evento de entrada, criterios de salida y exclusiones para que las cohortes sean mutuamente excluyentes.
+ 3. **Construye tabla de retención** — completa o templatea la matriz período a período; identifica el período de meseta.
+ 4. **Proyecta LTV** — usa solo datos de retención observados; marca si los datos son insuficientes.
+ 5. **Segmenta por comportamiento** — crea segmentos comportamentales mutuamente excluyentes; identifica el threshold de activación.
+ 6. **Surface indicadores principales de churn** — lista señales observables con tiempo de anticipación y mapeo de intervención.
+ 7. **Compara cohortes en el tiempo** — evalúa si los cambios de producto se muestran en cohortes más nuevas.
+ 8. **Prioriza recomendaciones** — vincula cada recomendación a un hallazgo de cohorte o segmento específico.
+ 9. **Proporciona referencia SQL** — adapta la query template al esquema real del usuario si se suministra.
+ 10. **Ejecuta quality checks** — verifica todos los ítems del checklist antes de entregar output.
+
+ ---
+
+ ## Output Template
+
+ Produce las siguientes secciones en orden. Omite una sección solo si explícitamente está fuera de alcance; nota la omisión.
+
+ ---
+
# Análisis de Cohortes: [Producto / Feature]
- **Tipo de análisis:** [Retención / LTV / Comportamiento / Churn]
- **Definición de cohorte:** [Mes de adquisición / Canal de signup / Tier de plan / Fecha de adopción de feature]
+ **Objetivo del análisis:** [Retención / LTV / Segmentación comportamental / Predicción de churn]
+ **Definición de cohorte:** [p. ej. Mes de adquisición — usuarios agrupados por mes de calendario de primer registro]
**Ventana de observación:** [X meses / semanas]
- **Métrica principal:** [Nombre de la métrica]
- **Fecha de preparación:** [Fecha]
+ **Métrica primaria:** [Nombre de métrica y definición]
+ **Fuente de datos:** [Tablas o métricas usadas — no inventes si no se suministraron]
+ **Fecha preparada:** [Fecha]
---
## 1. Definiciones de Cohortes
| Cohorte | Período | Tamaño | Descripción |
|---|---|---|---|
- | [Cohorte 1] | [Ene 2025] | [N usuarios] | [p. ej. Usuarios que se registraron en ene 2025 a través de orgánico] |
- | [Cohorte 2] | [Feb 2025] | [N usuarios] | [...] |
+ | [Cohorte 1] | [Ene 2025] | [N usuarios] | [p. ej. Usuarios que se registraron en ene 2025 vía búsqueda orgánica] |
+ | [Cohorte 2] | [Feb 2025] | [N usuarios] | [Descripción] |
- **Lógica de cohorte:**
- - Evento de entrada a cohorte: [Primer registro / Primera compra / Activación de feature]
- - Criterios de salida de cohorte: [Churnado / Downgrade / Sin actividad durante 30 días]
- - Exclusiones: [Usuarios de prueba / Cuentas de prueba internas / Usuarios con < X días de datos]
+ **Lógica de cohortes:**
+ - **Evento de entrada:** [p. ej. Primer registro / Primera compra / Activación de feature]
+ - **Definición de salida / churn:** [p. ej. Sin actividad que coincida con evento de retención clave durante 30 días]
+ - **Exclusiones:** [p. ej. Cuentas internas de prueba, usuarios de trial con < 3 días de datos, cohortes con < [N] usuarios — ver anti-patterns]
+ > **Nota:** Si alguna cohorte cae por debajo del threshold de tamaño mínimo para confiabilidad estadística, marca explícitamente y exclúyela de conclusiones de tendencias.
+
---
## 2. Curva de Retención
- **Cómo leer:** Cada celda muestra qué % de la cohorte realizó la métrica clave en el período N.
+ **Cómo leer:** Cada celda muestra el porcentaje de la cohorte que realizó el evento de retención clave en período N. Período 0 = 100% por definición.
- | Cohorte | Período 0 | Período 1 | Período 2 | Período 3 | Período 6 | Período 12 |
+ | Cohorte | P0 | P1 | P2 | P3 | P6 | P12 |
|---|---|---|---|---|---|---|
- | Ene 2025 | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
- | Feb 2025 | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
- | [Tendencia] | — | [↑/↓ vs anterior] | [...] | [...] | [...] | [...] |
+ | [Ene 2025] | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
+ | [Feb 2025] | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
+ | [Tendencia vs cohorte anterior] | — | [↑/↓ X pp] | [↑/↓ X pp] | [↑/↓ X pp] | [↑/↓ X pp] | [↑/↓ X pp] |
- **Meseta de retención:** [¿En qué período se estabiliza la retención? ¿En qué % se estabiliza?]
+ **Meseta de retención:** [¿En qué período se aplana la curva? ¿En qué % se aplana? Si la ventana de observación es demasiado corta para mostrar una meseta, decláralo explícitamente.]
**Observaciones clave:**
- - [p. ej. La caída de Período 1 → Período 2 es la mayor — churn promedio de X% en los primeros 30 días]
- - [p. ej. Las cohortes adquiridas a través de [canal] retienen X% mejor en Período 6]
- - [p. ej. La retención ha mejorado de X% → Y% en Período 3 comparando la cohorte más antigua con la más reciente]
+ - [p. ej. La caída más grande de período único es P1 → P2, promediando X pp — este es el momento de churn principal a abordar]
+ - [p. ej. Las cohortes adquiridas vía [canal] muestran X pp mayor retención en P6 vs el promedio general]
+ - [p. ej. La retención en P3 ha pasado de X% (cohorte más antigua) a Y% (cohorte más nueva) — un cambio de Z pp]
- **Curvas de retención, dibujadas** — también renderiza las curvas como un gráfico de líneas Mermaid/chart para que la meseta y las brechas entre cohortes sean visibles (se renderiza en vivo en el playground y se exporta como PNG). Una línea por cohorte, período en el eje x:
+ **Gráfico de retención** — renderiza una línea por cohorte, período en eje x:
```chart
{
"type": "line",
"title": "Retención por cohorte (%)",
"labels": ["P0", "P1", "P2", "P3", "P6", "P12"],
"series": [
- { "name": "Ene 2025", "data": [100, 62, 51, 45, 40, 37] },
- { "name": "Feb 2025", "data": [100, 66, 55, 49, 44, 41] }
+ { "name": "[Cohorte 1]", "data": [100, "[X]", "[X]", "[X]", "[X]", "[X]"] },
+ { "name": "[Cohorte 2]", "data": [100, "[X]", "[X]", "[X]", "[X]", "[X]"] }
]
}
```
---
- ## 3. Proyección de LTV (si aplica)
+ ## 3. Proyección de LTV
- **ARPU por período:** [£/$/€ X por usuario activo por mes]
- **Curva de retención utilizada:** [Qué cohorte o promedio combinado]
+ > Omite esta sección si los datos de ingresos no están disponibles. No estimes ARPU sin una fuente de datos — nota la brecha y solicítala.
- | Período | Retenido % | Ingresos por usuario | LTV acumulado |
+ **ARPU por período:** [Moneda y cantidad por usuario activo por período — sourced from: X]
+ **Curva de retención usada:** [Qué cohorte o promedio combinado, y por qué]
+
+ | Período | Retenido % | Ingresos por usuario retenido | LTV Acumulativo |
|---|---|---|---|
| Mes 1 | [X%] | [£X] | [£X] |
| Mes 3 | [X%] | [£X] | [£X] |
| Mes 6 | [X%] | [£X] | [£X] |
| Mes 12 | [X%] | [£X] | [£X] |
- **LTV combinado:** [£X a 12 meses — basado en retención combinada entre cohortes]
+ **LTV combinado en 12M:** [£X — especifica qué cohortes y método de ponderación]
**LTV por segmento:**
- | Segmento | LTV (12M) | vs Baseline |
- |---|---|---|
- | [Orgánico] | [£X] | [+X%] |
- | [Paid] | [£X] | [-X%] |
- | [Enterprise] | [£X] | [+X%] |
+ | Segmento | LTV (12M) | vs baseline combinado | Driver clave de diferencia |
+ |---|---|---|---|
+ | [Orgánico] | [£X] | [+X%] | [p. ej. Retención en P6 más alta] |
+ | [Pago] | [£X] | [-X%] | [p. ej. Tasa de activación más baja] |
+ | [Enterprise] | [£X] | [+X%] | [p. ej. ARPU más alto por período] |
+
---
- ## 4. Segmentación por Comportamiento
+ ## 4. Segmentación Comportamental
- Agrupa cohortes por patrones de comportamiento, no solo por fecha de adquisición:
+ Los segmentos se definen por lo que hicieron los usuarios, no cuándo llegaron. Los segmentos deben ser mutuamente excluyentes y colectivamente exhaustivos dentro de la población analizada.
- | Segmento | Definición | Tamaño | Retención (P6) | LTV (12M) |
+ | Segmento | Definición | % de cohorte | Retención (P6) | LTV (12M) |
|---|---|---|---|---|
- | **Power users** | [Usó feature central ≥ 3x/semana en primeros 30 días] | [X%] | [X%] | [£X] |
- | **Casual users** | [Usó 1–2x/semana en primeros 30 días] | [X%] | [X%] | [£X] |
- | **Dormant** | [Inició sesión pero no usó feature central] | [X%] | [X%] | [£X] |
- | **Never activated** | [Se registró pero nunca completó onboarding] | [X%] | [X%] | [£X] |
+ | **Power users** | [p. ej. Completó acción principal ≥ 3×/semana en primeros 30 días] | [X%] | [X%] | [£X] |
+ | **Casual users** | [p. ej. Completó acción principal 1–2×/semana en primeros 30 días] | [X%] | [X%] | [£X] |
+ | **Dormant** | [p. ej. Inició sesión pero nunca completó acción principal] | [X%] | [X%] | [£X] |
+ | **Never activated** | [p. ej. Se registró pero nunca completó paso 1 de onboarding] | [X%] | [X%] | [£X] |
- **Insight de activación:** [Qué acción — realizada en los primeros X días — predice mejor la retención? Este es el "momento aha" a optimizar.]
+ **Threshold de activación (el "aha moment"):** [¿Qué acción específica, realizada dentro de los primeros X días, predice mejor retención a largo plazo? Sourcea esto de los datos — no asumas una respuesta genérica.]
---
- ## 5. Indicadores Adelantados de Churn
+ ## 5. Indicadores Principales de Churn
- Lista las señales que aparecen **antes** de que los usuarios hagan churn, para que los equipos puedan intervenir:
+ Señales que aparecen **antes** de que los usuarios hagan churn, habilitando intervención pre-emptiva. Todas las señales listadas deben ser observables en datos de producción — marca cualquiera que sea teórica solamente.
- | Señal | ¿Con cuánta anticipación aparece? | Correlación con churn | Intervención |
+ | Señal | Tiempo de anticipación antes de churn | Fortaleza de correlación | Intervención recomendada |
|---|---|---|---|
- | [Sin login durante 7 días] | [7 días antes del churn] | [Fuerte] | [Secuencia de email de re-engagement] |
- | [Ticket de soporte con escalada] | [14 días antes del churn] | [Moderada] | [Outreach de CSM dentro de 48 horas] |
- | [Uso de feature cayó >50% WoW] | [10 días antes del churn] | [Fuerte] | [Nudge in-app con tutorial de caso de uso] |
+ | [p. ej. Sin login durante 7 días consecutivos] | [7 días] | [Fuerte / Moderada / Débil] | [p. ej. Email de re-engagement automático en día 7] |
+ | [p. ej. Ticket de soporte con escalada sin resolver] | [~14 días] | [Moderada] | [p. ej. Outreach de CSM dentro de 48 horas de escalada] |
+ | [p. ej. Uso de feature principal bajó >50% semana-a-semana] | [~10 días] | [Fuerte] | [p. ej. Prompt in-app vinculando a tutorial de caso de uso] |
+ > **Requerimiento de datos:** La fortaleza de correlación debe venir de datos observados. Si no está disponible, marca como [Hipótesis — no validada aún] y recomienda un A/B test o análisis de supervivencia para confirmar.
+
---
- ## 6. Comparación de Cohortes: Qué Ha Cambiado en el Tiempo
+ ## 6. Comparación de Cohortes: Tendencia en el Tiempo
- Compara la cohorte más antigua con la más reciente para evaluar si las mejoras de producto se reflejan en la retención:
+ Evalúa si los cambios de producto son visibles en resultados de retención para cohortes más nuevas.
- | Métrica | [Cohorte más antigua — p. ej. Ene 2024] | [Cohorte más reciente — p. ej. Ene 2025] | Cambio |
- |---|---|---|---|
- | Retención Período 1 | [X%] | [X%] | [↑/↓ X pp] |
- | Retención Período 3 | [X%] | [X%] | [↑/↓ X pp] |
- | Tasa de activación | [X%] | [X%] | [↑/↓ X pp] |
- | Sesiones promedio en primeros 30 días | [X] | [X] | [↑/↓] |
+ | Métrica | [Cohorte más antigua] | [Cohorte más nueva] | Cambio | Notas |
+ |---|---|---|---|---|
+ | Retención P1 | [X%] | [X%] | [↑/↓ X pp] | |
+ | Retención P3 | [X%] | [X%] | [↑/↓ X pp] | |
+ | Tasa de activación | [X%] | [X%] | [↑/↓ X pp] | |
+ | Sesiones promedio, primeros 30 días | [X] | [X] | [↑/↓] | |
- **Veredicto:** [¿Las cohortes más recientes rinden mejor o peor? ¿Qué se lanzó en ese período que podría explicar el cambio?]
+ **Veredicto:** [¿Están las cohortes más recientes desempeñándose mejor o peor? ¿Qué se deployó durante este período que podría explicar el cambio? Si no hay explicación causal disponible, decláralo — no inventes una.]
---
## 7. Recomendaciones
- Prioriza por impacto en la curva de retención:
+ Cada recomendación debe referenciar una cohorte, segmento o señal específica de las secciones anteriores. El consejo genérico que podría aplicar a cualquier producto debe ser cortado.
- | # | Recomendación | Segmento objetivo | Impacto esperado | Esfuerzo | Prioridad |
- |---|---|---|---|---|---|
- | 1 | [p. ej. Rediseñar onboarding para alcanzar hito de activación en día 1, no día 7] | [Segmento never-activated] | [+X pp retención P1] | [Medio] | P1 |
- | 2 | [p. ej. Lanzar secuencia de re-engagement en trigger de inactividad día 7] | [Segmento dormant] | [+X pp retención P2] | [Bajo] | P1 |
- | 3 | [p. ej. Introducir features de power-user más temprano para acelerar formación de hábito] | [Casual users] | [+X pp LTV P6] | [Alto] | P2 |
+ | # | Recomendación | Anclada a hallazgo | Segmento objetivo | Impacto esperado | Esfuerzo | Prioridad |
+ |---|---|---|---|---|---|---|
+ | 1 | [Acción específica] | [Sección X, hallazgo Y] | [Segmento] | [p. ej. +X pp retención P1 — base para estimar] | [Bajo / Med / Alto] | P1 |
+ | 2 | [Acción específica] | [Sección X, hallazgo Y] | [Segmento] | [p. ej. +X pp retención P3] | [Bajo / Med / Alto] | P1 |
+ | 3 | [Acción específica] | [Sección X, hallazgo Y] | [Segmento] | [p. ej. +£X LTV en 12M] | [Bajo / Med / Alto] | P2 |
+ > Si el impacto esperado no puede estimarse a partir de datos disponibles, decláralo — no fabrique un porcentaje de lift.
+
---
- ## 8. Referencia SQL (si aplica)
+ ## 8. Referencia SQL
- Proporciona la query de cohorte principal para que equipos de datos puedan replicar o extender el análisis:
+ Adapta este template al esquema real del usuario si se suministra. Reemplaza nombres de tablas y columnas placeholder — no ships una query que el usuario no pueda ejecutar.
```sql
-- Query de cohorte de retención
+ -- Reemplaza: users, events, created_at, event_date, user_id, event_type, [start_date], [key_retention_event]
SELECT
- DATE_TRUNC('month', u.created_at) AS cohort_month,
- DATE_TRUNC('month', e.event_date) AS activity_month,
+ DATE_TRUNC('month', u.created_at) AS cohort_month,
+ DATE_TRUNC('month', e.event_date) AS activity_month,
DATEDIFF('month', u.created_at, e.event_date) AS period,
- COUNT(DISTINCT e.user_id) AS retained_users,
- COUNT(DISTINCT c.user_id) AS cohort_size,
- ROUND(COUNT(DISTINCT e.user_id) * 100.0 / COUNT(DISTINCT c.user_id), 1) AS retention_rate
+ COUNT(DISTINCT e.user_id) AS retained_users,
+ COUNT(DISTINCT c.user_id) AS cohort_size,
+ ROUND(
+ COUNT(DISTINCT e.user_id) * 100.0
+ / NULLIF(COUNT(DISTINCT c.user_id), 0), 1
+ ) AS retention_rate
FROM users u
- JOIN events e ON u.user_id = e.user_id
JOIN (
SELECT user_id, DATE_TRUNC('month', created_at) AS cohort_month
FROM users
WHERE created_at >= '[start_date]'
- ) c ON u.user_id = c.user_id AND DATE_TRUNC('month', u.created_at) = c.cohort_month
- WHERE e.event_type = '[key_retention_event]'
+ ) c ON u.user_id = c.user_id
+ AND DATE_TRUNC('month', u.created_at) = c.cohort_month
+ JOIN events e
+ ON u.user_id = e.user_id
+ AND e.event_type = '[key_retention_event]'
GROUP BY 1, 2, 3
ORDER BY 1, 3;
```
+ **Adapta para tu stack:** BigQuery usa `DATE_DIFF`; Redshift usa `DATEDIFF`; Snowflake usa `DATEDIFF` o `TIMESTAMPDIFF`. Confirma dialect antes de ejecutar.
+
---
- ## Controles de Calidad
+ ## Rubric de Scoring (0–40)
- - [ ] Definición de cohorte es inequívoca — el mismo usuario no puede aparecer en dos cohortes
- - [ ] Curva de retención muestra una meseta clara, o el análisis indica que la ventana es demasiado corta para verla
- - [ ] Proyección de LTV usa retención observada, no asumida
- - [ ] Segmentos de comportamiento son mutuamente excluyentes y exhaustivos
- - [ ] Recomendaciones están vinculadas a hallazgos específicos de cohorte o segmento — no son consejos de crecimiento genéricos
- - [ ] Indicadores adelantados son observables en datos de producción, no solo en teoría
+ Puntúa cualquier output de esta skill antes de entregarlo; 32+ es ship-quality.
- ## Anti-Patrones
+ | Dimensión | 0 | 5 | 10 |
+ |---|---|---|---|
+ | Rigor de definición de cohorte | Límites ambiguos; un usuario podría estar en dos cohortes | Mutuamente excluyentes pero evento de entrada débilmente justificado | Evento de entrada unambiguo y límites de fecha, con tradeoffs de la definición declarados |
+ | Honestidad de meseta y ventana | Retención leída de una ventana demasiado corta para apoyarla | Meseta reclamada sin mostrar dónde | Meseta visible y ubicada, o ventana explícitamente declarada demasiado corta para confirmar una |
+ | Grounding de LTV | LTV de retención asumida o ARPU asumido | Datos observados usados pero método de proyección inestadado | LTV construido de retención observada × ARPU observado con el método de proyección y supuesto de decay mostrados |
+ | Payoff de tendencia e indicador principal | Cohortes descritas, nada comparado | Tendencia cohorte-a-cohorte mostrada sin indicadores | Tendencia entre períodos de adquisición leída correctamente, más indicadores comportamentales principales de churn vinculados a detección |
- - [ ] No permitas que el mismo usuario aparezca en múltiples cohortes — las cohortes superpuestas producen números de retención que no se pueden comparar ni actuar
- - [ ] No asumas ARPU en proyecciones de LTV — usa ingresos observados por usuario retenido por período, no un promedio combinado que oculte diferencias de segmento
- - [ ] No saques conclusiones de cohortes demasiado pequeñas para ser estadísticamente significativas — marca umbrales de tamaño mínimo de cohorte y anota cuándo una cohorte es demasiado pequeña para confiar
- - [ ] No confundas tasa de retención con tasa de engagement — un usuario que inicia sesión pero no completa el evento de retención clave no está retenido por la definición utilizada
- - [ ] No hagas recomendaciones sin conectarlas a hallazgos específicos de cohorte o segmento — el consejo de crecimiento genérico que se podría aplicar a cualquier producto no añade valor
+ ## Quality Checks
- ## Frases Gatillo de Ejemplo
+ Ejecuta todos los checks antes de entregar output. No marques un check como pasado a menos que sea verificablemente verdadero dado los datos suministrados.
- - "Ejecuta un análisis de cohortes para nuestro producto SaaS"
- - "Analiza retención por mes de adquisición para las últimas 12 cohortes"
- - "¿Cuál es el LTV de usuarios que vinieron a través de paid vs orgánico?"
- - "Construye un modelo de retención de cohortes mostrando período 0 a período 12"
- - "Segmenta usuarios por comportamiento y muéstrame qué grupo retiene mejor"
+ - [ ] **Exclusividad mutua:** Ningún usuario puede aparecer en dos cohortes — evento de entrada y límites de fecha son unambiguos
+ - [ ] **Meseta de retención:** La curva muestra una meseta visible, o el análisis explícitamente declara la ventana demasiado corta para confirmar una
+ - [ ] **Grounding de LTV:** Las proyecciones de LTV usan retención observada y ARPU observado — no figuras asumidas
+ - [ ] **Segmentos comportamentales:** Mutuamente excluyentes y colectivamente exhaustivos — cada usuario en alcance cae en exactamente un segmento
+ - [ ] **Tamaño mínimo de cohorte:** Cualquier cohorte por debajo del threshold de confiabilidad está marcada y excluida de conclusiones de tendencias
+ - [ ] **Señales de churn:** Todos los indicadores principales listados son observables en datos de producción, o explícitamente marcados como hipótesis
+ - [ ] **Recomendaciones ancladas:** Cada recomendación referencia un hallazgo específico — no consejos de growth flotantes
+ - [ ] **SQL adaptado:** La query usa los nombres de tabla/columna reales del usuario si esquema fue proporcionado
+
+ ---
+
+ ## Anti-Patterns
+
+ Evita estos failure modes — producen análisis que parecen rigurosos pero no pueden ser confiados o actados.
+
+ | Anti-pattern | Por qué falla | Approach correcto |
+ |---|---|---|
+ | Membresía de cohorte superpuesta | Los números de retención entre cohortes no pueden compararse | Define un único evento de entrada unambiguo; un usuario, una cohorte |
+ | ARPU asumido en proyecciones de LTV | Oculta diferencias de segmento; produce un número que suena preciso pero no lo es | Usa ingresos observados por usuario retenido por período, desglosado por segmento |
+ | Sacando conclusiones de cohortes undersized | La variación aleatoria se disfraza de signal | Marca tamaño mínimo de cohorte; excluye o caveata cohortes bajo threshold |
+ | Conflating login con retención | Un usuario que inicia sesión pero no completa el evento clave no está retenido por definición | Retención = completación del evento de retención clave definido, no una sesión |
+ | Fabricando estimados de lift | Números de impacto proyectado sin base de datos mislead decisiones de priorización | Si el impacto no puede estimarse de datos, decláralo y recomienda un test |
+ | Recomendaciones genéricas | Consejos que podrían aplicar a cualquier producto SaaS no añade valor analítico | Cada recomendación debe referenciar un hallazgo específico de cohorte, segmento o señal |
+
+ ---
+
+ ## Frases Trigger
+
+ Esta skill se activa en frases incluyendo:
+
+ - "Ejecuta un análisis de cohortes para [producto]"
+ - "Analiza retención por mes de adquisición"
+ - "¿Cuál es el LTV de usuarios de [canal] vs [canal]?"
+ - "Construye un modelo de retención de cohortes desde"
+
+ ## Ejemplos de Frases Trigger
+
+ - "Ejecuta un análisis de cohortes."
+ - "Analiza retención por cohorte."
+ - "Calcula valor de vida útil por período de adquisición."