amplitude/builder-skills

Analista de Experimentos

Realize uma análise aprofundada e abrangente de experimentos para tomar decisões de lançamento/não lançamento baseadas em dados. Esta NÃO é uma análise rápida - forneça insights detalhados com números específicos e implicações de negócio.

Quando Usar

• Analisar resultados de experimentos concluídos para decisões de lançamento
• Verificar o progresso de experimentos em execução e sinais precoces
• Entender por que um experimento teve sucesso ou falhou
• Investigar resultados inesperados ou efeitos em nível de segmento

---

Filosofia de Análise

Seja abrangente, não breve:

• Inclua números, porcentagens e pontos de dados específicos
• Explique o significado estatístico E as implicações de negócio em linguagem simples
• Cubra todas as métricas (primárias, secundárias, guardrails) com valores reais
• Esta é uma análise única e abrangente - não se apresse nem forneça resumos superficiais

---

Instruções

Etapa 0: Identificar o Experimento

Se o usuário fornecer um experimento específico:

• Aceite a URL ou ID do experimento
• Se for URL: use Amplitude:get_from_url para extrair os detalhes
• Se for ID: prossiga para a Etapa 1

Se o usuário perguntar sobre experimentos em geral:

• Use Amplitude:search com entityTypes: ["EXPERIMENT"] e termos de consulta relevantes
• Apresente os 3-5 principais resultados com nomes, IDs e estados
• Pergunte ao usuário qual experimento analisar

Se nenhum experimento for especificado:

• Peça explicitamente a URL, ID ou termos de busca do experimento e pare

---

Etapa 1: Recuperar e Validar a Configuração

Use Amplitude:get_experiments com o ID do experimento para capturar:

• Nome, chave, descrição e estado do experimento
• Datas de início/término e duração
• Variantes: nomes, alocação de tráfego
• Métricas anexadas: primária (recommendation=true), secundárias, guardrails (armazenadas como IDs)
• Estratégia de agrupamento

Obter nomes das métricas:

• Extraia os IDs das métricas da resposta do experimento (ex.: "c4pn8fkv")
• CRÍTICO: O MCP do Amplitude não consegue recuperar nomes de métricas diretamente pelo ID
• Opções de contorno:
  1. Pesquise gráficos relacionados ao experimento usando Amplitude:search com entityTypes: ["CHART"] e nome do experimento
  2. Use Amplitude:get_charts em gráficos relacionados para examinar suas definições em busca de referências de métricas
  3. Verifique se a descrição do experimento contém links para documentação das métricas
• Se os nomes das métricas não puderem ser encontrados, relate como placeholders descritivos:
  • Métrica primária: "Métrica de Objetivo Principal (ID: {id})"
  • Métricas secundárias: "Métrica Secundária {índice} (ID: {id})"
  • Inclua os IDs das métricas para que os usuários possam consultá-los na interface do Amplitude

Validação:

• O experimento está em execução ou concluído? (não rascunho)
• Ele está em execução há 1+ semanas?
• As variantes e métricas estão claramente definidas?

Se estiver incompleto, explique o que está faltando e pare.

---

Etapa 2: Verificar a Qualidade dos Dados (com limites explícitos)

Use Amplitude:query_experiment (apenas métrica primária) para avaliar:

Equilíbrio de Tráfego (Verificação de SRM):

• Relate a divisão real de tráfego por variante (ex.: 48,2% controle, 51,8% tratamento)
• Use o campo srmDetected da API: Sinalize se srmDetected: true
• SRM (Sample Ratio Mismatch - Incompatibilidade na Proporção da Amostra) indica que a divisão de tráfego observada se desvia significativamente da alocação esperada
• Se SRM for detectado, relate a alocação esperada vs. real com porcentagens específicas
• SRM grave pode indicar problemas de instrumentação ou problemas de agrupamento que podem invalidar os resultados

Análise do Tamanho da Amostra:

A. Avaliação da Amostra Atual:

• Relate o total de usuários por variante com números específicos
• Sinalize se <100 usuários por variante (insuficiente para qualquer conclusão)
• Sinalize se 100-1000 usuários (sinais direcionais apenas, não uma decisão confiante)
• São necessários 1000+ por variante para decisões confiantes

B. Análise de Poder Estatístico:

• Tamanho do efeito alvo: Qual o menor aumento que seria significativo para o negócio? (tipicamente 2-5% para métricas de conversão)
• Poder alcançado: Dado o tamanho atual da amostra e a variância observada, qual é a probabilidade de detectar o efeito alvo, se ele existir?
• Interpretação do poder:
  • <50%: Severamente com baixo poder - provável que perca efeitos reais
  • 50-70%: Com baixo poder - alto risco de falsos negativos
  • 70-80%: Marginalmente adequado - considere estender se o valor-p estiver no limite
  • 80%+: Bem dimensionado - suficiente para detectar o tamanho do efeito alvo
• Se com baixo poder: Calcule o tamanho adicional da amostra necessário para atingir 80% de poder
• Recomendação: Se o poder <70% e os resultados forem inconclusivos, estenda a duração em vez de tomar uma decisão prematura

C. Análise de Precisão (Largura do Intervalo de Confiança):

• Largura do IC para a métrica primária: Relate a largura do intervalo de confiança de 95% como porcentagem da linha de base
• Avaliação de precisão:
  • Largura do IC >10% da linha de base: Baixa precisão - a incerteza do tamanho do efeito é muito alta para decisões confiantes
  • Largura do IC entre 5-10% da linha de base: Precisão moderada - aceitável para decisões direcionais
  • Largura do IC <5% da linha de base: Alta precisão - estreito o suficiente para decisões confiantes
• Limite de acionabilidade: O IC é estreito o suficiente para distinguir entre efeitos praticamente significativos e insignificantes?
  • Se o limite inferior do IC sugerir um aumento significativo, mas o limite superior for marginal, a precisão pode ser insuficiente
  • Exemplo: Se o alvo for um aumento de +5% e o IC for [-2%, +12%], é muito amplo para concluir com confiança que o efeito excede o alvo
• Recomendação: Se o IC for muito amplo, estenda a duração ou aumente a alocação de tráfego para melhorar a precisão

Sinalizadores Abrangentes de Qualidade de Dados:

A API Amplitude:query_experiment retorna múltiplos sinalizadores booleanos que avaliam a validade estatística. Verifique e documente cada um:

1. statsAssumptionsMetForWholeExperiment:

   • Indica se as suposições estatísticas principais são satisfeitas (normalidade, independência)
   • Se falso: Os resultados podem não ser confiáveis; considere abordagens não paramétricas ou maior tempo de execução
   • Impacto: Alto - afeta todas as conclusões estatísticas

2. hasSuspiciousUplift:

   • Sinaliza tamanhos de efeito inesperadamente grandes que podem indicar problemas de qualidade de dados
   • Se verdadeiro: Verifique a instrumentação, procure por tráfego de bots ou anomalias de segmento
   • Impacto: Alto - pode indicar erro de medição em vez de efeito real

3. isVariancePositive:

   • Confirma que a variância da métrica é positiva (matematicamente necessária para testes estatísticos)
   • Se falso: Problema crítico de qualidade de dados - a métrica pode ser constante ou computada incorretamente
   • Impacto: Crítico - testes estatísticos inválidos se falso

4. isConfidenceIntervalNotFlipped:

   • Garante que o limite inferior do IC < limite superior do IC (verificação de consistência matemática)
   • Se falso: Indica erro de cálculo ou corrupção de dados
   • Impacto: Crítico - os resultados não podem ser confiáveis

5. isStandardErrorLargeEnough:

   • Verifica se o erro padrão é suficiente para inferência confiável
   • Se falso: Variância alta ou amostra muito pequena pode produzir intervalos de confiança não confiáveis
   • Impacto: Médio - afeta a precisão das estimativas

6. isPointEstimateInsideConfidenceInterval:

   • Valida que a estimativa pontual cai dentro do seu intervalo de confiança (verificação de consistência)
   • Se falso: Erro de cálculo ou instabilidade numérica
   • Impacto: Alto - indica problemas de computação estatística

7. isMeanValid:

   • Confirma que o valor médio é um número válido (não NaN, não infinito)
   • Se falso: Problema de qualidade de dados - verifique valores nulos ou erros de computação
   • Impacto: Crítico - não é possível analisar se a média é inválida

Para cada sinalizador que falhar (retornar falso ou verdadeiro para uplift suspeito), documente:

• Qual sinalizador falhou
• O que significa em linguagem simples
• Impacto específico na confiabilidade do resultado
• Ação recomendada (estender duração, investigar instrumentação, etc.)

Se todos os sinalizadores passarem: Observe isso explicitamente como um forte sinal de qualidade de dados

Estabilidade Temporal:

• Verifique se a métrica primária é estável dia após dia
• Observe o período de ramp-up (primeiras 24-48 horas) ou efeitos de dia da semana

Documente todos os problemas de qualidade de dados encontrados - eles afetam a confiabilidade dos resultados.

---

Etapa 3: Analisar a Métrica Primária

Use Amplitude:query_experiment sem metricIds para obter apenas a métrica primária.

Use o nome da métrica da Etapa 1 - Relate usando o nome legível da métrica, não o ID da métrica.

Extraia e relate:

• Linha de base do controle: valor da métrica e tamanho da amostra
• Desempenho do tratamento: valor da métrica e tamanho da amostra
• Aumento absoluto: tratamento - controle
• Aumento relativo: (tratamento - controle) / controle × 100%
• Valor-p: com interpretação
• Intervalo de confiança: relate os limites do IC de 95%

Interpretação:

• ✅ Estatisticamente significativo: p < 0,05 e IC não inclui 0
• ⚠️ Tendência: 0,05 < p < 0,15 (sugestivo, mas inconclusivo)
• ❌ Sem efeito: p ≥ 0,15 ou IC inclui 0

Significância prática:

• A magnitude do aumento é significativa para o negócio?
• Aumentos pequenos (<2-3%) podem não valer a complexidade, mesmo que significativos
• Considere o impacto da métrica no negócio (receita vs. engajamento de baixo valor)

---

Etapa 4: Analisar Métricas Secundárias e Guardrails

Use Amplitude:query_experiment com metricIds para todas as métricas.

Use os nomes das métricas da Etapa 1 - Relate usando nomes legíveis, não IDs.

Para cada métrica secundária:

• Relate o nome da métrica (do mapeamento da Etapa 1), o desempenho da variante e a significância estatística
• Observe quais se moveram e quais não (com números específicos)
• Identifique consequências não intencionais: Sinalize quaisquer impactos negativos com valores específicos

Para cada guardrail:

• ✅ Sem regressão: neutro ou positivo (p > 0,05)
• ⚠️ Preocupação marginal: pequeno impacto negativo (1-5%) com p < 0,10
• 🚩 Regressão significativa: impacto negativo com p < 0,05 - relate números reais

Pergunta-chave: Alguma métrica está mostrando degradação (receita, retenção, engajamento, taxas de erro)?

Testes múltiplos: Se analisar 5+ métricas, considere a correção de Bonferroni (alfa = 0,05 / número de métricas)

---

Etapa 5: Análise Abrangente de Segmentos

Use Amplitude:query_experiment com o parâmetro groupBy (um de cada vez).

Teste 3-4 segmentos de alto sinal:

1. Plataforma (iOS, Android, Web)
2. Tempo de uso (usuários novos vs. estabelecidos)
3. Tipo de plano (gratuito vs. pago)
4. Geografia (país, região)

OBRIGATÓRIO: Formate os resultados como tabelas de divisão em markdown

Para cada análise de segmento, apresente os resultados neste formato exato:

Segmento	Taxa de Controle	Exposições de Controle	% do Total de Controle	Taxa de Tratamento	Exposições de Tratamento	% do Total de Tratamento	Aumento Relativo	Significativo?
iOS	48,7%	1.234	45,2%	55,4%	1.456	54,8%	+13,6%	Sim (p=0,02)
Android	63,9%	567	20,8%	65,1%	589	22,2%	+1,9%	Não (p=0,45)
Web	51,2%	928	34,0%	50,8%	611	23,0%	-0,8%	Não (p=0,89)

Calcule a % do Total:

• Some todas as exposições entre os segmentos para obter o total
• Mostre a parcela de cada segmento: (exposições do segmento / exposições totais) × 100%
• Isso revela quais segmentos impulsionam os resultados gerais

Insights-chave:

• Identifique segmentos onde o tratamento tem melhor desempenho (oportunidade de lançamento direcionado)
• Identifique segmentos onde o tratamento prejudica (considere exclusões)
• Explique por que segmentos diferentes mostram desempenho diferente
• Cuidado com o Paradoxo de Simpson: O resultado geral pode diferir de todos os resultados do segmento

Use groupByLimit: 10 para evitar sobrecarregar a saída.

---

Etapa 6: Avaliar Suficiência de Duração e Tempo de Execução

Avaliação de Duração: Com base na análise de poder e precisão da Etapa 2, avalie se o experimento foi executado por tempo suficiente:

Fatores de tempo de execução:

• Duração mínima: O experimento foi executado por pelo menos 1-2 semanas para capturar o ciclo de vida completo do usuário?
• Efeitos de aprendizado: Para mudanças de funcionalidades, os usuários tiveram tempo para se adaptar? (tipicamente 3-7 dias)
• Sazonalidade semanal: O experimento capturou pelo menos uma semana completa para levar em conta os padrões de dia da semana?
• Ciclos de negócios: Para produtos B2B, ele foi executado durante os padrões completos da semana de trabalho?

Integração com a análise de poder da Etapa 2:

• Se a Etapa 2 mostrou poder adequado (>80%) E p < 0,05: O experimento tem dados suficientes, a duração é adequada
• Se a Etapa 2 mostrou baixo poder (<70%) E p > 0,05: Inconclusivo devido a dados insuficientes, estenda a duração
• Se a Etapa 2 mostrou poder adequado (>80%) E p > 0,15: Dados suficientes para aceitar o resultado nulo (sem efeito)
• Se a Etapa 2 mostrou poder adequado, mas a largura do IC é muito ampla: Precisa de mais dados para precisão, estenda a duração

Projeção de velocidade (apenas se a extensão for recomendada):

• Inscrição diária atual: Calcule usuários por dia por variante
• Dias para a amostra alvo: Com base no cálculo de poder da Etapa 2, quantos dias adicionais são necessários?
• Dias para a precisão alvo: Com base no cálculo de largura do IC da Etapa 2, quantos dias adicionais para atingir a precisão desejada?
• Recomendação: Forneça uma data específica em que o experimento deve atingir poder/precisão suficientes

NÃO repita os cálculos de poder da Etapa 2 - faça referência a essas descobertas e concentre-se nas recomendações de duração e cronograma.

---

Etapa 7: Entender o Porquê (Contexto Qualitativo)

Para resultados significativos (positivos ou negativos):

Use Amplitude:get_feedback_insights:

• Filtre pelo intervalo de datas do experimento
• Para vitórias: procure por ["lovedFeature", "mentionedFeature"]
• Para perdas: procure por ["bug", "complaint", "painPoint"]
• Verifique se os temas estão alinhados com a hipótese do experimento

Conecte o quantitativo ao qualitativo:

• Explique o aumento com citações de usuários ou temas de feedback
• Apresente 2-3 exemplos representativos com detalhes específicos

---

Etapa 8: Sintetizar Descobertas e Fazer Recomendação

Antes de finalizar, verifique se você incluiu:

• ✓ Todos os dados da métrica primária (aumento, IC, valor-p, interpretação)
• ✓ Todas as descobertas de qualidade de dados (SRM, tamanho da amostra, poder, precisão, todos os 7 sinalizadores de validade com valores reais)
• ✓ Todas as métricas secundárias e guardrails (com valores reais e significância)
• ✓ Todas as tabelas de análise de segmento (formatadas com % de exposições totais)
• ✓ Avaliação de poder estatístico (poder atual, amostra necessária, duração)
• ✓ Descobertas qualitativas (temas de feedback, citações de usuários)
• ✓ Implicações de negócio claras (o que significa para receita, retenção, experiência do usuário)
• ✓ Risco de extensão (perigo de continuar o experimento - custo de oportunidade de não lançar algo melhor)
• ✓ Recomendação final clara com justificativa

Formate seu resumo final:

📋 Resumo da Análise

Experimento: [Nome do Experimento] Estado: [Em execução / Concluído] Duração: [Dias] dias Métrica Primária: [Nome]

🔑 Principais Conclusões

• [Conclusão principal da métrica primária]
• [Principais descobertas de qualidade de dados]
• [Alterações nas métricas secundárias]
• [Efeitos de segmento]

✅ Recomendação: [LANÇAR / NÃO LANÇAR / ESTENDER]

Justificativa: [Explicação concisa baseada em todas as análises acima]

Próximos passos:

• [Recomendações acionáveis]
• [Riscos a monitorar]
• [Experimentos de acompanhamento sugeridos]