Desarrollar en Google Tag Manager (u otro TMS) vs. implementar en código
A lo largo de mi carrera profesional, casi siempre he seguido el mismo modus operandi a la hora de enfrentar un proyecto de implementación de analítica estándar:
- Elaboración de un documento de definición de data layers. Qué valores se expondrán en la capa de datos de cada página.
- Elaboración de una guía de etiquetado. Qué interacciones se van a trazar y qué llamadas deben ejecutarse en cada uno de estos casos.
- Elaboración de una guía de implementación. Qué es un data layer, cómo y cuándo debe implementarse, cómo implementar en un site o app un Tag Manager System (TMS a partir de ahora) como Google Tag Manager o Tealium.
Una vez que he terminado de elaborar esta documentación, me reúno con el equipo de desarrollo implicado en el proyecto y le hago entrega de esta documentación. Por norma general, el DEV team se pone manos a la obra e implementa la analítica en un entorno de preproducción siguiendo estas instrucciones y me avisa para validar el trabajo.
Pues bien, la realidad es que en más de una ocasión, al terminar este trabajo de documentación me he dado de bruces con el hecho de que los equipos de desarrollo no tenían recursos suficientes para abordar este trabajo. En estas situaciones, he tenido que ser yo mismo el que asumiera el trabajo de desarrollo de analítica de principio a fin desde un gestor de etiquetas (GTM o Tealium iQ en mi caso). Esto es algo que técnicamente es perfectamente posible, pero que tiene sus ventajas y desventajas. Qué es mejor ¿implementar la analítica de un TMS o hacerlo por código? Difícil cuestión que probablemente no tenga una única respuesta válida.
En busca de una implementación limpia, fácil de mantener y escalable
Escribí el post ‘Implementar Enhanced Ecommerce (GA4) en tu ‘site’ generando tus propios dataLayers desde Google Tag Manager (GTM)’ con el objetivo de ilustrar lo anterior. Es decir: cómo puedes proceder desde un TMS (GTM en este caso) en caso de que no tengas soporte de un equipo de desarrollo.
Como te decía al principio de este post, una implementación debe ser lo más sencilla, limpia y escalable posible. Cuando el 100% de tu implementación se hace desde Google Tag Manager (o Tealium iQ o cualquier otro TMS en realidad), corres el riesgo de que esto no se cumpla. ¿Por qué? Por muchos motivos: mucha gente trabajando en un mismo contenedor, diferentes departamentos implementado scripts que no están relacionados entre sí, actualizaciones del código del site que hacen que se rompa tu tracking, etc. Esto es algo que he vivido en muchos proyectos diferentes.
Pues bien, siguiendo esta senda, en este post te quiero mostrar el ejercicio opuesto: cómo puedes liberar a tu gestor de etiquetas del peso del desarrollo de analítica y llevarlo a un archivo externo. Para ello, voy a migrar el desarrollo de analítica necesario para generar los data layers de Enhanced Ecommerce (EEC) de GA4 desde Google Tag Manager a un archivo javascript externo. Con esto busco:
- Simplificar y aligerar la configuración de mi contenedor de Google Tag Manager
- Separar el desarrollo de estos dataLayers de GTM. Esto hace más fácil identificar y solucionar posibles bugs de código
- Tener un único código al que acudir para realizar modificaciones u optimizaciones
- Tener un control de versiones efectivo en Github (aunque en realidad esto es algo que también se podría hacer con los scripts que se implementan desde GTM)
De Google Tag Manager a un archivo Javascript
El proceso que he seguido para migrar el código desarrollado e implementado en todos estos CHTML Tags a un único archivo javascript ha sido bastante sencillo. He ido evento a evento y lo he migrado a un archivo javascript que he llamado tracker.js Quizá lo más complejo haya sido controlar cuándo debe ejecutarse cada parte de este script (con GTM esto se gestiona fácil gracias a sus triggers) Básicamente lo que he hecho ha sido englobar el código que debe ejecutarse en una página u otra dentro de una función. Al final del código, ejecuto una función u otra apoyándome en las variables del dataLayer.
Te invito a que, si te interesa, eches un vistazo al código en el repositorio que he creado para ello en mi perfil de Github . El código está comentado, por lo que es fácil seguirlo.
Llamar al archivo javascript desde Google Tag Manager (GTM) para que se ejecute al cargarse el DOM
Ya tengo mi tracking migrado a un archivo javascript, ahora tengo que alojarlo en un servidor. Lo más fácil en estos casos es subir el fichero a un server que comparta dominio con tu site. De esta forma evitas problemas con llamadas a endpoints de terceros.
Para que este código javascript se ejecute, tengo que llamar al archivo cuando se carga mi página. Esto se puede hacer de muchas formas distintas, pero en un contexto como éste, voy a valorar las siguientes dos:
- Desde Google Tag Manager. Es la opción más sencilla, puedes controlar con facilidad en qué momento llamar al fichero.
- Desde código fuente. Esta opción es un poco más compleja, ya que tienes que desarrollar la lógica para controlar en qué momento quieres llamar al archivo. Pero te permite desacoplar por completo el desarrollo de GTM.
Si optas por llamar a tu fichero desde GTM (yo lo haría), puedes optar por una de las siguientes dos opciones:
-Implementar la llamada a través de un Custom HTML Tag. De esta forma crearías un script en tu DOM que llamaría al archivo javascript. Puedes probar con este código, fíjate:
<script>
(function() {
//Storing dataLayer in a local variable
var dataLayer = window.dataLayer || [];
//Creating script...
var trackerScript = document.createElement('script');
//Setting its source attribute...
trackerScript.src = 'https://analyticsimplementations.com/tests/tracker.js';
//Script loader must be asynchronous...
trackerScript.async = true;
//When script is loaded, push event to dataLayer
trackerScript.addEventListener('load', function() {
dataLayer.push({
event:'tracker_loaded'
});
});
//Add script to DOM
document.body.appendChild(trackerScript);
})();
</script>Como ves, el script está creado de tal forma que el recurso se cargará de forma asíncrona. Además, se añade un eventListener para que cuando se haya cargado, se ejecuté un dataLayer.push() a modo de notificación. Así puedo trabajar en GTM con la garantía de que el fichero ya está cargado.
En esta secuencia de capturas, puedes ver un CHTML Tag con el anterior código ejecutándose, lo que resulta en un elemento script añadiéndose a mi DOM y llamando al archivo tracker.js
-La segunda opción consiste en implementar la llamada al archivo javascript a través de un Custom Template. Esta es, de hecho, la forma correcta de hacer esto desde de Google Tag Manager. Los Custom Templates usan una serie de API’s propias y una versión de javascript que hacen que sea más seguro trabajar con JS.
Echa un vistazo a la Galería de plantillas comunitarias, seguramente encuentres una plantilla que te sirva para este propósito. Si no, siempre puedes usar el custom template que yo desarrollé al respecto. Te explico cómo usarlo en el post ‘JavaScript race conditions en Google Tag Manager (GTM): cómo evitar fallos al trabajar con scripts asíncronos con un Custom Template’. Usando este Custom Template, el resultado es el mismo que con el anterior ejemplo de CHTML Tag:
Llamar al archivo javascript desde el código fuente de tu site
Hasta aquí los approaches que puedes seguir para llamar al archivo javascript desde Google Tag Manager. Si quieres llamar al fichero desde tu código fuente, tienes que controlar bien en qué momento quieres llamar al archivo. La carga de estos ficheros debe ser asíncrona (salvo contadas excepciones), y puesto que mi código se apoya en la estructura del DOM, quiero evitar que se cargue antes de que el propio DOM esté disponible. Esto se puede conseguir de muchas maneras, y yo he optado por apoyarme en el evento ‘load’ que emite el objeto window cuando todos los recursos que componen la página se han descargado y por lo tanto están disponibles. De esta forma me aseguro de que el archivo javascript al que estoy llamando, que como te digo se apoya en la estructura del DOM, no vaya a dar ningún fallo. Fíjate en el siguiente código:
//Adding load event listener to window object and using the trackerSCript() function as an event handlder
window.addEventListener('load',
function trackerScript(e){
var script = document.createElement("script");
script.src = "/tests/tracker.js";
script.async = true;
document.body.appendChild(script);
}
); Como ves es algo muy sencillo. Añado un eventListener al objeto window para escuchar el evento load. Cuando éste se emite (y por lo tanto sé que la página está cargada), ejecuto la función trackerScript(), en donde construyo un elemento script que llamada a mi archivo tracker.js En las siguientes capturas de pantalla te muestro esta solución en acción.
En la anterior captura puedes ver cómo añado el código en el CMS en la cabecera de este site, aunque nunca se ejecutará hasta que el objeto window emita el evento load.
Reflexiones finales
Pues ahí lo tienes, acabas de ver en vivo y en directo el proceso a seguir para migrar una implementación de analítica -el tracking– de un TMS (Google Tag Manager en este caso) a un archivo javascript externo. Pero más allá de la miga técnica del asunto, lo que yo creo que subyace en este asunto es si es viable o no implementar el 100% del tracking desde un TMS.
En líneas generales la respuesta es sí, si puedes implementar analítica desde un TMS. Es una de las ventajas de estas herramientas: la flexibilidad que brindan. Pero bajo mi punto de vista, si el 100% de tu tracking está implementado desde GTM (o Tealium iQ o cualquier otro TMS), corres el riesgo de que tu implementación de analítica se vuelva frágil y de que se pueda romper con cualquier mínimo cambio de código en tu site. Es la desventaja de apoyarte en algo tan cambiante como el DOM (estructuras de nodos, clases, id’s, atributos, etc).
Hay un término medio que a mí me gusta mucho, y es el de trabajar con data-atributos semánticos en tu html. Estos atributos no tienen ninguna funcionalidad más allá de la de identificar semánticamente a los elementos de tu código. Añadiéndolos de forma selectiva a los nodos de tus DOM puedes aprovecharlos en tu tracking sin temor a que vayan a cambiar como si pueden hacerlo, por ejemplo, una clase o un id. El gran David Vallejo explica esto te maravilla en su artículo ‘Tracking Google Analytics 4 events using data attributes’. Te recomiendo que lo leas, a mi me ha ayudado un montón.