No matter your background, most people understand the benefits of collaboration and concurrency. When you have multiple people sharing ideas, improving on them, and working on them at the same time, you increase efficiency and produce better work faster.
Additionally, tag management
has brought a tidal wave of flexibility into deploying digital analytics solutions in a timelier manner. Instead of waiting for the next development release cycle -- which may not be for another six months -- a tag management solution provides the power to push an update, fix, or new feature within days. Innovation and optimization can now be accelerated, taking a company’s analytics program to new heights much, much faster.
Combining concurrency with tag management seems like the perfect match. Unfortunately, without the proper care, throwing concurrency onto a tag management solution is not unlike pouring water on a Mogwai. For those of you who are unfamiliar with the movie “Gremlins”, a Mogwai is a cute, furry creature (see below):
As 80s as it looks (and is), you cannot tell me it isn’t adorable. When you pour water on a Mogwai, it spawns multiple other Mogwais. What’s the issue, you ask? When you accidentally feed a Mogwai after midnight, it turns into a Gremlin:
Gremlins are less adorable, mischievous, and threatening. Similarly, tag management and concurrent collaboration can work wonderfully together. However, if you feed them after midnight (so to speak), you can run into serious trouble quickly.
Imagine someone working on new tracking code and running some tests. It may not be cross-browser compatible, it may have bugs, and in general, it is not yet ready for production. Now, imagine someone else needs to make a very simple, straight-forward addition to their tagging via tag management. They log in, make the addition or change they may have done a hundred times in the past, and push the new version out to production. Simple, with very quick results guaranteed to please the business. Right?
Wrong. If the new tracking code gets moved out to production with the simple change, you may run into production issues with your site that are not caught for hours, or even days. The flexibility of tag management and the efficiency of currency have just turned into gremlins and are now making mischief on your production site.
What’s the answer? Governance
. It’s very natural to wince at least a bit at the idea of having to apply restrictions around the sudden freedom that a tag management solution provides, but with great power comes great responsibility. Having to wait a few extra days in order to follow proper governance of releases from a tag management system is still light years better than waiting a few months before your code is released.
To help get you started, here are a few basic guidelines for governing multiple developers in the same tag management application:
Have a select few people (or a single person) manage production releases. Everyone else should only be able to push into a development or QA environment. This system ensures that someone has more control over what happens to the production environment.
Schedule production releases from your tag management solution for a certain time in advance. This schedule can be a regular period, such as every Tuesday at 4 p.m., or it can simply be advance notice. Make sure all developers are aware of this schedule.
Keep communication lines wide open. Any time a production push is going to happen, alert everyone who is or could have worked on the profile/space/account in question. If an irregular production push is going to happen, alert all the developers as soon as possible
For developers, if you have code that still needs to be thoroughly tested, disable it when you are not actively testing. The extra time it takes to re-enable for future testing is a small price to pay for it accidentally moving into production.
When a production push happens, always have the appropriate developers around to smoke test the production environment. Run quick tests in all appropriate browsers to make sure site functionality was not affected, and all of the new or updated functionality is working as expected. If anything at all is off, revert back to the previous version and fix it in development before attempting another production push. This process serves as a safety net to be absolutely sure no scraps were left on the table for a conniving Mogwai to grab while you’re sleeping.
Of course you can apply stricter user rights if necessary, but even a simple system of checks and balances will keep your efficient tactics safe and cuddly.
What do you think? Do you have Gremlins in your tag management system? For more tips, reach out to us at firstname.lastname@example.org