[ESP] ¿Cómo implantar experimentos A/B de una funcionalidad?

Para implantar experimentos A/B de una funcionalidad en nuestra plataforma, recomendamos no empezar por la funcionalidad más crítica.

Usemos un objetivo, una métrica y una prestación que no sean claves para nosotros con la mentalidad de ganar confianza en el método.

Para recordar cómo definir un test A/B para una funcionalidad, podéis leer nuestro post acerca de ¿Cómo definir un test A/B para una funcionalidad?

Primeros pasos

Esta metodología nos va a garantizar mejoras en nuestros objetivos a medio plazo, pero con el coste de perder rendimiento de vez en cuando a corto plazo.

La parte positiva es que las pérdidas de rendimiento van a ser muy pequeñas con respecto a los beneficios permanentes.

Resultados	Monthly_newsletter_subscriptions
Antes del experimento	1.234
Pérdida durante el experimento	1.247 (+13) (+1.05%)
Beneficios después del experimento	1.320 (+86) (+6.97%)

Si tenemos suficientes usuarios, incluso podemos reducir el % del grupo de test, reduciendo aún más las pérdidas en caso de no acertar con la hipótesis.

Resultados	Monthly_newsletter_subscriptions
Antes del experimento	1.234
Pérdida durante el experimento (15%)	+13 (+1.05%)
Pérdida durante el experimento (3%)	+2.69 (+0.22%)

Implantación en el código

Un test A/B es un caso concreto de Feature Version.

Usando Feature Flags la implantación del ejemplo

que hemos tratado anteriormente sería envolver cada uno de los dos bloques de código con un:

if (isActive(FEATURE_NAME) && version(FEATURE_NAME) == “A”) {
    show_form();
}

En este caso, tanto si se usa Angular, React, Twig, Blade o el sistema de render que sea, se recomienda un patrón de proxy como el siguiente en el fichero del template de la feature:

Feature_X {
    if ( ! isActive(FEATURE_NAME) ) return
    
    if ( version(FEATURE_NAME) == “A” )
        return Feature_X_A
    else if ( version(FEATURE_NAME == “B” )
        return Feature_X_B
    else decide_what_to_do_here()
}

Vamos a tratar el versionado de las features utilizando semver.

Ejemplo:

1.7.4-alpha

(major).(minor).(patch)-(pre-release)

major = cambio en la Feature que rompe compatibilidad

minor = cambio en la Feature que no rompe compatibilidad

patch = fix de algún bug que no rompe compatibilidad

pre-release = indica que la versión no es estable

---

Feature Version 1.7.4 (control, 95% del tráfico).

Feature Version 1.8.0-exp.B (test, 5% del tráfico).

Esta nomenclatura nos permite descartar una versión fácilmente en caso de que el resultado del experimento sea negativo.

Por contra, esta nomenclatura nos implica un cambio en el código una vez decidamos que la Feature Version sustituye a la actual como versión estable o control.
Cambio de 1.8.0-exp.B a 1.8.0 en el código.

---

Feature Version 1.7.4 (control, 95% del tráfico).

Feature Version 1.8.0 (test, 5% del tráfico).

Esta nomenclatura nos permite ignorar si estamos seguros o no de una Feature, y simplemente asume que aunque solo se le pase el 5% del tráfico, ya se ha hecho el lanzamiento de esta feature en producción, saltando el paso de mantener etiquetas experimentales, etc.

Por contra, algunos de los usuarios percibirán que se salta de la versión 1.7.4 a la 1.10.0 de golpe (esto no debería de ser un problema ya que los usuarios raramente serán conscientes de la versión de una Feature).