Overview

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.

Problem

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

Performance

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.

Security

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.

Maintenance

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.

Migration to Zaraz

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

Pros

• Simple and straight forward interface
• Loads 3rd party tools in the cloud away from browser
  • Improves web app speed
  • Improves security
  • Improves privacy
  • Note: If you use Custom HTML option, this will go into your browser while common supported tools such as GA4, Facebook Pixel, Reddit Pixel, etc are handled in the cloud

Drawbacks

• 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

Overall Utilization

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.

Migration 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
  • We get more than 1 million events / month which is as much as the free tier allows for
• Familiarity
  • We have contracted marketers and SEO teams who are not familiar with Zaraz
• Complex marketing tracking requirements
  • If you need control and complex conversion tracking, Google Tag Manager allows more options to customize to your need
  • Zaraz allows just the simple configurations

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.

Conclusion

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
  • In this case, it is the dev maintainer who will have the final say to co-sign the requested marketing tags once all of it’s features are tested and it works as intended
• Setup a development and production environment for your tag managers and its corresponding tools
• COLLABORATE, COMMUNICATE, SYNCRONIZE
  • Adding new ads and marketing scripts aren’t a simple copy and paste and “the code will work”
  • There are a lot of setup involved so introduce and explain the requirements, set it up, and TEST TEST TEST, then when it is set up and all maintainers approve it, then it can go through
  • Marketing team provides the spreadsheet of the events they need tracked as a source of truth
  • Developer setup the events whether its through GTM or other tools

Future Idea Consideration

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.

Hopefully someone will implement this or a better solution in the future since it is more accurate to track things via server side.

Additional Resources

• Google Tag Manager naming convention by Analytics mania
• Google Tag Manager naming convention example by Precis digital