Condiciones de un A/B incompletas y banderas que ya ganaron
Una condición que contempla la variante nueva y se olvida de qué pasa cuando el experimento no está activo. Y el problema opuesto: banderas encendidas hace un año que nadie se anima a sacar.
En un producto que prueba cambios con experimentos, cada funcionalidad nueva nace detrás de una condición. Y esa condición tiene más estados de los que uno escribe: no son dos, son cuatro.
El usuario puede estar en la variante nueva, en la de control, fuera del experimento, o el servicio que asigna variantes puede no haber respondido. Los comentarios de review sobre esto apuntan casi siempre a los dos últimos.
Los cuatro estados
| Estado | Qué se suele escribir | Qué debería pasar |
|---|---|---|
| Variante nueva | Se contempla siempre | La funcionalidad nueva |
| Control | Se contempla casi siempre | El comportamiento anterior, intacto |
| Fuera del experimento | Cae en el `else`, junto con el control | El comportamiento anterior — que puede no ser lo mismo que «control» |
| Sin respuesta del servicio | Nadie lo piensa | El comportamiento anterior, sin bloquear la pantalla ni esperar |
El cuarto es el más caro: si la pantalla espera la asignación para decidir qué mostrar, el día que ese servicio esté lento la aplicación queda en blanco para todos, con el experimento que no era crítico como causa.
Las condiciones que se olvidan de un caso
Los tres olvidos frecuentes
- Sólo se cubre el camino feliz de la variante nueva. El evento de analítica se dispara sólo en una rama, y después las métricas del experimento no cierran porque falta la mitad de la muestra.
- La condición se evalúa en un lugar y el efecto en otro. El usuario entra al experimento después de que la pantalla ya decidió, y ve una mezcla de las dos variantes.
- Se asume que quien está fuera del experimento es equivalente al control. A veces sí; a veces el control es una variante deliberada con instrumentación propia, y mezclarlos ensucia el resultado.
El problema opuesto: la bandera que ya ganó
El experimento termina, la variante nueva gana, y la bandera queda. Al año hay treinta condiciones encendidas que nadie se anima a tocar porque no sabe si algo todavía depende de ellas.
Antes de seguir, predecí
Ese código muerto tiene un costo que se subestima: cada persona que toca esa pantalla tiene que entender las dos ramas, y los tests tienen que cubrir ambas o dejar una sin cubrir.
Lo que hace que no se acumulen
Cuatro reglas baratas
- Fecha de vencimiento al crearla. La bandera nace con una fecha y un dueño. Sin eso, la limpieza nunca es prioridad de nadie.
- Una lista visible. Un lugar donde estén todas las banderas activas, desde cuándo y en qué porcentaje. Si nadie la mira, ya se acumularon.
- La limpieza es parte de terminar el experimento, no un ticket futuro. El experimento termina cuando se borró la rama perdedora, no cuando se leyó el resultado.
- Separar tipos de bandera. Las de experimento son temporales por definición; las de configuración por país o marca son permanentes y no se limpian nunca. Mezclarlas en el mismo mecanismo es lo que hace imposible saber cuáles se pueden borrar.
Más a fondo · nivel seniorLa bandera como interruptor de emergencia
Hay un tercer tipo que conviene conservar: el interruptor que permite apagar una funcionalidad en producción sin desplegar. Ése no vence, pero necesita su propia disciplina —que esté probado que apagarlo funciona—. Un interruptor de emergencia que nadie ejercitó nunca es una suposición, y el día del incidente no es el momento de descubrir que la rama apagada ya no compila.
Los cuatro estados en un diff
Hay 4 problemas en este cambio. Tocá la línea donde creas que está.
| 5 | 5 | ||
| 6 | |||
| 6 | |||
| 7 | |||
| 8 | |||
BloqueaEstar fuera del experimento cae en la rama de control sin que nadie lo decida Quien no entró al experimento —porque no cumple los criterios de segmentación— termina viendo lo mismo que el grupo de control. Puede estar bien, y tiene que ser una decisión escrita: si después se analizan los resultados contando a esa gente como control, la comparación queda contaminada. | |||
| 9 | |||
PreguntaFalta qué pasa cuando el experimento termine Toda condición de experimento nace con fecha de vencimiento y casi ninguna se saca. Cuando esto se decida, hay que borrar una de las dos ramas, y conviene que el ticket de limpieza exista desde ahora: es la única forma de que dentro de dos años el código no tenga treinta condiciones de experimentos que ya se decidieron. | |||
| 10 | |||
| 11 | |||
| 12 | |||
BloqueaY si el servicio de variantes no respondió, pasa lo mismo, en silencio Una falla del servicio de experimentos es indistinguible de estar en control. El día que ese servicio se caiga, el experimento va a mostrar que el 100% de la gente estuvo en control y nadie va a notar nada raro en el panel. Los cuatro estados —tratamiento, control, fuera y sin respuesta— necesitan cada uno su rama. | |||
| 7 | 13 | ||
Dos ramas escritas, cuatro estados posibles, y los dos que faltan se ven exactamente iguales al control.
La vida de una bandera
Cierre
Autoevaluación
¿Lo entendiste?
Práctica
SugerenciaLa llamada es síncrona en el camino de renderizado
Si useExperiment sale a la red, el botón de pagar depende de que ese servicio conteste. El componente más importante del embudo no debería poder quedarse esperando a un sistema que existe para medir. Conviene un valor por defecto inmediato y la variante aplicada cuando llegue.