Instalación de analítica web: comprueba todo el recorrido

Instalar un script es el principio, no la aceptación

Una instalación analítica funciona cuando las acciones previstas producen los registros correctos, los datos no deseados quedan fuera y los informes coinciden con el recorrido de prueba. Ver una etiqueta de script o un indicador verde demuestra mucho menos. No confirma que la navegación se cuente una vez, se respete el consentimiento o las conversiones de pago sean reales.

Empieza con un proyecto de pruebas y actividad ficticia. Conserva un registro breve de aceptación con revisión del sitio, configuración del rastreador, navegador, hora, eventos esperados y resultados observados. Así otra persona puede repetir la prueba y una regresión posterior no se descarta con un «funcionaba al instalarlo».

Define las reglas antes de abrir las herramientas de desarrollo

Enumera los pocos eventos necesarios y su disparador exacto. «Registro» puede significar hacer clic, enviar un formulario o crear correctamente una cuenta. Elige un significado y da nombres distintos a las otras acciones. Decide qué rutas cuentan como vistas de página y qué valores se permiten en las propiedades de eventos.

Documenta la política de consentimiento y almacenamiento aparte de la lista de eventos. La prueba siguiente supone una implementación que no envía eventos analíticos antes del permiso. Otros productos pueden documentar un comportamiento diferente. Comprueba tu política aprobada y los requisitos aplicables; no supongas que una herramienta «sin cookies» carece de obligaciones de privacidad.

pageview: se hace visible una ruta pública admitida.
signup-completed: la aplicación confirma que se creó la cuenta.
checkout-started: se crea una sesión de pago válida.
payment-succeeded: el sistema de pagos de confianza confirma el éxito, no el navegador.

Inspecciona solicitudes reales del navegador

Abre el panel Network antes del recorrido, borra el tráfico anterior y filtra por el endpoint de recopilación. La documentación de Chrome explica cómo inspeccionar solicitudes, cargas útiles y respuestas. Una respuesta HTTP correcta es una prueba útil, pero verifica también que exista el registro correspondiente en el proyecto adecuado.

Comprueba host de destino, identificador de proyecto, nombre del evento, etiquetas de fuente permitidas y hora. Busca correos, textos de búsqueda, tokens de acceso o URL específicas de clientes que se hayan incluido por accidente. Un evento puede ser técnicamente válido y recoger información que el plan de medición no autorizó.

Si falta una solicitud, investiga desde el navegador hacia fuera: carga del script, errores JavaScript, restricciones de políticas, solicitud de red, validación del servidor y registro almacenado. No reinstales el script una y otra vez antes de localizar la capa que falla.

Ejecuta una matriz de recorridos pequeña y explícita

Este es un ejemplo ficticio de aceptación, no una afirmación sobre ningún rastreador desplegado. Usa un identificador nuevo de prueba en cada ejecución y conserva un registro de pruebas sin datos sensibles. Los recuentos corresponden a la política elegida de consentimiento, no al comportamiento de todos los proveedores.

MATRIZ FICTICIA DE PRUEBAS
Acción                             Analítica esperada del navegador
Cargar / sin consentimiento        0 eventos
Dar consentimiento en /           1 vista inicial permitida
Navegar a /pricing                 1 vista nueva
Recargar /pricing                  1 vista nueva para esa carga
Cambiar solo un filtro en la URL   0 si la política ignora esos cambios
Retirar el consentimiento          No recopilar eventos posteriores
Completar un pago de prueba        El servidor verifica el dinero aparte

Prueba la navegación SPA sin contar dos veces

Una aplicación de página única puede cambiar de pantalla sin recargar el documento. Un rastreador ligado solo a la carga inicial podría perder esas navegaciones. En el extremo contrario, combinar seguimiento automático del historial con un evento manual del router puede contar dos veces la misma pantalla. La guía SPA de Google advierte sobre enfoques superpuestos en su implementación.

Elige un único responsable de emitir vistas y prueba carga inicial, navegación del cliente, atrás, adelante y recarga. Si el router usa rutas con fragmentos hash, pruébalas expresamente. Si un parámetro solo ordena una tabla, decide si representa una pantalla analítica nueva; no dejes que un detalle accidental de implementación elija la métrica.

Confirma que la instrumentación no rompe la navegación. Botones, historial, estado de formularios y gestión de errores deben funcionar con seguimiento activado, desactivado y bloqueado. La analítica debe observar el producto, no convertirse en un requisito para usarlo.

Comprueba cambios de permiso y situaciones de fallo

Prueba permiso denegado, concedido y retirado durante la misma sesión. Revisa almacenamiento y red después de cada transición. Retirarlo no puede deshacer el envío de un evento ya entregado; por eso debes distinguir entre detener recopilación futura y eliminar registros históricos.

Después bloquea la solicitud analítica y repite la acción principal de la aplicación. El usuario debería poder registrarse o avanzar al pago aunque la analítica no esté disponible. Prueba también una conexión lenta: una dependencia temporal puede desaparecer en una computadora de desarrollo rápida y fallar en un teléfono.

Revisa cómo declara la implementación que trata las señales de privacidad del navegador y las restricciones de almacenamiento. Documenta honestamente una limitación si no puede soportarse o medirse. Es preferible tener datos ausentes que eludir la elección del visitante para completar un gráfico.

Verifica los ingresos aparte y después su asociación

Crea un pago de prueba del proveedor e inspecciona su estado de referencia. Confirma que el proyecto analítico recibe un solo pago canónico con moneda e importe correctos. Repite la notificación y comprueba que no se duplica el dinero. Una devolución parcial debe seguir la regla documentada.

Solo cuando funcione la parte financiera revisa si se asoció la visita consentida. Repite sin visita elegible: un pago Sin atribución puede ser el resultado correcto. Probar únicamente el recorrido ideal favorece sistemas que esconden precisamente la incertidumbre que deberían mostrar.

Deja una comprobación repetible para cada publicación

Conserva la matriz con la documentación y repítela después de cambiar rutas, gestión del consentimiento, proceso de pago, dominios o rastreador. Guarda pruebas sin datos sensibles, no cargas útiles de clientes reales. Registra la fecha y configuración efectivas en vez de mantener una insignia permanente de «verificado».

Superar la comprobación establece el comportamiento probado en unas condiciones declaradas. No garantiza cobertura completa de visitantes, cumplimiento legal ni corrección de despliegues futuros. Esa conclusión más acotada es útil: sabes qué funciona, qué falla y qué debe reparar exactamente el siguiente cambio.

Referencias

Ejemplo con fines educativos. Los datos y cálculos de ejemplo no representan resultados empresariales verificados.