This tutorial is still in draft and is incomplete. Please use with caution.
There are many ways of structuring your Google Tag Manager Accounts.
Depending on how many sites you have, how you want to do tracking across different domains or platforms. Additionally, there are considerations to make for your development and staging environments.
1 Account to Rule Them All
One strategy is to have a single account for all your properties, platforms, and environments.
While setting this up can be rather verbose and tedious, but you’ll gain efficiencies if you need to deploy quickly across multiple properties and platforms.
However, I feel that this strategy has a higher likelihood of accidental errors given you have to create a rule specifically for each domain or environment.
The Container Store: Multiple Containers with Multiple Accounts
The other strategy is to create a separate container for each property and for each environment.
By creating separate containers, there is much lower chance of missing the creation of a rule, however, there is a potential issue if your development team isn’t well versed in the Google Tag Manager constraints.
If they accidently copy and paste the wrong container into a different environment, they could pollute your data. For example pushing the development container into production or staging. You can actively protect against that by using the 1 Account to Rule Them All strategy, but then you might as well just go with that the entire time. Another way of protecting against this is to make sure that each environment has it’s own config file that uses the appropriate container. This reduces the change of an unknowning developer making an accidently push, but this does require your DevOps team to be more invovled.
The Goldilocks Strategy
A strategy that I like is actually to have 1 container per property but to use that container for each environment and platform.
It’s probably unlikely that you’ll need to push a change across your entire network of sites all at once. You’ll probably want to have a QA team inspect one property at a time.
But you don’t want to have to mess with config files.
You’ll still need to use the rules based strategy but there will be fewer rules to manage especially if you have multiple properties and environments.