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?

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:

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:

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érmino	Descripción	Ejemplo
<nombre_proyecto>	Indica el nombre del proyecto	Datola, Luratic, Estrella Galicia

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.

Estilo	Estructura	Ejemplo
SNAKE_CASE	<NOMBRE_PROYECTO>_?<ENTORNO>_?<PLATAFORMA>	DATOLA_WEB_PRO DATOLA_ANDROID_PRE DATOLA_SS o DATOLA_SERVER_SIDE

Definición de términos:

Término	Descripción	Ejemplo
<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

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

Campo	Descripción	Ejemplos
Nombre de la versión	Debe 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ón	Contienen 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

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

Estilo	Estructura	Ejemplo
SNAKE_CASE	<TIPO>	CONSTANTS

Recomendación de carpeta por tipo:

Tipo	Descripción
CONSTANTS	Todas las variables de tipo constante.
COOKIE_VARIABLES	Todas las variables de tipo cookie.
DATALAYER_VARIABLES	Todas las variables de tipo dataLayer.
UNIVERSAL_ANALYTICS o GA3 o UA	Todas las etiquetas y variables de configuración relacionadas con Universal Analytics.
GA4	Todas las etiquetas y variables relacionadas con GA4.
CMP	Etiquetas relacionadas con el Consent Manager Platform.
LOOKUP_TABLE_VARIABLES	Todas las variables de tipo tabla de consulta.
ADVERTISING	Etiquetas de herramientas con propósito publicitario.
ANALYTICS	Etiquetas de herramientas con propósito analítico
MARKETING	Etiquetas de herramientas con propósito más marketiniano.
PIXEL_TAGS	Etiquetas de herramientas de terceros. A veces, no necesitamos bajar tanto al detalle.
REGEX_TABLE_VARIABLES	Variables de tipo tabla RegEx.
TEMPLATE_VARIABLES	Todas las variables de tipo template.
TRIGGERS	Todos los triggers o disparadores que su propósito principal sea el lanzamiento de etiquetas
EXCEPTIONS	Todos los triggers o disparadores que su propósito principal sea impedir que se lance una etiqueta.
UTILS	Todo aquello que sean utilidades.
FIXES	Todo aquello relacionado con los fixes.

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.

Estilo	Estructura	Ejemplo
SNAKE_CASE	<TIPO_ETIQUETA>_?<EQUIPO>_<NOMBRE>_?<FUNCIONALIDAD>_?<TÉRMINO_DESCRIPTIVO>	PX_DA_FB_PURCHASE PX_GADS_RMK TAG_HOME_ALTA_NEWSLETTER

Definición de términos

Término	Descripción	Ejemplo
<TIPO_ETIQUETA>	Indica el tipo de etiqueta usada	PX, 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 etiqueta	RMK CONVERSION LEAD
<TÉRMINO_DESCRIPTIVO>	Para distinguir entre etiquetas del mismo tipo, nombre y funcionalidad.	_LATAM

Tipos de etiquetas

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

Tipo	Descripción	Ejemplo
TAG	Etiquetas 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.
PX	Para todas aquellas etiquetas de terceros.	Etiquetas como Google Ads, Facebook, Hotjar.
CMP	Etiquetas relacionadas con los CMPs	Las etiquetas relacionadas con los CMPs como Onetrust, CookieBot, Osano, ConsentManager…
FIX	Reservado para correcciones y bugs. Su carácter debería de ser siempre temporal.	FIX_PRODUCT_PRICE
UTIL	Utilidades que no encajen en las categorías anteriores.	El custom html de la solución del rogue referrer en las páginas SPA.
TPL	Se utilizan para custom templates que no encajen en las categorías anteriores.

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.

Estilo	Estructura	Ejemplo
snake_case	<tipo>_?<equipo>_<funcionalidad>	trg_page_view, trg_add_to_cart, exc_portugal, exc_product_pages

Definición de términos

Término	Descripción	Ejemplo
<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

Tipos de triggers

Tipo	Descripción	Ejemplo
trg	Función principal lanzar las etiquetas	trg_add_to_cart, trg_purchase, trg_generate_lead trg_da_add_to_cart, trg_da_purchase, trg_da_generate_lead
exc	Funció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
trgrp	Grupo de activadores	trgrp_scroll_depth_and_time_spent trgrp_da_scroll_depth_and_time_spent

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.

Estilo	Estructura	Ejemplo
snake_case	<tipo>_?<equipo>_<nombre>	dl_page_title, js_products, cnt_ga4_id dl_da_page_title, js_da_products, cnt_da_ga4_id

Definición de términos

Término	Descripción	Ejemplo
<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

Tipos de variable

Tipo	Descripción	Ejemplo
url_ref	URL de referencia	url_ref, url_ref_hostname
url	URL	url_q_utm_source, url_protocol
ck	Cookie	ck_ga,
js	Javascript personalizada – Función GTM	js_products,
dl	Variable de capa de datos	dl_post_id, dl_user_id
js	Variable de Javascript – Variable global(windows)	js_navigator.userAgent, js_gaGlobal
dom	Elemento DOM	dom_checkout
aev	Variable de evento automático	aev_outbound
vis	Visibilidad del elemento	vis_add_to_cart
cnt o c	Constante	cnt_ga4_id, cnt_fb_id
event	Evento	event
gas	Google Analytics Settings	gas
env	Nombre del entorno	env
rnd	Número aleatorio	rnd
lt	Tabla de consulta	lt_fb_countries, lt_gads_id
rt	Tabla RegEx	rt_page_type
undefined	Valor undefined	undefined
container_id	ID de contenedor	container_id
debug_mode	Modo de depuración	debug_mode
container_version	container_version	container_version
fn_	Javascript personalizada que devuelve a otra función – A veces llamadas clousures	fn_set_cookie

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…).

Hoja de estilos: zonas

? -> Indica que el término es opcional.

Estilo	Estructura	Ejemplo
snake_case	zone_?<equipo>_?<funcionalidad>	zone_google_analytics zone_luratic zone_luratic_gads

Definición de términos

Término	Descripción	Ejemplo
<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 nombre	google_analytics

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.

• 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.
• GTM es una herramienta de gestión de etiquetas no la utilices para Test A/B.
• GTM es una herramienta de gestión de etiquetas, no la aproveches para otro tipo de tareas o fines. No estarás haciendo lo correcto.
• 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.