Correlación no implica causalidad
Tres casos reales de correlaciones que nos podían haber llevado al engaño. La importancia de los tests A/B. Sesgos y cómo evitarlos.
Antes de empezar con el post de hoy, comentaros que Juan Castillo y Víctor Mollá me entrevistaron hace unas semanas en Gurupod, el podcast de Guruwalk. Hablamos de todo un poco, pero sobre todo de cómo hacer producto.
Este viernes, mientras investigaba un posible problema, creé un panel de control comparando el comportamiento de dos grupos de usuarios. Los primeros habían activado una funcionalidad concreta. Los segundos no.
A simple vista, los que la habían activado tenían un comportamiento muchísimo mejor. Interactuaban, convertían y retenían mejor. Sólo había un problema: la funcionalidad no implicaba ningún cambio en la experiencia de usuario.
Se trataba de una opción de configuración que algunos usuarios activaban voluntariamente para compartir sus datos y ayudarnos a mejorar la aplicación. De hecho, mi hipótesis de partida al comenzar an investigar el problema, era que este grupo podría tener un comportamiento peor porque su aplicación consumiría más recursos y ancho de banda.
Lo que estaba observando no era, ni más ni menos, que una de las máximas que cualquiera que trabaje creando producto digital debe aprender lo antes posible: correlación no implica causalidad.
En este caso en concreto, los usuarios que tenían activada esta opción no se comportaban mejor por haberlo hecho. Se comportaban mejor simplemente porque eran mejores usuarios. Eran usuarios ya de por sí lo suficientemente enganchados al producto como para querer contribuir con sus datos a mejorarlo.
En otra ocasión, nos sucedió algo parecido. Desarrollamos un tutorial basado en completar misiones para mejorar el onboarding en la aplicación. Sin embargo, al analizar el experimento correspondiente, observamos que no tenía ningún impacto. Resultó que los usuarios que lo terminaban eran precisamente los que ya venían motivados de casa.
Otro error típico que me he encontrado durante mi carrera es el relacionado con la personalización. En una ocasión detectamos que los usuarios que personalizaban su experiencia retenían mejor, así que tratamos de forzar la personalización durante el proceso de onboarding. En este caso, el resultado fue incluso negativo, porque no ganamos nada con quienes personalizaban por obligación y, de hecho, algunos usuarios abandonaban el proceso por haber añadido esos pasos extra.
Solemos pecar de creyentes. Somos presas de un fuerte sesgo de confirmación y, cuando vemos un comportamiento que mueve la métrica que queremos en la dirección adecuada, pensamos rápidamente en qué podemos hacer para lograr que el resto de usuarios replique ese comportamiento. Pero, como hemos visto, puede haber otras causas por las que se comporten de forma diferente.
Esta es una de las razones por las que los tests A/B son tan importantes. Son una de las mejores formas que tenemos de comprobar si nuestros cambios tienen un impacto real, o bien estamos observando otro tipo de efecto. Por ejemplo, imaginad realizar un cambio en un algoritmo de recomendación en una plataforma de streaming al tiempo que se lanza un estreno que genera un gran número de horas de visualización. Sin el experimento apropiado, podríamos confundirnos pensando que el incremento viene del cambio en el algoritmo cuando en realidad no ha tenido nada que ver.
Así pues, la próxima vez que consideréis realizar un cambio basado en una correlación, tened en cuenta los siguientes puntos:
Correlación no implica causalidad: que dos métricas se muevan en la misma dirección no quiere decir que una cause la otra. Puede haber otros factores implicados y que no hemos tenido en cuenta.
Conoce a tus usuarios: los comportamientos que vemos en los datos están fuertemente influenciados por el tipo de usuario que los genera. Nuestros usuarios más motivados se comportan de forma diferente que el resto.
Experimenta: siempre que puedas, lanza un test A/B para confirmar que el efecto que estás viendo es real y no está influenciado por otros factores.
No fuerces: muy probablemente tus usuarios no sean un grupo homogéneo. No intentes forzar funcionalidades a todos por igual. Identifica los segmentos más relevantes y diseña tu producto teniéndolos en cuenta. Recuerda: Los datos agregados son basura.
Y hasta aquí la entrada de hoy. Si queréis profundizar, aquí os dejo unos cuantos enlaces al respecto:
¡Hasta el domingo que viene!
Muy interesante la reflexión. He cometido este error muchas veces. Solemos tender a buscar causas cuando muchas veces lo que estamos observando son consecuencias. Es tentador pensar que activar la opción de compartir de datos es la causa que provoca que se conviertan en mejores usuarios cuando en realidad se trata de la consecuencia de que ya lo fueran. Nos gustaría que fuera la causa porque eso nos da el control a los que hacemos el producto. Cuando es consecuencia nos quedamos sin palanca.