Trasfondo
En donde estoy trabajando, cada nuevo feature o idea, pasa por un proceso de A/B Testing.
Normalmente lo que hacemos es:
- Generamos una hipótesis del estilo: "Si los usuarios tuviesen una notificación cuando pasa
X
, entonces van a hacerY
más seguido". - Desatollamos esta notificación, o lo que sea.
- Apuntamos a algún mercado para participar de esta prueba
- Dividimos a la mitad de los usuarios de ese mercado, tal que vean e interactúen con en nuevo feature, mientras que la otra mitad (grupo control) no.
- Esperamos dos semanas
- Comparamos las métricas entre los dos grupos.
Este último paso puede llevar a miles de ramificaciones: Activamos el feature para toda la población. Cambiamos algo y volvemos a hacer una prueba. Lo deshabilitamos por completo porque nuestra hipótesis era incorrecta. Etc, etc.
Para la segmentación de la población, estamos usando un servicio de un tercero. A este servicio, ocasionalmente le brindamos la información de segmentación de nuestros usuarios.
Información como
El usuario
123
es de Madrid
para que luego, cuando queramos segmentar, podrÃamos segmentar solo usuarios de Madrid.
Este servicio externo, adicionalmente, solo nos provee acceso a las variantes (si un usuario pertenece al segmento, es parte del grupo de control, o es parte del grupo que participa) mediante un SDK para usar en móviles (iOS y Android).
Esto nos presentaba dos dificultades:
- Si quisiéramos hacer un A/B Test en alguno de los micro-servicios de backend, no podrÃamos consultar a este servicio.
- Si quisiéramos segmentar por algo de lo que no le habÃamos informado al servicio, deberÃamos compartirle toda esta nueva información para que este pueda segmentar.
Por esta situación, decidimos crear un micro-servicio que se encargue de segmentar y separar en variantes a nuestros usuarios.
Problemas
Rápidamente nos vimos enfrentados a resolver como hacer para obtener la información para segmentar.
Normalmente segmentamos por paÃs, lo que serÃa sencillo hacer que el nuevo micro-servicio consultara con otro micro-servicio de información; y obtuviese el paÃs del usuario.
Con esta nueva información, podrÃamos segmentar.
Lo que presenta un desafÃo interesante:
Como evitar que este micro-servicio crezca cada vez introduzcamos un nuevo micro-servicio que almacene alguna información del usuario?
Por eso, pensamos que podrÃamos delegar la responsabilidad de obtener el contexto del usuario, a quien consuma este micro-servicio; por lo que una llamada podrÃa ser:
Dado el usuario
123
, de Madrid; a qué variante pertenece?
De esta manera, es quien consume quien necesita saber todas las dependencias del experimento, y cada experimento puede tener dependencias distintas, de distintas formas de computarse, y el micro-servicio podrÃa no crecer.
DSL (Domain-specific language - Lenguaje especÃfico de dominio)
Ya sabÃamos como querrÃamos que se comporte el micro-servicio, ahora necesitábamos una forma de expresar como querrÃamos segmentar nuestra población. HacÃa poco estaba trabajando mucho con Mongo
y se me ocurrió que un lenguaje de consultas como el de mongo podrÃa ser interesante de explorar.
De tal forma que una segmentación como:
Quiero que solo participen del experimento
EXP001
, usuarios quienes sean de Madrid. De estos, la mitad estarán en el grupo departicipando
y el esto encontrol
.
Se transformarÃa en:
{ "EXP001": { "ubicación": "Madrid", "$children": { "participando": { "$rand": { "$gt": 0.5 } }, "control": {} } } }
De esta manera, quien consuma al micro-servicio deberÃa proveer, al menos, la información de la "ubicación"
del usuario.
Una posible consulta podrÃa ser con el contexto:
{
"ubicación": "Madrid",
"userId": 5
}
El micro-servicio deberÃa responder que pertenece al EXP001
(dado que la ubicación empareja con la definición), y podrÃa pertenecer a la variante participando
o control
.
Los usuarios deberÃan estar distribuidos 50%-50%; dado que hay un 50% de probabilidad que un numero al azar, uniformemente distribuido entre 0 y 1 (como es $rand
) sea mayor a 0.5.
Con esta idea, sabiendo que la intención era que el micro-servicio no dependiente de ninguna otra parte de arquitectura de nuestro ecosistema; se me ocurrió que podrÃa desarrollarlo como una librerÃa pública; por si alguien más tiene la necesidad que tuvimos nosotros.
koncierge 🛎
La librerÃa está en GitHub/jazcarate/koncierge
Cover image by Nicolas Cool on Unsplash
Top comments (0)