Cuidado si usas entornos y workspace en GTM

De todos es sabido que cuando se trata de un gestor de etiquetas hay que andarse con mucho cuidado para no acabar liándola. Si a eso le sumas que, en la mayoría de los casos, son más de una las personas responsables de estos cambios el lío que se puede formar, sin una buena organización, está más que asegurado.

Workspace

Por eso se crearon los espacios de trabajo o workspace de GTM, para que el trabajo en paralelo en un mismo contenedor no fuera tan peligroso. Por defecto GTM viene con un único workspace.

Además podemos crear 2 espacios de trabajo más, en el caso de los 360 es ilimitado. Lo que hay que tener en cuenta es que estos workspace lo que hacen es trabajar sobre la última versión del contenedor. Esto quiere decir que si creamos un espacio nuevo, inicialmente este espacio tendrá todos los tags, triggers y variables que tenga la última versión creada. Otra cosa importante, es que cuando publicas un contenedor o creas una versión, éste desaparece. Están pensados para que se pueda trabajar en paralelo de manera puntual. Si quieres volver a tener un espacio una vez publicado, tendrás que creártelo otra vez.

Ahora bien, imaginemos que creamos 2 espacios, uno pensado para aquellos usuarios que suelen meter tags publicitarios o pixels, y otro para temas más técnicos.

En el mismo momento, tenemos a un IT creando unos tags para unos eventos en su workspace, y a uno de marketing en el otro workspace porque está poniendo un tag de adwords. Este último es más rápido y publica sus cambios mientras el primero sigue editando tus tags en el otro espacio.

El workspace de marketing habrá desaparecido con la publicación, pero en el workspace de IT le aparecerán diferentes mensajes advirtiéndole de la existencia de una nueva versión y que tiene que actualizar su espacio de trabajo.

No podrá publicar ni crear una nueva versión sino actualiza antes, de esta manera se asegura que los cambios hechos por el de marketing se incluyan en su workspace y que la publicación de IT no machaque la versión del de marketing.

¿Qué pasa si el usuario de un workspace toca un tag que también está tocando el usuario del otro workspace?

En este caso, al actualizar la versión, advertirá de un posible conflicto, se verá de manera directa dónde se produce ese conflicto y con quién.

Además, se puede resolver viendo de manera más profunda cuáles son esos cambios que han creado el conflicto. Es importante destacar que el cambio es de la última versión con el workspace actual.

Hay 3 tipos diferentes de cambios:

  • Verde: se ha añadido un elemento nuevo.
  • Rojo: se ha eliminado un elemento.
  • Azul: se ha producido un cambio diferente sobre el mismo elemento.

Una vez solucionado el conflicto, se guarda y listo. Hasta aquí uno puede pensar que todo es correcto, que no puede pasar nada si se va con cuidado.

Pero ojo! ¿Qué pasa si introducimos el término entornos de GTM?

Nuestro compañero Javier nos habló de los entornos de GTM en un excelente post, nos enseñó qué son, para qué pueden servir y cómo crearlos.

Enviroments

Así que ahora imaginémonos que estamos desarrollando una nueva implementación y que ésta queremos probarla en un entorno de preproducción, a la vez que tenemos un entorno “live” que será el de producción.

Cada vez que publiquemos deberemos escoger el entorno donde queremos publicar, si es “live” será en producción, o si es “PRE” que será el entorno que hemos creado para preproducción/desarrollo.

Puede parecer limpio a primera vista, el problema es que con cada publicación que se realice se crea una nueva versión del workspace, con lo cual te obligará a actualizar la versión independientemente del entorno en el que hayas publicado.

Así que si un usuario hace una publicación en el entorno PRE, se creará una nueva versión del contenedor que pasará a ser la “latest version”. Todos los workspace que hayan avisarán que hay una nueva versión y que es necesario actualizar.

¡CUIDADO!

Si le das a actualizar y previamente en tu espacio de trabajo no habías tocado ningún elemento, no te avisará de ningún conflicto y sin embargo, con esa actualización, se te habrán añadido todos los elementos y cambios que se hayan hecho en el entorno de preproducción. Si lo que querías era publicar algo en producción, con este merge lo que pasará es que subirás todo lo que había en preproducción a producción.

Sino te das cuenta, puedes liarla muy gorda, y enterarte días después porque de repente ya no estás recibiendo las transacciones o directamente no te llega ningún dato ya que se están enviado todos los hits a la UA de test, por ejemplo!

¿Cómo puedo evitar esto?

Pues por ahora, aunque es algo sucio, lo que puedes hacer es irte a las versiones y marcar la que te interese en cada caso como “última versión” ya que el workspace se actualizará con esos datos. O sea, que cuando hagas una publicación tienes que dejar claro si se trata de un cambio para PRE o para PRO, y restaurar la ultima versión que te sea válida en cada momento dependiendo de si quieres el workspace que contenía las cosas de PRO o de PRE.

Sí, lo sé, esto no mola nada. Pero si uno se empeña en usar los entornos de GTM de esta manera no he encontrado una mejor solución, si tú sabes de alguna, por favor házmela saber xD

Otra cosa es que te crees una lookuptable donde pongas los diferentes entornos que hay y mandar cada cosa a su sitio. Pero entonces no se hace uso de los entornos de GTM que era de lo que se trataba.

 

Leave Comment

Your email address will not be published. Required fields are marked *