Cómo monitorear la calidad de los datos: una guía detallada

Prevenir un error en la recopilación de datos es más fácil que lidiar con sus consecuencias. La sagacidad de sus decisiones comerciales depende de la calidad de sus datos. En este artículo, le decimos cómo verificar la calidad de los datos en todas las etapas de la recopilación, desde la declaración de trabajo hasta los informes completos.

Desafortunadamente, muchas empresas que gastan recursos sustanciales en almacenar y procesar datos aún toman decisiones importantes basadas en la intuición y sus propias expectativas en lugar de en los datos.

¿Por qué sucede eso? La desconfianza hacia los datos se ve exacerbada por situaciones en las que los datos brindan una respuesta que no concuerda con las expectativas del tomador de decisiones. Además, si alguien ha encontrado errores en los datos o informes en el pasado, se inclina a favorecer la intuición. Esto es comprensible, ya que una decisión tomada sobre la base de datos incorrectos puede hacerle retroceder en lugar de hacerlo avanzar.

Imagina que tienes un proyecto multidivisa. Su analista configuró Google Analytics en una moneda y el especialista en marketing a cargo de la publicidad contextual configuró la importación de costos a Google Analytics en otra moneda. Como resultado, tiene un retorno de la inversión publicitaria (ROAS) poco realista en los informes de su campaña publicitaria. Si no nota este error a tiempo, puede deshabilitar las campañas rentables o aumentar el presupuesto de las que generan pérdidas.

Además, los desarrolladores suelen estar muy ocupados y la implementación de la analítica web es una tarea secundaria para ellos. Al implementar una nueva funcionalidad, por ejemplo, un nuevo diseño para una unidad con accesorios, los desarrolladores pueden olvidarse de verificar que los datos se recopilan en Google Analytics. Como resultado, cuando llega el momento de evaluar la efectividad del nuevo diseño, resulta que la recopilación de datos se interrumpió hace dos semanas. Sorpresa.

Imagina que has cometido un error durante la fase de especificación. Si lo encuentra y lo corrige de inmediato, la solución será relativamente económica. Si el error se revela después de la implementación, al generar informes o incluso al tomar decisiones, el costo de corregirlo será muy alto.

La recopilación de datos generalmente consta de cinco pasos clave:

1. Formular un desafío empresarial. Digamos que necesita evaluar la eficiencia de un algoritmo para seleccionar productos en un bloque de recomendaciones.
2. El analista o responsable de la recolección de datos diseña un sistema de métricas para ser rastreado en el sitio.
3. La persona configura Google Analytics y Google Tag Manager.
4. El que envía términos de referencia para que los desarrolladores los implementen.
5. Una vez que el desarrollador implementa las métricas y configura la recopilación de datos, el analista trabaja con los informes.

En casi todas estas etapas, es muy importante verificar sus datos. Es necesario probar la documentación técnica, la configuración de Google Analytics y Google Tag Manager y, por supuesto, la calidad de los datos recopilados en su sitio o en su aplicación móvil.

Antes de ir a cada paso, echemos un vistazo a algunos requisitos para la prueba de datos:

• No se puede probar sin herramientas. Como mínimo, deberá trabajar con la consola del desarrollador en un navegador.
• No hay un resultado esperado abstracto. Necesitas saber exactamente con qué deberías terminar. Siempre tenemos un determinado conjunto de parámetros que debemos recopilar para cualquier interacción del usuario con un sitio. Y sabemos los valores que deben tomar estos parámetros.
• Es necesario un conocimiento especial. Como mínimo, debe estar familiarizado con la documentación de las herramientas de análisis web que utiliza, la práctica y la experiencia de los participantes del mercado.

Como hemos mencionado, es mucho más fácil corregir un error si lo detecta en las especificaciones. Por lo tanto, la verificación de la documentación comienza mucho antes de la recopilación de datos. Averigüemos por qué necesitamos verificar su documentación.

Propósitos de la documentación de prueba:

• Corrija los errores con poco esfuerzo. Un error en la documentación es solo un error en el texto escrito, por lo que todo lo que tiene que hacer es realizar una edición rápida.
• Evite la necesidad de cambios en el futuro que puedan afectar la arquitectura del sitio/aplicación.
• Proteger la reputación del analista. Un instrumento con errores en el desarrollo podría poner en duda la competencia de la persona que lo redactó.

Errores más comunes en las especificaciones:

1. Errores tipográficos. Un desarrollador puede copiar el nombre de los parámetros sin leerlos. No se trata de errores gramaticales o de ortografía, sino de nombres incorrectos de parámetros o valores que contienen estos parámetros.
2. Ignorar campos al rastrear eventos. Por ejemplo, se puede ignorar un mensaje de error si un formulario no se envió correctamente.
3. Nombres de campo no válidos y no coinciden con el esquema de comercio electrónico mejorado. La implementación de comercio electrónico mejorado con una variable dataLayer requiere una documentación clara. Por lo tanto, es mejor verificar todos los campos dos veces al redactar sus especificaciones.
4. No tiene soporte de moneda para un sitio de varias monedas. Este problema es relevante para todos los informes relacionados con los ingresos.
5. Los límites de aciertos no se tienen en cuenta. Por ejemplo, digamos que puede haber hasta 30 productos diferentes en una página de catálogo. Si transferimos información sobre vistas al mismo tiempo para todos los productos, es probable que no se transfiera el hit en Google Analytics.

El siguiente paso después de verificar su documentación técnica es verificar su configuración de Google Analytics y Google Tag Manager.

¿Por qué probar la configuración de Google Analytics y Google Tag Manager?

• Asegúrese de que los parámetros sean procesados ​​correctamente por los sistemas de recopilación de datos. Google Analytics y Google Tag Manager se pueden configurar en paralelo con la implementación de métricas en su sitio. Y hasta que el analista termine, los datos no aparecerán en Google Analytics.
• Facilite la prueba de métricas incrustadas en el sitio. Solo necesitarás concentrarte en parte del trabajo del desarrollador. En la etapa final de X, deberá buscar la causa del error directamente en el sitio, no en la configuración de la plataforma.
• Bajo costo de reparación ya que no hay necesidad de involucrar a los desarrolladores.

Errores más comunes en Google Analytics:

1. No se creó una variable personalizada. Esto es especialmente relevante para las cuentas de Google Analytics 360, que pueden tener hasta 200 métricas y 200 parámetros. En ese caso, es muy fácil perder uno.
2. El ámbito de acceso especificado no es válido. No podrá detectar este error durante la fase de revisión de la capa de datos o al revisar el hit que está enviando, pero cuando cree el informe, verá que los datos no se ven como se esperaba.
3. Obtiene un duplicado de un parámetro existente. Este error no afecta los datos que se envían, pero puede causar problemas al verificar y generar informes.

Errores más comunes en Google Tag Manager:

1. No se han agregado parámetros, como la etiqueta de Universal Analytics o la variable de configuración de Google Analytics.
2. El índice de la etiqueta no coincide con el parámetro de Google Analytics, lo que genera el riesgo de que los valores se transfieran a parámetros incorrectos. Por ejemplo, supongamos que especificó el índice del parámetro de número de usuarios en GTM para el parámetro de calificación del artículo. Es probable que este error se encuentre de inmediato al crear informes, pero ya no podrá influir en los datos recopilados.
3. Nombre de variable no válido especificado en la capa de datos. Cuando cree una capa de datos, asegúrese de especificar con qué nombre se encontrará la variable en la matriz de capa de datos. Si escribe o escribe otro valor, esta variable nunca se leerá de la capa de datos.
4. El seguimiento de comercio electrónico mejorado no está habilitado.
5. El activador de inicio no está configurado correctamente. Por ejemplo, la expresión regular para activar X está escrita incorrectamente o hay un error en el nombre del evento.

La última etapa de prueba es probar directamente en el sitio. Esta etapa requiere más conocimientos técnicos porque deberá observar el código, verificar cómo está instalado el contenedor y leer los registros. Por lo tanto, debe ser inteligente y utilizar las herramientas adecuadas.

¿Por qué probar métricas incrustadas?

• Verifique que lo implementado cumpla con las especificaciones y registre cualquier error.
• Compruebe si los valores a enviar son adecuados. Verifique que los parámetros estén transmitiendo los valores a transmitir. Por ejemplo, la categoría de bienes no pasa su nombre en su lugar.
• Dar retroalimentación a los desarrolladores sobre la calidad de la implementación. Según estos comentarios, los desarrolladores pueden realizar cambios en el sitio.

Los errores más comunes:

1. No todos los escenarios están cubiertos. Por ejemplo, digamos que se puede agregar un artículo al carrito en el producto, catálogo, promoción o página maestra, es decir, en cualquier lugar donde haya un enlace al artículo. Con tantos puntos de entrada, puede perderse algo.
2. La tarea no está implementada en todas las páginas. Es decir, para algunas páginas o alguna partición/directorio, los datos no se recopilan en absoluto o solo se recopilan parcialmente. Para prevenir tales situaciones, podemos elaborar una lista de control. En algunos casos, podemos tener hasta 100 comprobaciones para una función.
3. No todos los parámetros están implementados; es decir, la capa de datos solo se implementa parcialmente.
4. El esquema de capa de datos para el comercio electrónico mejorado no funciona. Esto es especialmente cierto para eventos como agregar artículos al carrito, moverse entre los pasos de pago y hacer clic en los artículos. Uno de los errores más comunes en la implementación de comercio electrónico mejorado es la falta de corchetes en la matriz Productos .
5. El dataLayer usa una cadena vacía en lugar de nulo o indefinido para poner a cero el parámetro. En este caso, los informes de Google Analytics contienen líneas vacías. Si usa nulo o indefinido, esta opción ni siquiera se incluirá en el hit que está enviando.

Herramientas que utilizamos para probar los datos:

• Extensión de Chrome del depurador de Google Analytics
• Depurador GTM, que puede usar para habilitar el modo de vista previa en Google Tag Manager
• El comando dataLayer en la consola del desarrollador
• La pestaña Red en la consola del desarrollador
• Extensión de Google Tag Assistant para Chrome

Echemos un vistazo más de cerca a estas herramientas.

Para comenzar, debe instalar esta extensión en su navegador y habilitarla. Luego abra la ID de la página y vaya a la pestaña Consola. La información que ve es proporcionada por la extensión.

Esta pantalla muestra los parámetros que se transmiten con aciertos y los valores que se transmiten para esos parámetros:

También hay un bloque de comercio electrónico extendido. Puede encontrarlo en la consola como ec :

Además, aquí se muestran mensajes de error, como por ejemplo, por exceder el límite de tamaño de visita.

Si necesita verificar la composición de la capa de datos, la forma más fácil de hacerlo es escribir el comando capa de datos en la consola:

Aquí están todos los parámetros que se transmiten. Puedes estudiarlos en detalle y verificarlos. Cada acción en el sitio se refleja en la capa de datos. Digamos que tienes siete objetos. Si hace clic en un campo vacío y vuelve a llamar al comando dataLayer , debería aparecer un octavo objeto en la consola.

Para acceder al Depurador de Google Tag Manager, abra su cuenta de Google Tag Manager y haga clic en el botón Vista previa :

Luego abra su sitio y actualice la página. En el panel inferior, debería aparecer un panel que muestre todas las etiquetas que se ejecutan en esa página.

Los eventos que se agregan a la capa de datos se muestran a la izquierda. Al hacer clic en ellos, puede verificar la composición en tiempo real de la capa de datos.

Características de las pruebas de navegador móvil:

• En teléfonos inteligentes y tabletas, los sitios se pueden iniciar en modo adaptativo o puede haber una versión móvil separada del sitio. Si ejecuta la versión móvil de un sitio en su escritorio, será diferente de la misma versión en su teléfono.
• En general, las extensiones no se pueden instalar en los navegadores móviles.
• Para compensar esto, debe habilitar el modo de depuración en la etiqueta de Universal Analytics o en el código de seguimiento de Google Analytics en el sitio.

Características de las pruebas de aplicaciones móviles:

• Trabajar con el código de la aplicación requiere más conocimientos técnicos.
• Necesitará un servidor proxy local para interceptar visitas. Para realizar un seguimiento de la cantidad de solicitudes que envía un dispositivo, puede filtrar las solicitudes por el nombre de la aplicación o el host al que se envían.
• Todos los hits se recopilan en formato de protocolo de medición y requieren un procesamiento adicional. Una vez que se han recopilado y filtrado los hits, deben copiarse y analizarse en parámetros. Puede usar cualquier herramienta conveniente para hacer esto: Hit Builder, fórmulas en Hojas de cálculo de Google o una aplicación de JavaScript o Python. Todo depende de lo que sea más conveniente para ti. Además, necesitará conocimiento de los parámetros del Protocolo de medición para identificar errores en los hits enviados.

1. Conecte su dispositivo móvil a su computadora portátil a través de USB.
2. Abra Google Chrome en su dispositivo.
3. En la consola para desarrolladores de Chrome, abra el informe Dispositivos remotos:

1. Confirme la conexión a su dispositivo haciendo clic en Aceptar en el cuadro de diálogo. Luego seleccione la pestaña que desea inspeccionar y haga clic en Inspeccionar .
2. Ahora puede trabajar con la consola de desarrollador en modo estándar, como en el navegador. Tendrá todas las pestañas familiares: Consola, Red y otras.

1. Para trabajar con una aplicación móvil, debe instalar y ejecutar un servidor proxy. Recomendamos a Carlos.
2. Una vez instalado su servidor proxy, verifique a qué dirección IP se conecta la aplicación:

3. Luego tome su dispositivo y configure la conexión Wi-Fi a través del servidor proxy usando el puerto 8888. Este es el puerto que usa Charles por defecto.

4. Después de eso, es hora de recolectar éxitos. Tenga en cuenta que en las aplicaciones, los hits no se envían para recopilar sino para procesar por lotes. Batch es una solicitud empaquetada que lo ayuda a enviar varias solicitudes. En primer lugar, ahorra recursos de la aplicación. En segundo lugar, si hay problemas de red, las solicitudes se almacenarán en la aplicación y se enviará un fondo común tan pronto como se restablezca la conexión de red.

5. Finalmente, los datos recopilados deben analizarse (desmontarse) en parámetros, verificarse en orden y compararse con las especificaciones.

Este paso es el más rápido y fácil. Al mismo tiempo, se asegura de que los datos recopilados en Google Analytics tengan sentido. En sus informes, puede verificar cientos de escenarios diferentes y ver indicadores según el dispositivo, el navegador, etc. Si encuentra alguna anomalía en los datos, puede reproducir el script en un dispositivo específico y en un navegador específico.

También puede utilizar los informes de Google Analytics para comprobar la integridad de los datos transferidos a la capa de datos. Es decir, dependiendo de cada uno de los escenarios se llena la variable, si en ella están todos los parámetros, si los parámetros toman los valores correctos, etc.

Queremos compartir los informes más útiles (en nuestra opinión). Puede usarlos como una lista de verificación de recopilación de datos:

• Informes de comercio electrónico:
  • Rendimiento del producto
  • Rendimiento de la lista de productos
  • Promoción Interna
• Comportamiento — Eventos — Principales eventos
• Adquisición — Campañas — Análisis de costos
• Informes personalizados: por ejemplo, uno que muestre pedidos duplicados

Veamos cómo se ven estos informes en la interfaz y a cuál de estos informes debe prestar atención primero.

La pestaña más valiosa de este informe es Comportamiento de compra. Analiza la integridad de la recopilación de datos en cada etapa del comercio electrónico mejorado. Es decir, podemos ver si Google Analytics transfiere vistas de lista de productos, clics, vistas de detalles de productos, adición/eliminación de productos a/de la cesta y las propias compras.

¿A qué debemos prestar atención aquí? Primero, es muy extraño si tiene valores cero en cualquiera de las columnas. En segundo lugar, si tiene más valores en alguna etapa que en la etapa anterior, es probable que tenga problemas para recopilar datos. Por ejemplo, digamos que la cantidad de compras únicas de un artículo es mayor que la cantidad de pagos. Eso es raro y vale la pena prestarle atención.

También puede cambiar entre otros parámetros en este informe, que también debe enviarse a Comercio electrónico mejorado. Por ejemplo, si selecciona Categoría de artículo como la opción principal, puede ver que hay ofertas para ciertas categorías de artículos pero no hay vistas para estos artículos, no se agregan al carrito, etc.

En primer lugar, es necesario recorrer todos los parámetros que se transmiten a Google Analytics y ver qué valores toma cada parámetro. Por lo general, queda claro de inmediato si todo está bien. Se pueden realizar análisis más detallados de cada uno de los eventos en informes personalizados.

Otro informe estándar que puede resultar útil para comprobar la importación de datos de gastos en Google Analytics es el análisis de costes.

Muchas veces vemos informes donde hay gastos por alguna fuente o campaña publicitaria pero no hay sesiones. Esto puede ser causado por problemas o errores en las etiquetas UTM. Alternativamente, los filtros en Google Analytics pueden excluir sesiones de una fuente en particular. Estos informes deben revisarse de vez en cuando.

Nos gustaría destacar el informe personalizado que le permite rastrear transacciones duplicadas. Es muy fácil de configurar: el parámetro debe ser un ID de transacción y la dimensión clave debe ser transacciones.

Tenga en cuenta que cuando hay más de una transacción en el informe, esto significa que la información sobre el mismo pedido se envió más de una vez.

Si encuentra un problema similar, lea estas instrucciones detalladas sobre cómo solucionarlo.

Google Analytics tiene una muy buena herramienta de alertas personalizadas que le permite realizar un seguimiento de cambios importantes sin ver informes. Por ejemplo, si deja de recopilar información sobre las sesiones de Google Analytics, puede recibir una notificación por correo electrónico.

Le recomendamos que configure notificaciones para al menos estas cuatro métricas:

• Número de sesiones
• Porcentaje de rebote
• Ingresos
• Número de transacciones

Según nuestra experiencia, esta es la tarea más difícil y que requiere más tiempo: la línea estrecha donde los errores son los más comunes.

Para evitar problemas con la implementación de dataLayer, las comprobaciones deben realizarse al menos una vez a la semana. En general, la frecuencia debe depender de la frecuencia con la que implemente cambios en el sitio. Idealmente, necesita probar la capa de datos después de cada cambio significativo. Lleva mucho tiempo hacerlo manualmente, por lo que decidimos automatizar el proceso.

Para automatizar las pruebas, hemos creado una solución basada en la nube que nos permite:

• Compruebe si la variable dataLayer en el sitio coincide con el valor de referencia
• Verifique la disponibilidad y la funcionalidad del código de Google Tag Manager
• Comprobar que los datos se envían a Google Analytics y OWOX BI
• Recopile informes de errores en Google BigQuery

Ventajas de la automatización de pruebas:

• Aumenta significativamente la velocidad de las pruebas. Según nuestra experiencia, puede probar miles de páginas en unas pocas horas.
• Obtenga resultados más precisos, ya que se excluye el factor humano.
• Reduzca el costo de las pruebas, ya que necesita menos especialistas.
• Aumente la frecuencia de las pruebas, ya que puede ejecutar pruebas después de cada cambio en el sitio.

Un esquema simplificado del algoritmo que usamos:

Cuando inicia sesión en nuestra aplicación, debe especificar las páginas que desea verificar. Puede hacerlo cargando un archivo CSV, especificando un enlace al mapa del sitio o simplemente especificando la URL del sitio, en cuyo caso la aplicación encontrará el mapa del sitio por sí misma.

Luego, es importante especificar el esquema de capa de datos para cada escenario a probar: páginas, eventos, scripts (una secuencia de acciones, como para pagar). Luego puede usar expresiones regulares para especificar que los tipos de página coincidan con la URL.

Después de recibir toda esta información, nuestra aplicación ejecuta todas las páginas y eventos según lo programado, verifica cada secuencia de comandos y carga los resultados de las pruebas en Google BigQuery. Con base en estos datos, configuramos el correo electrónico y las notificaciones de Slack.

PS Si necesita una auditoría completa del sitio web, puede solicitar servicios de consultoría de OWOX BI. Regístrese para una demostración y discutiremos las posibilidades.