Who on your team can create new tags? Who can modify existing tags? Who can turn tags on and off? Without clear governance, anyone can change anything. A junior developer accidentally deletes a critical tag. A marketer adds a tag that breaks tracking. A contractor modifies conversion logic and nobody knows. Governance prevents chaos. Clear roles and permissions mean the right people make the right decisions. Approval processes catch mistakes before they break production data.
This article explains how to set up tag governance that protects your tracking while letting your team work efficiently.
What Is a Tag
A tag is a code snippet that fires when a specific action happens on your website. Tags are managed through a tag manager, which is a container that holds all your tracking codes. Instead of putting multiple tracking codes directly on your site, you install one tag manager code. The tag manager then fires all your individual tags based on the rules and conditions you set up.
Tags measure conversions, engagement, and specific user behaviors. A purchase tag fires when someone completes a purchase. A form submission tag fires when someone submits a form. Each tag sends data to your analytics platform to track these important actions.
Governance is about controlling who can create, modify, and deploy these tags to ensure data quality and prevent accidental breakage.
Define Clear Roles and Responsibilities
Create roles for tag management. Who owns analytics? Who owns advertising? Who owns conversion tracking? Each area should have an owner who approves changes.
Different roles have different permissions. Viewers can see tags but not modify them. Editors can modify tags in staging. Publishers can push tags to production. Admins can do everything. Assign roles based on job function and experience level.
Document who has what role. Make it clear who owns which tags. When someone needs a tag change, they know who to ask.
Require Approval for Production Changes
Don't let anyone push tags to production without approval. Create an approval process. A developer creates a tag in staging. Another person reviews it. A third person approves it. Then it goes to production.
This three-step process catches mistakes. The reviewer asks questions. The approver makes sure the change fits business goals. By the time a tag reaches production, multiple people have checked it.
For urgent changes, you can streamline the process. But never skip it entirely. A broken tag in production costs more than a few hours of approval process.
Use Separate Staging and Production Environments
Create a staging tag manager and a production tag manager. All changes happen in staging first. Teams test changes in staging. After approval, tags get promoted to production.
This prevents accidental changes in production. Developers can experiment in staging without worrying about breaking real data. When they're confident the change works, they request promotion to production.
Staging environment should mirror production. Same sites. Same actions. Same data layer. This ensures staging tests accurately predict production behavior.
Document Change Requests
When someone requests a tag change, require documentation. What's the change? Why is it needed? What business goal does it support? Who approved it?
Keep change requests in a system. A spreadsheet works. A dedicated tool is better. Track what changed, when, and why. This history is invaluable when something breaks and you need to understand what happened.
Include a rollback plan in the change request. If the tag breaks, how do you revert? How quickly can you roll back? What's the impact if rollback fails?
Control Access by Permission Level
Limit who can access what. A marketer should see advertising tags but not conversion tracking tags. A developer should see conversion tags but not advertising tags. Permissions prevent accidental modifications to areas you don't own.
Use role-based access. Viewers see everything. Editors modify tags in their area. Publishers push tags to production. Admins do everything. Granular permissions prevent accidents.
Set Up Alerts for Unauthorized Changes
If someone modifies a tag without going through the approval process, alert the owner. Most tag managers support audit logs. Use them to catch unauthorized changes.
Set up automated notifications. If someone modifies a critical tag, send an alert. The owner can review the change and revert if needed. Alerts create accountability.
Schedule Regular Access Reviews
Every quarter, review who has access to what. Remove people who left the team. Update permissions for people who changed roles. Access creep is real. People accumulate permissions over time.
During the review, audit recent changes. Who modified what? Did they follow the approval process? Did changes break anything? Regular audits catch problems early.
Frequently asked questions
Should everyone have editing access or only certain people?
Only certain people. Limit editing to team leads and experienced implementers. Viewers can see everything but modify nothing. Editors in staging but not production. Publishers handle production promotion. This role-based access prevents accidental changes. New team members start as viewers and graduate to editors after training. With WEMASY's website builder, you can set this up directly on your website.
What's the right approval process for tag changes?
Three-step works well. Create in staging. Have a peer review it. Have a manager or lead approve it. Then push to production. For routine changes, you can streamline to two-step. But never skip approval entirely. The cost of reviewing a change is less than the cost of fixing a broken tag.
We're a small team. Can we skip formal governance?
You can be more informal, but don't skip it entirely. At minimum, one person creates and another reviews before production. Use staging to test changes. Use audit logs to track modifications. Even small teams benefit from basic governance. As you grow, formal processes become essential.
How do we handle urgent changes that need to go live quickly?
Create an expedited approval process. Maybe just one approver instead of two. Maybe verbal approval instead of written. But still document the change. Still have someone review it. Still test in staging if possible. Urgency doesn't mean reckless. Speed comes from practice and clear processes, not from skipping steps.
What do we do if someone breaks production with an unapproved change?
First, revert the change immediately. Second, review what happened. Third, reinforce the approval process. Use it as a learning moment. Enforce approval going forward. Repeated rule-breaking might mean removing someone's editing access. Make it clear that approval protects everyone, including the person making the change.
How do we manage access when people change roles?
During their role change, review their permissions. Do they still need access to their old area? Do they need access to their new area? Remove old access. Add new access. Schedule quarterly reviews to catch any stragglers. People sometimes forget to request access changes. Regular reviews catch it.