His Tracking Worked Fine — Until He Needed to Trust It.

How a Shopify store went from renting its measurement to owning every signal — and why the difference matters more than most founders realize.


The client was doing everything right on the surface.

His store, Immuto, sold customized products through Shopify. He was running ads across Google, Facebook, X, and Pinterest. He had Klaviyo handling email. Google Analytics was collecting data. The pixels were installed. The dashboards had numbers in them.

But when I asked him a simple question — how is your Facebook tracking actually configured? — he couldn’t answer it.

Not because he wasn’t smart. Because the setup wasn’t built to be understood. It was built to exist. Shopify’s native pixel integrations had been switched on at some point, and they were collecting something. But there was no architecture underneath. No single system governs what data is captured, how it is shaped, or where it is sent. Each platform was wired independently, with its own logic, gaps, and blind spots.

The client had tracking. He just didn’t own it.

And there’s a problem with tracking you don’t own — one that doesn’t show up until it matters. When something breaks, you can’t fix it because you don’t know how it was built. When a platform changes its rules, you can’t adapt because you don’t control the infrastructure. When you want to add a new channel, you’re starting from scratch every time because nothing connects to anything else.

It’s the difference between renting a house and owning one. In a rental, the lights work — until they don’t. And when they don’t, you call someone else and hope they understand the wiring.

The client was ready to stop renting.

What was actually broken

Before touching anything, I needed to see the full picture.

The tracking across Immuto wasn’t broken in the dramatic sense — pixels were firing, data was appearing in dashboards. The problem was structural.

Shopify’s native integrations handle tracking the way templates handle design: they give you something functional without giving you understanding or control. Each platform — GA4, Google Ads, Facebook, X, Pinterest, Klaviyo — was connected via a separate integration with its own event logic. There was no unified event taxonomy tying them together. No shared data layer. No single place where events were defined once and distributed consistently.

This meant every platform was seeing a slightly different version of the customer journey. The same purchase might be reported with different parameters across different tools. And if one integration stopped working — or started under-reporting due to ad blockers, iOS privacy settings, or browser restrictions — there was no way to know until the numbers started looking strange. By then, the damage was already done.

Six platforms. Six separate configurations. Zero governance.

The deeper issue wasn’t technical. It was what the client couldn’t explain, debug, or trust his own measurement. The system wasn’t something he could open up and understand — it was a black box he was paying to keep running.

Why we didn’t fix everything at once

The instinct with a setup like this is to rip it all out and rebuild everything simultaneously. Six platforms, one project, ship it all at once.

We didn’t do that. And the reason matters.

When you’re rebuilding someone’s entire measurement infrastructure, the worst thing you can do is make them wait until everything is done before they see any value. That’s how trust erodes — not because the work is bad, but because the silence between start and delivery is too long.

So we split the work into two phases.

Phase 1 was the foundation: GA4 wired through GTM (both web and server containers), Facebook Conversion API set up on the server side, and Google Ads conversion tracking with enhanced conversions. These are the platforms the client relied on most. Getting them right first meant he had a working, trustworthy system within weeks — not months.

Phase 2 was the expansion: X, Pinterest (including the Pinterest Conversion API via Stape), Klaviyo, and Google Search Console. These were layered onto the foundation that was already proven.

This sequencing does something important. It lets the client see the approach working before the full scope is delivered. By the time Phase 2 started, the client already understood how the system was built, because he’d watched Phase 1 come together. He wasn’t taking our word for it anymore — he could see it in his own dashboards.

You don’t bolt eight platforms onto a shaky base. You build the base first, prove it holds, then layer.

Building the foundation

The core architectural decision was straightforward: move everything out of Shopify’s native integrations and into Google Tag Manager — both a web and a server container — so that every event is defined once and sent to every platform through a single governed system.

Server-side tracking replaced the browser-dependent approach. Instead of each platform relying on its own pixel running in the customer’s browser — where ad blockers, privacy settings, and cookie restrictions quietly erode data quality — events now flow through a server Immuto controls. The data reaches each platform intact, regardless of what the browser decides to block.

A unified data layer meant every platform receives the same event structure. When a customer views a product, adds to cart, begins checkout, or completes a purchase, each of those events is defined once in the data layer and distributed to GA4, Google Ads, Facebook, and every other platform through the same taxonomy. No more six platforms seeing six different versions of the same action.

GA4 e-commerce tracking was wired end-to-end: view_item, view_item_list, add_to_cart, view_cart, remove_from_cart, begin_checkout, and purchase. For a customized-product store, every stage of the funnel matters — the path from browsing to buying isn’t linear, and partial visibility means missing where customers actually drop off.

Once Phase 1 was running and verified, something became clear. The foundation was solid enough that adding Google Ads dynamic remarketing — which wasn’t in the original scope — cost very little effort. So we added it. When you’ve done the deeper work, small acts of generosity stop being expensive. They become natural.

New territory

Phase 2 brought a challenge we hadn’t faced before.

X and Pinterest were straightforward — the GTM infrastructure from Phase 1 made adding new platforms a matter of configuration rather than architecture. Pinterest’s Conversion API through Stape followed a pattern we knew well.

Klaviyo server-side was different. We hadn’t set it up before.

There’s a way some people handle unfamiliar territory — they wing it, pattern-match from something similar, and hope it works. That approach ships faster. It also breaks faster, and when it breaks, you don’t know why because you never understood the implementation in the first place.

We worked through Stape’s documentation step by step. Methodically. Not because we couldn’t have moved faster, but because the client’s measurement infrastructure isn’t the place to cut corners. The system had to be right, not just running.

It shipped. It works. And because we understood every decision we made along the way, when something eventually needs adjustment — and it will — the logic is documented, not guessed at.

The handover

Here’s where most engagements end: the system is built, the invoice is sent, and the consultant disappears.

That’s not what happened.

The client received documentation that explains what each tool does, how it’s configured, and where to look when something needs attention. He received a video walkthrough of the full system. Not a screencast of someone clicking through dashboards — an explanation of the architecture, the decisions behind it, and how to think about it when things change.

The goal was never to make the client dependent on us. It was to make him capable.

There’s a difference between building someone a system they need you to maintain and building one they understand. The first one creates a client. The second one creates trust — the kind that means when the client is ready to go deeper, he comes back because he wants to, not because he has to.

What Immuto runs on now

Web and server containers are configured and governed through GTM. GA4 e-commerce tracking operational end-to-end. Google Ads is wired with enhanced conversions and dynamic remarketing. Facebook Conversion API, X, Pinterest (with Pinterest CAPI via Stape), and Klaviyo — all firing server-side. Documentation and a video walkthrough sit alongside the build.

The tracking that used to be scattered across six separate Shopify integrations — each a black box — now runs through a single system the client can explain, debug, and maintain.

He owns his measurement. He doesn’t rent it.

Three questions about your own tracking

01

Can you explain how your tracking works?

Not what platforms you’re using — how they’re configured. If you can’t walk someone through the setup, you don’t own it. You’re renting it from whoever installed it.


02

If your tracking broke tomorrow, would you know?

Browser-based pixels fail silently. Ad blockers strip data. iOS privacy settings degrade match rates. If your system can’t tell you when it’s underperforming, it isn’t a system — it’s a hope.


03

Are your platforms seeing the same customer journey?

If each tool defines events independently, each one is telling a different story. The purchase that Facebook reports might not match what GA4 sees, which might not match what your email platform claims. Consistency isn’t a feature — it’s the foundation.


The platforms you run ads on will keep working whether your tracking is yours or not. The pixels will fire. The dashboards will show numbers. Everything will look functional.

The difference shows up when you need to make a decision — and you realize you’re reading six different answers to the same question, and you can’t tell which one to trust.

That’s the moment you find out whether you own your measurement, or it owns you.

Book a 30-minute conversation →