Cómo procesan las llamadas de tracking el dataLayer de Google Tag Manager (GTM) y la librería utag.js de Tealium iQ

Un tag manager (TMS por sus siglas en inglés – Tag Manager System) va de la mano de un data layer: una capa de datos que expone información sobre una pantalla o interacción. El gestor de etiquetas lee esta información y la pone a disposición de sus tags, load rules y demás activos. Se puede trabajar con data layers agnósticos, aunque lo normal es que cada TMS se implemente junto con su propia capa de datos: Google Tag Manager (GTM) con el dataLayer y Tealium iQ con el Universal Data Object (UDO). El cometido de ambas capas de datos es similar, pero su funcionamiento es diferente, al igual que también es diferente la forma en cada uno de estos tag managers procesa sus respectivas llamadas de tracking: dataLayer.push(), utag.view() y utag.link(). En este post te explicaré algunas de estas diferencias. Es una temática que me resulta súper interesante, ojalá te sirva de ayuda

El método dataLayer.push(): el event driven dataLayer de Google Tag Manager (GTM)

El dataLayer de Google Tag Manager es un array que se inicializa en el Global Namespace de tu navegador, es decir, en el objeto Window.
El array dataLayer se constituye como una propiedad del objeto Window, por lo que es accesible desde cualquier script que se ejecute bajo el objeto Window.

Cualquier interacción que quieras trazar con Google Tag Manager debe pasar por el dataLayer: la visualización de una página, un error en un formulario, una notificación que viene del backend, etc. GTM lee esta información y la pone a disposición de sus variables, triggers y tags. Para enviar un evento o añadir nueva información al dataLayer debes hacer uso del método dataLayer.push() (window.dataLayer es, al fin y al cabo, un array), que podría considerarse la llamada de tracking de Google Tag Manager. Fíjate, te pongo un ejemplo:

El estado de mi dataLayer según lo veo en el debug view de mi contenedor de Google Tag Manager...
...ejecuto un dataLayer.push() en la consola de mi navegador simulando el tracking de un evento...
...el dataLayer de GTM cambia: se actualiza con la información de ese evento.

Como puedes comprobar, el dataLayer ha cambiado, se ha actualizado. Esto es así porque el dataLayer de Google Tag Manager es dinámico, está constantemente cambiando con cada interacción que GTM captura. Es lo que el gran Jim Gordon acuñó como ‘The Event-Driven Data Layer’. ¿Qué quiere decir esto? Pues que cualquier evento que pasa por el dataLayer… actualiza el dataLayer.

El propio Jim Gordon señala una ventaja de esto en el vídeo ‘Tag Management | Why You Should Use an Event Driven Data Layer’, publicado en el canal de YouTube de Further: las implementaciones de Google Tag Manager son fáciles de mantener. Sólo hay que usar un método para trazar cualquier interacción: window.dataLayer.push(). Punto. A mi esto me parece especialmente útil, por ejemplo, a la hora de implementar un plan de medición en una SPA (Single Page Application) Sólo tienes que pedir a tu equipo de desarrollo que implemente (o en su defecto hacerlo tú mismo) una llamada datalayer.push() para trazar cualquier interacción: desde la visualizaciones de una pantalla hasta un evento hover sobre un icono determinado.

El internal data model de Google Tag Manager (GTM)

Si inspeccionas el array window.dataLayer de cualquier página con Google Tag Manager implementado verás que contiene varios objetos. Cada uno de ellos se corresponde con un evento que se ha añadido al dataLayer. Unos los ha añadido la librería gtm.js de forma automática al cargarse GTM y la propia página (gtm.js, gtm.dom, gtm.load, etc.), otros los has podido añadir tú mismo con diferentes llamadas dataLayer.push().
Captura de pantalla del array window.dataLayer implementado en este mismo blog según se ve cuando se accede a él desde la consola javascript de tu navegador,

Bien, si ahora inspeccionas el dataLayer desde el debug view de Google Tag Manager encontrarás un único objeto y no un array con varios objetos.

Es más, si añades un nuevo objeto al array window.dataLayer, en el debug view de GTM seguirás viendo un único objeto que ahora se ha actualizado con esta información.
Añado un objeto nuevo al array window.dataLayer...
...pero si inspecciono el dataLayer a través del debug view de GTM veo que el objeto se ha mergeado dentro del propio dataLayer.
Esto es así por el llamado internal data model de Google Tag Manager. Este gestor de etiquetas no usa el array window.dataLayer como tal, sino que lo emplea para generar su modelo propio del dataLayer. Es decir, el dataLayer de GTM es una versión procesada del array window.dataLayer, y es esta versión procesada la que se pone a disposición de los tags, triggers y variables de este tag manager. Esto es algo que explica muy bien el gran Julius Fedorovicius en un vídeo publicado en el canal de YouTube de MeasureSchool: ‘Understanding the GTM dataLayer’.

Los objetos utag_data y utag.data y las llamadas de tracking de Tealium iQ

El data layer de Tealium iQ se denomina Universal Data Object (UDO), aunque también se conoce como objeto utag_data. Es un objeto javascript que se inicializa en el objeto Window, es decir, en el Global Namespace de tu navegador.

Detalle del objeto utag_data del site de pruebas de Tealium https://ecommerce.tealiumdemo.com/ según se ve al acceder a él desde la consola javascript de tu navegador. Al constituirse como una propiedad del objeto Window se puede acceder al objeto desde cualquier script que se ejecute bajo Window.

Si bien en Google Tag Manager sólo necesitas usar el método dataLayer.push() para trazar cualquier interacción, Tealium iQ hace uso de la llamada utag.view() para trazar visualizaciones de pantallas y de la llamada utag.link() para trazar interacciones (aunque en realidad podrías optimizar tu implementación usando la llamada utag.track()) Pero al contrario de lo que sucede con el dataLayer de GTM, el objeto utag_data de Tealium iQ no es dinámico, no muta con cada llamada de tracking…pero sí se procesa.

Cuando visitas un site con Tealium implementado, la librería utag.js pasa por varias fases desde que se empieza a cargar hasta que lanza una llamada utag.view() de forma automática (esto es lo que se conoce como el Tealium Order of Operations.) Al comienzo de este proceso, en la llamada fase Pre Loader, el objeto utag_data se procesa y se combina con otros elementos de la página (cookies, elementos del DOM, etiquetas Meta, variables javascript, etc.) para formar el objeto utag.data, que también se constituye como una propiedad del objeto Window.

En esta captura de pantalla, tomada de la consola javascript de mi navegador al visitar el site de pruebas de Tealium https://ecommerce.tealiumdemo.com/, puedes observar como los objetos utag_data y utag.data son idénticos. Esto es así porque en javascript los objetos se asignan por referencia.
Pues bien, será este objeto utag.data el que constituya el payload de la llamada utag.view() que ejecuta la librería utag.js de forma automática al cargarse. El proceso es similar si utag.js intercepta otra llamada utag.link() o utag.view() después de haberse cargado, salvo que en este caso la librería no tomará en cuenta el objeto utag.data ya expuesto en el objeto Window, sino que fusionará el payload de esta llamada view o link con información propia de la página (variables Javascript, elementos del DOM, elementos de la url, cookies, etiquetas Meta, etc).

Como ves, el data layer de Tealium iQ no procesa el contenido de una llamada de tracking, sino que es la librería utag.js la que procesa el objeto utag_data (o el contenido de la llamada de tracking) para fusionarlo con otras variables. Esta es una diferencia sustancial con respecto al funcionamiento del dataLayer de GTM.

El objeto b de Tealium iQ: el payload de llamada de tracking que sí ha mutado

Después de que se forme el payload de una llamada utag.view() o utag.link(), utag.js sigue avanzando en su ejecución y procesa todas las extensiones que puedan estar configuradas en el profile de Tealium iQ hasta generar el objeto b, que es una copia local (no se expone en el objeto Window de tu navegador) y procesada del payload de estas llamadas de tracking.

Es este objeto b el que se pone a disposición de los tags, load rules y extensiones, y su contenido puede ser diferente al del payload inicial de las llamadas de tracking. ¿Por qué? Porque las extensiones de un profile de Tealium pueden influir en este output, es decir, en el objeto b resultante. Es lo que el gran Lukas Oldenburg denomina input data layer vs output data layer en su post ‘Issues of Tracking QA Solutions, and what a better one could look like’. El artículo ilustra súper bien precisamente esto: una cosa es la llamada utag.view() o utag.link() que Tealium iQ recibe, y otra el objeto b final que genera tras procesar las llamadas de tracking y las extensiones. Te recomiendo que lo leas.

1 comentario en «Cómo procesan las llamadas de tracking el dataLayer de Google Tag Manager (GTM) y la librería utag.js de Tealium iQ»

Los comentarios están cerrados.

pornance.net
www.fuck-videos.net
zettaporn.com