Moved GA4 tagging from a hardcoded, undocumented implementation onto Google Tag Manager, so tag changes no longer require a developer, backed by a full site audit, cookie log, and Legal compliance checks.
→ Tag changes no longer require a developer. Full cookie log and Legal sign-off in place.
Problem
GA4 had been hardcoded directly onto the site with no documentation of what was tracked or why, and every tagging change needed a developer to make it.
Context
This was one of the platform foundations I inherited alongside the wider Fortescue delivery rebuild, discovered during the initial audit period rather than flagged to me ahead of joining.
Business objective
Move GA4 tagging onto Google Tag Manager so changes could be made without developer involvement, with full documentation of what was being tracked and why, and full compliance sign-off.
Customer/user objective
The team needed to be able to make and test tagging changes themselves, without a developer as a bottleneck for every adjustment.
Constraints
The migration had to happen without breaking existing analytics continuity, and any change to what was being tracked needed Legal sign-off given it touched cookie and consent handling.
Stakeholders
The development team who previously owned every tagging change, Legal, who reviewed the cookie log and compliance position, and the wider business relying on GA4 data staying continuous through the migration.
Research and discovery
I ran a full site audit to establish exactly what was being tracked under the hardcoded implementation, since there was no documentation to start from, and built a cookie log to capture it properly for the first time.
Options considered
I considered leaving the hardcoded implementation in place and just documenting it, versus migrating to GTM so future changes wouldn’t need a developer at all. I chose the migration, since documentation alone wouldn’t have removed the developer dependency that was the real bottleneck.
Prioritisation
The site audit and cookie log came first, since migrating tags to GTM without a clear picture of what was currently tracked risked losing or duplicating data in the process.
Delivery
I worked with Dev to plan and execute the transition to a GTM-based model, migrating tags across so future changes could be made directly in GTM rather than requiring a code deployment, and took the cookie log and compliance position through Legal review before completing the migration.
Decisions made
Migrating fully to GTM, rather than a partial move that kept some tags hardcoded, was the decision that mattered most, a partial migration would have kept the same developer dependency for whatever was left behind.
Trade-offs
The full site audit and cookie log took time upfront before any migration work started. I judged that necessary, since migrating tags without knowing what was currently live risked breaking analytics continuity.
Business outcome
GA4 tagging now runs through GTM with full documentation and Legal sign-off, and tag changes no longer require a developer.
Customer outcome
The team can make and test tagging changes themselves, with a documented cookie log to reference rather than undocumented, hardcoded tracking.
Lessons learned
Undocumented analytics implementations are a slow-building risk, not a one-off inconvenience, the audit surfaced tracking nobody currently on the team could fully account for.
What I'd improve today
I wasn’t there for the original implementation, but the general recommendation I’d make to any team in that position is to build the documentation habit in from day one, so a future migration like this one isn’t needed again.
