Como Configurar Grupos de Experimentos Mutuamente Exclusivos no Optimizely

Quando equipes de produto e crescimento executam múltiplos testes A/B simultâneos em uma mesma página, fluxo de checkout ou jornada de conversão, o risco de colisão de tráfego é iminente. Se um mesmo visitante participa de dois testes sobrepostos ao mesmo tempo, os efeitos de interação (Interaction Effects) tornam impossível isolar qual alteração impulsionou os resultados, além de desvios na distribuição poderem gerar uma incompatibilidade de proporção de amostra (Sample Ratio Mismatch, SRM).

No Optimizely, as equipes resolvem esse desafio configurando Grupos de Exclusão (Exclusion Groups). Um grupo de exclusão funciona como um contêiner de tráfego que reúne múltiplos experimentos e particiona a audiência por meio de um algoritmo de hash determinístico compartilhado. Um usuário alocado no Experimento A jamais será exposto ao Experimento B dentro do mesmo grupo.

Quando Utilizar Grupos de Exclusão (e Quando Evitá-los)

A exclusão mútua assegura a integridade estatística das métricas, mas impõe um custo operacional claro: a diluição do tráfego. Ao dividir uma audiência finita entre múltiplos testes, o tamanho da amostra de cada experimento é reduzido, prolongando o tempo necessário para atingir significância estatística.

Líderes de experimentação devem avaliar cada cenário:

Funcionamento Interno da Exclusão Mútua no Optimizely

Por padrão, o Optimizely avalia cada experimento de maneira independente. Para cada teste, a plataforma combina o identificador do usuário (User ID ou Bucketing ID) com o ID do experimento (Experiment ID), aplicando a função de hash determinística MurmurHash3 para mapear o usuário em um dos 10.000 baldes de tráfego (de 0 a 9.999).

Como experimentos independentes utilizam sementes distintas, um visitante pode facilmente cair na faixa ativa de múltiplos testes simultâneos.

Ao configurar um Grupo de Exclusão (Exclusion Group), o Optimizely ajusta o particionamento:

1. Domínio de Hash Compartilhado: A função de hash processa o identificador do usuário em conjunto com o ID do Grupo de Exclusão.
2. Divisão Determinística: Os 10.000 baldes são distribuídos exclusivamente entre os experimentos membros, de acordo com as porcentagens definidas.
3. Isolamento Rigoroso: Se um usuário cai na faixa atribuída ao Experimento A, ele torna-se elegível apenas para o Experimento A, sendo automaticamente desconsiderado para o Experimento B ou C do grupo.

Ordem de Prioridade e Avaliação (Evaluation Order)

No Optimizely Feature Experimentation e no Web Experimentation, as decisões seguem uma hierarquia estrita:

1. Status da Regra: Valida se a flag ou o experimento está ativo.
2. Variações Forçadas (Forced Variations): Prioridade máxima (utilizada em QA e testes internos).
3. Lista de Permissões (User Allowlisting): Mapeamento direto de IDs de usuário específicos.
4. Serviço de Perfil de Usuário (User Profile Service, UPS): Consulta alocações persistidas de sessões anteriores.
5. Segmentação de Audiência (Audience Targeting): Avalia se o usuário atende aos critérios da audiência.
6. Avaliação do Grupo de Exclusão: Verifica se o usuário já pertence a outro experimento do grupo; em caso afirmativo, ele é excluído.
7. Distribuição de Tráfego e Variação (Traffic Allocation): Define em qual variante o usuário será alocado dentro do experimento selecionado.

Passo a Passo: Optimizely Web Experimentation

Para equipes que realizam testes no lado do cliente ou na camada Edge:

1. Criar o Grupo de Exclusão

1. No painel do Optimizely Web Experimentation, acesse Experiments.
2. Clique na aba Exclusion Groups. (Nota: Caso utilize o Optimizely Personalization, acesse via Optimizations > Exclusion Groups).
3. Clique no botão Create New Exclusion Group.
4. Defina um Nome claro (ex.: Checkout_Funnel_Q2_Exclusion) e uma Descrição opcional.

2. Adicionar Experimentos e Alocar Percentuais de Tráfego

1. Selecione os experimentos em rascunho que devem integrar o grupo.
2. Defina a distribuição do tráfego total do grupo entre os experimentos:
   • Por exemplo, 50% para o Experimento 1 e 50% para o Experimento 2;
   • Ou reserve uma fatia de controle não alocada (ex.: 40% Experimento 1, 40% Experimento 2 e 20% de reserva).
3. Clique em Create Exclusion Group para salvar.

3. Validar Parâmetros de Disparo

Confirme se todos os testes reunidos no grupo compartilham as mesmas condições de URL e disparadores para manter a coerência da distribuição de tráfego.

Passo a Passo: Optimizely Feature Experimentation

Para equipes de engenharia de software operando em backend, microsserviços e aplicativos móveis:

1. Criar o Grupo no Painel de Flags

1. Navegue até o menu Flags e clique na aba Exclusion Groups.
2. Clique em Create New Exclusion Group.
3. Preencha o nome e a descrição do grupo.
4. Selecione o Ambiente (Environment) correspondente (ex.: Production ou Staging, pois os grupos pertencem a cada ambiente específico).
5. Clique em Create Exclusion Group.

2. Vincular as Regras de Experimento ao Grupo

1. Retorne à lista de Flags e selecione a feature flag que contém sua regra de teste.
2. Escolha o ambiente e clique na Experiment Rule desejada.
3. Na seção Configure Rule, localize o menu suspenso: "Add this experiment to the following exclusion group".
4. Selecione o grupo de exclusão recém-criado.
5. Indique o percentual de tráfego do grupo que este experimento consumirá.
6. Clique em Save Experiment.
7. Repita este procedimento para todos os experimentos paralelos que devem ser isolados.

3. Configuração Programática via API REST

Equipes que utilizam fluxos de CI/CD podem provisionar grupos de exclusão via API:

• Criar grupo: POST /v2/groups com o payload {"name": "Cart_Redesign_Group", "environment_key": "production"}.
• Atualizar regras: PATCH /v2/groups/{group_id} informando o rule_id da regra de experimento.
• Auditoria: GET /v2/groups para inspecionar os grupos de exclusão ativos no ambiente.

4. Zero Alteração no Código da Aplicação

A lógica de exclusão é transmitida via Datafile e processada em memória pelo SDK. Ao chamar client.decide(user_key, flag_key), o SDK resolve o baldeamento e a exclusão localmente, sem introduzir latência de rede.

Quatro Regras Fundamentais de Governança

Para assegurar dados consistentes e evitar falhas estatísticas graves, as equipes devem respeitar quatro preceitos essenciais:

1. Iniciar Todos os Experimentos do Grupo Simultaneamente

Não inicie o Experimento 1 hoje para adicionar o Experimento 2 na semana seguinte. Se parte dos visitantes já tiver recebido baldes de alocação em um grupo ativo, adições posteriores recalculam as faixas de hash, provocando migração indesejada de usuários e distorcendo a aleatoriedade da amostra.

2. Nunca Adicionar ou Remover Experimentos de um Grupo em Execução

Enquanto houver qualquer teste ativo no grupo:

• Não adicione novos experimentos;
• Não remova experimentos em andamento. Alterações com tráfego ao vivo desregulam as proporções esperadas, disparam alertas de Sample Ratio Mismatch (SRM) e invalidam a análise estatística. Caso um teste precise ser encerrado antecipadamente, pause a regra em vez de alterar o grupo.

3. Manter Critérios Consistentes de Audiência

Se o Experimento A é voltado para desktop e o Experimento B foca apenas em mobile, colocá-los no mesmo grupo gera desperdício. Como a divisão ocorre no nível do grupo, os usuários de desktop sorteados para o Experimento B não verão nada, drenando amostras úteis do Experimento A.

4. Atenção com a Prioridade do User Profile Service (UPS)

Em arquiteturas que adotam o User Profile Service (UPS) para fixar variantes entre sessões, a consulta ao UPS ocorre antes da verificação do grupo de exclusão. Se um usuário já possuir uma variante gravada de uma execução anterior, o UPS retornará essa alocação antiga, desrespeitando o grupo. Use OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE quando for necessário garantir isolamento completo.

Referências

• Use mutual exclusion - Feature Experimentation docs
• How bucketing works - Feature Experimentation docs
• Optimizely's automatic sample ratio mismatch detection