DEV Community

John Builds
John Builds

Posted on

Why we moved from hardcoded gtag snippets to Google Tag Manager in our Next.js app

For the first year of building XreplyAI, our tracking setup was the standard mess: gtag scripts in _app.tsx, conversion events scattered across components, and a tacit rule that any tracking change needed a full deploy cycle.

It worked, but it had a real cost: we consistently under-instrumented. Adding a conversion event for a new experiment didn't feel worth a PR when you're moving fast solo.

The switch to GTM

The migration was about 2 hours. The short version:

  1. Replace inline gtag calls with window.dataLayer.push() calls
  2. Move all tag configs (Google Ads, GA4, any new pixels) into a GTM container
  3. Publish the container — done

What actually changed

No deploys for tracking changes. New pixel, new conversion event, tweaked trigger — all done in GTM in minutes. This sounds minor until you ship 3 new conversion events in a week without opening your codebase once.

Preview mode is a real debugger. GTM shows every tag, trigger, and variable state as you click through your app in real time. We caught two misfiring conversion events we didn't know existed.

Explicit load order. Async gtag snippets fire whenever the browser gets around to them. GTM lets you sequence tags so dependencies are guaranteed to load before dependents run.

One place to audit everything. One dashboard instead of grepping through _app.tsx and a dozen component files.

Worth it at early stage?

Yes — especially if you're running any paid acquisition. The ops overhead of tracking living in your codebase compounds as you add channels. Moving it out early is much easier than untangling it later.

We're building XreplyAI — AI social media tool for solo founders. Happy to share the full GTM container structure in the comments if useful.

Top comments (0)