Como ya sabréis, Adobe Launch es el “nuevo” tag manager de Adobe, dentro de poco será el único, ya que DTM está a punto de cerrar sus puertas. Previsiblemente, a final de año, DTM dejará de funcionar y, aproximadamente, en otoño ya no se podrán editar las propiedades.
Antes de ponernos a hablar sobre las peculiaridades de este tag manager deberíamos saber qué es, si no lo sabemos o tenemos alguna duda, os dejo un post que, si bien es antiguo, nos ayudará a entender cómo funciona un tag manager.
En Launch las configuraciones y el código que debemos insertar se reparte en tres pestañas: reglas, data elements y extensiones. El orden normal de ejecución es: primero las extensiones, a continuación las reglas y los data elements solo cuando se les llama (como si de una función se tratara).
Una vez sabido esto, entremos más en detalle sobre las reglas.
Las reglas en Launch tienen, a priori, un comportamiento sencillo. Se dividen en tres partes: eventos, condiciones y acciones. Los eventos son los “triggers” o disparadores de la regla, nos dicen cuándo se va a activar esta regla. Las condiciones, como su nombre indica, nos dirán si una regla se dispara o no en base a los parámetros que deseemos. Y las acciones son lo que esta regla hace, así, muchas de las extensiones disponibles en Launch nos permiten añadir acciones predeterminadas de dicha extensión, como, por ejemplo, un set Variables de Adobe Analytics.
Centrándonos en los eventos, la extensión CORE nos brinda muchas posibilidades para “disparar” una regla, como un click, un evento o una direct call, entre otras. Si nos centramos en el grupo de page load rules, que, son quizás las más utilizadas, por orden de ejecución son: library loaded, page bottom, dom ready, window loaded. Según el propio Adobe, siempre van a cargar primero las reglas que estén en library loaded, y, en función del order que podemos poner en estos eventos, podemos jugar con ellas un poco. Si quieres saber más te dejo este enlace a la documentación oficial.
Pero… ¿qué pasa si no usamos la regla tal y como está diseñada?, ¿y si queremos un conjunto de funciones definido lo más pronto posible dentro de la página? Pues bien, podemos usar los eventos de la rule configurados como custom code. En él, insertamos dentro nuestras funciones o lo que queramos y el resto de la regla vacía. De esta manera, conseguimos tener nuestras custom code, cargado antes de que se ejecuten las reglas que tenemos definidas con eventos de library loaded.
Os dejo una captura de estas reglas de prueba y el custom code que llevan dentro.
Pues bien, si en una librería metemos estas dos reglas e insertamos el script en una página, el resultado por consola sería este:
Efectivamente, se ejecuta antes la regla cuyo evento es custom code, por lo que podemos utilizarlo para declarar funciones, o incluso, para hacer comprobaciones por custom code, y, como nos muestra Launch, llamando a la función trigger() se ejecutaría antes nuestra rule.
Pero, es más ¿qué pasaría si metemos una extensión como, por ejemplo, la de Adobe Analytics, y realizamos la misma prueba?
Para realizar esta prueba se ha dejado la extensión de Adobe Analytics vacía y se ha insertado ese mensaje por consola dentro del custom code de la propia extensión.
Pues bien, nuestra regla carga antes que la extensión de Adobe Analytics.
Este truco viene muy bien para pequeñas piezas de código que necesitamos que se ejecuten lo antes posible, pero, recordad que todo esto se ejecuta de forma asíncrona y, si el contenido de nuestro custom code es muy grande, puede que se llegue a ejecutar después de las extensiones e, incluso, otras reglas.
