Mejores prácticas para establecer una fuente única de la verdad (SSOT) para las pruebas A/B

Su prueba de CX vive o muere según la calidad de sus datos. No puede formular hipótesis válidas y comprobables utilizando datos cuestionables. Y no puede confiar en los resultados de sus pruebas si no sabe que está buscando métricas precisas.

Es por eso que necesita construir su programa de prueba en torno a un conjunto de datos de fuente única de la verdad (SSOT). Si no puede, incluso la prueba A/B más simple carecerá de valor. Este artículo explora por qué es tan importante establecer un SSOT y comparte algunas de las mejores prácticas probadas en el campo que hemos desarrollado para hacerlo aquí en Kameleoon.

¿Qué es un SSOT?

La toma de decisiones empresariales modernas debe basarse en datos. Mantener un SSOT significa que para la experimentación de CX, o cualquier otra función, se estandariza en una fuente de datos como la "verdad" definitiva en torno a la cual realiza el trabajo de ese equipo e informa las decisiones de su empresa.

Sin un SSOT, corre el riesgo de que sus datos se fragmenten en silos protegidos por diferentes equipos para diferentes funciones. No hay estandarización, consenso ni forma de saber si alguien está tomando decisiones basándose en la mejor información disponible.

Un SSOT no es una tecnología o un sistema en particular. Es una práctica empresarial diseñada para obtener resultados óptimos de las actividades de su equipo. Algunas empresas han ahorrado millones al cambiar a una estrategia de datos SSOT sin siquiera tocar el trabajo subyacente.

Los estudios han demostrado que las métricas de comportamiento del cliente de alta calidad siguen siendo los datos más buscados para informar las decisiones estratégicas. Durante varios años consecutivos, en la encuesta anual de directores ejecutivos de PricewaterhouseCoopers, los directores ejecutivos lo califican como la métrica más importante que desean para la planificación estratégica.

¿Qué son las pruebas A/B?

Las pruebas A/B son un método para experimentar con sitios web, aplicaciones móviles o anuncios mediante la comparación del rendimiento de una versión original (la versión A o de control) con una versión B modificada. El objetivo es recopilar datos de rendimiento para cada uno, realizar análisis estadísticos y determinar, en función de los datos, qué versión funcionó mejor.
Las pruebas A/B funcionan para probar más que solo elementos de una página web. Por ejemplo, puede usarlo para optimizar precios, validar características de productos y personalizar sitios web para diferentes segmentos de visitantes. Además, las pruebas A/B son la base de muchas otras técnicas de optimización de CX, incluidas las pruebas multivariadas, la recomendación de productos y la orientación basada en perfiles.

¿Quién necesita un SSOT para sus pruebas?

Los equipos de experimentación navegan a través de los datos generados en sus plataformas de análisis, CRM, plataformas de prueba y más. Necesitan establecer un SSOT para realizar pruebas y aclarar lo que quieren hacer sus equipos. Consideremos un ejemplo.

Uno de los clientes de Kameleoon lanzó una campaña para optimizar la función de búsqueda de su sitio web. Realizaron pruebas del lado del servidor que involucraron el seguimiento del tráfico a una página de acceso.

Pero se encontraron con un problema al que se enfrentan muchos programas de experimentación: los datos de Google Analytics mostraban un número de visitas a la página y su herramienta de experimentación mostraba otro. La diferencia fue de más del 9 por ciento.

Al ser un sitio web de comercio electrónico con más de un millón de visitantes al mes, la decisión de en qué conjunto de datos confiar marcó una gran diferencia en los informes de KPI de la empresa. Si bien algunas marcas medianas y empresariales pueden ignorar las disparidades de hasta el 10 por ciento en las estadísticas de visitantes, una disparidad del 9 por ciento en los datos puso nervioso al equipo de experimentación de esta empresa.

Este equipo acababa de obtener la aceptación de su programa de experimentación, incluido un presupuesto para invertir en herramientas como Kameleoon. Esperaban pruebas con conclusiones claras. En cambio, la precisión de sus datos estaba en duda. Necesitaban establecer un SSOT.

Ayudamos a esta empresa a limpiar su seguimiento de datos de visitantes, establecer un SSOT y obtener los resultados de las pruebas que necesitaban para crecer. Para ello, les ayudamos a adoptar siete prácticas recomendadas de SSOT. Compartimos esas mejores prácticas aquí porque cualquier equipo de CX que busque discutir sus datos de prueba y aprovechar al máximo su programa de experimentación puede usarlos para crecer.

Las mejores prácticas para eliminar las discrepancias en los datos de prueba y establecer un SSOT

1. Antes de hacer cualquier otra cosa, realice una prueba A/A

Mientras que una prueba A/B compara una versión antigua con una nueva de su producto o página, una prueba A/A compara lo similar con lo similar. Por qué querrías hacer esto? Para que puedas comparar los datos generados por cada plataforma de monitoreo.

En la prueba A/A, ambas variaciones son iguales, pero los usuarios que las vean serán diferentes:

como actuar

Antes de realizar cualquier prueba A/B seria o implementar una nueva implementación en la que desee recopilar datos, ejecute una prueba A/A para calibrar. En un mundo perfecto, su prueba A/A arrojará resultados idénticos. En realidad, eso rara vez sucede, pero aún aprenderá con cuánta discrepancia está lidiando.

Por ejemplo, ejecutar una prueba A/A le permite ver qué métricas obtiene Google Analytics en comparación con su herramienta de prueba en las mismas sesiones, usuarios, visitas, conversiones o cualquier métrica que desee medir.

2. Realice un seguimiento de los visitantes y las visitas de la misma manera en todas sus herramientas

La cantidad de visitantes o visitas rastreadas por sus herramientas de análisis nunca coincidirá con precisión con los usuarios y las sesiones. Sin embargo, puede asegurarse de que las visitas se cuenten de la misma manera en sus plataformas analíticas y A/B para disminuir la discrepancia.

En Google Analytics, hay dos formas de finalizar una visita:

• Caducidad basada en el tiempo: aquí, la sesión caduca después de 30 minutos de inactividad o a la medianoche. Mientras que, por ejemplo, en Kameleoon, es después de 30 minutos de inactividad.

• Cambio de campaña : si el mismo visitante llega a través de una campaña, se va después de 2 minutos y luego regresa a través de una campaña diferente 2 minutos después, Google Analytics contará dos visitas. Algunas herramientas de prueba A/B verán esto como uno.

como actuar

Verifique cómo se cuentan los visitantes y las visitas en su herramienta de análisis y asegúrese de que sea lo mismo para su herramienta de prueba. O que puedes cambiarlo. En Kameleoon, recomendamos utilizar su plataforma de análisis como única fuente de información.

En GA, puede editar cuánto tiempo transcurre hasta que se agota el tiempo de espera de las sesiones y las campañas en Configuración de la sesión.

¿Por qué? Los SSOT deben definirse a nivel organizacional. Entonces, incluso si su equipo de prueba pasa todo el día trabajando con datos en su plataforma de prueba, es posible que otros equipos aún necesiten hacer referencia a datos de GA para otros fines. Configure el SSOT para que sea el conjunto de datos al que hace referencia la gama más amplia de equipos de su organización.

3. Cree filtros de navegador y versión en su herramienta de análisis

Muchas plataformas de pruebas A/B no se ejecutan en Internet Explorer, por lo que cualquier visita en ese navegador se excluye automáticamente de los informes de experimentos. Pero IE aún podría causar una discrepancia de datos si se dirige a grandes organizaciones heredadas que lo utilizan.

Otro posible problema de seguimiento es que Google Analytics es compatible con todas las versiones del navegador, mientras que las herramientas de prueba A/B suelen mantener una compatibilidad total solo con las últimas versiones.

como actuar

En Google Analytics, cree filtros personalizados basados ​​en los navegadores y las versiones de navegador que le interesan para que todas las plataformas coincidan. haces esto en

Por ejemplo, en Ver, así es como excluiría una versión anterior de Google Chrome:

4. Filtra el tráfico problemático en todas tus herramientas

Mantenga su conjunto de datos SSOT lo más limpio posible al recopilar solo datos de miembros legítimos de la audiencia. No desea enturbiar sus datos con bots, trolls, errores de seguimiento u otro tráfico atípico. No se preocupe por las disminuciones de volumen, la calidad de sus resultados aumentará.

como actuar

Las herramientas avanzadas de prueba A/B ofrecen varias configuraciones de filtrado de bots listas para usar. Por ejemplo, pueden eliminar automáticamente el tráfico de las estadísticas recopiladas si detectan un comportamiento atípico o si la sesión cae en una condición de actividad sospechosa.

Por otro lado, si usa GA, depende de usted decidir cómo detectar y excluir el tráfico de bots de sus datos analíticos mediante filtros. Como referencia, aquí hay algunas condiciones que quizás desee excluir.

• Duración de la visita > 120 minutos
• Duración de la visita < 100 milisegundos
• Número de eventos (conversiones, clics, segmentación, producto, vista de página, etc.) > 10K

También desea excluir el tráfico interno de su organización. Recuerde, el objetivo de crear este conjunto de datos SSOT es tener una fuente definitiva de datos sobre sus clientes reales, no sobre sus colegas.

Para filtrar el tráfico interno en GA, vaya a Panel de administración > Todos los filtros y cree un nuevo filtro. Establezca el tipo de filtro en 'indefinido'. Luego, agregue los rangos de IP internos que desea excluir.

5. Evita los bloqueadores de anuncios

Muchos visitantes usan bloqueadores de anuncios como Adblock, Ghostery y uBlock. Algunos bloqueadores de anuncios también pueden bloquear los rastreadores del lado del cliente, incluidos los eventos de análisis de las herramientas de experimentación.

Si una parte significativa de sus visitantes tienen bloqueadores de anuncios habilitados en su navegador, existe una alta probabilidad de que la cantidad de visitas registradas varíe entre su herramienta de prueba A/B y su plataforma de análisis.

como actuar

Algunas plataformas pueden proporcionar direcciones URL de solicitud de seguimiento "en las instalaciones" que les permiten evitar ser bloqueadas por bloqueadores de anuncios. Aquí, el seguimiento ocurre del lado del servidor, por lo que el bloqueo de código del lado del cliente, como el de un bloqueador de anuncios, no detiene el seguimiento legítimo. Actívalo en todas las plataformas posibles.

Otra forma de comprender mejor la discrepancia entre sus plataformas de análisis y prueba es enviar un evento a su plataforma de análisis después de que se haya cargado su herramienta de prueba. Eso debería darle una idea clara del porcentaje de visitantes que usan bloqueadores de anuncios que bloquean su herramienta de prueba A/B. Luego, deberá filtrar su tráfico para excluir a los visitantes que usan bloqueadores de anuncios.

6. Instale sus herramientas en todas las mismas páginas

La colocación de fragmentos es una causa raíz común de las discrepancias de datos, especialmente si desea ejecutar un experimento que apunte a un sitio completo. La razón es que muchas herramientas de experimentación tratan el "sitio completo" como todas las páginas que contienen su fragmento de código. Desafortunadamente, eso podría incluso incluir su sitio de prueba si tiene fragmentos copiados allí.

como actuar

Si aún no lo ha hecho, ahora es un buen momento para ejecutar esa prueba A/A para calibrar sus plataformas. Luego, asegúrese de que todas sus herramientas estén implementadas en las mismas páginas.

Una forma de identificar si no lo son es desglosar sus datos por las URL de las páginas visitadas. Esto le mostrará todas las URL principales donde se ejecutó el experimento para que pueda identificar aquellas donde su herramienta de prueba no debería haberse cargado. Así es como se ve esta opción en Kameleoon:

Pensamientos finales

Después de un análisis cuidadoso, Kameleoon determinó que el cliente con una discrepancia de datos encontró ese último problema. Google Analytics y su herramienta de prueba no se estaban ejecutando en las mismas páginas.

Mientras que GA rastreó todo el tráfico que iba a su página de resultados de búsqueda, configuraron su herramienta de prueba con un parámetro más limitado: el experimento contó las visitas a la página de acceso solo después de una búsqueda en la barra de búsqueda.

Si bien ambas páginas tenían el mismo aspecto, las URL eran diferentes, lo que creaba una discrepancia de datos. Sin embargo, una vez resueltos, tenían un SSOT confiable para probar datos y generarían muchos conocimientos valiosos.

Al reconocer dónde la configuración lista para usar en su herramienta de prueba no se alinea con su seguimiento analítico, puede decidir qué cantidad de visitantes informar o cómo usar su configuración para minimizar la diferencia.

Elimine las discrepancias, establezca una única fuente de información y reúna a sus equipos en torno a un conjunto de datos común. Establecer un SSOT es el primer paso para realizar pruebas mejores, más confiables y más perspicaces.