Se dispara un evento. Registra una compra. El importe de la compra debería ser $99. Pero registra $990. Un punto decimal está mal. Eso son datos malos. Se dispara un evento. Debería capturar una categoría de producto. Pero no captura nada. Eso son datos que faltan. Los datos malos distorsionan tu analítica. Llegan conclusiones equivocadas. Tomas decisiones basadas en números erróneos. La calidad de los datos es crítica. Cada evento debe capturar datos precisos. Cada parámetro debe tener el valor correcto. Esto requiere una configuración cuidadosa y una supervisión constante.
Este artículo explica cómo asegurar que los parámetros de evento capturen datos de calidad.
Por qué importa la calidad de los datos
La analítica solo es útil si los datos son precisos. Analizas tasas de conversión. Optimizas según los números. Pero si los números de conversión son erróneos, tu optimización es errónea. Puedes optimizar lo que no toca. Puedes perder oportunidades.
Los datos malos se acumulan. Un pequeño error en un evento se convierte en un gran error en conjunto. Si el 10 por ciento de los eventos de compra tiene importes erróneos, tus cifras de ingresos fallan en un 10 por ciento. Es un error importante para las decisiones de negocio.
La calidad de los datos genera confianza. Tu equipo confía en la analítica cuando los números son precisos. Toma decisiones basándose en ella. Si los datos no son fiables, dejan de confiar. Dejan de usar la analítica.
Define los parámetros de evento con precisión
Antes de crear un evento, define qué debe contener cada parámetro. Nombre del parámetro. Descripción del parámetro. Tipo de dato del parámetro. Rango de valores esperado. De dónde viene el valor.
Un parámetro de importe de compra debe estar claramente definido. ¿Es el total con impuestos y envío? ¿O solo el coste del producto? ¿Está en céntimos o en dólares? ¿Es texto o número? Defínelo con precisión. La implementación depende de ello.
Documenta cada parámetro. Documentar evita confusiones. Un desarrollador que implementa el evento sabe exactamente qué capturar. Un analista que lee los datos sabe qué representan.
Captura los datos desde la fuente correcta
La calidad de los datos depende de capturarlos desde la fuente correcta. Un importe de compra debe venir de tu sistema de procesamiento de pedidos. No de una estimación. No de lo que escribe el usuario. El importe real confirmado.
Una categoría de producto debe venir de tu base de datos de productos. No de lo que escribió el usuario. No de una suposición. La categoría de referencia.
Obtén los datos lo más cerca posible de la fuente. Los sistemas de transacciones reales conocen los importes reales. Las bases de datos reales conocen la categorización real. Extrae de ahí. No calcules ni estimes.
Valida los datos antes de que se disparen los eventos
Valida los datos antes de enviarlos a la analítica. Comprueba que el importe de la compra es un número. Comprueba que es positivo. Comprueba que el ID del producto existe.
La validación detecta errores antes de que se conviertan en problemas de analítica. Un desarrollador se equivoca. La validación lo detecta. Los datos nunca llegan a la analítica. El evento se dispara con buenos datos.
Las validaciones habituales incluyen la comprobación de tipo (¿es texto, número o fecha?), la comprobación de rango (¿está dentro de los valores esperados?) y la comprobación de existencia (¿existe el elemento al que se refiere?).
Usa nombres de parámetros coherentes
El nombre de los parámetros importa. Si un evento llama a un parámetro "amount" y otro lo llama "purchase_amount", tus informes los tratan como parámetros distintos. No puedes compararlos.
Crea un estándar de nombres. Todos los valores monetarios usan el sufijo "_amount". Todos los IDs usan el sufijo "_id". Todos los recuentos usan el sufijo "_count". Aplica este estándar de forma coherente.
Una vez que nombras un parámetro, no lo cambies. Cambiar los nombres de los parámetros divide tus datos. Los datos antiguos quedan bajo el nombre antiguo. Los datos nuevos, bajo el nombre nuevo. Los informes muestran datos divididos. Acierta con los nombres antes de publicar.
Gestiona los casos límite y los datos que faltan
Algunos datos son difíciles de capturar. Transacciones sin conexión. Transacciones de sistemas antiguos. Información de usuario incompleta. ¿Cómo gestionas los datos que faltan?
Nunca envíes eventos a los que les falten parámetros críticos. Si no puedes obtener el importe de la compra, no dispares el evento de compra. Envía el evento solo cuando tengas los datos completos.
Para los datos opcionales, usa null o una cadena vacía de forma coherente. No uses "desconocido" en un sitio y "N/D" en otro. Tratar los datos que faltan de forma coherente facilita el análisis.
Vigila la calidad de los datos con el tiempo
La calidad de los datos se degrada con el tiempo. Las integraciones se rompen. Los sistemas cambian. Lo que funcionaba el mes pasado puede romperse este mes. Vigila de forma continua.
Busca patrones inesperados. Valores nulos donde no deberían estar. Valores atípicos en los importes. Parámetros que faltan. Configura alertas. Si algo parece raro, investiga.
Revisa con regularidad los informes de calidad de datos. La mayoría de las plataformas de analítica los tiene. Úsalos. Detecta los problemas pronto.
Preguntas frecuentes
¿Cómo probamos si los parámetros de evento capturan bien?
Usa los informes en tiempo real. Haz la acción. Mira el informe. Comprueba que el evento aparece con los parámetros y los valores correctos. Usa las herramientas de desarrollo del navegador. Inspecciona los datos antes de que se envíen a la analítica. Verifica que coinciden con lo esperado. Con el creador de webs de WEMASY puedes configurarlo directamente en tu web.
¿Y si el valor de un parámetro siempre está vacío?
Los datos no se están capturando. Revisa tu implementación. ¿Está bien configurado el parámetro? ¿Están disponibles los datos cuando se dispara el evento? ¿Hay un problema de sincronización? Depura el origen. No envíes datos vacíos. Arregla la causa raíz.
¿Podemos cambiar el nombre de un parámetro después de recoger datos?
Técnicamente sí, pero no lo hagas. Los datos antiguos se quedan con el nombre antiguo. Los datos nuevos van con el nombre nuevo. Tus informes muestran datos divididos. Acierta con el nombre desde el principio. Si tienes que cambiarlo, prevé la división de los datos.
¿Cómo gestionamos la moneda en los parámetros de evento?
Captura el importe numérico y el código de moneda por separado. El importe en un parámetro como "purchase_amount". La moneda en un parámetro como "currency_code", con valores como "USD" o "EUR". Así puedes analizar entre monedas.
¿Debemos guardar datos en bruto o con formato en los parámetros?
Guarda datos en bruto. Importes en céntimos, no en dólares. Marcas de tiempo en formato ISO, no legibles para personas. Los datos con formato son más difíciles de analizar y comparar. Los datos en bruto son más flexibles. Dales formato en los informes si hace falta.
¿Qué tasa de error es razonable en los datos de eventos?
El objetivo es cero. Pero en la práctica, menos del 1 por ciento es aceptable. Algunos casos límite tendrán problemas. Puede que los sistemas antiguos no tengan datos. Pero si las tasas de error superan el 1-2 por ciento, investiga y arregla la causa raíz.