During my time at Quimbee since 2021 - 2024, I was one of the developers that was the maintainer of the marketing side of Quimbee’s applications so I interacted a lot with the marketing team to deal with marketing related scripts and SEOs. The standard tool for injecting marketing script is Google Tag Manager. During that time, we have moved from Google Tag Manager to Cloudflare Zaraz and back to Google Tag Manager.

Originally, the product owner of Google Tag Manager are solely on the marketers. Whatever tags or scripts they want to introduce was on them. This created a few issues:

Performance

Security

Maintainance

Because GTM allows for as many scripts you want to inject, having more Javascript can increase page load time, and this can affect APDEX score if you want to measure this on Page speed. Since there’s no maintainer / dev owner to sign off on what is allowed to be added or whatnot, a script can be introduced which would slow down site performance.

If a developer have a sprint planned to work on paying off tech debt or they build a feature that wasn’t the cause of the slowdown, it becomes difficult to diagnose the issue unless both teams are on the same page and then metrics can be measured.

Because marketers are the ones with main access to Google Tag Manager and have publish permissions, they can publish whatever they want whenever they want before a developer can audit and approve of it. This would allow someone to accidentally introduce arbritary insecure Javascript code which can be a system exploit or a cryptominer if the code was malicious.

Because there are no set standards and developers aren’t following the lifecycle of the marketing scripts, why it is being introduced, and what is it trying to accomplished, it is harder to pinpoint exactly what is needed and what is not.

For example, sometimes a marketer wants to track certain metrics and data. They add the snippets to GTM, but do not adhere to a naming structure. They might make a mistake or named something unconventional and someone else may need to make an update on that marketing tag. It’ll be hard to pinpoint what tag that is.

Also when syncing between developers and marketers, there are certain conversion tracking that will require additional developer work such as additional information to pass to a Javascript dataLayer. If it’s hard to pinpoint which script requires what dataLayer in Google Tag Manager, trying to sync the work for it would be a nightmare to maintain.

This was done around 2022. Since we were already managing our website through Cloudflare, we looked into Zaraz as there was an article by one of companies that was an early adopter (probably Zapier) and they boasted that it heavily increased their front end web performances significantly. Zaraz at the time was barely acquired by Cloudflare and was considered to be in beta as they’re doing some extra work on it.

This article by Julian Juenemann on Measure School covers how to use Zaraz very well and I’ve pretty much setup and utilize it in a similar fashion. We did created 3 different environments for our Zaraz setup for each tool (production, staging, development).

Simple and straight forward interface

Loads 3rd party tools in the cloud away from browser

Not as much ability to organize tags / triggers when needed

Not many marketers are familiar with the tool

Becomes expensive when your site have high traffic

Cannot handle complex marketing conversion requirements

Unsure about the future of Cloudflare business model when it comes to pricing for Zaraz

Due to future requirements for complex marketing tracking and data collection plus contractors who are not familiar with Zaraz, Zaraz couldn’t meet the marketing tracking requirements that was provided so we need to migrate back to Google Tag Manager.

We ended up migrating back to Google Tag Manager, but we started with a new setup since the old setup was too convoluted. This time we made sure to do the following:

Create 3 separate environments for development, staging, and production

Set a naming standards to maintain consistency across each tags and triggers

Document what we are doing and why it is needed in Google Tag Manager

Allow publish permissions only to those who needs it

Reasons for switching back from Zaraz to Google Tag Manager:

Cost

Familiarity

Complex marketing tracking requirements

Things that can do better:

Individual marketing tools should have their own environment configurations

Our main front end tools for tracking a lot of metrics are GA4 and Facebook pixel. I think those are industry standard most common tools that a lot of teams used to measure their metrics. The marketing team in this case controls those tools whereas the development team have the final say on Google Tag Manager (as injecting scripts have a direct impact on APDEX scores). The unfortunate part in regards to the current setup with GA4 / Facebook Pixel accounts are that there are only 1 environment setup for the 2 tools.

In this case, the staging and development setup for GTM will point to nothing because we don’t want to include fake data into a production environment as marketing statistics, otherwise we would skew the sample. If we have a staging environment for the individual marketing tool, it might be easier for marketing teams to test the setup to see if data are actually populating or not vs only relying on Google Tag Manager testing tools and see whether the event “fires” or not and then see if there’s any data populating in production.

Those are the areas that I would say would require the most improvement and will require better communications and sync between teams.

Overall, work on the marketing aspects had still been a constant work in progress, but there’s a few takeaways I have since working on various marketing related implementation and migration efforts:

Stick with the standard that all parties can agree on (tried and proven technologies with familiarity)

Agree on a standardized naming convention, document it, and adhere to it

Lock down publish permissions to only those who needs it

Setup a development and production environment for your tag managers and its corresponding tools

COLLABORATE, COMMUNICATE, SYNCRONIZE

I’d consider using Google Tag Manager Server Side if we need to be on the GTM ecosystem. It’d improve page speed by moving the tracking from browser to client side and also track our data more accurately being agnostic to client’s device and browser limitations. Security will also be improved by reducing the possibility of data leakage through the client.