Guía de estilo y recomendaciones en GTM

Una de las patas principales y más importantes en la analítica digital es y será la recolección de los datos. Entender y comprender su naturaleza nos hará mejores.

Pensar que los alimentos nacen en el supermercado o que los datos aparecen mágicamente en tus herramientas solo te traerá problemas. No cuidar su recolección también, asúmelo.

Los alimentos no nacen en los supermercados y los datos no nacen en las herramientas.

Si arrojamos las semillas a la tierra nacen y terminan dando sus frutos, pero se plantan siguiendo una simetría casi perfecta y da igual que el proceso sea manual o se usen las máquinas más punteras. No me gustaría ver un campo de cultivo sin un orden y una harmonía.

Me encantaría ver y poder decir lo mismo de las herramientas del sector digital, empezando por los Tag Managers.

El estilo en GTM

El estilo es el estilo, construye uno o mucho mejor adapta uno ya existente. Hay muchas formas de hacer las cosas. Elige la tuya pero no reinventes la rueda. Hay gente que lleva jugando a esto, mucho tiempo. Cópialos, mejóralo y sobre todo comparte para que todos nos podamos beneficiar de tus avances y el sector pueda seguir evolucionando.

Nosotros te enseñamos: el estilo lurático. Nos encantaría debatirlo y mejorarlo contigo. Seguramente, en algún momento nuestras vidas se terminen cruzando. ¿No te molaría que hubiese un estilo común en las herramientas de analítica digital?

El estilo Lurático, nace con los amigos de profesión Txema y Alfonso e intenta poner en valor la analítica técnica, tantas veces oculta e infravalorada.
El estilo Lurático nace con los amigos de profesión Txema y Alfonso e intenta poner en valor la analítica técnica, tantas veces oculta e infravalorada.

Si la analítica técnica fuese una posición en el deporte no me cabe duda que sería como los mediocentros en el fútbol o los gregarios en el ciclismo. Si estás más ligado a esta parte, quiérete y si ya te quieres no te columpies.

El estilo si se hace bien hace equipo, hace comunidad. El estilo se va puliendo, se va retocando y sobre todo tiene que ir evolucionando. El estilo te permite jugar de memoria. Cambiarte de superficie proyecto y no sufrir tanto. Y con mucha suerte el estilo podrá ser recordado, copiado y mejorado. El estilo es estrategia, es fútbol de salón, es espectáculo, pero si somos más prácticos el estilo sentará unas bases, te ahorrará tiempo y te servirá de documentación.

He de decir que a nosotros, trabajar el estilo, las buenas prácticas nos ahorró horas de curro, pero sobre todo nos sirvió de motivación, de horas de charla y nos ayudó a reflotar nuestra lastrada autoestima.

Nomenclatura

Lo primero en un estilo es tener clara la nomenclatura y una nomenclatura que mole debe cumplir o tener por lo menos presentes los siguientes propósitos:

  • Descriptiva
  • Concisa y clara
  • Homogénea
  • Consistente

Esto nos ayudará a que todos los miembros del equipo bailemos al mismo ritmo que exista un orden, una conexión que nos facilite las tareas de depuración, cambios de proyecto, incorporación de gente nueva, las automatizaciones, la refactorización, las auditorías que a veces también tocan. Más cariño, más joga bonito y ya verás, menos curro 🤫

Nuestra nomenclatura, por norma general, seguirá la notación snake_case separando cada palabra o espacio en blanco por un guion bajo(_).

Un buen resumen del artículo en cuento a la nomenclatura y al estilo podría ser este:

Captura de Slack donde se resume el estilo Lurático.
Captura de Slack donde se resume el estilo Lurático.

A medida que los contenedores crezcan en número de etiquetas, triggers, variables o crezca el número de proyectos que gestionas. El estilo, las buenas prácticas, los procesos cobrarán cada vez más fuerza y serán tus mejores aliados.

Cuida tus herramientas digitales con el cariño y delicadeza que lo haría un artesano.

Volvemos a repetir lo de que ya sabemos que los estilos no se imponen, se van construyendo, evolucionado…pero ojalá si no tenías uno te sirva este como base y si ya lo tenías, ¿no te molaría hacer un estilo común?

A lo largo del artículo iremos hablando del estilo y dando recomendaciones de las diferentes partes que componen GTM:

Estructura de GTM
Estructura de GTM

Cuenta

Crearemos una cuenta por organización, activo digital, cliente, proyecto…

Aquí, no solemos ser muy rígidos ni en nomenclatura ni en estructura, pero sería fantástico que te hagas o lances preguntas para intentar averiguar como está estructurado o como se va estructurar el negocio.

Será útil para intentar replicar esa estructura tanto en GTM como en Google Analytics u otras herramientas digitales.

Te facilitará, a futuro, la gestión de permisos.

El gran Iñaki Huerta te lo cuenta más en detalle en este vídeo que puede ayudar a hacerte preguntas.

Hoja de estilos: cuenta

TérminoDescripciónEjemplo
<nombre_proyecto>Indica el nombre del proyecto Datola, Luratic, Estrella Galicia
Hojas de estilo: cuenta

Contenedores de GTM

Si antes te has parado a pensar, ahora, vuelve a hacerlo. Es importante crear una estrategia antes de comenzar una implementación. Hazte y haz preguntas, no hay preguntas malas, tampoco solución mala. Todas pueden tener sus ventajas.
Por lo general, cuántos menos contenedores, mejor.

¿Puedo tener más de un contenedor por página?

Sí, pero su uso está totalmente desaconsejado y puede ocasionar problemas de rendimiento. Por norma general, nunca más de un contenedor por página o por aplicación.

¿Son la misma plataforma o son plataformas diferentes web/app?

Como mínimo por limitaciones de la tecnología necesitamos un contenedor por cada plataforma (iOS, Android, Web).

¿Tenemos varios entornos de desarrollo?

Pues un contenedor de GTM para PRO y otro contenedor para los entornos de desarrollo(Dev, Stage, PRE). Aunque haya varios entornos de desarrollo, por norma general, usaría el mismo contenedor en todos los entornos.
Cuántos más contenedores haya más facilidad de que los contenedores de desarrollo y PRO no estén alineados. Esto incrementaría el trabajo de mantenimiento y suele derivar en que se termine haciendo todo directamente en el contenedor de PRO.

Lo ideal pero no siempre factible es que tanto entornos como contenedores de PRE y PRO sean lo más parecido posibles.

Lo de no tener entornos de desarrollo y usar siempre el contenedor de PRO con esta historia de los entornos me parece una castaña. Le veo más inconvenientes que ventajas. Lo de tener solo un contenedor, no me parece ni buena idea, ni buena práctica.

¿Desarrolla todo el mismo equipo? ¿Se usa en toda/s las webs la misma tecnología?

Si lo desarrolla todo el mismo equipo, un contenedor. Si hay varios equipos implicados cada uno de su padre y de su madre, diferentes tecnologías, diferentes etiquetados, diferentes tiempos de despliegue, podrías plantearte tener un contenedor para las diferentes casuísticas.
Pero vamos a tender a lo mínimo, siempre.

¿Vamos a tener en ellas una misma estrategia? ¿Son diferentes estrategias pero comparten flujos?

Si la estrategia es diferente, NO se comparte y es otro ente, con sus reglas y todos sus órganos independientes pues crearía un contenedor para cada historia. Pero no confundir, ente, con mil landings de captación.

Algo a tener en cuenta es que los entes diferentes se pueden agrupar y no necesariamente por cada ente se tiene que crear un contenedor.

Repito, tendemos siempre a lo mínimo pero buscando siempre la facilidad y comodidad en nuestro día a día.

¿Varios países o dominios?

Depende de la estrategia, pero a priori, un contenedor solo. No haría distinción ni por dominio, ni por país… Si ves que la cosa se complica, se vuelve liosa siempre habrá tiempo para crear otro.

Hoja de estilos: contenedores

? -> Indica que el término es opcional.
EstiloEstructuraEjemplo
SNAKE_CASE <NOMBRE_PROYECTO>_?<ENTORNO>_?<PLATAFORMA>DATOLA_WEB_PRO
DATOLA_ANDROID_PRE
DATOLA_SS o DATOLA_SERVER_SIDE
Hoja de Estilos: Contenedores de GTM

Definición de términos:

TérminoDescripciónEjemplo
<NOMBRE_PROYECTO>Indica la marca, empresa, activo digital al que aplica el contenedor.Datola
Luratic
Estrella Galicia
<ENTORNO>Indica el entorno al que aplica el contenedor.PRO
PRE
<PLATAFORMA>Indica la plataforma a la que aplica el contenedor.IOS
ANDROID
SS –> (Server Side)
WEB
Tabla de términos: Contenedores de GTM

Workspaces (Espacio de trabajo)

Los workspaces o espacios de trabajo son ese lugar temporal que nos permiten agrupar y gestionar los cambios en un mismo contenedor para que cada miembro o equipo pueda trabajar de forma independiente. Al publicar un workspace, se convierte automáticamente en una nueva versión del contenedor y ese espacio de trabajo desaparece.

¿Cuántos workspaces puedo tener creados simúltaneamente?

Puedes tener hasta 3 worskpaces en la versión gratuita de GTM y workspaces ilimitados si tienes Tag Manager 360.

¿Cuándo debería de crear un workspace?

SIEMPRE que vayas a hacer cualquier cambio en GTM.

No te lances a realizar cambios, probar configuraciones, añadir variables, etiquetas o triggers sin crear antes un workspace. Si estás tú solo, también. Será algo que ya tendrás adquirido el día que tengas compartir contenedor con otras personas, equipos, empresas…

¿Cuál es la forma más correcta de trabajar con los workspaces?

Crear un workspace por cada conjunto de cambios que estén relacionados y se vayan a publicar al mismo tiempo. Si los cambios no están relacionados aunque se publiquen el mismo día es recomendable separar las funcionalidades, configuraciones o implementaciones de herramientas de terceros en workspaces diferentes. Si algo falla es mucho más fácil de revertir.

¿Beneficios de trabajar con workspaces?

Crear un workspace de trabajo siempre que se necesiten hacer pruebas, cambios… Es la mejor práctica para evitar que otro usuario publique por error el workspace por defecto.

También es la mejor forma para trabajar con otros usuarios, equipos sin que nos pisemos los cambios.

¿Es obligatorio ponerle nombre y añadir una descripción?

SIEMPRE.

Tiempo que te ahorrarás en la publicación del contenedor. El nombre del workspace y la descripción forman parte del registro de versiones. Nos ayudará a identificar en que se está trabajando en la actualidad y al publicar nos quedarán ambos campos registrados en el historial de versiones. Algo muy útil para saber de un vistazo que se hizo y cuándo se hizo sin tener que ir pinchando.

Versiones

El historial de versiones nos permite visualizar de un plumazo lo que ocurrió en GTM a lo largo del tiempo. Por eso, es muy importante que cuando publiques rellenes de la forma más descriptiva y clara posible los campos: nombre de la versión y descripción.
Es muy habitual en este mundillo que algo se rompa, haya una caída de datos y necesites investigar si está relacionado con algún cambio hecho en GTM y ahí el historial de versiones será tu mayor amigo. ¿Con que historial de versiones te gustaría encontrarte?

Hoja de estilos: versiones

CampoDescripciónEjemplos
Nombre de la versiónDebe de ser lo más descriptiva y clara posible. Vamos, que de un vistazo sepas que se hizo.– Configuración Google Ads

– Se añaden nuevas dimensiones a GA4
DescripciónContienen de la forma más detallada y clara posible todos los cambios realizados. Si se usa un sistema de tareas puede ser muy útil incluir su enlace, aquí. Se configura el lanzamiento del píxel de Google Ads con id: 123456.

Se añaden los siguientes parámetros a GA4:
– author_id
– language
– section
Hoja de estilo: versiones
Publicar nueva versión GTM con los campos nombre y descripción cubiertos
Ejemplo de publicación con nombre y descripción de la versión en GTM

Carpetas

Las carpetas nos sirven para organizar y agrupar nuestras etiquetas, activadores y variables siguiendo un objetivo.

Durante muchos años dudé de la utilidad de las carpetas, pero un día nos hicieron una auditoría de GTM y tacharon en rojo el NO uso de carpetas. Desde aquella no hay contenedor que salga a producción y que no esté estructurado por carpetas.
A pesar de ser un creyente tardío de las carpetas, usarlas si que nos puede ayudar y mucho a mantener todo más organizado.

Como siempre es importante seguir un criterio y cumplirlo. Cada contenedor o cada proyecto tendrá los suyos. Lo mejor será siempre adaptarse.

Criterios que podríamos seguir para estructurar el contenido en carpetas:

  • Estructurar las carpetas por tipo, funcionalidad o consentimiento(publicidad, analítica…)
  • Estructurar las carpetas por equipos implicados en la gestión de GTM.
  • Estructurar por países.

Sigas el criterio que sigas muchas veces tendrás el dilema que muchas variables, triggers o etiquetas puedan ir en varias carpetas a la vez. Cuando se den estos casos, acuérdate siempre de seguir el mismo criterio.
Para no complicarnos mucho las variables y los triggers los metemos siempre en sus propias carpetas según tipología o fin. Son elementos, normalmente, de propósito general y que van a ser reutilizados con diferentes usos.

Solemos organizar las carpetas por tipo o propósito. Si la herramienta de terceros o proveedor, por ejemplo, un Facebook, un Google Analytics tiene una cantidad importante de lógica en el contenedor o relevancia como herramienta podemos crear una carpeta específica para ese proveedor.

Hoja de estilos: carpetas

EstiloEstructuraEjemplo
SNAKE_CASE <TIPO>CONSTANTS
Hoja de Estilos: Carpetas de GTM

Recomendación de carpeta por tipo:

TipoDescripción
CONSTANTSTodas las variables de tipo constante.
COOKIE_VARIABLESTodas las variables de tipo cookie.
DATALAYER_VARIABLESTodas las variables de tipo dataLayer.
UNIVERSAL_ANALYTICS o GA3 o UATodas las etiquetas y variables de configuración relacionadas con Universal Analytics.
GA4Todas las etiquetas y variables relacionadas con GA4.
CMPEtiquetas relacionadas con el Consent Manager Platform.
LOOKUP_TABLE_VARIABLESTodas las variables de tipo tabla de consulta.
ADVERTISINGEtiquetas de herramientas con propósito publicitario.
ANALYTICSEtiquetas de herramientas con propósito analítico
MARKETINGEtiquetas de herramientas con propósito más marketiniano.
PIXEL_TAGSEtiquetas de herramientas de terceros. A veces, no necesitamos bajar tanto al detalle.
REGEX_TABLE_VARIABLESVariables de tipo tabla RegEx.
TEMPLATE_VARIABLESTodas las variables de tipo template.
TRIGGERSTodos los triggers o disparadores que su propósito principal sea el lanzamiento de etiquetas
EXCEPTIONSTodos los triggers o disparadores que su propósito principal sea impedir que se lance una etiqueta.
UTILSTodo aquello que sean utilidades.
FIXESTodo aquello relacionado con los fixes.
Tipos de Carpetas en GTM

Tags (etiquetas)

Las etiquetas son fragmentos de código, normalmente herramientas de terceros que se lanzan en tu página mediante triggers. Son el núcleo de GTM. Por regla general, cuántas menos etiquetas más fácil será trabajar en el contenedor.

Hoja de estilos: tags

? -> Indica que el término es opcional.
EstiloEstructuraEjemplo
SNAKE_CASE<TIPO_ETIQUETA>_?<EQUIPO>_<NOMBRE>_?<FUNCIONALIDAD>_?<TÉRMINO_DESCRIPTIVO>PX_DA_FB_PURCHASE
PX_GADS_RMK
TAG_HOME_ALTA_NEWSLETTER
Hoja de Estilos: Tags de GTM

Definición de términos

TérminoDescripciónEjemplo
<TIPO_ETIQUETA> Indica el tipo de etiqueta usadaPX, GA4
<EQUIPO> Siglas o abreviatura del equipo, empresa, agencia que realiza la implementación.
Esto es muy útil en GTM gestionados por diferentes empresas o equipos. Nos permite distinguir de un vistazo quién hizo cada cosa y saber de forma sencilla a quién dirigirnos ante cualquier problema o duda.
DA, LU
<NOMBRE> Nombre de la herramienta, aplicación o propósito.
En caso de nombres de herramientas se intentarán usar abreviaturas siempre que se consideren descriptivas:
Facebook: FB
Twitter: TW
Google Ads: GADS
FB
CLARITY
GADS
<FUNCIONALIDAD> Nos indica el uso o la finalidad de la etiquetaRMK
CONVERSION
LEAD
<TÉRMINO_DESCRIPTIVO> Para distinguir entre etiquetas del mismo tipo, nombre y funcionalidad. _LATAM
Tabla de términos: Tags de GTM

Tipos de etiquetas

Entre los tipos de etiquetas más usados por nosotros podemos encontrar los siguientes:

TipoDescripciónEjemplo
TAGEtiquetas que se usan para etiquetar la web. Una custom html que haga un push al datalayer al pulsar los botones de suscripción a la newsletter.
PXPara todas aquellas etiquetas de terceros. Etiquetas como Google Ads, Facebook, Hotjar.
CMPEtiquetas relacionadas con los CMPsLas etiquetas relacionadas con los CMPs como Onetrust, CookieBot, Osano, ConsentManager…
FIXReservado para correcciones y bugs. Su carácter debería de ser siempre temporal. FIX_PRODUCT_PRICE
UTILUtilidades que no encajen en las categorías anteriores. El custom html de la solución del rogue referrer en las páginas SPA.
TPLSe utilizan para custom templates que no encajen en las categorías anteriores.
Tipos de etiquetas en GTM
Tipos de etiquetas contenedor de GTM de Datola
Ejemplo de tipos de etiquetas en el contenedor de GTM de Datola.

Triggers (disparadores)

Son los encargados de lanzar los tags(etiquetas).

Intentaremos hacerlos lo más reutilizables posibles para poder reutilizarlos en todas las etiquetas que tengan una misma funcionalidad.
Ejemplo de funcionalidades: Añadir a la cesta, ver producto, confirmación de compra…
Si lo hacemos así cuando falle una etiqueta/herramienta que se lanza en X funcionalidad fallan todas. Mucho más fácil de encontrar el problema y mucho más fácil de aplicar la solución. Aplicándola en 1 sitio afectará a N etiquetas.

Para condicionar las etiquetas de una forma más específica utilizaremos, normalmente, los inhibidores o exceptions. De esta forma, conseguimos que los triggers e incluso las excepciones sean lo más reutilizables y genéricas posibles.
Usamos inhibidores para controlar y condicionar temas como: las cookies, el país, tipos de página, estado de usuario…

Esto ayudará en gran medida a mantener escalable el contenedor de GTM.

Hoja de estilos: triggers

? -> Indica que el término es opcional.
EstiloEstructuraEjemplo
snake_case<tipo>_?<equipo>_<funcionalidad>trg_page_view, trg_add_to_cart, exc_portugal, exc_product_pages
Hoja de Estilos: Triggers de GTM

Definición de términos

TérminoDescripciónEjemplo
<tipo>Indica la función del trigger.exc
trg
<equipo> Siglas o abreviatura del equipo, empresa, agencia que realiza la implementación.
Esto es muy útil en GTM gestionados por diferentes empresas, equipos. Nos permite distinguir de un vistazo quién hizo cada cosa y saber de forma sencilla a quién dirigirnos ante cualquier problema o duda.
da, lu
<funcionalidad> Indica la funcionalidad, finalidad del trigger o inhibidor.add_to_cart
purchase
Tabla de términos: Triggers de GTM

Tipos de triggers

TipoDescripciónEjemplo
trgFunción principal lanzar las etiquetastrg_add_to_cart, trg_purchase, trg_generate_lead
trg_da_add_to_cart, trg_da_purchase, trg_da_generate_lead
excFunción principal evitar el lanzamiento de las etiquetas. exc_blog_pages, exc_fb, exc_advertising_cookies, exc_hotjar, exc_portugal
exc_da_blog_pages, exc_da_fb, exc_da_advertising_cookies, exc_da_hotjar
trgrpGrupo de activadorestrgrp_scroll_depth_and_time_spent
trgrp_da_scroll_depth_and_time_spent
Tipos de triggers en GTM
Ejemplos de triggers contenedor de Datola
Ejemplos de triggers/inhibidores en el contenedor de Datola.

Variables

Usaremos siempre variables para alimentar nuestras etiquetas y triggers y evitaremos los valores hardcodeados.

Todas nuestras variables GTM irán prefijadas con el tipo de variable.

Hoja de estilos: variables

? -> Indica que el término es opcional.
EstiloEstructuraEjemplo
snake_case<tipo>_?<equipo>_<nombre>dl_page_title, js_products, cnt_ga4_id
dl_da_page_title, js_da_products, cnt_da_ga4_id
Hoja de Estilos: Variables de GTM

Definición de términos

TérminoDescripciónEjemplo
<tipo>Indica el tipo de variable.dl, lt, js
<equipo> Siglas o abreviatura del equipo, empresa, agencia que realiza la implementación.
Esto es muy útil en GTM gestionados por diferentes empresas, equipos. Nos permite distinguir de un vistazo quién hizo cada cosa y saber de forma sencilla a quién dirigirnos ante cualquier problema o duda.
da, lu
<nombre> Nombre de la variable intentará ser siempre lo más descriptivo y claro posible.
Si la variable hace referencia a una herramienta el nombre será la herramienta a la que hace referencia + su funcionalidad.
En el caso de variables del dataLayer o variables globlales de javascript el nombre de la variable será el mismo que nos encontremos en el dataLayer o en window. Incluyendo los puntos que marcan la ruta completa y anidamiento de la propiedad.
Podemos omitir en este último caso la palabra window.
products, fb_countries
fb_id
navigator.language
Tabla de términos: Variables de GTM

Tipos de variable

TipoDescripciónEjemplo
url_refURL de referenciaurl_ref, url_ref_hostname
urlURLurl_q_utm_source, url_protocol
ckCookieck_ga,
jsJavascript personalizada – Función GTMjs_products,
dlVariable de capa de datosdl_post_id, dl_user_id
jsVariable de Javascript – Variable global(windows)js_navigator.userAgent, js_gaGlobal
domElemento DOMdom_checkout
aevVariable de evento automáticoaev_outbound
visVisibilidad del elementovis_add_to_cart
cnt o cConstantecnt_ga4_id, cnt_fb_id
eventEventoevent
gasGoogle Analytics Settingsgas
envNombre del entornoenv
rndNúmero aleatoriornd
ltTabla de consultalt_fb_countries, lt_gads_id
rtTabla RegExrt_page_type
undefinedValor undefinedundefined
container_idID de contenedorcontainer_id
debug_modeModo de depuracióndebug_mode
container_versioncontainer_versioncontainer_version
fn_ Javascript personalizada que devuelve a otra función – A veces llamadas clousuresfn_set_cookie
Tipos de variables en GTM

Información adicional

Built-in Variables (Variables Integradas)

Este tipo de variables no permiten configuración y solo las activaremos cuándo las vayamos usar.

Custom Javascript

Los custom Javascript siempre tienen que retornar algo, puede ser un valor u otra función. En el segundo caso, la nomenclatura tendrá que empezar por fn_.

Javascript Variable

Este tipo de variable nos será muy útil, siempre que tengamos que utilizar una variable global en varios sitios(tags, variables). Si en el futuro cambia el nombre de la variable global o decidimos mandar en el píxel otro valor solo tendremos que ir a un único sitio a hacer el cambio.

Constantes

Siempre, siempre, siempre utilizaremos constantes para aquellos valores estáticos alimenten a nuestras etiquetas.

Zonas

Funcionalidad disponible solo para Google Tag Manager 360. Las zonas funcionan como contenedores secundarios y entre sus principales utilidades está la de poder restringir el acceso al contenedor principal a personas y a empresas de terceros. Te ayudan a tener mucho mayor control y seguridad sobre lo que se ejecuta en tu página.
Al agregar una zona, tienes la posibilidad desde el contenedor principal de elegir las páginas en las que quieres que se ejecute el contenedor secundario y también te permite definir lo que quieres que se ejecute(tipo de etiquetas, tipo de variables…).

Zonas de GTM
Zonas de GTM

Hoja de estilos: zonas

? -> Indica que el término es opcional.
EstiloEstructuraEjemplo
snake_casezone_?<equipo>_?<funcionalidad>zone_google_analytics
zone_luratic
zone_luratic_gads
Hoja de Estilos: Zonas de GTM

Definición de términos

TérminoDescripciónEjemplo
<equipo> Equipo, organización o empresa que va a utilizar la zona.luratic
<funcionalidad> Si la zona va a tener una funcionalidad concreta lo indicamos en el nombregoogle_analytics
Tabla de términos: Zonas de GTM.

Notas

Añade notas a todo lo que hagas en GTM. Nos permitirán saber que hace un elemento sin necesidad de descifrar, probar el código programado.

Lo agradecerá tu yo del futuro y será la mejor documentación de GTM que podrás hacer y tener.

Vista previa (preview)

Antes de publicar cualquier cambio debemos siempre probar y comprobar que todo funciona de la forma que esperábamos.

Acuérdate, que todo lo que publicamos en GTM es código que directamente propagamos/inyectamos en nuestra web/app. Código que puede provocar comportamientos anómalos con los que no contábamos.

No te confíes nunca e insistimos prueba siempre tus desarrollos antes de publicar.

Como buena práctica habitúate a hacer como mínimo un flujo que pase por todos los pasos críticos(compra, registro…) de tu web o app y consigue minimizar en la medida de lo posible los riesgos.

Recuerda que el modo preview es una capa(código) que se añade a tu página, por eso, aunque en modo preview funcione no garantiza que en el paso a producción se comporte todo exactamente igual. Es conveniente y obligatorio volver a revisar una vez publicado los cambios.

No seas de gatillo fácil y prueba siempre los cambios.

Publicación

Repetimos, antes de publicar, acuérdate siempre de probar los cambios y comprobar que todo es correcto.

Una vez publicado el contenedor tendremos que volver a hacer como mínimo un flujo completo que pase por todos los pasos críticos de nuestra web o app y haremos especial hincapié en aquellos sitios en los que los cambios, a priori, afectan.

Como norma general y por vuestra salud nunca publicaremos minutos antes de marchar de la oficina, los vísperas de festivo y los viernes.

Herramientas de apoyo

Acuérdate de la regla del Boy Scout e intenta poco a poco dejar tus contenedores de GTM documentados y con un estilo homogéneo e uniforme. A la larga te ahorrarás mucho tiempo.

Las siguientes herramientas también te pueden ayudar en esta tarea:

  • GTM Tools de Simo Ahava: Genera automáticamente la documentación de la última versión de tu contenedor, etiquetas, activadores y variables de Google Tag Manager y permite actualizar en lote el campo notas.
  • Extending Simo Ahava’s Superb GTM Tools fork por QA2L: Es un fork del complemento anterior y añade soporte para mover etiquetas, triggers y variables a carpetas, nos permite extraer el historial de versiones del contenedores entre otras cosas…
  • Google Tag Manager Renamr por Measure School. Puede ser útil para renombrar etiquetas, triggers y variables en lote.
  • SandoGTM de Jason. Esta última la usamos para eliminar en lote variables, triggers y tags que no están en uso en el contenedor.

Consejos y recomendaciones generales en GTM

Como lo anterior quedó denso, espeso y no responsive y en su día Txema, Alfonso y servidor decidimos que tener un listado de puntos sería una buena forma de evangelizar. Pues eso, ahí os van:

  • Evitaremos siempre que sea posible el uso de Custom HTML.
  • Siempre que exista la posibilidad de usar la plantilla predefinida de una etiqueta(tag) se utilizará este método en detrimento de otras historias.
  • En caso de usar plantillas (custom templates) de la comunidad, revisar siempre su código y funcionamiento interno.
  • En el caso de usar Custom HTML se debe encapsular siempre que sea posible el contenido javascript en una función anónima.
Función anónima en GTM
Función anónima en GTM
  • Para evitar peligros con el uso de los Custom HTML, recomendamos envolver el código javascript con un Try-Catch
  • Si vamos a usar un script que haga uso del document.write, por seguridad, marcar la opción en el editor del Custom HTML.
  • Cualquier valor que se use en más de una etiqueta, trigger… se debe utilizar siempre haciendo uso de una variable de GTM.
  • Añadir notas a todo, siempre. Son la mejor forma de documentar un contenedor GTM.
  • Las condiciones de los triggers deben de ser claras y sencillas.
  • Cualquier condición que no quede clara y visible a simple vista tendríamos que intentar abordarla de otra forma como, por ejemplo, externalizando a un js|lt.
  • Si tenemos que aplicar una misma condición o excepción a los disparadores de varias etiquetas de una misma herramienta, por claridad, lo haremos en forma de inhibidor. Hacerlo así nos permite ver de un vistazo qué es lo que lo activa y lo que lo inhibe, sin tener que ir comprobando uno por uno la lógica de la condición.
  • Siempre que necesitemos datos del dataLayer en una etiqueta, debemos de lanzar la etiqueta con ese evento del dataLayer. Usar otros eventos no nos garantiza el volcado de la información.
  • Usar siempre workspaces con un nombre y una descripción.
  • Antes de publicar comprobar siempre en modo preview.
  • Al publicar o al crear una nueva versión, rellenar siempre los campos nombre y descripción.
  • En los proyectos tochos y salvo que sea estrictamente necesario no hacer uso de los eventos automáticos como el click, scroll… Relentizan bastante el modo preview y pueden provocar problemas de rendimiento.
  • Reducir y agrupar el número de etiquetas haciendo uso de las variables. Acuérdate, en la mayoría de ocasiones, menos es más.
  • Pausar etiquetas es una medida temporal. Si la etiqueta no se va a volver a utilizar o lleva un tiempo en cuarentena, la eliminamos sin miramientos.
  • Dar permisos de publicación a la gente correcta.
  • Usar constantes siempre que haya que reutilizar un mismo valor o uses valores estáticos.
  • Usar carpetas para mantener todo lo más organizado posible.
  • Prueba siempre tus cambios.
  • Por norma general, no necesitas implementar gtag.js si utilizas GTM.
  • Este enlace es cremita.
  • Si las cosas no nos salen. Nos relajamos, nos tomamos un respiro y a la vuelta seguimos.
  • En plantillas personalizadas las que aparecen con el sello Luratic son de confianza.
  • Si tienes cualquier duda técnica, visita siempre el blog de Simo Ahava.
  • Y si las dudas siguen, saluda primero y pregunta siempre.


Si esto se puede disfrutar, disfrútalo. Si te ha gustado comparte y si te gustaría añadir o rebatir cosas estaríamos encantados de poder hacerlo.

Brais Calvo
Brais Calvo

Más de 5 años en esto, solo sé que no se nada pero me motiva y me divierte la parte más técnica de los datos. Los entresijos, las anomalías y las automatizaciones. No os voy a engañar, los datos chorra son mi fuerte. Lo que sé me gusta contarlo y normalmente ya está Simo Ahava para documentarlo.

Necesitas compartirlo y lo sabes!

Deja un comentario