Hemos preparado para los lectores de Habra una traducción de un artículo de Michael Kaminsky, ex director de análisis de Harry's. Habla sobre lo que está mal con las pruebas A / B. Comentarios sobre el material de Gleb Sologub, director de análisis de Skyeng.
El concepto de prueba A / B se basa en la suposición fundamentalmente errónea de que hay una solución única que es, en promedio, mejor para todos los clientes. Los analistas deben abandonar la suposición de que su audiencia es homogénea y comenzar a desarrollar sistemas que permitan el uso (y alienten) los resultados de pruebas que no sean binarias.
En las últimas semanas, se han publicado dos artículos muy interesantes sobre interpretaciones no estándar de las pruebas A / B. Uno de los artículos del blog de ingeniería de Uber trata sobre el cálculo del efecto de impacto por cuantiles, y el otro ( del excelente blog StitchFix Data Science ) trata sobre el uso de algoritmos contextuales de bandidos para lograr la personalización.
Ambos artículos son interesantes, pero me parece que tienen demasiada teoría sobre la interpretación e implementación de pruebas y carecen de hechos. Reformulo mi tesis para mayor claridad:
Las pruebas A / B tradicionales se basan en una suposición fundamentalmente errónea. En la mayoría de los casos, la opción A será mejor para algunos subgrupos y la opción B para otros. Al elegir A o B, inicialmente se pierde una combinación cuidadosamente seleccionada de A y B.
Desafortunadamente, aplicar este enfoque a las pruebas, la optimización y el desarrollo de software no es fácil. Esto requiere nuevas herramientas estadísticas, nuevas herramientas para desarrollar y respaldar soluciones de software, así como capacitar a las partes interesadas, si desea que participen en el proceso. En este artículo, daré un ejemplo motivador y luego hablaré sobre algunos de los problemas que encontrará al crear sistemas que se adapten a la nueva realidad. No discutiré los datos estadísticos subyacentes y relacionados con la construcción de este tipo de sistemas (mejor lea el artículo de StitchFix y este artículo de Google ), pero hablaré sobre las oportunidades que veo en los niveles estratégico y arquitectónico.
Ejemplo motivador
Para convencerte de que esto es importante, veamos un pequeño ejemplo. Aunque estas cifras son ficticias, representan perfectamente lo que he visto innumerables veces en la evaluación en tiempo real de las pruebas A / B.
Otra empresa de colchones (EOMK) vende colchones en línea (se puede ver su anuncio en el metro). Quieren probar un formulario de pedido actualizado optimizado para teléfonos. Los diseñadores están un poco preocupados porque, aunque la versión actualizada es menos engorrosa, también transmite menos información durante el proceso de pedido y esto puede afectar negativamente las conversiones de los usuarios con computadoras de escritorio.
El equipo comienza la prueba y obtiene los siguientes resultados:
Maldita sea, no hay diferencia! Intuitivamente, decide compartir el tráfico en su dispositivo móvil y PC.
Wow! La nueva versión ... mostró exactamente lo que esperaban los diseñadores. La situación ha mejorado para los usuarios de dispositivos móviles y peor para los usuarios de PC.
Es malo que nuestra prueba A / B no haya mostrado ningún efecto. Quizás deberíamos enviar a nuestros diseñadores a pensar en una nueva versión del formulario de pedido.
Pero espera! ¿Qué sucede si admitimos una versión móvil optimizada para los usuarios que acceden al sitio por teléfono? ¿Y la versión de escritorio optimizada para usuarios en computadoras de escritorio? ¿Qué pasaría si creáramos una página de destino que funcionaría mejor los fines de semana cuando la gente tiene más tiempo para leer? ¿Qué pasa si creamos un anuncio que funcionó mejor en California en lugar de Massachusetts?
¿Qué pasa si la página web no debería adaptarse a todos a la vez?
Las tareas
Es difícil decir si esta idea es obvia o revolucionaria. Es tan obvio que parece casi estúpido. Pero si observa cómo la mayoría de las empresas desarrollan, prueban y depuran productos de software, resulta que este es un cambio bastante fundamental en el enfoque de los problemas de software.
Muchas compañías todavía tienen una sola versión funcional del sitio web. Se pueden realizar pruebas, pero tan pronto como una de las pruebas gana, la versión perdedora se descarta y aparece la única versión correcta, el "rey de la colina".
Para cubrir toda la diversidad de clientes y usuarios, es necesario desarrollar soluciones de software de una manera fundamentalmente diferente. Necesitamos herramientas nuevas y más avanzadas, y también necesitamos capacitar a los interesados en una nueva forma de pensar.
Hoy en día, tratar de administrar escenarios de uso con tantas variables es muy difícil (si es posible). Dado que administrar tantas opciones es costoso, muchas empresas ni siquiera intentan personalizar su experiencia del cliente. A continuación, hablaré más sobre los problemas y describiré formas de resolverlos.
Herramientas de programación
En nuestro mundo nuevo y valiente, donde brindamos una variedad de contenido a diferentes categorías de usuarios (en proporciones que pueden cambiar con el tiempo), necesitaremos herramientas tanto para el desarrollo como para el análisis de nuestro software.
Parece que la consecuencia más obvia del uso de tal paradigma será un aumento significativo en la cantidad de código en el proyecto. En lugar de eliminar ramas de código obsoletas después de la prueba, tendremos que admitirlas (tal vez para siempre). ¡Esto es horrible!
De hecho, necesitamos hacer que las aplicaciones sean más modulares para que podamos desarrollar, probar, implementar y mantener constantemente nuevas ramas de código (por ejemplo, nuevas versiones para probar).
Para poder dirigir a los usuarios a diferentes ramas del código en función de sus características (potencialmente, la cantidad de ramas del script de usuario puede ser enorme), es necesario desarrollar una arquitectura que admita dicha ramificación. Necesitamos un mecanismo centralizado de toma de decisiones que pueda elegir la ruta para este usuario. También es necesario que los componentes de la ruta sean lo suficientemente intercambiables para guiar libremente al usuario a lo largo de la ruta, incluso si se desarrollaron independientemente uno del otro y sin un solo caso de uso.
Finalmente, sin un solo caso de uso holístico, necesitamos herramientas para que los gerentes y diseñadores de productos puedan imaginar el camino de un cliente en un jardín de caminos divergentes. ¿Cómo presentamos y evaluamos nuevas características? ¿Cómo hacemos un seguimiento de los pasos que siguió este usuario cuando utilizó nuestra aplicación? ¿Cómo podemos evitar que una aplicación se convierta en una masa sin forma de código de espagueti?
Comunicación y formación
Será especialmente difícil para las personas que están lejos del proceso de creación de un producto adoptar esta nueva visión del desarrollo de software. Los gerentes están acostumbrados a cuidar la ruta de un solo usuario, el único sonido de la marca y la misma experiencia universal de interactuar con un cliente. Cuando comenzamos a personalizar la experiencia del usuario, desaparece la oportunidad de hablar sobre una solución de software desde un solo punto de vista.
Necesitamos educar a las partes interesadas sobre el valor de este nuevo enfoque y ayudarlos a pensar sobre secuencias de comandos personalizadas y sonido de marca en este contexto. Es necesario desarrollar métodos para determinar las rutas más comunes. Y brinde a los gerentes las herramientas para estudiar el producto en nombre de un usuario de un determinado subgrupo, para que puedan adquirir experiencia interactuando con un producto personalizado para diferentes usuarios desde diferentes puntos de vista.
Herramientas estadísticas
Lo más probable es que en un mundo sin pruebas A / B, tengamos que deshacernos de muchas herramientas que tradicionalmente hemos utilizado para optimizar las aplicaciones web. Todos nuestros esfuerzos para capacitar a gerentes de producto y especialistas en marketing en el lanzamiento e interpretación de pruebas A / B no serán importantes.
En este nuevo mundo, necesitaremos desarrollar nuevos métodos de investigación y visualización de muestras de diferentes tamaños. Necesitaremos métodos de comparación nuevos y más avanzados para no caer en la trampa de las comparaciones múltiples .
Conclusiones
Teniendo en cuenta la verdadera diversidad en nuestra base de usuarios, podemos mejorar la interacción con una gran cantidad de usuarios, lo cual es muy valioso. Desafortunadamente, como sucede a menudo cuando se cambia el enfoque para el desarrollo y la implementación de tecnologías, estas ventajas son costosas. Tenemos un largo camino por recorrer desde el punto donde estamos ahora, hasta un futuro emocionante y más personalizado, y estoy seguro de que este viaje será emocionante.
Nota del autor:
Excluyo todas las discusiones sobre intervalos de confianza y significación estadística por simplicidad. Lo siento
Comentario de Gleb Sologub, director de análisis de Skyeng
Michael resume las tendencias actuales de personalización y fantasea sobre cuáles deberían ser los medios y métodos de desarrollo y análisis, cuando todos los productos de TI se individualizarán por completo para usuarios específicos.
Hasta ahora, hemos aprendido a personalizar de dos maneras: en primer lugar, creando escenarios separados para diferentes segmentos de usuarios, en segundo lugar, desarrollando soluciones algorítmicas para mostrar contenido personalizado en pasos individuales del embudo.
Entonces, Skyeng ciertamente ha optimizado las versiones móviles del sitio y la plataforma de capacitación, así como varias versiones de estos productos para usuarios de diferentes edades. Además, realizamos pruebas AB y nos dimos cuenta de que los usuarios de diferentes regiones tienen diferentes necesidades, después de lo cual introdujimos una diferenciación de la descripción de marketing según la región.
A los ejemplos de personalización algorítmica, además de los citados por Michael, se pueden agregar tanto las largas y ampliamente utilizadas listas de productos o contenidos recomendados, como los éxitos relativamente recientes en la generación de carteles de películas individuales.
Sin embargo, todo esto se puede hacer mientras se siguen utilizando los métodos de desarrollo y análisis anteriores.
En el mismo futuro que Michael describe, las pruebas AB, tal como son, pueden no valer la pena, pero necesitarán una increíble modularidad de software y algunos métodos analíticos nuevos para crear una variedad infinita de escenarios de usuario completamente individuales .
En Skyeng ya tenemos y estamos expandiendo un equipo de investigadores y analistas que estudian estas tendencias y tratan de aplicarlas para mejorar nuestros productos.