Experimentos (A/B testing)

Un experimento en Kilden no es un segundo repartidor de tráfico. Es una lente sobre un feature flag multivariante que ya tienes: el flag sigue decidiendo quién ve qué, igual que antes, y el experimento lee las exposiciones que tu SDK ya está enviando y te dice si la diferencia es real.

Eso tiene dos consecuencias que conviene saber de entrada. Arrancar un experimento no cambia nada de lo que ven tus usuarios. Y cualquier flag con dos o más variantes ya es medible: no tienes que instrumentar nada nuevo.

Antes de arrancar

Un experimento necesita:

• Un flag multivariante con al menos dos variantes, una marcada como control.
• Que tu código realmente consulte el flag. Las exposiciones vienen de getFeatureFlag() / isFeatureEnabled(). Si tu código ramifica sin llamar a ninguna de las dos, el experimento no mide nada — y te lo dice.
• Un evento objetivo: eso de lo que quieres más. Conversión (¿esta persona lo hizo al menos una vez?) o un valor por persona (una suma, o un conteo).

// Esta llamada es la que mete a la persona en el experimento.
const variant = await kilden.getFeatureFlag('checkout_flow');

if (variant === 'one_step') {
  renderOneStepCheckout();
} else {
  renderClassicCheckout();
}

El SDK envía una exposición por flag por sesión; el análisis se queda con la primera variante que vio cada persona.

Crear uno

Experimentos → Nuevo experimento, en tres pasos: la hipótesis, el flag y su control, y qué cuenta como éxito.

El último paso estima cuánto necesita durar el test, usando el tráfico reciente del propio flag. Si la respuesta es “ocho meses”, te lo dice antes de arrancar y no después: la forma más común en que un test A/B fracasa es no poder detectar el efecto que buscaba.

Mientras un experimento corre, el reparto del flag queda congelado. Cambiar pesos a mitad de camino mezcla dos configuraciones de asignación distintas bajo un solo resultado, que es la forma más silenciosa de arruinar un test. Pausa el experimento si necesitas editar el flag.

Leer los resultados

La página abre con un veredicto en palabras, y todo lo que está debajo existe para que puedas auditarlo.

Por qué una probabilidad y no un p-value

Kilden reporta “B supera al control con 91% de probabilidad”. Esa es una afirmación bayesiana sobre este experimento, y significa exactamente lo que parece que significa.

Un p-value no. Responde otra pregunta (“¿qué tan sorprendentes serían estos datos si no hubiera ninguna diferencia?”), se malinterpreta rutinariamente como la probabilidad de tener razón, y castiga justo el comportamiento que tiene todo equipo real: mirar los resultados todos los días. Bajo observación continua, una regla de decisión basada en p-values infla los falsos positivos de forma severa. La lectura bayesiana se degrada mucho mejor.

Junto a ella tienes:

• El intervalo creíble — el rango donde plausiblemente vive el efecto real. Kilden nunca muestra un uplift sin uno.
• La pérdida esperada — cuánto sacrificas en promedio si eliges esa variante y resulta que estabas equivocado. Este es el número que de verdad responde “¿es seguro lanzarlo?”.

El gráfico de efecto

Una fila por variante, con el uplift contra el control y su intervalo creíble al 95%. El cero siempre está en el encuadre, y un intervalo que cruza el cero se dibuja en gris neutro — porque un efecto que podría ser positivo y podría ser negativo todavía no es un resultado.

Deliberadamente no es un gráfico de barras de tasas de conversión: las barras invitan al eje truncado que convierte 2,1% contra 2,3% en una montaña.

Las curvas posteriores

Las distribuciones de lo que podría ser la tasa real de cada variante. El solape es la incertidumbre: dos curvas montadas una sobre otra significan que todavía no puedes distinguirlas, diga lo que diga el número que va ganando.

Evolución

La probabilidad de superar al control, día a día, calculada solo con lo que se sabía cada día. Ver esa línea cruzar el 95% temprano y volver a bajar es el argumento más claro que existe contra parar apenas el resultado se ve bien.

Los diagnósticos de validez

Cada experimento corre tres chequeos. Un resultado que los falla es peor que ningún resultado, porque se ve igual de convincente — así que Kilden no reporta ganador cuando fallan, no matiza la lectura.

Reparto (SRM)

Compara el tráfico que recibió realmente cada brazo contra el que el flag estaba configurado para mandar. Que no coincidan significa que algo rompió la asignación: un filtro de bots asimétrico, un cambio de pesos a mitad de camino o una integración que consulta el flag solo en una rama. Cualquier conclusión encima de eso es ruido.

Contaminación

Personas que vieron más de una variante. Suele pasar cuando visitantes anónimos se identifican a mitad del test: el bucket depende del ID, así que cambiar el ID puede moverlas de brazo.

Kilden las excluye del análisis y reporta la tasa en vez de corregirla en silencio. Sobre el 2%, el resultado se marca como comprometido. La exclusión tiene un sesgo propio —deja fuera a quienes iniciaron sesión durante el test— y ese es un problema menor y visible, contra uno invisible.

Muestra

Cada brazo necesita al menos 100 personas antes de que se reporte inferencia alguna, y el veredicto sigue el avance contra la muestra que implica tu MDE.

Acá te vas a encontrar con la diferencia entre lidera y decisivo. Un brazo puede cruzar el 95% al tercer día con un cuarto de la muestra: los efectos reales y el ruido puro hacen ambos eso. Kilden lo llama lidera, te dice cuánta muestra falta, y aun así te deja concluir — la decisión es tuya, la herramienta solo se niega a fingir que el test terminó.

Concluir

Concluir congela los resultados tal como están, como la evidencia detrás de la decisión, junto con lo que escribas sobre por qué la tomaste. Ese snapshot no se recalcula jamás: los datos de abajo se mueven —merges, retención, backfills— y un número que cambia después de la decisión no es evidencia.

Concluir no cambia tu flag. Poner el ganador al 100% es una acción aparte y explícita, con la auditoría propia del flag. Kilden nunca cambia lo que hace tu producto por su cuenta.

Límites en v1

• Solo tráfico de browser. Los SDKs server-side todavía no emiten eventos de exposición, por diseño.
• Un evento objetivo como métrica primaria; los funnels multi-paso se aproximan con el último paso.
• Las métricas de revenue se winsorizan al percentil 99 antes de comparar, para que un pedido enorme no mueva la media. La página te dice cuántos valores tocó.