1.1 A intuição erra — muito

• Em empresas grandes que medem, a maioria das ideias de produto testadas não move a métrica-alvo; uma fração pequena move para cima; algumas pioram. Isso vale para times muito bons.
• Sem experimento, você lança pela opinião de quem tem mais poder (o HiPPO — highest paid person's opinion) ou pela última pessoa que falou.
• Experimentação é o método científico aplicado a produto: hipótese → intervenção controlada → medição → conclusão sobre causa.

1.2 Causalidade vs correlação

• "Usuários que usam o recurso X retêm mais" — pode ser que X cause retenção, ou que quem já ia reter descobre X. Só um experimento randomizado separa os dois: você atribui X ao acaso, então os grupos só diferem em X.
• Análises observacionais (comparar quem usou vs quem não usou) são cheias de viés de seleção.

1.3 Quando a cultura faz sentido — e quando não

• Precisa de tráfego: com poucos usuários, você nunca atinge poder estatístico para detectar efeitos realistas (Módulo 4). Startup pré-product-market-fit: experimente qualitativamente, decida rápido, não gaste em A/B.
• Precisa de disciplina: pré-registro, não parar cedo, métricas honestas — sem isso, "experimentação" vira teatro que legitima qualquer decisão.
• Precisa de instrumentação: eventos confiáveis, um pipeline de dados, métricas definidas.
• Onde faz sentido: produtos com escala, mudanças incrementais frequentes, times que topam ser contrariados pelos dados.

1.4 Tipos de experimento

2.1 A ideia: separar deploy de release

Um feature flag (ou toggle) é um ponto de decisão no código: if (flags.isEnabled('novo-checkout', user)) { ... }. Você deploya o código com o novo caminho desligado, e depois libera (release) mudando a flag — para 1%, para um segmento, para todos — sem novo deploy. E pode desligar na hora se der problema (kill switch).

2.2 Os tipos

Confundir os tipos causa flag debt (Módulo 8): flags de release que nunca são removidas viram if mortos que ninguém entende.

2.3 Targeting

• Por porcentagem (rollout: 1% → 10% → 50% → 100%).
• Por atributo: país, plano, plataforma, versão do app, data de cadastro, um flag interno "beta".
• Por segmento: listas de usuários/contas (allowlist para o time, para um cliente piloto).
• Consistência: o mesmo usuário deve ver a mesma coisa entre sessões e dispositivos — a avaliação é determinística (hash do user id + o nome da flag → um número em [0,1)).

2.4 Cliente vs servidor

• Servidor: a flag é avaliada no backend; ótimo para lógica crítica, não expõe features não lançadas, mas exige que o backend saiba os atributos.
• Cliente (web/mobile): um SDK avalia localmente com regras baixadas; rápido, funciona offline, mas o bundle "sabe" das flags e há latência de sincronização.
• Edge: avaliar num middleware/CDN (ex.: Next.js middleware) para não ter flash de conteúdo.
• Evite o flicker: se a flag muda a UI, avalie antes do primeiro render (servidor/edge) ou reserve o espaço.

2.5 Ferramentas

• Plataformas: LaunchDarkly, Statsig, Eppo, Split, Flagsmith, Unleash (open source), GrowthBook (open source), PostHog (flags + analytics + experimentos).
• Caseiro: uma tabela + um endpoint + um SDK fino — viável para começar; você reimplementa targeting, consistência, e a análise de experimento (a parte difícil).

3.1 A hipótese

Escreva antes: "Porque [insight], acreditamos que [mudança] vai [efeito] em [métrica primária] para [segmento], sem prejudicar [guardrails]." Se você não consegue completar essa frase, o experimento não está pronto.

3.2 A métrica primária — uma só

• Uma única métrica que decide o experimento. Se você tem "5 métricas primárias", tem zero — vai escolher a que deu bem depois (Módulo 9).
• Deve ser sensível (muda com a intervenção no prazo do teste), alinhada ao objetivo real, e não-gaming (não dá para melhorá-la de um jeito ruim).

3.3 Guardrails

• Métricas que não podem piorar: latência, taxa de erro, receita, retenção, cancelamentos, reclamações, acessibilidade.
• Um tratamento que ganha na primária mas quebra um guardrail não lança.

3.4 Unidade de randomização

• Usuário (o mais comum): consistente entre sessões; a análise precisa considerar que ações do mesmo usuário são correlacionadas.
• Sessão: mais poder, mas o usuário pode ver as duas versões — só quando a mudança é "dentro da sessão" e sem memória.
• Conta / organização: para B2B, onde vários usuários compartilham um contexto — reduz muito o tamanho efetivo de amostra.
• Cluster (região, mercado): quando há interferência entre unidades (Módulo 7).

3.5 Assignment determinístico

bucket = hash(unit_id + "|" + experiment_key) mod 10000 / 10000   // em [0,1)
if bucket < 0.5  → controle
else             → tratamento

• Determinístico (sempre o mesmo grupo), independente entre experimentos (o experiment_key no hash), e uniforme (um bom hash).
• Reservar uma fração para não-expostos / futuros experimentos, se a plataforma usa "layers".

3.6 Exposição vs atribuição

• Atribuição: o usuário foi designado a um grupo.
• Exposição / trigger: o usuário de fato encontrou o ponto do experimento (viu a tela, chegou no fluxo). Analisar só os expostos aumenta o poder e evita diluir o efeito com quem nunca chegou lá — mas registre a exposição corretamente (é uma fonte comum de bug e de SRM — Módulo 5).

4.1 O problema

Você mede uma diferença de 2% na conversão entre os grupos. Isso é o efeito real ou ruído (variação amostral — os dois grupos diferem um pouco por acaso)? A estatística responde "quão provável seria ver uma diferença desse tamanho se não houvesse efeito nenhum".

4.2 P-valor — o que não é

• O p-valor é: a probabilidade de observar uma diferença pelo menos tão grande quanto a sua, assumindo que a hipótese nula é verdadeira (não há efeito).
• Não é: a probabilidade de a hipótese nula ser verdadeira; não é a probabilidade de você estar errado; não é o tamanho nem a importância do efeito.
• p < 0.05 (o limiar convencional) = "se não houvesse efeito, veríamos algo assim < 5% das vezes" → declaramos "significativo". É uma convenção, não uma lei da natureza.

4.3 Intervalo de confiança

• Mais útil que o p-valor: "o efeito está entre +0.3% e +3.7% com 95% de confiança". Mostra a magnitude e a incerteza. Se o intervalo cruza o zero, é "não significativo" — mas o intervalo diz quanto você ainda não sabe.

4.4 Poder, tamanho de amostra e MDE

• Poder: a probabilidade de detectar um efeito que existe. Convenção: 80%. Baixo poder = você "não vê" efeitos reais e conclui "flat" errado.
• MDE (minimum detectable effect): o menor efeito que o seu experimento consegue detectar com o poder desejado. Depende do tamanho de amostra, da variância da métrica, e do α.
• Tamanho de amostra: calcule antes. Uma calculadora (Evan Miller, a da sua plataforma) pega a métrica base, o MDE que te interessa, α e poder, e dá quantos usuários por grupo — e daí quantos dias, dado o tráfego.
• Se o número de dias for absurdo (meses), o efeito que você quer detectar é pequeno demais para o seu tráfego — repense (efeito maior, métrica menos ruidosa, CUPED, ou não faça o teste).

4.5 Frequentista, bayesiano, sequential

• Frequentista (o clássico): p-valor + intervalo de confiança, com o tamanho de amostra fixado antes.
• Bayesiano: "probabilidade de o tratamento ser melhor" e "perda esperada se eu escolher errado" — mais intuitivo para decidir, exige priors.
• Sequential testing (o que muitas plataformas usam): permite olhar continuamente sem inflar o erro (ao contrário do frequentista clássico, onde "espiar" é trapaça — Módulo 5). Sequência ou "always valid p-values".
• CUPED e variance reduction (Módulo 7): usar dados pré-experimento do usuário para reduzir a variância da métrica → menos amostra para o mesmo poder.

4.6 Erros

• Tipo I (falso positivo): declarar efeito quando não há. Controlado por α.
• Tipo II (falso negativo): não detectar um efeito real. Controlado por poder.
• Comparações múltiplas (várias métricas, vários segmentos, várias variantes) multiplicam o risco de Tipo I — corrija (Bonferroni, FDR) ou pré-registre.

5.1 Duração

• Rode por ciclos completos (múltiplos de 7 dias) — comportamento varia por dia da semana.
• Pelo menos 1–2 semanas mesmo que o tamanho de amostra seja atingido antes — para capturar novelty effect (o efeito inicial de "algo mudou", que decai) e primacy (usuários habituados resistem ao novo).
• Não rode demais tempo sem motivo — flags acumulam, o produto evolve por baixo, e o custo de oportunidade cresce.

5.2 Não pare cedo (peeking)

• No teste frequentista clássico, olhar o resultado repetidamente e parar quando "fica significativo" infla o falso positivo dramaticamente (de 5% para 20–30%+). É o erro mais comum e mais caro.
• Soluções: fixar a duração antes e só olhar no fim; ou usar sequential testing / always-valid p-values (a plataforma faz a correção) — aí você pode olhar continuamente.

5.3 Pré-registro

• Antes de ligar: registrar a hipótese, a métrica primária, os guardrails, os segmentos que você vai analisar, a duração/tamanho de amostra, e o critério de decisão.
• Isso impede o HARKing (Hypothesizing After the Results are Known) — inventar a hipótese depois de ver o que deu bem.

5.4 SRM — Sample Ratio Mismatch

• Você configurou 50/50 e observou 52/48 (com N grande, isso é altamente improvável por acaso). SRM é um alarme de bug: assignment enviesado, um bug que faz um grupo crashar/desistir mais (e sumir dos dados), logging que perde eventos de um lado, um bot filtrado desigualmente.
• Um teste de qui-quadrado no ratio de amostra é a primeira checagem de todo experimento. Com SRM, não confie no resultado — ache o bug.

5.5 Segmentação pós-hoc

• "Não deu no geral, mas deu para usuários de iOS no Brasil que se cadastraram em março" — cuidado: com muitos cortes, algum vai parecer significativo por acaso (comparações múltiplas).
• Segmentos pré-registrados e com hipótese: ok, com correção. Segmentos garimpados depois: tratar como geradores de hipótese para um próximo teste, não como conclusão.

5.6 O resultado "flat"

• A maioria dos experimentos dá inconclusivo — o intervalo de confiança inclui zero. Isso é informação: a mudança não teve o efeito grande que você esperava.
• Perguntas: o experimento tinha poder para o efeito que interessava? A exposição foi registrada certo (talvez pouca gente chegou no ponto)? Houve SRM? O tratamento foi implementado como planejado (bug de execução)?
• Decisão típica com "flat": não lançar (não pague a complexidade por um efeito que não se mede), a menos que haja um motivo estratégico e os guardrails estejam ok. Um "flat" que não piora nada e simplifica o código pode valer lançar.

6.1 A hierarquia

• North Star: a métrica que captura o valor entregue ao usuário e ao negócio (ex.: "noites reservadas", "mensagens enviadas entre amigos", "tarefas concluídas"). Muda devagar; nenhum experimento único a move de forma detectável.
• Drivers / input metrics: as alavancas que empurram a North Star (ativação, frequência, retenção, amplitude de uso).
• Métricas de feature: específicas do que você está testando (cliques no novo botão, conclusão do novo fluxo).
• Guardrails: o que não pode piorar (Módulo 3).
• Um experimento tem uma primária (geralmente um driver ou uma métrica de feature bem escolhida), guardrails, e algumas secundárias exploratórias.

6.2 Curto prazo como proxy de longo prazo

• Você mede em 2 semanas, mas quer o efeito em 1 ano. O risco: mudanças que ganham no curto prazo (mais notificações, mais fricção removida do checkout) podem perder no longo (irritação, arrependimento, churn).
• Mitigações: holdouts de longo prazo (Módulo 7), métricas de curto prazo validadas como preditoras do longo (a empresa estuda historicamente quais proxies funcionam), e guardrails de retenção/satisfação.

6.3 OEC — Overall Evaluation Criterion

• Quando uma métrica só não basta, um OEC combina algumas numa fórmula que representa o que a empresa realmente quer (ex.: uma combinação de engajamento e receita com pesos). Difícil de acertar, mas força o debate sobre trade-offs antes do experimento.

6.4 Gaming e contra-peso

• Toda métrica pode ser "gamada" de um jeito ruim: aumentar "sessões" tornando o app confuso; aumentar "cliques" com iscas; aumentar "tempo no app" com scroll infinito viciante.
• Métricas de contra-peso: para cada métrica que você quer subir, uma que flagra o abuso (aumentei cliques mas a taxa de "voltar imediatamente" subiu → cliquei em iscas; aumentei tempo de sessão mas a satisfação caiu).
• "Otimizar a métrica" não é "servir o usuário" — a métrica é uma aproximação (Módulo 9).

7.1 Interferência entre unidades

• O A/B assume que o tratamento de um usuário não afeta o resultado de outro (SUTVA). Em marketplaces (o preço/disponibilidade que um comprador vê depende de outros), redes sociais (você vê o post do seu amigo), e logística (motoristas compartilham a mesma frota), isso não vale — randomizar por usuário mistura os grupos e enviesa o efeito.
• Soluções: cluster randomization (randomizar por cidade/mercado/comunidade — menos poder, mas válido), switchback (todo o sistema alterna tratamento/controle em janelas de tempo), e desenhos de "ego-network" para grafos sociais.

7.2 Holdouts de longo prazo

• Um grupo (ex.: 5%) fica fora de um conjunto de features por meses/trimestres. Compara-se com o resto para medir o efeito acumulado — que costuma ser menor que a soma dos ganhos individuais reportados (interações, novelty que decai, otimização de proxy).
• Também detecta degradação lenta que nenhum experimento curto pega.

7.3 Experimentos em ML

• Rankers, modelos de recomendação, modelos de IA em produto: a avaliação offline (num dataset) dá um sinal, mas o que decide é a avaliação online (A/B) — o modelo muda o comportamento do usuário, que muda os dados futuros (feedback loop).
• Cuidados: o modelo "campeão" precisa de um holdout para não se auto-confirmar; medir métricas de negócio, não só a loss; ver LLMOps & Avaliação de Sistemas de IA e Design de Produtos com IA.

7.4 Variance reduction (CUPED)

• CUPED (Controlled-experiment Using Pre-Existing Data): ajusta a métrica de cada usuário pelo seu comportamento antes do experimento (que é ruído conhecido, não efeito do tratamento) → reduz a variância, às vezes pela metade → menos amostra / menos tempo para o mesmo poder.
• Também: escolher métricas menos ruidosas, "capar" outliers, estratificar.

7.5 Sequential e bandits

• Sequential testing: monitorar continuamente com garantias válidas (Módulo 4) — decidir mais cedo quando o efeito é grande, sem inflar o erro.
• Multi-armed bandits: em vez de esperar o fim para escolher a melhor variante, o algoritmo desloca o tráfego para as variantes que vão bem durante o teste. Bom para: muitas variantes, decisões de curto prazo (manchetes, criativos de anúncio), quando o custo de servir a variante ruim é alto. Ruim para: quando você quer uma estimativa limpa do efeito de cada variante (o bandit enviesa isso).

8.1 O ciclo de vida

1. Criar: hipótese, métrica primária, guardrails, MDE/tamanho, segmentos — num registro (o "experiment doc").
2. Targetear: a flag, o % de tráfego, os filtros de elegibilidade; um "layer" para não colidir com outros experimentos na mesma superfície.
3. Expor: o código chama a avaliação e emite o evento de exposição.
4. Coletar: os eventos de exposição + os eventos de métrica fluem para o warehouse.
5. Analisar: o cálculo de métricas por grupo, com IC, SRM, correções.
6. Decidir: lançar / não lançar / iterar — com base na primária e nos guardrails, documentado.
7. Limpar: remover a flag e o código do braço perdedor.

8.2 O pipeline de dados

• Eventos (exposição, ações do usuário) → um data warehouse → um job que junta exposição com métricas e calcula os resultados por experimento (ver Engenharia de Dados, Análise de Dados com Python).
• Um metrics repo / semantic layer: as métricas definidas uma vez, versionadas, usadas por todos os experimentos e dashboards — para "conversão" significar a mesma coisa em todo lugar (ver Business Intelligence Corporativo).
• Qualidade dos dados: eventos duplicados, atrasados, perdidos, bots — tudo enviesa; o pipeline precisa de checagens.

8.3 Dashboards

• Por experimento: a primária com IC ao longo do tempo, os guardrails, o SRM, os segmentos pré-registrados, a exposição acumulada vs o alvo, e um "verdict" claro.
• Evitar o "mar de números" — destacar a decisão e a confiança (ver Design de Produtos com IA para comunicar incerteza).

8.4 Governança

• Review de design antes de ligar: alguém confere hipótese, métrica primária única, poder, guardrails, e se não colide com outro experimento.
• Conflitos: dois experimentos na mesma superfície podem interagir; "layers" mutuamente exclusivos ou análise de interação.
• Quem pode lançar sem experimento (mudanças triviais, correções); quem precisa.
• Um registro central de todos os experimentos rodando e seus resultados (memória institucional — para não re-testar o que já se sabe).

8.5 Flag debt

• Flags de release/experimento que não são removidas viram ifs mortos, caminhos de código não testados, e configuração que ninguém entende.
• Processos: data de expiração na flag, um relatório de "flags velhas", "limpar a flag" como parte da definição de pronto do experimento, lint que sinaliza flags antigas.

9.1 Armadilhas estatísticas

• P-hacking: rodar até dar significativo (peeking), testar muitas métricas/segmentos e reportar o que "deu", parar/continuar conforme conveniente. Combate: pré-registro, correção de múltiplos, sequential.
• HARKing: apresentar uma hipótese pós-hoc como se fosse pré-registrada.
• Winner's curse: entre os experimentos que "ganham", o efeito medido é inflado (você só declara vitória quando o ruído ajudou). O ganho real em produção costuma ser menor que o reportado — daí a importância de holdouts para calibrar.
• Paradoxo de Simpson: o tratamento ganha em cada segmento mas perde no agregado (ou vice-versa), por causa de mix desigual entre os grupos. Cheque a composição.
• Novelty / change aversion: usuários reagem ao "novo" (curiosidade) ou resistem à mudança — o efeito das primeiras semanas não é o efeito de regime.

9.2 O custo de oportunidade

• Cada experimento ocupa tráfego, tempo de engenharia e uma "vaga" na superfície. Testar mudanças triviais (a cor de um botão que não muda nada) desperdiça isso. Priorize experimentos com hipótese forte e potencial de efeito relevante.

9.3 Ética

• Dano ao grupo: um experimento expõe parte dos usuários a uma versão pior (ou o controle "perde" um bug fix por semanas). Isso é aceitável para mudanças pequenas e reversíveis; não é para coisas que afetam saúde, dinheiro, segurança ou grupos vulneráveis. O caso do experimento de "contágio emocional" do Facebook (2014) é o exemplo de linha cruzada.
• Consentimento e transparência: os ToS geralmente cobrem "melhoramos o produto continuamente", mas experimentos que manipulam emoção, exploram vieses, ou testam preços de forma discriminatória exigem cuidado ético e às vezes legal.
• Equidade: o experimento tem efeitos diferentes por grupo demográfico? Uma "otimização" pode piorar a experiência de um grupo minoritário e o agregado esconde isso — analise por grupo com essa lente.
• Acessibilidade: o tratamento não pode regredir a acessibilidade "porque converteu melhor". Guardrail de a11y (ver Acessibilidade Digital & WCAG).
• Dark patterns "otimizados": A/B testing pode "provar" que um padrão manipulador (confirmshaming, urgência falsa, cancelamento difícil) aumenta a métrica. Otimizar a métrica não é servir o usuário — a métrica é uma aproximação, e o julgamento humano precisa vetar o que é predatório mesmo que "funcione" (ver Design de Produtos com IA, Módulo 9).

9.4 Quando A/B não é a ferramenta

• Poucos usuários (sem poder).
• Decisões estratégicas ou de marca (o efeito é de longo prazo, holístico, e você não vai reverter pelo p-valor).
• Mudanças onde o certo é óbvio (consertar um bug, seguir a lei, acessibilidade) — apenas faça.
• Quando o custo de rodar (complexidade, dois caminhos de código, atraso) supera o valor da certeza — para muitas mudanças pequenas, um rollout monitorado basta.
• Pesquisa generativa (entender por que, descobrir necessidades) — isso é qualitativo, não A/B.

10.1 Onde essa habilidade pesa

• Product analyst / data analyst (product): desenhar experimentos, analisar, traduzir em decisão.
• Data scientist (experimentation / causal inference): a estatística, os desenhos avançados, a metodologia.
• Experimentation PM / Growth PM: priorizar, escrever hipóteses, tomar as decisões.
• Growth engineer / experimentation platform engineer: a infra de flags, assignment, pipeline e análise.
• É uma competência transversal cobrada de PMs, designers e engenheiros de produto em qualquer empresa que meça.

10.2 Roadmap de estudo (4–6 semanas)

10.3 Banco de perguntas (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Experimento fim-a-fim (âncora): um caso (real ou simulado) com o experiment doc pré-registrado (hipótese, métrica primária, guardrails, sample size/MDE), a implementação com feature flags, e a análise honesta (IC, SRM, decisão) — incluindo o que fazer se der "flat".
2. Feature flags num app: targeting por %, atributo e segmento, avaliação determinística, e um rollout gradual com kill switch documentado.
3. Estudo de sample size / poder: uma análise (Python) de quanto tráfego é preciso para vários MDEs numa métrica, e uma simulação do custo do "peeking".
4. Análise de um experimento "flat": demonstrar a checagem de poder, exposição, SRM e execução, e a recomendação — a habilidade que separa quem entende de quem só sabe rodar.
5. Desenho de experimento em rede/marketplace: a justificativa da interferência e o desenho switchback/cluster, com as métricas e a análise.

10.5 Fontes para continuar

• A referência: Trustworthy Online Controlled Experiments (Kohavi, Tang & Xu) — a "bíblia" do assunto; os artigos e palestras de Ronny Kohavi.
• Estatística prática: as calculadoras de Evan Miller; os posts sobre CUPED, sequential testing e SRM dos blogs de engenharia (Microsoft ExP, Booking, Netflix, Airbnb, Spotify, DoorDash para switchback).
• Plataformas / conceitos: a documentação e o blog de Statsig, Eppo, GrowthBook, LaunchDarkly; PostHog.
• Cultura: Experimentation Works (Stefan Thomke); o material de experimentação de produto do Reforge e da Amplitude.
• Nesta trilha: Marketing Digital & Análise de Resultados, Análise de Dados com Python, Engenharia de Dados, Business Intelligence Corporativo, LLMOps & Avaliação de Sistemas de IA, Design de Produtos com IA, Observabilidade & SRE, Acessibilidade Digital & WCAG, Arquitetura de Software & System Design.