// Case study / Instrumentation
All analytics in the tag manager. Not one line in the site code.
A B2B/B2C hardware authentication brand’s e-commerce storefront had a security requirement that banned analytics code from the site codebase entirely. Every tag, variable, and trigger had to live in GTM. When the purchase funnel became a Single Page Application mid-build, the constraint stayed the same — wildcard matching, history-state pageviews, and enhanced ecommerce delivered from a container alone.
What happened
Security constraint, GTM-only architecture, SPA funnel handled without touching the codebase.
The client was a hardware authentication brand building an e-commerce storefront on Magento with a custom frontend. Security requirements prohibited analytics code from the site codebase entirely. All measurement had to live in a tag management container. When the purchase funnel became a SPA mid-build, the constraint stayed fixed — the implementation approach had to change instead.
Context
Magento backend, custom storefront, rapid iteration, and a security constraint.
Magento handled purchase processing; developers were building the storefront on top of it. The site was in active development — class names and element structures changing across sprints. The security concern was straightforward: analytics code embedded in the codebase could introduce vulnerabilities and created an audit surface the client was not willing to accept.
GTM was selected to handle the full analytics layer. That meant DOM-driven variables, history-state listeners for SPA navigation, and the ability to prototype and iterate tags without touching the site code — requirements that shaped every implementation decision from day one.
Task
Define the requirements, build the containers, and keep pace with the site.
The role covered the full implementation: writing tagging requirements, building GTM containers, designing DOM-based variable schemas, handling SPA pageview capture via history state, configuring enhanced ecommerce, and specifying form fallout and error tracking. QA ran against each sprint release as the site changed beneath the container.
Phase 1Requirements + isolation
Second GTM container for the new site section. Full analytics isolation from day one — no analytics code in the site codebase.
Phase 2Wildcard + SPA handling
Dynamic CSS classes meant switching to wildcard tag logic and history-state change listeners to capture SPA navigation reliably.
OutcomeEnhanced ecommerce live
Product impressions, add-to-cart, checkout steps, purchases, full form fallout. WCAG compliance improved as a side effect.
Wildcard matching required. Class names changed between sprints; stable element identifiers were not available for standard GTM trigger logic.
History-state listeners replaced standard pageview triggers once the purchase funnel became a Single Page Application mid-build.
Zero analytics code in the site codebase, at any point. Every analytics update deployed through the GTM container independently of site releases.
Site and analytics iterated in parallel across sprints, requiring GTM to stay current without access to the site’s build pipeline.
Outcome
Enhanced ecommerce live. Form fallout coverage complete. SPA handled correctly.
- Enhanced ecommerce: product impressions, add-to-cart, checkout steps, and purchase events tracked entirely via GTM.
- Form fallout + error tracking: complete coverage of purchase and account forms.
- SPA pageviews: history-state-based virtual pageviews firing correctly across the full funnel.
- WCAG improvement: adding IDs and stable classes for GTM targeting also improved accessibility compliance.
Design lesson
When analytics can’t touch the codebase, GTM has to be the whole system.
The security constraint that looked like a limitation produced a cleaner architecture: one versioned container, all analytics logic in one place, zero coupling between site releases and analytics releases. That isolation principle applies anywhere a measurement layer needs to be independently deployable.
The constraint also surfaced a problem that site-embedded analytics often misses: when the only way to tag an element is via the DOM, every poorly-structured markup decision becomes a tracking problem. The feedback loop improved both the analytics layer and the underlying site structure.