Experimentos
Tipos, estados, asignación determinística y kill switch.
Un experimento reparte visitantes entre variantes de forma determinística, aplica los cambios de la variante asignada y mide el resultado con criterios que no se dejan engañar por el ruido.
Tipos
| Tipo | Qué hace |
|---|---|
ab |
Control contra una o más variantes con cambios visuales. |
multivariate |
Varias variantes simultáneas. |
redirect |
Redirige a otra URL. |
feature_flag |
Devuelve un valor a tu código sin tocar el DOM. |
personalization |
Aplica un cambio a un segmento, sin control. |
Estados
draft ─→ qa ─→ scheduled ─→ running ─→ paused ─→ completed ─→ archived
Las transiciones válidas están tabuladas en el servidor: no puedes pasar de archived a running ni de completed a draft. Un salto inválido devuelve 409 invalid_transition con las transiciones permitidas.
Solo running y qa se sirven a tráfico. Publicar guarda además una instantánea inmutable de la configuración, de modo que el análisis siempre lee lo que estuvo vivo, no el borrador actual.
Asignación determinística
bucket = murmur3(siteId : visitorId : experimentId : version : salt) % 10000
La misma tupla siempre da el mismo bucket: en el navegador, en el servidor, hoy y en seis meses. No se consulta ningún estado, así que dos servicios nunca discrepan y un visitante que borra cookies pero conserva su id sigue en la misma variante.
Dos hashes, no uno
La inclusión en el experimento y la elección de variante usan espacios de hash distintos.
Si un solo bucket hiciera ambas cosas, subir el tráfico del 50% al 100% reasignaría a los visitantes que ya estaban dentro y mezclarías dos cohortes en un mismo dataset. Con dos espacios, ampliar la asignación solo añade visitantes y quien ya tenía variante la conserva.
Cambiar la versión reasigna a propósito
Incrementar version cambia el hash y por tanto reparte de nuevo. Es la forma de empezar una cohorte limpia cuando modificas el experimento de forma que invalida los datos previos. Si no quieres reasignar, no toques la versión.
Exposición
Una exposición se registra solo después de que los cambios se hayan aplicado realmente al DOM, y una sola vez por vista de página.
Esto es la diferencia entre un dato fiable y uno sesgado. Registrar en el momento de la asignación contaría visitantes que nunca vieron el cambio —porque el selector no existía, porque el script falló, porque abandonaron antes— e inflaría el denominador del control tanto como el de la variante, pero no por igual.
Si una variante no puede aplicarse, el SDK revierte al control y reporta un sdk_error. No registra exposición.
Distribución de tráfico
- Traffic allocation: qué fracción del tráfico elegible entra al experimento (0–1).
- Weight por variante: reparto relativo entre las variantes. No necesitan sumar 1.
Los pesos se aplican sobre el espacio completo de buckets, independientemente de la asignación de tráfico. Esa es la propiedad que permite ampliar tráfico sin reasignar.
Exclusión mutua
Los experimentos que comparten exclusionGroup no se muestran juntos. Un visitante ve como máximo uno del grupo, elegido por hash del visitante contra el grupo.
Se elige por hash y no "el primero activo" porque lo segundo dejaría sin tráfico a los experimentos nuevos y correlacionaría la pertenencia al grupo con el orden de creación.
Programación
startAt y endAt acotan la ventana. El servicio cron activa los experimentos programados cuya fecha llegó y completa los que pasaron su fecha de fin, aunque nadie se acordara de pausarlos.
Kill switch
En Sitios → Configuración hay un interruptor por sitio. Al activarlo:
killSwitch: trueentra en la configuración firmada.- Se invalida la caché y sube
configVersion. - El SDK deja de aplicar todos los experimentos en cuanto refresca (≤60 s).
- Los cambios ya aplicados se revierten sin recargar la página.
El kill switch se comprueba antes que cualquier otra cosa, incluso antes de una variante forzada por preview. Es el camino de rollback cuando algo rompe una tienda.
Preview y QA
Añade parámetros a cualquier URL de tu sitio:
?gl_preview=1&gl_experiment=exp_abc123&gl_variant=b
Una variante forzada ignora el estado y la programación —puedes previsualizar un borrador— pero nunca ignora el kill switch.
El tráfico de preview se marca con is_preview y se excluye de todos los análisis. Ver el experimento no contamina los resultados.
Criterios de decisión
Un porcentaje más alto nunca es por sí solo un ganador. Para declararlo hacen falta cinco condiciones simultáneas:
- Sin Sample Ratio Mismatch.
- Muestra mínima por variante alcanzada.
- Duración mínima alcanzada (por defecto una semana: quien compra en lunes no es quien compra en sábado).
- Probabilidad posterior de superar al control por encima del umbral.
- Pérdida esperada por debajo del máximo aceptable.
Si falta cualquiera, el resultado es insufficient_data o inconclusive, con la lista explícita de bloqueadores.
Una variante puede tener 96% de probabilidad de ganar y seguir sin ser recomendable si su pérdida esperada es alta o si el revenue por visitante cae. Eso último es un guardrail: bloquea el envío aunque la conversión suba.