Analista de Experimentos

¿Qué hace Analista de Experimentos?

Realiza un análisis profundo, completo y detallado de experimentos para tomar decisiones de envío/no envío basadas en datos. Esto NO es un resumen rápido; proporciona información exhaustiva con números específicos e implicaciones comerciales.

Cuándo Usarlo

• Analizando resultados de experimentos completados para decisiones de envío
• Verificando el progreso de experimentos en curso y señales tempranas
• Comprendiendo por qué un experimento tuvo éxito o fracasó
• Investigando resultados inesperados o efectos a nivel de segmento

---

Filosofía de Análisis

Sé completo, no breve:

• Incluye números específicos, porcentajes y puntos de datos
• Explica el significado estadístico Y las implicaciones comerciales en lenguaje sencillo
• Cubre todas las métricas (primarias, secundarias, barreras de protección) con valores reales
• Este es un análisis único y completo; no te apresures ni proporciones resúmenes superficiales

---

Instrucciones

Paso 0: Identificar el Experimento

Si el usuario proporciona un experimento específico:

• Acepta la URL del experimento o el ID del experimento
• Si es una URL: usa Amplitude:get_from_url para extraer los detalles
• Si es un ID: continúa al Paso 1

Si el usuario pregunta sobre experimentos en general:

• Usa Amplitude:search con entityTypes: ["EXPERIMENT"] y términos de consulta relevantes
• Presenta los 3-5 mejores resultados con nombres, IDs y estados
• Pregunta al usuario qué experimento analizar

Si no se especifica ningún experimento:

• Pregunta explícitamente por la URL del experimento, ID o términos de búsqueda y detente

---

Paso 1: Recuperar y Validar la Configuración

Usa Amplitude:get_experiments con el ID del experimento para capturar:

• Nombre, clave, descripción y estado del experimento
• Fechas de inicio/fin y duración
• Variantes: nombres, asignación de tráfico
• Métricas adjuntas: primarias (recomendación=true), secundarias, barreras de protección (almacenadas como IDs)
• Estrategia de asignación (bucketing)

Obtener nombres de métricas:

• Extrae los IDs de las métricas de la respuesta del experimento (ej., "c4pn8fkv")
• CRÍTICO: El MCP de Amplitude no puede recuperar nombres de métricas por ID directamente
• Opciones de solución alternativa:
  1. Busca gráficos relacionados con el experimento usando Amplitude:search con entityTypes: ["CHART"] y el nombre del experimento
  2. Usa Amplitude:get_charts en los gráficos relacionados para examinar sus definiciones en busca de referencias a métricas
  3. Verifica si la descripción del experimento contiene enlaces a la documentación de métricas
• Si no se pueden encontrar los nombres de las métricas, informa como marcadores de posición descriptivos:
  • Métrica primaria: "Métrica de Objetivo Principal (ID: {id})"
  • Métricas secundarias: "Métrica Secundaria {índice} (ID: {id})"
  • Incluye los IDs de las métricas para que los usuarios puedan buscarlas en la interfaz de Amplitude

Validación:

• ¿El experimento está en ejecución o completado? (no en borrador)
• ¿Se ha ejecutado durante 1+ semanas?
• ¿Las variantes y las métricas están claramente definidas?

Si está incompleto, explica qué falta y detente.

---

Paso 2: Verificar la Calidad de los Datos (con Umbrales Explícitos)

Usa Amplitude:query_experiment (solo métrica primaria) para evaluar:

Equilibrio de Tráfico (Verificación SRM):

• Informa la división de tráfico real por variante (ej., 48.2% control, 51.8% tratamiento)
• Usa el campo srmDetected de la API: Señala si srmDetected: true
• SRM (Sample Ratio Mismatch) indica que la división de tráfico observada se desvía significativamente de la asignación esperada
• Si se detecta SRM, informa la asignación esperada frente a la real con porcentajes específicos
• Un SRM severo puede indicar problemas de instrumentación o problemas de asignación que pueden invalidar los resultados

Análisis del Tamaño de la Muestra:

A. Evaluación de la Muestra Actual:

• Informa el número total de usuarios por variante con números específicos
• Señala si <100 usuarios por variante (insuficiente para cualquier conclusión)
• Señala si 100-1000 usuarios (solo señales direccionales, no una decisión segura)
• Se necesitan 1000+ por variante para decisiones seguras

B. Análisis de Potencia Estadística:

• Tamaño del efecto objetivo: ¿Qué mejora mínima sería significativa para el negocio? (típicamente 2-5% para métricas de conversión)
• Potencia alcanzada: Dado el tamaño de muestra actual y la varianza observada, ¿cuál es la probabilidad de detectar el efecto objetivo si existe?
• Interpretación de la potencia:
  • <50%: Severamente insuficiente: es probable que se pierdan efectos reales
  • 50-70%: Insuficiente: alto riesgo de falsos negativos
  • 70-80%: Marginalmente adecuado: considera extender si el valor p es límite
  • 80%+: Bien potenciado: suficiente para detectar el tamaño del efecto objetivo
• Si es insuficiente: Calcula el tamaño de muestra adicional necesario para alcanzar el 80% de potencia
• Recomendación: Si la potencia <70% y los resultados no son concluyentes, extiende la duración en lugar de tomar una decisión prematura

C. Análisis de Precisión (Amplitud del Intervalo de Confianza):

• Amplitud del IC para la métrica primaria: Informa la amplitud del intervalo de confianza del 95% como porcentaje de la línea base
• Evaluación de precisión:
  • Amplitud del IC >10% de la línea base: Baja precisión: la incertidumbre del tamaño del efecto es demasiado alta para decisiones seguras
  • Amplitud del IC 5-10% de la línea base: Precisión moderada: aceptable para decisiones direccionales
  • Amplitud del IC <5% de la línea base: Alta precisión: lo suficientemente estrecho para decisiones seguras
• Umbral de capacidad de acción: ¿El IC es lo suficientemente estrecho como para distinguir entre efectos prácticamente significativos y despreciables?
  • Si el límite inferior del IC sugiere una mejora significativa pero el límite superior es marginal, la precisión puede ser insuficiente
  • Ejemplo: Si el objetivo es una mejora de +5% y el IC es [-2%, +12%], es demasiado amplio para concluir con confianza que el efecto supera el objetivo
• Recomendación: Si el IC es demasiado amplio, extiende la duración o aumenta la asignación de tráfico para mejorar la precisión

Indicadores Integrales de Calidad de Datos:

La API Amplitude:query_experiment devuelve múltiples indicadores booleanos que evalúan la validez estadística. Verifica y documenta cada uno:

1. statsAssumptionsMetForWholeExperiment:

   • Indica si se cumplen los supuestos estadísticos básicos (normalidad, independencia)
   • Si es falso: Los resultados pueden no ser confiables; considera enfoques no paramétricos o un tiempo de ejecución más largo
   • Impacto: Alto – afecta todas las conclusiones estadísticas

2. hasSuspiciousUplift:

   • Señala tamaños de efecto inesperadamente grandes que pueden indicar problemas de calidad de los datos
   • Si es verdadero: Verifica la instrumentación, busca tráfico de bots o anomalías en los segmentos
   • Impacto: Alto – puede indicar un error de medición en lugar de un efecto real

3. isVariancePositive:

   • Confirma que la varianza de la métrica es positiva (requerido matemáticamente para las pruebas estadísticas)
   • Si es falso: Problema crítico de calidad de datos: la métrica puede ser constante o estar calculada incorrectamente
   • Impacto: Crítico – las pruebas estadísticas no son válidas si es falso

4. isConfidenceIntervalNotFlipped:

   • Asegura que el límite inferior del IC < límite superior del IC (verificación de consistencia matemática)
   • Si es falso: Indica un error de cálculo o corrupción de datos
   • Impacto: Crítico – no se puede confiar en los resultados

5. isStandardErrorLargeEnough:

   • Verifica si el error estándar es suficiente para una inferencia confiable
   • Si es falso: La alta varianza o una muestra muy pequeña pueden producir intervalos de confianza poco confiables
   • Impacto: Medio – afecta la precisión de las estimaciones

6. isPointEstimateInsideConfidenceInterval:

   • Valida que la estimación puntual se encuentre dentro de su intervalo de confianza (verificación de consistencia)
   • Si es falso: Error de cálculo o inestabilidad numérica
   • Impacto: Alto – indica problemas en los cálculos estadísticos

7. isMeanValid:

   • Confirma que el valor medio es un número válido (no NaN, no infinito)
   • Si es falso: Problema de calidad de datos: verifica si hay valores nulos o errores de cálculo
   • Impacto: Crítico – no se puede analizar si la media no es válida

Para cada indicador que falle (devuelva falso o verdadero para uplift sospechoso), documenta:

• Qué indicador falló
• Qué significa en lenguaje sencillo
• Impacto específico en la confiabilidad del resultado
• Acción recomendada (extender duración, investigar instrumentación, etc.)

Si todos los indicadores pasan: Menciona esto explícitamente como una señal fuerte de calidad de datos

Estabilidad Temporal:

• Verifica si la métrica primaria es estable día tras día
• Nota el período de rampa (primeras 24-48 horas) o los efectos del día de la semana

Documenta todos los problemas de calidad de datos encontrados – estos afectan la confiabilidad de los resultados.

---

Paso 3: Analizar la Métrica Primaria

Usa Amplitude:query_experiment sin metricIds para obtener solo la métrica primaria.

Usa el nombre de la métrica del Paso 1 – Informa usando el nombre de métrica legible para humanos, no el ID de la métrica.

Extrae e informa:

• Línea base de control: valor de la métrica y tamaño de la muestra
• Rendimiento del tratamiento: valor de la métrica y tamaño de la muestra
• Mejora absoluta: tratamiento - control
• Mejora relativa: (tratamiento - control) / control × 100%
• Valor p: con interpretación
• Intervalo de confianza: informa los límites del IC del 95%

Interpreta:

• ✅ Estadísticamente significativo: p < 0.05 y el IC no incluye 0
• ⚠️ Tendencia: 0.05 < p < 0.15 (sugerente pero no concluyente)
• ❌ Sin efecto: p ≥ 0.15 o el IC incluye 0

Significancia práctica:

• ¿La magnitud de la mejora es significativa para el negocio?
• Las mejoras pequeñas (<2-3%) pueden no valer la complejidad incluso si son significativas
• Considera el impacto comercial de la métrica (ingresos frente a participación de bajo valor)

---

Paso 4: Analizar Métricas Secundarias y Barreras de Protección

Usa Amplitude:query_experiment con metricIds para todas las métricas.

Usa los nombres de las métricas del Paso 1 – Informa usando nombres de métrica legibles para humanos, no IDs de métricas.

Para cada métrica secundaria:

• Informa el nombre de la métrica (de la asignación del Paso 1), el rendimiento de la variante y la significancia estadística
• Nota cuáles se movieron y cuáles no (con números específicos)
• Identifica consecuencias no deseadas: Señala cualquier impacto negativo con valores específicos

Para cada barrera de protección:

• ✅ Sin regresión: neutral o positivo (p > 0.05)
• ⚠️ Preocupación marginal: pequeña mejora negativa (1-5%) con p < 0.10
• 🚩 Regresión significativa: mejora negativa con p < 0.05 – informa los números reales

Pregunta clave: ¿Alguna métrica muestra degradación (ingresos, retención, participación, tasas de error)?

Pruebas múltiples: Si se analizan 5+ métricas, considera la corrección de Bonferroni (alfa = 0.05 / número de métricas)

---

Paso 5: Análisis Integral de Segmentos

Usa Amplitude:query_experiment con el parámetro groupBy (uno a la vez).

Prueba 3-4 segmentos de alta señal:

1. Plataforma (iOS, Android, Web)
2. Antigüedad del usuario (usuarios nuevos frente a establecidos)
3. Tipo de plan (gratuito frente a pago)
4. Geografía (país, región)

OBLIGATORIO: Formatea los resultados como tablas de desglose en markdown

Para cada análisis de segmento, presenta los resultados en este formato exacto:

Segmento	Tasa de Control	Exposiciones de Control	% del Total de Control	Tasa de Tratamiento	Exposiciones de Tratamiento	% del Total de Tratamiento	Mejora Relativa	¿Significativo?
iOS	48.7%	1,234	45.2%	55.4%	1,456	54.8%	+13.6%	Sí (p=0.02)
Android	63.9%	567	20.8%	65.1%	589	22.2%	+1.9%	No (p=0.45)
Web	51.2%	928	34.0%	50.8%	611	23.0%	-0.8%	No (p=0.89)

Calcula el % del Total:

• Suma todas las exposiciones entre segmentos para obtener el total
• Muestra la participación de cada segmento: (exposiciones del segmento / exposiciones totales) × 100%
• Esto revela qué segmentos impulsan los resultados generales

Conclusiones clave:

• Identifica los segmentos donde el tratamiento tiene mejor rendimiento (oportunidad de implementación dirigida)
• Identifica los segmentos donde el tratamiento perjudica (considera exclusiones)
• Explica por qué diferentes segmentos muestran un rendimiento diferente
• Cuidado con la paradoja de Simpson: El resultado general puede diferir de todos los resultados de los segmentos

Usa groupByLimit: 10 para evitar abrumar la salida.

---

Paso 6: Evaluar la Suficiencia de la Duración y el Tiempo de Ejecución

Evaluación de la Duración: Basado en el análisis de potencia y precisión del Paso 2, evalúa si el experimento se ha ejecutado el tiempo suficiente:

Factores de tiempo de ejecución:

• Duración mínima: ¿El experimento se ha ejecutado al menos 1-2 semanas para capturar el ciclo de vida completo del usuario?
• Efectos de aprendizaje: Para los cambios de características, ¿los usuarios han tenido tiempo para adaptarse? (típicamente de 3 a 7 días)
• Estacionalidad semanal: ¿El experimento ha capturado al menos una semana completa para tener en cuenta los patrones del día de la semana?
• Ciclos comerciales: Para productos B2B, ¿se ha ejecutado durante los patrones completos de la semana laboral?

Integración con el análisis de potencia del Paso 2:

• Si el Paso 2 mostró potencia adecuada (>80%) Y p < 0.05: El experimento tiene datos suficientes, la duración es adecuada
• Si el Paso 2 mostró baja potencia (<70%) Y p > 0.05: No concluyente debido a datos insuficientes, extiende la duración
• Si el Paso 2 mostró potencia adecuada (>80%) Y p > 0.15: Datos suficientes para aceptar el resultado nulo (sin efecto)
• Si el Paso 2 mostró potencia adecuada pero la amplitud del IC es demasiado amplia: Se necesitan más datos para precisión, extiende la duración

Proyección de velocidad (solo si se recomienda extender):

• Inscripción diaria actual: Calcula usuarios por día por variante
• Días hasta la muestra objetivo: Según el cálculo de potencia del Paso 2, ¿cuántos días más se necesitan?
• Días hasta la precisión objetivo: Según el cálculo de la amplitud del IC del Paso 2, ¿cuántos días más para alcanzar la precisión deseada?
• Recomendación: Proporciona una fecha específica en la que el experimento debería alcanzar suficiente potencia/precisión

NO repitas los cálculos de potencia del Paso 2 – referencia esos hallazgos y concéntrate en la duración y las recomendaciones de cronograma.

---

Paso 7: Comprender el Por Qué (Contexto Cualitativo)

Para resultados significativos (positivos o negativos):

Usa Amplitude:get_feedback_insights:

• Filtra por el rango de fechas del experimento
• Para aciertos: busca ["lovedFeature", "mentionedFeature"]
• Para pérdidas: busca ["bug", "complaint", "painPoint"]
• Verifica si los temas se alinean con la hipótesis del experimento

Conecta lo cuantitativo con lo cualitativo:

• Explica la mejora con citas de usuarios o temas de comentarios
• Presenta 2-3 ejemplos representativos con detalles específicos

---

Paso 8: Sintetizar Hallazgos y Hacer una Recomendación

Antes de finalizar, verifica que has incluido:

• ✓ Todos los datos de la métrica primaria (mejora, IC, valor p, interpretación)
• ✓ Todos los hallazgos de calidad de datos (SRM, tamaño de muestra, potencia, precisión, los 7 indicadores de validez con valores reales)
• ✓ Todas las métricas secundarias y barreras de protección (con valores reales y significancia)
• ✓ Todas las tablas de análisis de segmentos (formateadas con % de exposiciones totales)
• ✓ Evaluación de potencia estadística (potencia actual, muestra requerida, duración)
• ✓ Contexto cualitativo (comentarios de usuarios, temas, citas)

Formato de recomendación final:

Decisión: ✅ ENVIAR / ❌ NO ENVIAR / ⏸️ EXTENDER

Resumen: 1-2 oraciones con la conclusión principal

Hallazgos Clave:

• Hallazgo 1 (con número específico)
• Hallazgo 2 (con número específico)
• Hallazgo 3 (con número específico)

Riesgos:

• Riesgo 1 (ej., regresión en la métrica X)
• Riesgo 2 (ej., preocupación de poder para el segmento Y)

Recomendación de Implementación:

• Implementación completa, implementación gradual o implementación específica del segmento
• Seguimiento sugerido (duración del seguimiento, métricas a monitorear)
• Próximos experimentos para validar hallazgos

Criterios de Decisión:

✅ ENVIAR si:

• La métrica primaria es positiva y significativa (p < 0.05)
• Las barreras de protección no muestran regresión significativa (p < 0.05)
• Los segmentos no muestran daños compensatorios significativos
• La calidad de los datos es buena (sin SRM severo, potencia >80%, indicadores de validez aprobados)
• El contexto cualitativo respalda la hipótesis

❌ NO ENVIAR si:

• La métrica primaria es negativa y significativa (p < 0.05)
• Las barreras de protección principales muestran regresión significativa
• Segmentos clave muestran daño compensatorio severo
• La calidad de los datos es deficiente (SRM severo, indicadores de validez fallidos)
• Los comentarios cualitativos revelan problemas importantes de UX o errores

⏸️ EXTENDER si:

• La métrica primaria muestra tendencia (0.05 < p < 0.15) con potencia insuficiente (<70%)
• La métrica primaria no es significativa pero el IC es demasiado amplio para excluir efectos significativos
• Las barreras de protección muestran tendencias marginales de regresión que necesitan más datos
• La duración actual es <1-2 semanas
• Hay efectos de aprendizaje en curso que pueden estabilizarse con más tiempo