En un proyecto de Conversion Rate Optimization (CRO) buscamos conseguir un mayor ratio de conversión a través de una mejora en la experiencia de usuario. Normalmente, esto lo podemos hacer de dos formas: bien lanzando un test A/B o multivariante para conocer el resultado de una hipótesis de negocio o haciendo un deploy directamente a producción con una interfaz o experiencia distinta de la que existía hasta el momento. Pero ¿qué opción debemos escoger?
Como norma general, habremos llegado hasta este test después de seguir un formato de trabajo estándar, en el que pasamos por la recolección y el análisis de los datos de comportamiento de los usuarios. En ROCKETROI, adaptamos el framework a cada cliente, pero puede resumirse de la siguiente manera:
Una vez hemos hecho el análisis de lo que hacen los usuarios cuando navegan por nuestra web o aplicación móvil, llegamos a la hipótesis que plantea una mejora en el rendimiento del producto digital. Y esta mejora la podemos ejecutar a través de un test A/B o mediante un lanzamiento a producción normal y corriente.
Como norma general, pasar por un experimento nos asegurará por lo menos un par de ventajas:
Comprobar de forma científica que el cambio en la experiencia de usuario aporta una mejora en el rendimiento del producto. Aunque estemos muy seguros del resultado, cualquier opinión, sin datos, es sólo eso: una opinión. Ese cambio puede también empeorar la conversión de la web.
Conocer en qué medida la versión alternativa mejora a lo que tenemos actualmente.
Pero ¿qué pasa si un test A/B o multivariante no es la mejor opción?
Planteamos los siguientes escenarios en los que puede no salir a cuenta hacer un experimento y, en su lugar, lanzar un cambio a producción:
Cuando el insight es muy claro. Serán muy raras las veces, pero es posible que lleguemos a una conclusión que no tiene lugar a interpretaciones. Hacer un cambio aportará una mejora en la experiencia de usuario y, por lo tanto, podemos hacer un deploy a producción, sin pasar por el proceso de testing. Lo malo es que nunca sabremos el impacto del cambio que estamos haciendo.
Cuando el producto digital ha quedado desfasado. En aquellos casos en los que el producto digital en el que trabajamos necesite una actualización porque se ha quedado atrás, normalmente la mayoría de cambios aportarán una mejor conversión.
Cuando no tenemos suficiente tráfico. Para que los resultados de cualquier test A/B sean representativos, necesitaremos que alcancen la significancia estadística del 95%. Para eso, necesitaremos un volumen de usuarios en particular, distinto para cada experimento. Si la web en la que trabajamos tiene poco tráfico, o la sección del site es visitada pocas veces, deberemos plantearnos si merece la pena hacer un test. ¿Cuánto tardaremos en conseguir datos representativos? En función de eso, será mejor hacer un deploy.
Cuando los cambios son poco medibles. Todo se puede medir, pero algunas cosas mejor que otras. Por ejemplo, las acciones con finalidad de branding suelen medirse a más medio/largo término, o tienen KPIs sujetos a interpretación. Por lo tanto, plantear un test A/B para medir el impacto de un cambio orientado a branding puede no ser la mejor opción.
