Cómo hacer implementaciones AMP eficientes con GTM

En un artículo anterior hacíamos una introducción a cómo trackear las páginas AMP con Google Analytics, en él mostrábamos cómo se configura Google Analytics para medir páginas AMP, y cómo se puede configurar de forma directa, o bien a través de Google Tag Manager.

A modo de resumen, en una implementación básica con GTM, justo después de la etiqueta <head> debe insertarse el siguiente código:

<!-- AMP Analytics --><script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>

Y justo después de la etiqueta <body> se añade este otro:

<!-- Google Tag Manager --> <amp-analytics config="https://www.googletagmanager.com/amp.json?id=GTM-XXXXXXX&gtm.url=SOURCE_URL" data-credentials="include"></amp-analytics> <script type="application/json">   {     "vars": {       "variable_1": "valor 1",        "variable_2":"valor 2"            //Añadir todas las variables aplicables en cada página     }   }   </script> </amp-analytics> 

La sección “vars” del JSON de configuración equivale al dataLayer de una implementación html, pero con el inconveniente de que es estático, debe estar definido desde el momento en que se genera la página y no podemos modificarlo por javascript, puesto que en AMP las funciones javascript están muy limitadas.

Esto nos impide mandar valores en respuesta a la acción de un usuario, por lo que la implementación de eventos más evidente es añadir al JSON una sección “triggers” en la que especificamos cuando se deben activar las etiquetas mediante selectores CSS.

Este método, aunque es la solución más obvia a la vista de la documentación, presenta dos inconvenientes: 

  1. El uso de selectores CSS lo convierte en una implementación fragil, que presentará una alta dependencia del diseño de la página. Si como selector usamos la clase “boton-azul” y en un rediseño pasa a ser “boton-rojo” los eventos dejarán de lanzarse. Y esto es algo que con seguridad, antes o después va a pasar.
  2. Definir un trigger para cada acción obliga a crear una etiqueta en GTM para cada uno de los triggers. Al hacer esto estamos introduciendo una complejidad de mantenimiento de GTM  proporcional al número de eventos definidos puesto que, además, en los contenedores AMP no existe la variable de configuración de Google Analytics, de modo que cada cambio que haya que hacer, hay que repetirlo una a una en todas las etiquetas.

Por ello, aunque es una configuración que funciona correctamente y puede ser útil para implementaciones sencillas vamos a mostrar una forma más eficiente de trabajar en implementaciones más complejas. 

Activar la API de ClientID de Google AMP

Antes de empezar con el detalle de la implementación de eventos, hay que recordar la necesidad de activar la API de ClientID en cualquier implementación AMP, pues es la que nos permitirá identificar a los usuarios que interactúan con el contenido en páginas AMP y en páginas de otro tipo. 

Al habilitarla, Google Analytics utiliza el ID de cliente de AMP para determinar los distintos eventos del sitio web que corresponden a cada usuario cuando este visita páginas AMP usando un visor de AMP de Google. Al asociar eventos y usuarios, puede aprovechar funciones como recuentos de usuarios y métricas basadas en sesiones.

Esta API hay que activarla tanto en las páginas AMP como en las páginas HTML, por lo que habrá que actuar en dos contenedores de GTM diferentes.

Se debe incluir el siguiente código en el <head> de todas las páginas AMP, previamente al código script de Google Tag Manager.

<meta name=»amp-google-client-id-api» content=»googleanalytics»>

Al activar la API se comparte el ID de cliente de AMP para asociarlo a las páginas AMP y no AMP, por lo que se debe incluir la advertencia en la política de privacidad sobre el uso del ID de cliente de AMP en relación con Google Analytics.

Limitaciones del uso de la API de ClientID de Google AMP

Si las páginas AMP se publican en un origen diferente al de otras páginas sin AMP que quiere utilizar con la API Client ID, el origen de todas las páginas debe seguir reglas específicas para que la API Client ID funcione:

  1. Los esquemas y los puertos siempre deben coincidir.
  2. Si se les quitan todos los prefijos, como m., amp. y www., los componentes de host del origen AMP y del origen canónico deben ser iguales.

Ejemplos de vinculaciones de origen AMP y origen sin AMP que funcionarán:

  • https://www.example.com (páginas AMP y páginas sin AMP en el mismo origen)
  • https://amp.example.com y https://www.example.com
  • https://m.example.com y https://www.example.com
  • https://amp.www.example.com y https://example.com
  • https://amp.example.com y https://m.www.example.com

Ejemplos de vinculaciones de origen AMP y origen sin AMP que no funcionarán:

  • https://www.example.com y http://www.example.com (el esquema no coincide)
  • https://www.example.com y https://www.example.com:8000 (el puerto no coincide)
  • https://amp.example.com y https://amp.google.com (como en una dirección se usa google.com en lugar de example.com, ambas direcciones no se consideran iguales)
  • https://amp.example.com y https://mobile.example.com (como en una dirección se utiliza mobile, las direcciones no se consideran iguales. Si en ambas se usara m., se considerarían iguales)
  • https://web.amp.example.com y https://web.m.example.com (en este caso, los componentes amp. y m. diferentes no son un prefijo del host)

Habilitar la API en páginas HTML

En la configuración de la etiqueta de Google Analytics para páginas HTML en GTM se deberá poner el campo allowLinker a TRUE para activar el seguimiento multidominio, y en la configuración de Google Analytics, añadir a la lista de exclusión de referencias los dominios de amp desde donde se esté sirviendo el contenido, como por ejemplo: amp.example.com,www.example.com

Implementación dinámica de eventos y variables

Y vamos ya con la implementación alternativa de eventos y variables. Para evitar el uso de un JSON complejo con triggers basados en selectores CSS, en lugar de mandar los datos desde el JSON vamos a usar atributos data, puesto que las variables AMP se pueden leer de ambas formas.

Esto es posible hacerlo para dos tipos de interacciones: clic, o visibilidad de un elemento.

Para gestionar el envío de eventos usaremos tres variables convertidas a atributos data:

  • data-vars-event-cat=»Categoría del evento»
  • data-vars-event-act=»Acción del evento»
  • data-vars-event-lbl=»Etiqueta del evento»

De ellos, la categoría es obligatorio que esté para que se lance el evento, puesto que lo utilizaremos como trigger en la configuración de GTM.

Además, si en algún evento de debe informar cualquier variable que no esté en el JSON de la página, se añadirá utilizando la misma técnica, con su nombre precedido de «data-vars-«.

Por ejemplo:

<span id=»test1″ class=»test1″ data-vars-event-cat=»Categoría del evento» data-vars-event-act=»Acción del evento» data-vars-event-lbl=»Etiqueta del evento» data-vars-search_term=»búsqueda»>Haga clic para generar un evento</span>

A la hora de poner los nombres de los atributos data hay que tener en cuenta como va a interpretarlos GTM. El inicio siempre debe ser “data-vars-” con guión medio. A continuación pondremos el nombre de la variable, pero si está formado por dos palabras y las separamos con un guión medio, desde GTM tendremos que leerlas convertidas a camelCase. Es decir, el atributo “data-vars-event-cat” que hemos mostrado se convertirá en la variable “eventCat” en GTM.

Si queremos mantener una separación visible entre palabras usaremos el guión bajo, por lo que el atributo “data-vars-search_term” del ejemplo lo leeremos en la variable “search_term”.

Teniendo en cuenta esto vamos a la configuración del contenedor AMP de GTM.

Configurar el contenedor AMP de GTM

En primer lugar tenemos que crear una variable de GTM por cada variable del JSON o atributo data que necesitemos usar, recordando lo mencionado respecto a la forma de interpretar los guiones medios en atributos data. 

Así las variables para definir el evento serían las siguientes:

Además, crearemos la variable “ampdocHost” que es un tipo especial de variable predefinida con la que podremos conocer el host que está sirviendo la página. Esta variable la mapearemos a una custom dimension y nos servirá para identificar cuando las visitas de AMP llegan a las páginas del dominio propio o de la caché.

No hay que olvidar que disponemos de diversas variables predefinidas que nos serán útiles, entre otras las que se muestran en la siguiente captura:

Además podemos definir variables desde parámetros del querystring

Con las variables ya creadas vamos a definir el tag básico de página vista. Para ello elegimos la etiqueta de Universal Analytics, la definimos de página vista,  y vamos mapeando todos los valores de dimensiones y/o métricas personalizadas. 


En los contenedores AMP no podemos configurar nada más, de modo que nos olvidamos de personalizar campos habituales. como la anonimización de IP, una página personalizada, etc. Además tampoco tenemos variable de configuración, así que es conveniente que no configuremos más etiquetas hasta que no tengamos la de páginas vistas lo más acabada y probada posible, pues esto nos simplificará el trabajo posterior.

Por último, como trigger elegimos el de All pages.

Una vez que la etiqueta de páginas vista está acabada, la duplicamos (evitando así repetir todo el trabajo de mapeado de variables) y la cambiamos a seguimiento de tipo evento. Esto habilitará los campos para definir los valores de categoría acción y etiqueta, que mapearemos desde las variables que hemos creado anteriormente.

Por último tenemos que crear el trigger que disparará cualquier evento que se produzca. Para ello le diremos a GTM que lance el evento cuando se haga clic (o cuando sea visible, según lo que queramos) en un elemento en el que exista el atributo data-vars-event-cat, valga, lo que valga.

Esto lo conseguimos con el selector CSS “[data-vars-event-cat]”, de modo que el trigger quedará así:

De este modo con una sola etiqueta de evento podemos registrar todos los clics en cualquier elemento. 

Si necesitáramos hacer saltar eventos cuando se muestre algún elemento habría que añadir otra etiqueta más en la que solo cambia tipo de trigger y controlaría todos los eventos de visibilidad de una vez.

Por último añadimos la etiqueta Conversion Linker para mejorar la atribución de conversiones y tendremos acabada la configuración de GTM. El resultado es un contenedor como este, con una etiqueta de eventos que controla todos los clics:

En lugar de uno como este con ¡72 etiquetas! para cada uno de los clics diferentes:


Oscar G. Peinado

Oscar G. Peinado

Share on facebook
Share on twitter
Share on linkedin
Share on email
6 min
Suscríbete a nuestra newsletter

Los mejores artículos de analítica digital para potenciar tu negocio.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Entradas relacionadas

Aproximación al CLV

El CLV o LTV es una métrica que representa el beneficio económico que obtiene una empresa de un usuario a lo largo del ciclo de relación entre ambos. En este artículo veremos diferentes versiones de esta métrica y cómo calcularlas.

4 minutos

Dificultad

¿Qué es Algolia? El motor de búsqueda para mejorar tu UX y CRO

En este post introducimos el motor de búsqueda Algolia. Este ofrece una API y herramientas de UX intuitivas para crear la experiencia de búsqueda definitiva y así mejorar la experiencia del usuario y aumentar la conversión.

2 minutos

Dificultad

Secuestro del navegador: cómo bloquear ad injectors

En este artículo describimos un problema que afecta sobre todo a sitios de ecommerce, el “secuestro” de navegadores por parte de programas maliciosos que muestran publicidad al usuario, con el objetivo de que finalice la conversión en sitios de la competencia.

6 minutos

Dificultad

Uso de librerías en Tealium

Cómo gestionar y utilizar las librerías en el gestor de etiquetas Tealium. Cuestiones a tener en cuenta, desventajas de usarlas y cómo solventar estas desventajas.

3 minutos

Dificultad