Ver el primer post de esta serie aquí
¡Bienvenido de nuevo! Como mencionamos en el primer post, la organización de productos ha decidido mejorar la parte de nuestro proceso de desarrollo de productos que se basa en los datos. Hace tiempo que contamos con una forma sólida de incorporar los aportes cualitativos de los usuarios a través de Descubrimientos Dirigidos; ahora hemos dado prioridad a ayudar a nuestros equipos de desarrollo multifuncionales a recopilar datos sobre cómo sus esfuerzos están afectando las métricas importantes para el negocio.
Al final del artículo anterior, identificamos las necesidades de una plataforma de experimentación. Concretamente, determinamos que se necesitaban varias iniciativas para crear una cultura de la experimentación.
Necesidades -> Soluciones
- Sólo déjame probar ——; fácil de probar tanto en el lado del cliente como en el del servidor
- Claridad de la métrica – …; Análisis riguroso y estándar de nuestras métricas clave
- ¿Puedo encontrar que la investigación —-; Un repositorio central de conocimientos de resultados
En este post, exploramos las opciones de construcción vs. compra, y describimos cómo estamos combinando soluciones de terceros con una pequeña construcción interna del estilo de producto mínimo viable (o del estilo MVP) para abordar las necesidades de experimentación.Pero primero, demos un paso atrás.la experimentación web originalmente era el reino de los vendedores y los equipos de optimización de la conversión que buscaban aumentar el número de usuarios que se inscribían en una prueba, hacían una compra o simplemente enviaban un formulario web.
Como estos primeros experimentos se basaron en cambios de diseño en una sola página, las pruebas del lado del cliente (o basadas en JavaScript) eran estándar y siguen siendo populares hoy en día.esencialmente, hay un WYSIWYG que permite cambiar fácilmente los elementos de la página como la tipografía, la copia, el arreglo, etc. sin la ayuda de un ingeniero de software.entonces la diferencia entre A y B se sirve en el navegador del usuario.
A medida que las experiencias en la web se volvieron más algorítmicas a través de características como la búsqueda y las recomendaciones, las pruebas del lado del servidor se volvieron más comunes porque las diferencias en las soluciones deben ser atendidas desde el propio servidor web. Mientras que las pruebas del lado del servidor se ofrecen a través de banderas de características y requieren el trabajo de ingenieros, las soluciones del lado del cliente permiten a los gerentes de producto y a los diseñadores lanzar pruebas a través de un editor WYSIWYG.
Como se ha mencionado, muchos gerentes de producto (PMs) expresaron una necesidad crítica de experimentar rápidamente, y se requerirían pruebas tanto del lado del cliente como del servidor, ya que gran parte de la experiencia está basada en datos.para abordar esa necesidad, así como la necesidad de un análisis riguroso y un repositorio central de conocimiento para albergar los resultados, surgió un enigma clásico: ¿construimos o compramos? Uno de nuestros marcos favoritos en este espacio es el de Kent McDonald y Neil Nickolaisen, llamado el Modelo de Alineación Basado en Propósitos, que se presenta en su libro Stand Back and Deliver: Acelerando la agilidad de los negocios .
El marco establece que si algo puede ser un diferenciador del mercado y es fundamental para el negocio, entonces es un momento particularmente bueno para poseer esa experiencia en la empresa y construir una solución que se adapte a las necesidades particulares de la empresa. En , el desarrollo de productos basado en datos es fundamental para nuestro negocio y un diferenciador del mercado, lo que indica que construir y poseer esa experiencia en la empresa tiene sentido. Sin embargo, hay herramientas de prueba A/B convincentes que nos interesaba explorar. Incluso si en última instancia, usted mismo construye la solución, hablar con los proveedores agudiza su pensamiento.
Evaluación de proveedores
Como parte del proceso de descubrimiento, investigamos a dos de los principales proveedores de este espacio de pruebas con la ayuda de nuestros equipos de arquitectura, ciencia de datos y analistas de productos: Optimizely y Adobe Target.Optimizely tiene dos productos principales, Web y Full Stack, que proporcionan herramientas para pruebas del lado del cliente y del lado del servidor, respectivamente. Tenemos muchos colegas que han aprovechado sus herramientas en el pasado, tienen un respetado motor de estadísticas y proporcionan un producto de primera calidad que puede costar más de 100.000 dólares al año. Fue impresionante trabajar con ellos y su producto tenía muchas características que nos gustaron: planificación de pruebas, parada temprana, SDKs polígloto y un procedimiento de aleatorización que no requiere llamadas http.
En , nuestros datos de clicks de usuarios se recogen a través de Adobe Analytics (AA). ha invertido mucho aquí en los últimos dos años, de tal manera que ahora podemos entender ampliamente el comportamiento de los usuarios a través de la aplicación. Aquí es donde surgieron las dificultades con la solución de Optimizely. Como queríamos que su motor de estadísticas procesara métricas basadas en nuestros datos de AA, esta integración fue crítica. Lo que encontramos fue que su motor era capaz de procesar métricas basadas en eventos como las evaluaciones tomadas y los autores seguidos, pero no tiene la capacidad de informar sobre las sesiones, visitas o juzgar las pruebas por métricas de retención basadas en el tiempo. Esto significa que no pudimos utilizar Optimizely y también priorizar métricas como la retención de usuarios, las visitas por visitante y el tiempo de contenido consumido, que son fundamentales para evaluar nuestra experiencia de usuario.la incertidumbre en torno al tiempo y la inversión técnica necesarios para que esto funcione fue demasiado para soportar.
Tengan en cuenta que esto puede ser una lección para la gente del producto SaaS que está haciendo experimentos. Históricamente, las soluciones de prueba se centraban en el lado del cliente y en métricas basadas en eventos de marketing como la conversión. Aunque cada vez es más común que los proveedores se centren en soluciones del lado del servidor y en métricas de SaaS en torno a la retención de usuarios, encontramos que las ofertas de terceros que hay son mucho menos robustas.
El otro proveedor que investigamos de cerca fue Adobe Target, el cual ha sido implementado y amado en nuestro departamento de mercadeo.Aquí la integración de Adobe Analytics es fácil, ya que cualquier métrica y segmento con el que trabajes en AA puede ser usado para juzgar las pruebas en Adobe Target.Del lado del cliente, como con la mayoría de las ofertas, el editor Target WYSIWYG facilita la manipulación de elementos web como la tipografía y la rápida implementación de pruebas A/B en un porcentaje deseado de usuarios.
En el lado del servidor, sin embargo, Adobe Target era menos atractivo. Si bien habían estado invirtiendo en su oferta del lado del servidor, se basa en llamadas http para aleatorizar a los usuarios en las experiencias A vs. B. En otras palabras, un servidor web debe llegar a través de una solicitud http a un servidor de Adobe para determinar la asignación de un determinado userhandle a la variante A vs. B.
Este tipo de llamadas http nos dan acidez estomacal desde la perspectiva de la fiabilidad de la ingeniería. Es fundamental para el PS que la experiencia del usuario dependa de la menor cantidad de dependencias de terceros posible (para que podamos evitar los tiempos de inactividad y de respuesta asociados).Debido a esto, cualquier nuevo proveedor con este requisito se enfrenta inmediatamente a un fuerte viento en contra.Tras una investigación más profunda, los tiempos de respuesta del lado del servidor de Adobe Target fueron inaceptables para nuestra experiencia de usuario. Sin embargo, determinamos que la herramienta WYSIWYG del lado del cliente de Adobe Target sería beneficiosa en el sentido de que permitiría a nuestros gerentes de producto y diseñadores crear rápidamente experimentos, especialmente porque muchos obstáculos de configuración ya habían sido superados por su uso a largo plazo en nuestra organización de marketing.
Solución técnica global
Ninguna de las soluciones de los proveedores por sí sola satisfizo nuestras necesidades, así que decidimos una mezcla de herramientas actuales y pequeñas inversiones de construcción para ayudar a escalar la experimentación a través de la organización del producto. Aquí nos centraremos en describir las soluciones relacionadas con 1) la aleatorización en A vs B; 2) el motor de estadísticas que proporcionará análisis estándar y rigurosos; y 3) la propia sede de los experimentos, que proporcionará a los usuarios internos la capacidad de revisar rápidamente el progreso de sus pruebas en vivo y aprender de los resultados de pruebas anteriores en toda la organización.
Aleatorización y seguimiento
Fundamental para las pruebas rigurosas de A/B es el procedimiento de aleatorización, que permite crear grupos de control y tratamiento sólidos que se distribuyen uniformemente entre diversos atributos de los usuarios. Por ejemplo, hay algunos usuarios que utilizan mucho nuestra función de notas cuando usan -para la mayoría de los experimentos, no nos importan específicamente las notas, por lo que una aleatorización simple eficaz tendrá una distribución representativa en los grupos de control y tratamiento de los usuarios que sí y que no utilizan las notas. Un buen instrumento de aleatorización también permite seleccionar a los usuarios para el experimento en su conjunto por el manejo de los usuarios o por criterios.
En el lado del servidor, LaunchDarkly ha sido nuestra herramienta de marcado de características para el lanzamiento de productos durante más de un año. Tiene varias características agradables que lo hacen apropiado para las pruebas del lado del servidor:
- Permite fácilmente aleatorizar a los usuarios en grupos de control vs. grupos de prueba para web y móvil
- Proporciona despliegues controlados independientes del objetivo
- Ofrece SDKs polígloto, esenciales para nuestros equipos políglotos
- No requiere llamadas http a los servidores de LaunchDarkly porque el SDK, si lo usas, depende de su estado de almacenamiento para evaluar las banderas
Del lado del cliente, Adobe Target proporciona varios beneficios:
- Nos permite manipular rápidamente los elementos de la web como la tipografía, el estilo, los colores y el diseño
- Permite a los PM y diseñadores lanzar pruebas sin recursos de ingeniería
- Ofrece pruebas específicas dirigidas a segmentos particulares de usuarios de AA (como los usuarios que han hecho X)
Adobe Target, al igual que LaunchDarkly, se utilizará principalmente para los trabajos de seleccionando usuarios en los experimentos, y asignándolos en grupos de prueba específicos.
Para asegurarse de que estos experimentos son rastreados coherentemente desde una perspectiva de Adobe Analytics, el equipo de análisis del producto ha desarrollado un método experimentTrack, que es un evento Javascript que es escuchado por nuestro sistema de gestión de etiquetas, que luego ejecuta el seguimiento del experimento en varios de nuestros sistemas de procesamiento de datos. Esto hace que AA no sólo capture datos estandarizados de aplicación cruzada sobre el comportamiento del usuario después de entrar en un experimento, sino también datos sobre quién fue asignado a qué grupo de experimentos. Aunque parte de este seguimiento podría hacerse en bases de datos de desarrolladores, la naturaleza autónoma de nuestros equipos (y el hecho de que cada equipo almacena datos en su propia base de datos) requeriría una inversión mucho mayor para lograr nuestros objetivos de experimentación.
A pesar de que entre el 5 y el 8% de nuestros usuarios bloquean las herramientas de análisis web con sus navegadores, nuestra implementación actual de Adobe Analytics nos proporciona datos estandarizados en todas las partes de la aplicación, y proporciona suficientes datos para sacar conclusiones significativas sobre la población de usuarios de PS en general.tener esta recopilación de datos estandarizados a través de AA nos permite ejecutar una prueba A/B en una esquina de la aplicación y medir la influencia de esa prueba en el comportamiento de seguimiento del usuario a través de la aplicación. Debido a esto, y aunque la solución v1 no es perfecta, estamos enrutando todos los datos del experimento a través de Adobe Analytics.
El motor de estadísticas
Aunque hay varios enfoques para las estadísticas de los experimentos A/B, vamos a empezar de forma sencilla y centrarnos en las estadísticas de los frecuentadores con pruebas de longitud fija. Mientras que los métodos bayesianos y las pruebas de hipótesis secuenciales proporcionan algunos beneficios intrigantes, considerando nuestras otras frutas de baja altura, vamos a empezar de forma sencilla desde la perspectiva de las estadísticas. Una vez que estos conductos de datos estén en su lugar y hayamos obtenido retroalimentación en esta primera iteración, estaremos abiertos a cambiar nuestro marco de análisis.
La primera versión del motor de estadísticas se basará en un repo de Python, respaldado por pruebas de unidad e integración continua, que se despliega a través de docker y produce resultados cada hora. En general, el motor proporcionará formas estándar de preprocesar los datos, definir métricas y computar los resultados de la prueba. En general, proporciona varios beneficios:
- Definición común de la métrica
- Estandarización del análisis de los experimentos
- Reproducibilidad del análisis
- Visibilidad en el proceso
El motor tiene la tarea de evaluar todas las pruebas A/B del producto por una de las pocas métricas del núcleo. Para gran parte de nuestra organización, eso será la retención de usuarios.
Tenga en cuenta que LaunchDarkly no proporciona análisis del comportamiento del usuario después de que el usuario atraviese la bandera de la característica y Adobe Target tampoco proporciona métricas de retención robustas, por lo que el motor de estadísticas proporcionará información sobre los experimentos y la estandarización en las pruebas tanto del lado del cliente como del servidor.
Experimentos HQ
En el primer post de esta serie destacamos el hecho de que los PMs y sus equipos luchan por encontrar la comprensión de los experimentos mientras su prueba está en vivo y después de que la prueba ha terminado. En el pasado, los espacios de trabajo de Adobe Analytics se habían utilizado de manera provisional, pero este fue típicamente el resultado: «Bien, veo que las visitas por visitante son mayores para B en comparación con A, pero ¿es eso significativo?» Para ayudar a resolver esto, estamos construyendo un MVP de una plataforma de experimentos que funcionará como sede de experimentación. La primera versión será esencialmente un tablero que presentará los resultados de todos los experimentos de una manera estándar, accesible a través de un dominio interno de fácil acceso.
Aunque habíamos contemplado hacer esto en Tableau, decidimos empezar a través de una aplicación web, de manera que tengamos la máxima flexibilidad y podamos eventualmente traspasarla a un equipo dedicado a la experiencia del producto.En un principio, esta aplicación web se utilizará para presentar resultados estandarizados tanto para pruebas en vivo como para pruebas concluidas, y actuará como un repositorio de conocimientos en el sentido de que centraliza y da formato a toda la documentación de las pruebas, recogiendo los detalles de las pruebas, guiando la elección de la métrica, alertando cuando las pruebas alcanzan la significación, etc.) a través de una base de datos transaccional dedicada exclusivamente a ese fin.
Figura 1: Una maqueta temprana de la plataforma de experimentos
En general, la patineta de nuestra solución casera incluirá LaunchDarkly para pruebas del lado del servidor, Adobe Target para pruebas del lado del cliente, Adobe Analytics para análisis web, un motor de estadísticas casero, y una plataforma de experimentos centralizada construida en una aplicación web.
Debemos reiterar que el objetivo de este proyecto es construir una cultura de la experimentación y facilitar que los equipos de producto experimenten de forma segura, rápida y rigurosa.Fuera de las prioridades técnicas que hemos descrito anteriormente, hay una importante pieza cultural en este proyecto, que dedicaremos a un futuro post. Mientras tanto, ¡felices pruebas!
Categorías: prácticasTags: descubrimiento dirigido, experimentos