Greenfield Tracking Build

A colleague already had work in the server container: a third-party automation lane that fanned events out over webhooks. I could have extended that and pushed GA4 through the same mechanism. Instead I built a GTM-native GA4 lane alongside it and left his work untouched.

There were a few reasons for that. Analytics and marketing automation tend to fail for different reasons, so it's better not to have them share a single path. I also didn't want GA4 reporting to depend on a third-party automation tool staying online. And his lane was working production code that I had no particular reason to modify, so modifying it would have added risk without adding value.

Starting from empty, I set up a GA4 property and data stream, then built a web container with 21 Data Layer Variables and 3 Custom Event triggers. A Google tag routed first-party traffic through the server subdomain. From there I extended the server container with a GA4 forwarding tag and four conversion tags, covering purchase, begin_checkout, trial, and sign_up.

There are two things here worth being honest about, plus one finding that isn't documented anywhere.

The first is that I built a set of triggers in the wrong container. I caught it, deleted them, and rebuilt them in the right one. It's a small mistake, but catching it there cost a few minutes, whereas not catching it would have cost a confusing debugging session later on.

The second was a scare in Tag Assistant: three Google tags showing, one of them undefined. It looked at first like a duplicate-source problem, but it turned out to be an internal config push originating from Firebase. I confirmed that with a few console checks rather than assuming, and once confirmed it was clearly expected behavior.

The finding worth recording: server-injected events don't show up in GA4 DebugView. The server-side tag template doesn't translate debug_mode into the wire flag that DebugView reads, so the events are firing correctly but stay invisible to that particular view. Server-lane verification has to be done through the outgoing-request view instead, which is not something the official docs mention.

Rather than settling for a setup that looked right, I confirmed it end to end. I hit the full live path with a raw curl, no preview header, and got a 200 back with the data client's response body. That confirmed the whole chain in production: browser, web container, first-party subdomain, server container, and GA4.

Building alongside someone else's work was a deliberate design choice rather than just a courtesy to a colleague. Keeping the two lanes independent means the GA4 lane and the automation lane each stand on their own, and neither one can take the other down if it fails. The details most worth writing down afterward were the ones no documentation would have told me: that server events skip DebugView, and that an undefined Google tag can be a Firebase config push rather than an actual bug.