Cómo Configurar Grupos de Experimentos Mutuamente Excluyentes en Optimizely

Cuando los equipos de experimentación digital ejecutan múltiples pruebas A/B simultáneamente sobre una misma página, embudo de pago o recorrido del usuario, el riesgo de colisión de tráfico es elevado. Si un visitante entra en dos pruebas superpuestas a la vez, los efectos de interacción (Interaction Effects) impiden determinar qué cambio impulsó las conversiones, mientras que los desequilibrios de tráfico pueden provocar un desajuste en la proporción de muestras (Sample Ratio Mismatch, SRM).

En Optimizely, este problema se resuelve configurando Grupos de Exclusión (Exclusion Groups). Un grupo de exclusión actúa como un contenedor de tráfico que agrupa múltiples experimentos y divide el tráfico de la audiencia utilizando una semilla de asignación determinista compartida. Un usuario asignado al Experimento A nunca será expuesto al Experimento B dentro del mismo grupo.

Cuándo Usar Grupos Mutuamente Excluyentes (y Cuándo Evitarlos)

La exclusión mutua protege la integridad estadística de los datos, pero conlleva un coste operativo directo: la dilución del tráfico. Dividir una audiencia finita entre múltiples pruebas reduce el tamaño muestral de cada una y prolonga considerablemente el tiempo necesario para alcanzar significancia estadística.

Los equipos de experimentación deben evaluar cada escenario con criterio:

Mecanismo Interno de Asignación en Optimizely

Por defecto, Optimizely evalúa cada experimento de forma independiente. Para cada prueba, combina el identificador del usuario (User ID o Bucketing ID) con el ID del experimento (Experiment ID) mediante el algoritmo de hash determinista MurmurHash3, asignando el resultado a uno de 10.000 segmentos de tráfico (del 0 al 9.999).

Dado que los experimentos independientes emplean semillas distintas, un mismo usuario puede quedar asignado a variantes activas en múltiples experimentos simultáneos.

Al incorporar experimentos a un Grupo de Exclusión (Exclusion Group), Optimizely modifica el flujo de partición:

1. Dominio de hash compartido: El algoritmo genera el hash del identificador del usuario junto con el ID del grupo de exclusión.
2. Partición determinista: Los 10.000 segmentos se distribuyen estrictamente entre los experimentos miembros según los porcentajes de tráfico configurados.
3. Aislamiento absoluto: Si un usuario cae en el rango asignado al Experimento A, solo podrá participar en dicho experimento y queda excluido de inmediato del Experimento B o C del grupo.

Jerarquía y Prioridad de Evaluación (Evaluation Order)

Tanto en Optimizely Feature Experimentation como en Web Experimentation, la decisión sigue una secuencia estricta:

1. Estado de la regla: Comprueba que la regla o experimento esté activo.
2. Variaciones forzadas (Forced Variations): Máxima prioridad (usadas para control de calidad y pruebas internas).
3. Lista de permitidos (User Allowlisting): Asignaciones explícitas de IDs de usuario.
4. Servicio de perfiles de usuario (User Profile Service, UPS): Consulta asignaciones persistentes de sesiones previas.
5. Segmentación de audiencia (Audience Targeting): Valida si los atributos del usuario cumplen las condiciones.
6. Evaluación del grupo de exclusión: Determina si el usuario ya pertenece a otro experimento del grupo; si es así, se descarta.
7. Asignación de tráfico y variación: Distribuye al usuario en una variante específica dentro del experimento elegido.

Guía Paso a Paso: Optimizely Web Experimentation

Para equipos que ejecutan pruebas en el navegador o en la capa Edge:

1. Crear el Grupo de Exclusión

1. En el panel de Optimizely Web Experimentation, diríjase a Experiments.
2. Seleccione la pestaña Exclusion Groups. (Nota: Si utiliza Optimizely Personalization, acceda mediante Optimizations > Exclusion Groups).
3. Haga clic en Create New Exclusion Group.
4. Ingrese un Nombre descriptivo (ej. Checkout_Funnel_Q2_Exclusion) y una Descripción opcional.

2. Añadir Experimentos y Asignar Porcentajes de Tráfico

1. Seleccione los experimentos en borrador que formarán parte del grupo.
2. Defina la distribución del tráfico total del grupo entre los experimentos:
   • Por ejemplo, 50% para el Experimento 1 y 50% para el Experimento 2;
   • O reserve una porción de control no asignada (ej. 40% Experimento 1, 40% Experimento 2 y 20% de reserva).
3. Haga clic en Create Exclusion Group para guardar.

3. Verificar Condiciones de Activación

Asegúrese de que todos los experimentos del grupo compartan las mismas condiciones de página o activadores de eventos para garantizar una distribución equilibrada.

Guía Paso a Paso: Optimizely Feature Experimentation

Para equipos de ingeniería que operan en backend, microservicios y aplicaciones móviles:

1. Crear el Grupo de Exclusión en el Panel de Flags

1. Diríjase a Flags y seleccione la pestaña Exclusion Groups.
2. Haga clic en Create New Exclusion Group.
3. Ingrese el nombre y la descripción.
4. Seleccione el Entorno (Environment) de destino (ej. Production o Staging, ya que los grupos están vinculados a cada entorno).
5. Haga clic en Create Exclusion Group.

2. Asociar las Reglas de Experimento al Grupo

1. Vuelva a la lista de Flags y abra la flag que contiene su regla de experimento.
2. Seleccione el entorno correspondiente y haga clic en la Experiment Rule.
3. En la sección Configure Rule, ubique el menú desplegable: "Add this experiment to the following exclusion group".
4. Seleccione el grupo de exclusión creado previamente.
5. Indique el porcentaje de tráfico del grupo asignado a esta regla.
6. Haga clic en Save Experiment.
7. Repita estos pasos para los demás experimentos que deban permanecer mutuamente excluyentes.

3. Configuración Programática mediante REST API

Los equipos con flujos de despliegue automatizados pueden gestionar los grupos mediante la API REST de Optimizely:

• Crear grupo: POST /v2/groups con el cuerpo {"name": "Cart_Redesign_Group", "environment_key": "production"}.
• Actualizar asignaciones: PATCH /v2/groups/{group_id} vinculando el rule_id del experimento.
• Auditoría: GET /v2/groups para consultar los límites de exclusión activos en cada entorno.

4. Sin Código Adicional en el SDK

La lógica de exclusión se incluye directamente en el archivo de configuración (Datafile / Ruleset) y se resuelve en memoria. Cuando su servicio invoca client.decide(user_key, flag_key), el SDK realiza el descarte y la asignación localmente sin latencia de red adicional.

Cuatro Reglas Fundamentales para Equipos de Experimentación

Para evitar datos corruptos, sesgos estadísticos y resultados equívocos, los equipos deben respetar cuatro normas esenciales:

1. Iniciar los Experimentos del Grupo Simultáneamente

No lance el Experimento 1 hoy y añada el Experimento 2 la próxima semana. Si los visitantes ya fueron asignados a un grupo activo, añadir nuevas pruebas alterará los límites de los segmentos, provocando reasignaciones indebidas y sesgando la aleatoriedad de la muestra.

2. Nunca Modificar un Grupo de Exclusión en Ejecución

Mientras haya experimentos activos en el grupo:

• No añada nuevos experimentos al grupo.
• No elimine experimentos en curso del grupo. Modificar grupos activos altera las proporciones de tráfico, dispara alertas de Sample Ratio Mismatch (SRM) e invalida los cálculos de significancia. Si necesita detener una prueba antes de tiempo, pause su regla en lugar de desmantelar el grupo.

3. Mantener Coherencia en la Segmentación de Audiencias

Si el Experimento A se dirige a usuarios de escritorio y el Experimento B solo a usuarios móviles, agruparlos desperdicia tráfico. Como la partición se efectúa a nivel del grupo, los usuarios de escritorio derivados al Experimento B no verán ninguna variante, privando al Experimento A de un valioso volumen muestral.

4. Precaución con el Servicio de Perfiles de Usuario (UPS)

En arquitecturas con User Profile Service (UPS) para mantener variantes fijas entre sesiones, la consulta al UPS se ejecuta antes que la evaluación del grupo de exclusión. Si un usuario ya tenía una variante almacenada de una fase previa, el UPS devolverá dicho valor histórico, ignorando la regla de exclusión. Utilice OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE cuando requiera un aislamiento estricto.

Referencias

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