[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EBG4MC4HSEWF177ZVSEM8R":3,"skill-same:01M6EBG4MC4HSEWF177ZVSEM8R":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M6EBG4MC4HSEWF177ZVSEM8R","ab-testing-framework",null,"Ab Testing Framework — Skill especializada para projetar, executar e analisar experimentos A\u002FB complexos para otimização de produtos e growth.","kursku\u002Fskills","kursku","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F15705647?v=4","01M6E5VWJKMRJQ1PNFP2P0PYVZ","01M6E5VWSCHN2C3RVE67795NRC",128,"MIT","https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F08-lancamento-growth\u002Fab-testing-framework\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33],"testing","framework","testing framework","ab testing","ab","ab testing framework","safe","code","para","growth","de","2026-11-10 10:12:30",false,"---\nname: ab-testing-framework\ndescription: \"Ab Testing Framework — Skill especializada para projetar, executar e analisar experimentos A\u002FB complexos para otimização de produtos e growth.\"\nlicense: MIT\nmetadata:\n  version: 1.0.0\n  author: Cafe Code AI\n  category: 08-lancamento-growth\n  updated: 2026-03-01\nrisk: safe\n---\n\n# Ab Testing Framework\n\nCapacita o Claude a projetar, executar e analisar experimentos A\u002FB complexos para otimização de produtos e growth, garantindo decisões baseadas em dados robustos e impactantes.\n\n---\n\n## Keywords\n\nTeste A\u002FB, Teste Multivariado (MVT), Otimização de Conversão (CRO), Hipótese de Experimento, Variância, Nível de Significância (p-valor), Poder Estatístico, Tamanho da Amostra, Mínimo Efeito Detectável (MED), Janela de Observação, Segmentação de Usuários, Métricas de Guarda, Backtesting, Personalização Dinâmica.\n\n---\n\n## Quick Start\n\n1.  **Formule uma Hipótese Específica**: Defina o que será testado, o resultado esperado e o porquê. Ex: \"Ao mudar a cor do botão 'Adicionar ao Carrinho' de cinza para laranja na página de produto, esperamos um aumento de 15% nas adições ao carrinho porque a cor laranja cria maior contraste e urgência visual.\"\n2.  **Calcule o Tamanho da Amostra e Duração**: Utilize uma calculadora de A\u002FB testing (e.g., Optimizely, VWO) para determinar quantos usuários são necessários por variante, considerando a taxa de conversão atual (baseline), o Mínimo Efeito Detectável (MED), poder estatístico (80%) e significância (95%). Ex: Para uma baseline de 5% e MED de 10%, são necessários ~4.000 usuários por variante.\n3.  **Implemente o Experimento**: Utilize uma plataforma de A\u002FB testing (e.g., Google Optimize, VWO, Optimizely, LaunchDarkly) para criar as variantes e direcionar o tráfego de forma aleatória e balanceada (e.g., 50\u002F50 ou 33\u002F33\u002F33).\n4.  **Monitore Métricas de Guarda**: Acompanhe métricas cruciais que não são o foco principal, mas podem ser impactadas negativamente. Ex: Se o teste foca em cliques, monitore a taxa de churn ou tempo na página para garantir que o aumento de cliques não vem à custa da experiência geral.\n5.  **Analise e Tome Decisão**: Após a duração pré-calculada, avalie os resultados estatísticos (p-valor, intervalo de confiança) para determinar se a variante de teste superou o controle de forma significativa. Não finalize o teste prematuramente.\n\n---\n\n## Core Workflows\n\n### Workflow 1: Otimizando a Taxa de Ativação em um Produto SaaS\n\nEste workflow detalha o processo para melhorar a taxa de ativação de novos usuários em um produto SaaS, focando na primeira experiência.\n\n1.  **Identificação da Oportunidade**:\n    *   **Análise de Funil**: Observar que 45% dos usuários que completam o cadastro não realizam a \"primeira ação de valor\" (ex: criar o primeiro projeto, convidar um colega) nos primeiros 7 dias. A taxa de ativação atual é de 30%.\n    *   **Pesquisa Qualitativa**: Entrevistas com usuários recém-cadastrados revelam confusão sobre o \"próximo passo\" após o login.\n2.  **Formulação da Hipótese**:\n    *   **Hipótese**: \"Para *novos usuários cadastrados*, se *implementarmos um tour guiado interativo (tooltip series) nos 3 principais recursos do produto na primeira sessão*, então *esperamos um aumento de 20% na taxa de ativação (primeiro projeto criado em 7 dias)* porque *isso reduzirá a barreira inicial e direcionará o usuário para a ação de valor principal*.\"\n3.  **Definição de Métricas**:\n    *   **Métrica Primária**: Taxa de ativação (percentual de novos usuários que criam o primeiro projeto em 7 dias). Baseline: 30%.\n    *   **Métricas Secundárias**: Taxa de conclusão do tour guiado, tempo para a primeira ação, churn rate em 30 dias.\n4.  **Cálculo do Tamanho da Amostra e Duração**:\n    *   **Baseline**: 30%\n    *   **Mínimo Efeito Detectável (MED)**: 20% de aumento relativo, ou seja, de 30% para 36% (+6 pontos percentuais).\n    *   **Poder Estatístico**: 80%\n    *   **Nível de Significância**: 95% (p \u003C 0.05)\n    *   **Cálculo**: Usando uma calculadora de A\u002FB, seriam necessários aproximadamente 2.500 usuários por variante.\n    *   **Duração**: Se o produto recebe 500 novos usuários por dia, o teste deve rodar por 10 dias (5.000 usuários \u002F 500 usuários\u002Fdia = 10 dias) para garantir que cada variante tenha a amostra necessária. Adicionar alguns dias para capturar o ciclo completo de 7 dias da métrica de ativação. Duração total: 14 dias.\n5.  **Implementação do Experimento**:\n    *   **Ferramenta**: Usar VWO ou Optimizely para criar duas variantes:\n        *   **Controle (A)**: Experiência atual de onboarding.\n        *   **Teste (B)**: Experiência com o tour guiado.\n    *   **Distribuição**: Dividir 50% do tráfego de novos usuários para A e 50% para B.\n    *   **QA**: Testar rigorosamente a implementação para garantir que o tour guiado funcione corretamente e não haja vieses técnicos.\n6.  **Análise e Decisão**:\n    *   **Monitoramento**: Acompanhar as métricas primárias e secundárias diariamente, mas *sem tomar decisões prematuras*.\n    *   **Após 14 dias**: Coletar e analisar os dados.\n        *   **Resultados**:\n            *   Controle (A): Taxa de ativação de 30.5% (n=2480)\n            *   Teste (B): Taxa de ativação de 37.2% (n=2510)\n            *   Delta: +6.7 pontos percentuais (+22% relativo)\n            *   p-valor: 0.008.\n            *   Intervalo de Confiança (95%): [4.1%, 9.3%] para o aumento absoluto.\n    *   **Decisão**: Com p-valor \u003C 0.05, a diferença é estatisticamente significativa. A variante B será implementada permanentemente.\n\n### Workflow 2: Otimizando o Funil de Checkout para E-commerce\n\nEste workflow foca em reduzir o abandono do carrinho e aumentar a taxa de conversão final em um e-commerce.\n\n1.  **Identificação da Oportunidade**:\n    *   **Análise de Funil**: O passo \"Informações de Envio\" no checkout tem uma taxa de abandono de 25%, a mais alta do funil após o carrinho. A taxa de conversão geral do checkout (do carrinho à compra) é de 40%.\n    *   **Feedback de Usuários**: Clientes relatam que a quantidade de campos e a necessidade de criar uma conta são frustrantes.\n2.  **Formulação da Hipótese**:\n    *   **Hipótese**: \"Para *usuários na etapa 'Informações de Envio' do checkout*, se *oferecermos a opção de 'Checkout como Convidado' e simplificarmos o formulário de endereço removendo campos opcionais (ex: complemento)*, então *esperamos um aumento de 10% na taxa de conclusão do checkout* porque *isso reduzirá o atrito e a exigência de dados desnecessários*.\"\n3.  **Definição de Métricas**:\n    *   **Métrica Primária**: Taxa de conclusão do checkout (percentual de usuários que chegam à página de confirmação de compra após iniciar o checkout). Baseline: 40%.\n    *   **Métricas Secundárias**: Taxa de criação de conta (para monitorar se o checkout como convidado impacta negativamente), Valor Médio do Pedido (AOV), Churn rate de clientes.\n4.  **Cálculo do Tamanho da Amostra e Duração**:\n    *   **Baseline**: 40%\n    *   **Mínimo Efeito Detectável (MED)**: 10% de aumento relativo, ou seja, de 40% para 44% (+4 pontos percentuais).\n    *   **Poder Estatístico**: 80%\n    *   **Nível de Significância**: 95% (p \u003C 0.05)\n    *   **Cálculo**: Aproximadamente 5.000 usuários por variante que iniciam o checkout.\n    *   **Duração**: Se o e-commerce tem 1.000 inícios de checkout por dia, o teste deve rodar por 10 dias (10.000 \u002F 1.000 = 10 dias). Duração total: 10-14 dias para cobrir um ciclo de vendas semanal.\n5.  **Implementação do Experimento**:\n    *   **Ferramenta**: Utilizar LaunchDarkly ou Optimizely para gerenciar a feature flag e dividir o tráfego.\n    *   **Variantes**:\n        *   **Controle (A)**: Checkout atual (obrigatório criar conta, formulário completo).\n        *   **Teste (B)**: Checkout como convidado e formulário simplificado.\n    *   **Distribuição**: 50% para A, 50% para B.\n    *   **QA**: Testar o fluxo completo de compra em ambas as variantes, incluindo diferentes métodos de pagamento e dispositivos.\n6.  **Análise e Decisão**:\n    *   **Monitoramento**: Acompanhar abandono de carrinho, taxa de conclusão e AOV.\n    *   **Após 14 dias**:\n        *   **Resultados**:\n            *   Controle (A): Taxa de conclusão de 40.2% (n=4950)\n            *   Teste (B): Taxa de conclusão de 46.5% (n=5050)\n            *   Delta: +6.3 pontos percentuais (+15.7% relativo)\n            *   p-valor: 0.001.\n            *   Intervalo de Confiança (95%): [3.8%, 8.8%] para o aumento absoluto.\n            *   Métrica Secundária (Criação de Conta): A taxa de criação de conta caiu em 12% na variante B, mas o AOV permaneceu estável.\n    *   **Decisão**: A variante B é estatisticamente superior na taxa de conclusão do checkout e o impacto na criação de conta é aceitável, dado o ganho na conversão. Implementar a variante B.\n\n---\n\n## Templates\n\n### Template de Hipótese de Experimento A\u002FB\n\n```\nPara [USUÁRIOS\u002FSEGMENTO ESPECÍFICO], se [EXECUTAMOS ESTA ALTERAÇÃO\u002FVARIANTE], então [ESPERAMOS ESTE RESULTADO MENSURÁVEL] porque [RAZÃO\u002FINSIGHT\u002FDADO QUE JUSTIFICA A ALTERAÇÃO].\n\nExemplo Preenchido:\nPara *novos visitantes da página de checkout mobile*, se *removemos o campo 'CPF' como obrigatório e o tornamos opcional*, então *esperamos um aumento de 7% na taxa de conclusão do checkout mobile* porque *a exigência de dados pessoais no primeiro contato gera atrito e desconfiança*.\n```\n\n### Template de Relatório de Experimento A\u002FB (Resumo Executivo)\n\n```\nTítulo do Experimento: Otimização da Página de Preços para Planos Enterprise\nID do Experimento: AB-2024-Q1-003\nPeríodo de Execução: 05\u002F02\u002F2024 - 19\u002F02\u002F2024\nResponsável: Equipe de Growth\nStatus: Concluído - Vitória\n\nHipótese: Alterar a hierarquia visual dos planos na página de preços, destacando o plano \"Enterprise\" com um selo \"Mais Popular\" e um botão CTA maior, aumentará as solicitações de demo para este plano em 12%.\n\nVariantes Testadas:\n- Controle (A): Página de preços padrão.\n- Teste (B): Página de preços com destaque para o plano Enterprise (selo \"Mais Popular\", CTA maior).\n\nMétrica Primária: Taxa de Cliques no Botão \"Solicitar Demo\" do Plano Enterprise.\nBaseline (Controle A): 2.8%\nResultado (Teste B): 3.5%\nDelta (B vs A): +0.7 pontos percentuais (equivalente a +25% relativo)\nSignificância Estatística (p-valor): 0.003 (Estatisticamente Significativo, p \u003C 0.05)\nIntervalo de Confiança (95%): [0.4%, 1.0%] no aumento absoluto da taxa de cliques.\n\nMétricas Secundárias:\n- Taxa de Cliques nos outros planos: Redução de 5% no plano \"Pro\", estável no \"Basic\".\n- Taxa de Conversão para Sales Qualified Leads (SQL): Aumento de 18% para o plano Enterprise.\n\nTamanho da Amostra por Variante: 8.500 visitantes únicos.\nDuração Necessária (calculada): 12 dias.\nDuração Real: 14 dias.\n\nDecisão: Implementar a variante B.\nJustificativa: A variante B demonstrou um aumento estatisticamente significativo na métrica primária e um impacto positivo na métrica secundária de SQLs, validando a hipótese.\n\nPróximos Passos:\n1. Implementar a variante B permanentemente na página de preços.\n2. Analisar o impacto no ciclo de vendas e fechamento de negócios para os leads Enterprise gerados.\n3. Considerar um novo teste para otimizar o formulário de solicitação de demo.\n```\n\n---\n\n## Checklist\n\n- [x] Hipótese clara, mensurável e testável formulada?\n- [x] Métrica primária e secundária (guardrail metrics) definidas e rastreáveis?\n- [x] Baseline da métrica primária coletada e validada?\n- [x] Mínimo Efeito Detectável (MED) definido para o teste?\n- [x] Tamanho da amostra calculado com poder estatístico (mínimo 80%) e nível de significância (95%) adequados?\n- [x] Duração do teste (janela de observação) estabelecida para cobrir ciclos completos de usuários e evitar sazonalidade?\n- [x] Variantes implementadas corretamente na ferramenta de A\u002FB testing?\n- [x] QA (Quality Assurance) completo realizado nas variantes (funcionalidade, UX, rastreamento) para evitar vieses?\n- [x] Segmentação de usuários para o teste definida e isolada de outros experimentos em andamento?\n- [x] Plano de análise pós-teste e critérios de decisão pré-definidos?\n- [x] Plano de contingência para reverter o teste em caso de impactos negativos severos nas métricas de guarda?\n\n---\n\n## Métricas de Referência\n\n| Métrica                      | Benchmark (Indústria)        | Meta (Exemplo)               |\n|------------------------------|------------------------------|------------------------------|\n| Taxa de Conversão (E-commerce) | 1.5% - 3.0%                  | 3.5%                         |\n| Taxa de Cliques (CTA)        | 5% - 15%                     | 18%                          |\n| Activation Rate (SaaS)       | 20% - 40% (primeira ação)    | 45%                          |\n| Retention Rate (30 dias)     | 25% - 35% (produtos digitais) | 40%                          |\n| p-valor (Significância)      | \u003C 0.05                       | \u003C 0.01 (para alta confiança) |\n| Poder Estatístico            | 80%                          | 90%                          |\n| Taxa de Abandono (Checkout)  | 60% - 75%                    | 50%                          |\n\n---\n\n## Erros Comuns\n\n1.  **Finalizar o Teste Prematuramente (Peeking)**: Interromper um experimento assim que a significância estatística é atingida, ignorando a duração calculada.\n    *   **Como evitar**: Defina a duração do teste com base no cálculo do tamanho da amostra e no ciclo de negócios, e adira a ela. Acompanhe os resultados, mas não tome decisões antes do tempo, pois isso aumenta a chance de falsos positivos (erro Tipo I). Ex: Um teste projetado para 14 dias que é parado no dia 5 porque \"já deu significativo\" pode estar apenas pegando uma flutuação aleatória.\n2.  **Testar Múltiplas Variáveis em um Único Experimento A\u002FB**: Alterar vários elementos (ex: cor do botão, texto, imagem) entre o controle e a variante de teste.\n    *   **Como evitar**: Se deseja testar o impacto de múltiplos elementos combinados, utilize um Teste Multivariado (MVT) que analisa a interação entre as variáveis. Para testes A\u002FB simples, altere apenas uma variável por vez ou crie variantes distintas com combinações específicas, mas saiba que atribuir o sucesso a um elemento específico será difícil. Ex: Em vez de mudar cor E texto do CTA, faça um teste para cor e, se significativo, um segundo teste para texto.\n3.  **Não Considerar Efeitos de Rede ou Sazonalidade**: Lançar um teste que não abrange um ciclo de negócios completo (ex: apenas dias de semana, ou durante um feriado atípico).\n    *   **Como evitar**: Calcule a duração do teste para incluir pelo menos um ciclo semanal completo (7 dias) e, idealmente, múltiplos ciclos se o comportamento do usuário variar significativamente por dia da semana ou mês. Para produtos com alta dependência de rede (ex: plataformas sociais), a interação entre usuários pode enviesar os resultados se a divisão for por usuário. Considere \"Switchback Testing\" ou \"Cluster-based Testing\" para mitigar esses efeitos em certos cenários.\n\n---\n\n## Dicas Avançadas\n\n1.  **Utilize Guardrail Metrics para Mitigar Riscos**: Além da métrica primária e secundária da hipótese, monitore métricas de saúde do produto (ex: taxa de churn, tempo na página, LTV) que não são o foco do teste, mas que poderiam ser negativamente impactadas. Isso garante que a otimização de uma métrica não prejudique a saúde geral do negócio. Ex: Um teste que aumenta a taxa de cliques no CTA pode estar levando a cliques de baixa qualidade, resultando em maior abandono posteriormente.\n2.  **Análise de Segmentos Pós-Teste (Subgroup Analysis)**: Mesmo que o resultado geral de um teste não seja estatisticamente significativo, analise o desempenho das variantes em segmentos específicos da sua base de usuários (ex: usuários mobile vs desktop, novos vs recorrentes, diferentes demografias). Pode ser que a variante tenha um impacto significativo para um subgrupo, revelando insights valiosos para personalização. Ex: A variante B pode não ter melhorado a conversão geral, mas aumentou em 20% a conversão para usuários de iOS.\n3.  **Implemente um Framework de Orquestração de Testes**: Mantenha um registro centralizado de todos os testes A\u002FB ativos e planejados. Isso evita a sobreposição de testes na mesma página ou funil, que pode levar a resultados conflitantes ou viesados. Ferramentas como LaunchDarkly ou sistemas internos de gerenciamento de experimentos são cruciações para gerenciar dependências e prioridades.\n4.  **Teste de Hipóteses Nulas (B\u002FA Testing)**: Antes de lançar um teste A\u002FB com uma nova variante, execute um teste A\u002FA (ou B\u002FA, onde B é apenas uma cópia de A) para validar sua infraestrutura de testes. Isso confirma que seu sistema de A\u002FB testing está dividindo o tráfego aleatoriamente e coletando dados de forma imparcial, sem vieses técnicos inerentes. Se o teste A\u002FA mostrar uma diferença significativa, há um problema na configuração.\n5.  **Considere Testes Baseados em Valor (Value-based Testing)**: Em vez de focar apenas em taxas de conversão ou cliques, priorize testes que impactam diretamente o valor gerado para o negócio (ex: Receita Média por Usuário (ARPU), Lifetime Value (LTV)). Embora mais complexos e demorados, esses testes fornecem insights mais profundos sobre o impacto financeiro real das suas otimizações. Ex: Um teste que aumenta ligeiramente o preço de um plano pode reduzir a taxa de conversão, mas se o ARPU por cliente convertido aumentar significativamente, o teste pode ser um sucesso.","# Ab Testing Framework\n\nCapacita o Claude a projetar, executar e analisar experimentos A\u002FB complexos para otimização de produtos e growth, garantindo decisões baseadas em dados robustos e impactantes.\n\n---\n\n## Keywords\n\nTeste A\u002FB, Teste Multivariado (MVT), Otimização de Conversão (CRO), Hipótese de Experimento, Variância, Nível de Significância (p-valor), Poder Estatístico, Tamanho da Amostra, Mínimo Efeito Detectável (MED), Janela de Observação, Segmentação de Usuários, Métricas de Guarda, Backtesting, Personalização Dinâmica.\n\n---\n\n## Quick Start\n\n1.  **Formule uma Hipótese Específica**: Defina o que será testado, o resultado esperado e o porquê. Ex: \"Ao mudar a cor do botão 'Adicionar ao Carrinho' de cinza para laranja na página de produto, esperamos um aumento de 15% nas adições ao carrinho porque a cor laranja cria maior contraste e urgência visual.\"\n2.  **Calcule o Tamanho da Amostra e Duração**: Utilize uma calculadora de A\u002FB testing (e.g., Optimizely, VWO) para determinar quantos usuários são necessários por variante, considerando a taxa de conversão atual (baseline), o Mínimo Efeito Detectável (MED), poder estatístico (80%) e significância (95%). Ex: Para uma baseline de 5% e MED de 10%, são necessários ~4.000 usuários por variante.\n3.  **Implemente o Experimento**: Utilize uma plataforma de A\u002FB testing (e.g., Google Optimize, VWO, Optimizely, LaunchDarkly) para criar as variantes e direcionar o tráfego de forma aleatória e balanceada (e.g., 50\u002F50 ou 33\u002F33\u002F33).\n4.  **Monitore Métricas de Guarda**: Acompanhe métricas cruciais que não são o foco principal, mas podem ser impactadas negativamente. Ex: Se o teste foca em cliques, monitore a taxa de churn ou tempo na página para garantir que o aumento de cliques não vem à custa da experiência geral.\n5.  **Analise e Tome Decisão**: Após a duração pré-calculada, avalie os resultados estatísticos (p-valor, intervalo de confiança) para determinar se a variante de teste superou o controle de forma significativa. Não finalize o teste prematuramente.\n\n---\n\n## Core Workflows\n\n### Workflow 1: Otimizando a Taxa de Ativação em um Produto SaaS\n\nEste workflow detalha o processo para melhorar a taxa de ativação de novos usuários em um produto SaaS, focando na primeira experiência.\n\n1.  **Identificação da Oportunidade**:\n    *   **Análise de Funil**: Observar que 45% dos usuários que completam o cadastro não realizam a \"primeira ação de valor\" (ex: criar o primeiro projeto, convidar um colega) nos primeiros 7 dias. A taxa de ativação atual é de 30%.\n    *   **Pesquisa Qualitativa**: Entrevistas com usuários recém-cadastrados revelam confusão sobre o \"próximo passo\" após o login.\n2.  **Formulação da Hipótese**:\n    *   **Hipótese**: \"Para *novos usuários cadastrados*, se *implementarmos um tour guiado interativo (tooltip series) nos 3 principais recursos do produto na primeira sessão*, então *esperamos um aumento de 20% na taxa de ativação (primeiro projeto criado em 7 dias)* porque *isso reduzirá a barreira inicial e direcionará o usuário para a ação de valor principal*.\"\n3.  **Definição de Métricas**:\n    *   **Métrica Primária**: Taxa de ativação (percentual de novos usuários que criam o primeiro projeto em 7 dias). Baseline: 30%.\n    *   **Métricas Secundárias**: Taxa de conclusão do tour guiado, tempo para a primeira ação, churn rate em 30 dias.\n4.  **Cálculo do Tamanho da Amostra e Duração**:\n    *   **Baseline**: 30%\n    *   **Mínimo Efeito Detectável (MED)**: 20% de aumento relativo, ou seja, de 30% para 36% (+6 pontos percentuais).\n    *   **Poder Estatístico**: 80%\n    *   **Nível de Significância**: 95% (p \u003C 0.05)\n    *   **Cálculo**: Usando uma calculadora de A\u002FB, seriam necessários aproximadamente 2.500 usuários por variante.\n    *   **Duração**: Se o produto recebe 500 novos usuários por dia, o teste deve rodar por 10 dias (5.000 usuários \u002F 500 usuários\u002Fdia = 10 dias) para garantir que cada variante tenha a amostra necessária. Adicionar alguns dias para capturar o ciclo completo de 7 dias da métrica de ativação. Duração total: 14 dias.\n5.  **Implementação do Experimento**:\n    *   **Ferramenta**: Usar VWO ou Optimizely para criar duas variantes:\n        *   **Controle (A)**: Experiência atual de onboarding.\n        *   **Teste (B)**: Experiência com o tour guiado.\n    *   **Distribuição**: Dividir 50% do tráfego de novos usuários para A e 50% para B.\n    *   **QA**: Testar rigorosamente a implementação para garantir que o tour guiado funcione corretamente e não haja vieses técnicos.\n6.  **Análise e Decisão**:\n    *   **Monitoramento**: Acompanhar as métricas primárias e secundárias diariamente, mas *sem tomar decisões prematuras*.\n    *   **Após 14 dias**: Coletar e analisar os dados.\n        *   **Resultados**:\n            *   Controle (A): Taxa de ativação de 30.5% (n=2480)\n            *   Teste (B): Taxa de ativação de 37.2% (n=2510)\n            *   Delta: +6.7 pontos percentuais (+22% relativo)\n            *   p-valor: 0.008.\n            *   Intervalo de Confiança (95%): [4.1%, 9.3%] para o aumento absoluto.\n    *   **Decisão**: Com p-valor \u003C 0.05, a diferença é estatisticamente significativa. A variante B será implementada permanentemente.\n\n### Workflow 2: Otimizando o Funil de Checkout para E-commerce\n\nEste workflow foca em reduzir o abandono do carrinho e aumentar a taxa de conversão final em um e-commerce.\n\n1.  **Identificação da Oportunidade**:\n    *   **Análise de Funil**: O passo \"Informações de Envio\" no checkout tem uma taxa de abandono de 25%, a mais alta do funil após o carrinho. A taxa de conversão geral do checkout (do carrinho à compra) é de 40%.\n    *   **Feedback de Usuários**: Clientes relatam que a quantidade de campos e a necessidade de criar uma conta são frustrantes.\n2.  **Formulação da Hipótese**:\n    *   **Hipótese**: \"Para *usuários na etapa 'Informações de Envio' do checkout*, se *oferecermos a opção de 'Checkout como Convidado' e simplificarmos o formulário de endereço removendo campos opcionais (ex: complemento)*, então *esperamos um aumento de 10% na taxa de conclusão do checkout* porque *isso reduzirá o atrito e a exigência de dados desnecessários*.\"\n3.  **Definição de Métricas**:\n    *   **Métrica Primária**: Taxa de conclusão do checkout (percentual de usuários que chegam à página de confirmação de compra após iniciar o checkout). Baseline: 40%.\n    *   **Métricas Secundárias**: Taxa de criação de conta (para monitorar se o checkout como convidado impacta negativamente), Valor Médio do Pedido (AOV), Churn rate de clientes.\n4.  **Cálculo do Tamanho da Amostra e Duração**:\n    *   **Baseline**: 40%\n    *   **Mínimo Efeito Detectável (MED)**: 10% de aumento relativo, ou seja, de 40% para 44% (+4 pontos percentuais).\n    *   **Poder Estatístico**: 80%\n    *   **Nível de Significância**: 95% (p \u003C 0.05)\n    *   **Cálculo**: Aproximadamente 5.000 usuários por variante que iniciam o checkout.\n    *   **Duração**: Se o e-commerce tem 1.000 inícios de checkout por dia, o teste deve rodar por 10 dias (10.000 \u002F 1.000 = 10 dias). Duração total: 10-14 dias para cobrir um ciclo de vendas semanal.\n5.  **Implementação do Experimento**:\n    *   **Ferramenta**: Utilizar LaunchDarkly ou Optimizely para gerenciar a feature flag e dividir o tráfego.\n    *   **Variantes**:\n        *   **Controle (A)**: Checkout atual (obrigatório criar conta, formulário completo).\n        *   **Teste (B)**: Checkout como convidado e formulário simplificado.\n    *   **Distribuição**: 50% para A, 50% para B.\n    *   **QA**: Testar o fluxo completo de compra em ambas as variantes, incluindo diferentes métodos de pagamento e dispositivos.\n6.  **Análise e Decisão**:\n    *   **Monitoramento**: Acompanhar abandono de carrinho, taxa de conclusão e AOV.\n    *   **Após 14 dias**:\n        *   **Resultados**:\n            *   Controle (A): Taxa de conclusão de 40.2% (n=4950)\n            *   Teste (B): Taxa de conclusão de 46.5% (n=5050)\n            *   Delta: +6.3 pontos percentuais (+15.7% relativo)\n            *   p-valor: 0.001.\n            *   Intervalo de Confiança (95%): [3.8%, 8.8%] para o aumento absoluto.\n            *   Métrica Secundária (Criação de Conta): A taxa de criação de conta caiu em 12% na variante B, mas o AOV permaneceu estável.\n    *   **Decisão**: A variante B é estatisticamente superior na taxa de conclusão do checkout e o impacto na criação de conta é aceitável, dado o ganho na conversão. Implementar a variante B.\n\n---\n\n## Templates\n\n### Template de Hipótese de Experimento A\u002FB\n\n```\nPara [USUÁRIOS\u002FSEGMENTO ESPECÍFICO], se [EXECUTAMOS ESTA ALTERAÇÃO\u002FVARIANTE], então [ESPERAMOS ESTE RESULTADO MENSURÁVEL] porque [RAZÃO\u002FINSIGHT\u002FDADO QUE JUSTIFICA A ALTERAÇÃO].\n\nExemplo Preenchido:\nPara *novos visitantes da página de checkout mobile*, se *removemos o campo 'CPF' como obrigatório e o tornamos opcional*, então *esperamos um aumento de 7% na taxa de conclusão do checkout mobile* porque *a exigência de dados pessoais no primeiro contato gera atrito e desconfiança*.\n```\n\n### Template de Relatório de Experimento A\u002FB (Resumo Executivo)\n\n```\nTítulo do Experimento: Otimização da Página de Preços para Planos Enterprise\nID do Experimento: AB-2024-Q1-003\nPeríodo de Execução: 05\u002F02\u002F2024 - 19\u002F02\u002F2024\nResponsável: Equipe de Growth\nStatus: Concluído - Vitória\n\nHipótese: Alterar a hierarquia visual dos planos na página de preços, destacando o plano \"Enterprise\" com um selo \"Mais Popular\" e um botão CTA maior, aumentará as solicitações de demo para este plano em 12%.\n\nVariantes Testadas:\n- Controle (A): Página de preços padrão.\n- Teste (B): Página de preços com destaque para o plano Enterprise (selo \"Mais Popular\", CTA maior).\n\nMétrica Primária: Taxa de Cliques no Botão \"Solicitar Demo\" do Plano Enterprise.\nBaseline (Controle A): 2.8%\nResultado (Teste B): 3.5%\nDelta (B vs A): +0.7 pontos percentuais (equivalente a +25% relativo)\nSignificância Estatística (p-valor): 0.003 (Estatisticamente Significativo, p \u003C 0.05)\nIntervalo de Confiança (95%): [0.4%, 1.0%] no aumento absoluto da taxa de cliques.\n\nMétricas Secundárias:\n- Taxa de Cliques nos outros planos: Redução de 5% no plano \"Pro\", estável no \"Basic\".\n- Taxa de Conversão para Sales Qualified Leads (SQL): Aumento de 18% para o plano Enterprise.\n\nTamanho da Amostra por Variante: 8.500 visitantes únicos.\nDuração Necessária (calculada): 12 dias.\nDuração Real: 14 dias.\n\nDecisão: Implementar a variante B.\nJustificativa: A variante B demonstrou um aumento estatisticamente significativo na métrica primária e um impacto positivo na métrica secundária de SQLs, validando a hipótese.\n\nPróximos Passos:\n1. Implementar a variante B permanentemente na página de preços.\n2. Analisar o impacto no ciclo de vendas e fechamento de negócios para os leads Enterprise gerados.\n3. Considerar um novo teste para otimizar o formulário de solicitação de demo.\n```\n\n---\n\n## Checklist\n\n- [x] Hipótese clara, mensurável e testável formulada?\n- [x] Métrica primária e secundária (guardrail metrics) definidas e rastreáveis?\n- [x] Baseline da métrica primária coletada e validada?\n- [x] Mínimo Efeito Detectável (MED) definido para o teste?\n- [x] Tamanho da amostra calculado com poder estatístico (mínimo 80%) e nível de significância (95%) adequados?\n- [x] Duração do teste (janela de observação) estabelecida para cobrir ciclos completos de usuários e evitar sazonalidade?\n- [x] Variantes implementadas corretamente na ferramenta de A\u002FB testing?\n- [x] QA (Quality Assurance) completo realizado nas variantes (funcionalidade, UX, rastreamento) para evitar vieses?\n- [x] Segmentação de usuários para o teste definida e isolada de outros experimentos em andamento?\n- [x] Plano de análise pós-teste e critérios de decisão pré-definidos?\n- [x] Plano de contingência para reverter o teste em caso de impactos negativos severos nas métricas de guarda?\n\n---\n\n## Métricas de Referência\n\n| Métrica                      | Benchmark (Indústria)        | Meta (Exemplo)               |\n|------------------------------|------------------------------|------------------------------|\n| Taxa de Conversão (E-commerce) | 1.5% - 3.0%                  | 3.5%                         |\n| Taxa de Cliques (CTA)        | 5% - 15%                     | 18%                          |\n| Activation Rate (SaaS)       | 20% - 40% (primeira ação)    | 45%                          |\n| Retention Rate (30 dias)     | 25% - 35% (produtos digitais) | 40%                          |\n| p-valor (Significância)      | \u003C 0.05                       | \u003C 0.01 (para alta confiança) |\n| Poder Estatístico            | 80%                          | 90%                          |\n| Taxa de Abandono (Checkout)  | 60% - 75%                    | 50%                          |\n\n---\n\n## Erros Comuns\n\n1.  **Finalizar o Teste Prematuramente (Peeking)**: Interromper um experimento assim que a significância estatística é atingida, ignorando a duração calculada.\n    *   **Como evitar**: Defina a duração do teste com base no cálculo do tamanho da amostra e no ciclo de negócios, e adira a ela. Acompanhe os resultados, mas não tome decisões antes do tempo, pois isso aumenta a chance de falsos positivos (erro Tipo I). Ex: Um teste projetado para 14 dias que é parado no dia 5 porque \"já deu significativo\" pode estar apenas pegando uma flutuação aleatória.\n2.  **Testar Múltiplas Variáveis em um Único Experimento A\u002FB**: Alterar vários elementos (ex: cor do botão, texto, imagem) entre o controle e a variante de teste.\n    *   **Como evitar**: Se deseja testar o impacto de múltiplos elementos combinados, utilize um Teste Multivariado (MVT) que analisa a interação entre as variáveis. Para testes A\u002FB simples, altere apenas uma variável por vez ou crie variantes distintas com combinações específicas, mas saiba que atribuir o sucesso a um elemento específico será difícil. Ex: Em vez de mudar cor E texto do CTA, faça um teste para cor e, se significativo, um segundo teste para texto.\n3.  **Não Considerar Efeitos de Rede ou Sazonalidade**: Lançar um teste que não abrange um ciclo de negócios completo (ex: apenas dias de semana, ou durante um feriado atípico).\n    *   **Como evitar**: Calcule a duração do teste para incluir pelo menos um ciclo semanal completo (7 dias) e, idealmente, múltiplos ciclos se o comportamento do usuário variar significativamente por dia da semana ou mês. Para produtos com alta dependência de rede (ex: plataformas sociais), a interação entre usuários pode enviesar os resultados se a divisão for por usuário. Considere \"Switchback Testing\" ou \"Cluster-based Testing\" para mitigar esses efeitos em certos cenários.\n\n---\n\n## Dicas Avançadas\n\n1.  **Utilize Guardrail Metrics para Mitigar Riscos**: Além da métrica primária e secundária da hipótese, monitore métricas de saúde do produto (ex: taxa de churn, tempo na página, LTV) que não são o foco do teste, mas que poderiam ser negativamente impactadas. Isso garante que a otimização de uma métrica não prejudique a saúde geral do negócio. Ex: Um teste que aumenta a taxa de cliques no CTA pode estar levando a cliques de baixa qualidade, resultando em maior abandono posteriormente.\n2.  **Análise de Segmentos Pós-Teste (Subgroup Analysis)**: Mesmo que o resultado geral de um teste não seja estatisticamente significativo, analise o desempenho das variantes em segmentos específicos da sua base de usuários (ex: usuários mobile vs desktop, novos vs recorrentes, diferentes demografias). Pode ser que a variante tenha um impacto significativo para um subgrupo, revelando insights valiosos para personalização. Ex: A variante B pode não ter melhorado a conversão geral, mas aumentou em 20% a conversão para usuários de iOS.\n3.  **Implemente um Framework de Orquestração de Testes**: Mantenha um registro centralizado de todos os testes A\u002FB ativos e planejados. Isso evita a sobreposição de testes na mesma página ou funil, que pode levar a resultados conflitantes ou viesados. Ferramentas como LaunchDarkly ou sistemas internos de gerenciamento de experimentos são cruciações para gerenciar dependências e prioridades.\n4.  **Teste de Hipóteses Nulas (B\u002FA Testing)**: Antes de lançar um teste A\u002FB com uma nova variante, execute um teste A\u002FA (ou B\u002FA, onde B é apenas uma cópia de A) para validar sua infraestrutura de testes. Isso confirma que seu sistema de A\u002FB testing está dividindo o tráfego aleatoriamente e coletando dados de forma imparcial, sem vieses técnicos inerentes. Se o teste A\u002FA mostrar uma diferença significativa, há um problema na configuração.\n5.  **Considere Testes Baseados em Valor (Value-based Testing)**: Em vez de focar apenas em taxas de conversão ou cliques, priorize testes que impactam diretamente o valor gerado para o negócio (ex: Receita Média por Usuário (ARPU), Lifetime Value (LTV)). Embora mais complexos e demorados, esses testes fornecem insights mais profundos sobre o impacto financeiro real das suas otimizações. Ex: Um teste que aumenta ligeiramente o preço de um plano pode reduzir a taxa de conversão, mas se o ARPU por cliente convertido aumentar significativamente, o teste pode ser um sucesso.",{"name":5,"risk":29,"license":14,"metadata":39,"description":7},{"author":40,"updated":41,"version":42,"category":43},"Cafe Code AI",1772323200000,"1.0.0","08-lancamento-growth","master","346c313fd2ec241a088c68274da26c538422568b","packs\u002Fkit-510-ptbr\u002F08-lancamento-growth\u002Fab-testing-framework",36,"https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills","https:\u002F\u002Fclaude.ai","https:\u002F\u002Fgithub.com\u002Fkursku","2026-03-27 22:43:37",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add kursku\u002Fskills --skill ab-testing-framework",{"tool":58,"command":59},"bunx","bunx skills add kursku\u002Fskills --skill ab-testing-framework",{"tool":61,"command":62},"pnpm","pnpm dlx skills add kursku\u002Fskills --skill ab-testing-framework","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F08-lancamento-growth\u002Fab-testing-framework\u002FSKILL.md",true,[66],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"LICENSE.txt","LICENSE","许可证",11607,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fpay-the-bills\u002FLICENSE.txt",[73,91,102,114,125,135],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":87,"publishedAt":34},"01M6ECKM7725267ZM3XNYWH608","wedding-marketing","Wedding Marketing — Skill especializada para criar e executar estratégias de marketing digital para o mercado de casamentos, focando em noivos e fornecedores.","https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F16-nichos-especificos\u002Fwedding-marketing\u002FSKILL.md",[79,82],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",[88,89,90,33,31,30],"wedding marketing","marketing","marketing digital",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":99,"publishedAt":34},"01M6ECKGP656JQC2C6CK5JH3ZG","travel-marketing","Travel Marketing — Skill especializada para travel marketing","https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F16-nichos-especificos\u002Ftravel-marketing\u002FSKILL.md",[97,98],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[100,101,89,31,30,29],"travel marketing","travel",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":110,"publishedAt":34},"01M6ECKBY53SJ7E167D6BXTMRK","tech-startup-marketing","Tech Startup Marketing — Skill especializada para tech startup marketing","https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F16-nichos-especificos\u002Ftech-startup-marketing\u002FSKILL.md",[108,109],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[111,112,89,113,31,30,29],"tech startup marketing","tech","startup",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":122,"publishedAt":34},"01M6ECK7W2W0J5MZ8BZHFM516P","saas-marketing","Saas Marketing — Skill especializada para desenvolver e executar estratégias de marketing digital focadas no crescimento de produtos SaaS.","https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F16-nichos-especificos\u002Fsaas-marketing\u002FSKILL.md",[120,121],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[123,89,124,29,90,33,31,30],"saas marketing","saas",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":133,"publishedAt":34},"01M6ECK42ZSX5ND0SCTRKD7XKB","restaurant-marketing","Restaurant Marketing — Skill especializada para otimizar a presença digital, atrair e reter clientes em restaurantes.","https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F16-nichos-especificos\u002Frestaurant-marketing\u002FSKILL.md",[131,132],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[134,89,30,31],"restaurant marketing",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":143,"publishedAt":34},"01M6ECK0S48CPYE9P7PRAG9R3T","real-estate-marketing","Real Estate Marketing — Skill especializada para criação e execução de estratégias de marketing digital para o setor imobiliário.","https:\u002F\u002Fgithub.com\u002Fkursku\u002Fskills\u002Fblob\u002Fmaster\u002Fpacks\u002Fkit-510-ptbr\u002F16-nichos-especificos\u002Freal-estate-marketing\u002FSKILL.md",[141,142],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[89,144,145,30,31,33,90,29],"real estate","real estate marketing"]