Al trabajar con el análisis de Solicitudes de una sola página (SPA)Hay una serie de cosas a las que hay que prestar atención. Por ejemplo, debes asegurarte de que Google Analytics no Romper la atribución de la sesióny que no lo estés haciendo sin darte cuenta Inflar las métricas de velocidad de su páginaEn realidad, hay muchos problemas cuando se trata del seguimiento de SPA en herramientas como Análisis de Google que simplemente no se puede lograr con una implementación plug-and-play.
Ver Excelente artículo de Dan Wilkersonlo que resume muy bien el problema que supone rastrear una SPA.
Uno de los problemas con los frameworks que cargan su contenido dinámicamente usando JavaScript (por ejemplo Reaccionar) es cuando se envía el evento histórico antes El contenido se ha cargado o la URL realmente ha cambiado.
Esto es problemático, ya que es posible que en realidad desees hacer referencia a los elementos cargados en este cambio de estado dinámico en tus etiquetas, pero debido a que Activador de cambio de historial se activa tan pronto como se envía el evento, es posible que el contenido aún no esté allí cuando se activen las etiquetas.
Entonces, en este artículo mostraré una forma rápida y sencilla de retrasar el disparador, de modo que sus etiquetas no se activen hasta que la página haya tenido tiempo de cargar el contenido.
incógnita
El boletín informativo de Simmer
Suscríbete a la Boletín informativo de Simmer ¡Para recibir las últimas noticias y contenidos de Simo Ahava en tu bandeja de entrada de correo electrónico!
Consejo 79: Retrasar el cambio de historial
El Manera fácil Para hacerlo hay que despedir a un Etiqueta HTML personalizada con el Historial de cambios que provocan problemas en su sitio.
Primero, asegúrese de tener toda la información relacionada con el historial. Variables incorporadas habilitado en el contenedor.
Luego, en la etiqueta HTML personalizada, agregue el siguiente código:
<script>
(operate() {
var timeout = 500; // Milliseconds - change to what you need the timeout to be.
window.setTimeout(operate() {
window.dataLayer.push({
occasion: 'customized.historyChange',
customized: {
historyChangeSource: {{Historical past Supply}},
newHistoryState: {{New Historical past State}},
oldHistoryState: {{Outdated Historical past State}},
newHistoryFragment: {{New Historical past Fragment}},
oldHistoryFragment: {{Outdated Historical past Fragment}}
}
});
}, timeout);
})();
script>Como se dijo anteriormente, asegúrese de que esta etiqueta se lively en el activador de cambio de historial que desea retrasar.
La etiqueta HTML personalizada agrega un retraso de 500 milisegundos, después del cual envía un evento personalizado llamado customized.historyChange dentro del dataLayerCon este evento, se introducen cinco nuevas variables de capa de datos, cada una con los valores de la authentic Evento histórico que activó la etiqueta HTML personalizada en primer lugar. Estas nuevas variables son:
-
customized.historyChangeSource– el evento histórico que desencadenó el retraso (por ejemplo,pushStateoreplaceState). -
customized.newHistoryState– el objeto de estado ambientado en el evento histórico. -
customized.oldHistoryState– el objeto de estado que fue sobrescrito con el nuevo objeto de estado. -
customized.newHistoryFragment– el fragmento de hash establecer en el evento histórico (por ejemplo#contactus). -
customized.oldHistoryFragment– el fragmento de hash que fue sobrescrito con el nuevo hash.
Ahora, crea un nuevo Activador de evento personalizado para el nombre del evento customized.historyChangey crear Variables de la capa de datos para todas las nuevas variables personalizadas enumeradas anteriormente (o al menos las que tengan sentido en su caso). Así es como se verían el disparador y una variable de muestra:
Agregue el disparador de evento personalizado a cualquier etiqueta que desee activar con el evento de historial y use las nuevas variables de capa de datos cuando sea necesario.
Quizás se pregunte por qué reescribir las variables integradas originales en variables de capa de datos personalizadas. Esto es solo una precaución. Si su sitio envía más de un evento de historial antes de que finalice el retraso de 500 milisegundos, las variables integradas siempre harán referencia a las variables de capa de datos personalizadas. el último Estado histórico, no el que se retrasó.
Problema con este enfoque
Este enfoque presenta un problema potencialmente grave. Al activar una etiqueta HTML personalizada con cada evento de historial, se obstruye el modelo de objetos de documento de la página, ya que se descarga cuando el usuario abandona la página y no cuando se incorpora contenido nuevo. Por ejemplo, después de diez eventos de historial, el DOM puede quedar así:
El problema de reescribir el DOM tantas veces es que cada nuevo elemento añadido obliga a reevaluar el modelo de objetos del documento y, cuantos más elementos haya en el DOM, más tiempo llevará esta reevaluación. Por lo tanto, cuantas más etiquetas HTML personalizadas se activen sin recargar o actualizar la página, más se verá afectado el rendimiento de la página.
Solución potencial
Una posible solución es utilizar una única etiqueta HTML personalizada, donde se sobrescribe el window.historical past.pushState y window.historical past.replaceState métodos. El código sobrescrito debe incluir el retraso dataLayer.push()y tú debe Pasar los argumentos al authentic window.historical past.pushState usando apply()a menos que quieras destruir la navegación de tu sitio. Ver aquí para inspirarse.
Básicamente, estás escribiendo un detector de eventos personalizadopero en lugar de escuchar las interacciones del usuario, estarás escuchando pushState y replaceState eventos.
No voy a escribir la solución aquí: es difícil escribir un detector de historial genérico que funcione con su caso de uso specific. Pero la Artículo de Stack Overflow Debería ayudarte a empezar. Solo recuerda probar minuciosamente si se sobrescriben las interfaces básicas del navegador, como la API del historial de ventanas.
Resumen
El truco descrito en este artículo debería ser realmente una temporario Solución (como deberían hacerlo todos los hacks). Deberías hablar con tus desarrolladores y pedirles que implementen el evento personalizado push directamente en cualquier código JavaScript que esté manejando los cambios de ruta/estado en el sitio.
Al delegar el trabajo a sus desarrolladores, ellos pueden garantizar que el dataLayer El evento se envía en el momento exacto. Utilizar un retraso como los 500 milisegundos de este artículo no es óptimo por dos motivos:
-
Puede ser demasiado cortolo que significa que el retraso desaparece, se envía el evento personalizado, pero la transición aún no está completa.
-
Puede ser demasiado largolo que significa que estás perdiendo tiempo con el disparador y el seguimiento de la vista de página de cada transición dinámica puede quedar rezagado respecto de los eventos enviados con cada nuevo fragmento de contenido.
De todos modos, es una manera de Haz que las cosas funcionenlo que supongo que es una buena justificación como cualquier otra para usar hacks.