When a client tells me:

“We need GA4, Google Ads and Meta tracking.”

My first response usually isn’t:

“Which tags should we install?”

Instead, I start with a much more important question:

Because adding 20–30 GTM tags doesn’t automatically create a reliable tracking system. If the architecture underneath those tags is wrong, you can end up with:

• Missing conversions
• Lost attribution
• Duplicate purchases
• Broken customer journeys
• Safari-related data loss
• Ad-blocked browser events
• Incorrect revenue
• Poor Meta/Google optimization
• GA4 and Shopify numbers that don’t match

This is the architecture approach I personally use when designing tracking systems.

Step 1: I Start With the Business Event, Not the Tag

Before touching GTM, I identify the events that actually matter to the business. For an eCommerce store, that could be:

But I don’t stop there. For the purchase event, I want to know:

• Order ID
• Transaction value
• Currency
• Products
• Customer information where permitted
• Click IDs
• UTM parameters
• First-touch attribution
• Last-touch attribution
• Consent state
• Event timestamp

The objective isn’t simply:

The objective is:

That distinction changes the entire architecture.

Step 2: I Map Where the Data Can Be Lost

This is one of the most important parts of my process. I mentally draw the journey:

Then I ask: Where can the signal disappear?

This immediately shows me where I need redundancy. Instead of assuming the browser will always behave perfectly, I design the system around the reality that browser-side tracking is fragile.

Step 3: I Separate Attribution Storage From Event Tracking

This is where many implementations become unnecessarily complicated. I don’t want attribution information to exist only inside the current browser session.

For example, when someone arrives through utm_source=google with a gclid, I want the important attribution information captured and retained according to the site’s consent and privacy requirements.

Depending on the implementation, I may use:

• Cookies
• LocalStorage
• First-party storage
• DataLayer
• Server-side persistence

The exact method depends on the website, consent framework and business requirements. The important architectural principle is:

Step 4: I Design for Safari and Browser Data Loss

This is where the architecture becomes much more interesting. Imagine this: a visitor arrives from an advertising campaign. The browser initially captures:

• UTM parameters
• GCLID
• FBCLID
• First-touch information

Later, browser storage is affected by privacy restrictions or tracking limitations. If the architecture depends entirely on that original cookie, attribution can disappear.

So I build a recovery layer where appropriate. For example:

The goal is not to “bypass” privacy controls. The goal is to build a privacy-aware first-party architecture so legitimate data isn’t unnecessarily lost because one browser storage mechanism failed.

Step 5: Then I Introduce Server-Side GTM

Only after understanding the data flow do I decide where Server-Side GTM belongs. My architecture typically looks something like this:

This changes GTM from simply being a place where marketing tags are installed into something closer to a data routing layer.

Step 6: I Validate Data Before Sending It

This is another area where I spend a lot of time. I don’t want this:

I want:

For example, you don’t want an empty or invalid value accidentally becoming a hashed representation of an invalid input. This principle applies to:

• Email
• Phone
• User IDs
• Click IDs
• Transaction IDs
• Product IDs
• Revenue
• Currency
• Event parameters

That one principle can prevent a surprising number of tracking problems.

Step 7: I Build Deduplication Into the Architecture

One of the biggest eCommerce tracking problems I see is duplicate purchases. For example:

If both paths represent the same transaction and there isn’t a proper deduplication strategy, you can end up reporting:

So I define the transaction identity early. For eCommerce, the Order ID / Transaction ID becomes extremely important. I ask:

That’s an architecture question—not merely a GTM tag question.

Step 8: I Add a Validation Layer

Before I consider the implementation finished, I test the entire pipeline. I don’t just check:

I check every layer of the stack:

For an eCommerce store, the final comparison might be:

That’s where tracking becomes measurable rather than theoretical.

The Architecture I Aim For

The final architecture might look conceptually like this:

The important thing is that the architecture comes before the tags.

What I Don’t Want My Tracking Architecture to Do

I don’t want it to depend on:

Instead, I want the architecture to be:

The Real Reason I Build It This Way

The goal isn’t to collect more data just for the sake of collecting data. The goal is to make the data that should legitimately exist more reliable.

Because when tracking breaks, the impact isn’t only inside GA4. It can affect:

A missing purchase isn’t just a missing row in Analytics. It can influence which campaign receives credit. And that can eventually influence where the business spends its next $10,000.

My Rule for GTM Architecture

I’ve learned to think about tracking in this order:

If Your GTM Setup Starts With Tags, Start Again

This is probably the biggest lesson I’d share with anyone building eCommerce tracking.

Don’t start with:

Start with:

Once that architecture is correct, the GTM implementation becomes much easier. And when something breaks, you know where to look.