Última actualización: 20 de septiembre de 2020
Nota: En julio de 2023, Universal Analytics dejará de funcionar. No se recomienda realizar nuevas implementaciones con Universal Analytics (GA3). En su lugar, utiliza Google Analytics 4.
El seguimiento de aplicaciones de una sola página (SPA) puede ser un desafío, especialmente cuando se trata de rastrear las interacciones del usuario. Este artículo se centra en cómo gestionar los pageviews virtuales utilizando Google Tag Manager (GTM). Si bien existe un artículo más detallado sobre el seguimiento de SPAs, aquí nos enfocaremos en un problema específico y sus posibles soluciones.
Introducción al seguimiento de aplicaciones de una sola página
Las aplicaciones de una sola página no recargan completamente la página, sino que cargan dinámicamente el contenido según la interacción del usuario. Esto significa que, al usar métodos de seguimiento tradicionales de Google Analytics, solo se registrará la primera vista de página. Para abordar este problema, se utilizan pageviews virtuales, que son registros enviados a Google Analytics cada vez que el contenido de la SPA cambia.
El seguimiento efectivo de estas aplicaciones requiere identificar un disparador que active los envíos de pageviews virtuales. Existen dos enfoques principales: el primero implica la colaboración con un desarrollador para enviar eventos personalizados al Data Layer; el segundo utiliza el disparador de cambio de historial de GTM.
Sin embargo, no siempre es posible trabajar directamente con un desarrollador, ya sea por falta de tiempo o porque se trata de un proyecto más pequeño. Por lo tanto, el enfoque del cambio de historial se convierte en una solución viable. A continuación, examinaremos algunos matices de este enfoque.
El problema de los eventos de historial múltiples
Cuando los usuarios navegan por una SPA, pueden ocurrir múltiples eventos de cambio de historial simultáneamente, a pesar de que solo haya un cambio de URL. Esto puede causar que se registren múltiples pageviews virtuales en Google Analytics, lo que distorsiona las métricas. Para entender este fenómeno, es crucial observar cómo se comportan los eventos de historial en GTM.
Al implementar el disparador de cambio de historial, asegúrate de habilitar el modo de vista previa y comenzar a navegar por la SPA. Cada vez que la URL cambie, deberías ver el evento de historial en la vista previa. Sin embargo, en algunos casos puede que veas más de un evento de historial disparado al mismo tiempo, lo que complica el seguimiento preciso de las interacciones del usuario.
Soluciones al problema de eventos de historial múltiples
Una solución potencial es evitar el uso del disparador de cambio de historial y trabajar con un desarrollador para enviar un evento personalizado al Data Layer cada vez que la URL cambie realmente. Esto, sin embargo, no siempre es viable.
Una alternativa efectiva, que ha funcionado en muchos casos, es reducir el origen del cambio de historial. Esto implica identificar cuál de los eventos de historial es el más relevante y único en el contexto de la navegación del usuario.
Comprobación de la fuente del cambio de historial
Cuando observes los múltiples eventos de historial en el modo de vista previa de GTM, selecciona el primero y dirígete a la pestaña del Data Layer. Busca el valor de gtm.historyChangeSource y regístralo. Por ejemplo, podría ser pushState.
Luego, revisa el siguiente evento de historial y anota su valor. Es posible que encuentres eventos de replaceState o incluso otros tipos. La clave aquí es determinar si hay un evento que tenga un valor de gtm.historyChangeSource único en comparación con los otros eventos que se dispararon al mismo tiempo.
- pushState: Generalmente utilizado para registrar un cambio de URL.
- replaceState: A menudo utilizado para modificar la URL actual sin generar un nuevo estado en el historial.
Si identificas que uno de los eventos de historial tiene un valor diferente, puedes configurar tu disparador de cambio de historial de GTM para que solo active los pageviews virtuales en función de ese evento único.
Actualización del disparador de cambio de historial
Una vez que hayas identificado el valor adecuado de gtm.historyChangeSource, es momento de actualizar la configuración del disparador de cambio de historial en GTM. Dirígete a tu contenedor de GTM, selecciona Triggers y abre el disparador que has creado previamente. Añade la condición: History Source es igual a pushState.
Recuerda que esta comparación es sensible a mayúsculas, y si no ves la variable History Source en la lista, puedes habilitarla como una variable integrada.
Es crucial probar si la etiqueta de pageview de Google Analytics se activa solo en los eventos de pushState. Vuelve a habilitar el modo de vista previa y comienza a navegar nuevamente para asegurarte de que el disparador funcione como se espera.
Pasar la URL correcta de la página
Si la URL de tu SPA contiene un # y la información importante se encuentra después de este símbolo (por ejemplo, example.com/#/pages/contact-us), debes realizar una configuración adicional. Por defecto, Google Analytics no registra las partes de la URL que siguen al símbolo #.
Para obtener más información sobre cómo manejar esto, consulta la sección correspondiente en mi guía sobre el seguimiento de SPAs. Hay varias opciones disponibles, así que escoge la que mejor se ajuste a tus necesidades.
Prueba final de la implementación
Una vez que hayas realizado los ajustes necesarios, es hora de validar que todo funcione correctamente. Aquí hay un plan de prueba rápido:
- Verifica cuántas veces se activa la etiqueta de pageview de GA: Al navegar de una página a otra en tu SPA, deberías observar múltiples eventos de historial, pero solo uno debe activar tu etiqueta de pageview.
- Consulta los informes en tiempo real: Dirígete a los informes en tiempo real de Google Analytics para confirmar que solo se registra un pageview al navegar entre páginas de tu SPA.
- Comprueba la URL con # en los informes: Si tu SPA utiliza un #, asegúrate de que esos cambios se reflejen en los informes en tiempo real de GA.
Consideraciones finales sobre el seguimiento de SPAs con GTM
El seguimiento de aplicaciones de una sola página presenta desafíos únicos, como hemos explorado en este artículo. La aparición de múltiples eventos de historial puede complicar la precisión de tus métricas. Al identificar un evento de historial con un valor único de gtm.historyChangeSource, puedes afinar tu seguimiento y asegurarte de que solo se registren las interacciones más relevantes.
Recuerda que cada SPA es diferente, y es posible que debas experimentar para identificar el mejor enfoque para tu caso. Si después de tus pruebas no puedes resolver el problema, considera colaborar nuevamente con un desarrollador para implementar un seguimiento más personalizado mediante eventos personalizados.

























