My sGTM Is Set Up. So Why Am I Still Losing Conversion Data?

You did the right thing. You set up server-side GTM. You connected a custom domain. You added the CAPI tag. You published the container. You told your client - or yourself - that tracking is fixed.

Then you opened Meta Events Manager, and the numbers still look off. Or GA4 shows half the purchases Shopify does. Or your Event Match Quality score is sitting at a 4 and refusing to move.

sGTM setups that look correct on the surface but leak data underneath are more common than anyone admits. The container runs. Events fire. But somewhere between your website and Meta's servers, data is falling through gaps that are invisible unless you know exactly where to look.

This post is that map. Six specific failure points, how to identify each one, and exactly how to fix it.

Failure Point #1: Your Hits Are Still Going to Google — Not Your Server

What it looks like: You set up the server container, connected your domain, but when you open GTM Server Container Preview Mode, nothing shows up. Events aren't arriving at your server at all.

What's happening: This is the most common setup error, and it's a simple one. Your GA4 Configuration tag in the web container still has the original Google Analytics server URL - it hasn't been updated to point to your sGTM server.

Every GA4 event your website fires goes to whichever URL the GA4 Configuration tag specifies. By default, that's Google's servers. To route traffic through your sGTM container, you need to update this tag with your server container URL — the custom subdomain you set up.

If that field is empty or still shows the default, your sGTM container is running but receiving nothing.

The fix: In your web GTM container, open your GA4 Configuration tag. Find the field labeled Server

Container URL. Enter your full server container URL — https://data.yourstore.com or whatever subdomain you configured. Save and publish the web container.

Then open GTM Server Preview Mode and reload your website. You should immediately start seeing hits arrive at the server container. If you don't see anything after 60 seconds of browsing your site, the URL is either wrong or DNS hasn't fully propagated yet.

One specific thing to check: make sure there's no trailing slash at the end of the URL. https://data.yourstore.com/ with a slash is not the same as https://data.yourstore.com without one. This small difference silently breaks routing.

Failure Point #2: Your GA4 Config Tag Is Firing Too Late

What it looks like: Some events show up in your server container, but not all of them. Specifically, some events seem to go to Google's servers directly while others route through sGTM. You see a mix in GTM debug mode - some hits labeled "gtag hit" (going to your server) and some labeled "Google Analytics Hit" (going to Google directly).

What's happening: In GTM, the GA4 Configuration tag determines where all subsequent GA4 event tags send their data. But this only works if the Configuration tag fires before the event tags on any given page load.

If a GA4 event tag (say, a purchase event) fires before the GA4 Configuration tag has loaded and run - which can happen if trigger conditions or tag sequencing aren't set up carefully - that event tag doesn't know to route through your server. It falls back to sending directly to Google.

The fix: In your web container, check the tag firing order. The GA4 Configuration tag needs to fire on All Pages with no conditions that could delay it. For every GA4 event tag, open the tag settings and under

Advanced Settings → Tag Sequencing, set the GA4 Configuration tag to fire before it.

Alternatively, check that no GA4 event tag is set to fire on Page View or DOM Ready without the Configuration tag also set to fire at those same points. Sequence problems are timing problems — the Configuration tag simply needs to win the race.

Failure Point #3: CAPI Is Firing but Event Match Quality Is Stuck Below 6

What it looks like: You can see server events arriving in Meta Events Manager. The CAPI connection is working. But your Event Match Quality score sits at 4 or 5, and your attributed conversions are still far lower than your actual order count.

What's happening: Event Match Quality isn't about whether CAPI is running — it's about how well Meta can match the events you're sending to real users in their system. A low score means Meta is receiving your purchase events but can't confidently say who made those purchases.

The matching uses customer identifiers you send with each event: email address, phone number, name, city, country, browser user agent, IP address. The more of these you provide — hashed before sending — the higher the score. Most setups that struggle with EMQ are sending purchase events with only the event name and value, nothing else.

The fix: In your server-side CAPI tag, check what parameters you're passing with the purchase event. At minimum you need:

• em — hashed email address (SHA-256)

• ph — hashed phone number (SHA-256)

These two fields alone typically move EMQ from the 4–5 range to 7–8. But you should also check that these values are actually making it from your data layer into the CAPI tag. The most common sub-problem here is that the customer's email exists in the data layer at checkout but the variable mapping in GTM isn't configured to pull it through to the CAPI tag.

Go to GTM Server Preview Mode, click on your Facebook CAPI tag firing on a test purchase, and inspect the event data it's sending. You'll see exactly what parameters are included. If em and ph are missing or empty, trace back through your variable configuration to find where they're being dropped.

One more thing: if you're on Shopify, the customer's email and phone are available in the checkout data layer but need to be explicitly mapped. They don't pass through automatically with the default GTM setup.

Failure Point #4: Deduplication Is Missing — and Meta Is Either Double-Counting or Dropping Events

What it looks like: Your conversion count in Meta is either significantly higher than your actual orders (double-counting) or significantly lower than what CAPI should be capturing (Meta dropping duplicate events it can't reconcile). This one is tricky because both outcomes look different and point to the same root cause.

What's happening: When you run Meta Pixel and CAPI together — which you should — both report the same purchase event. Meta's system is built for this. It uses a unique event_id to identify when a Pixel event and a CAPI event represent the same purchase, and counts it only once.

But this only works if you're actually sending an event_id. If you're not, Meta has no way to know whether the browser Pixel event and the server CAPI event are the same purchase or two separate ones. Depending on timing and its own internal logic, it either counts both (inflating your numbers) or gets confused and drops one (deflating them).

The fix: In both your web container Pixel tag and your server-side CAPI tag, you need to send the same unique event_id for each purchase. The standard approach is to generate a unique ID at the time the purchase event fires in the data layer — often the order ID works well — and pass it to both tags through a GTM variable.

Open your GTM server preview, find your CAPI purchase tag, and check whether event_id is present in the event data. Then check your web container Pixel tag for the same purchase event and confirm it's sending the same event_id value. If either is missing, or if they're sending different values, deduplication isn't working.

After fixing this, give Meta 48–72 hours to recalibrate before evaluating your conversion numbers. The historical data won't change, but new events will deduplicate correctly going forward.

Failure Point #5: Cold Start Latency Is Dropping Events

What it looks like: Your setup seems correct. Events mostly arrive. But there's inconsistency — sometimes purchase events show up in the server container, sometimes they don't. You can't reproduce it reliably. It seems random.

What's happening: This failure point only affects people running sGTM on Google Cloud Run with the minimum number of instances set to zero — which is the default configuration and the cost-saving choice most people make when setting up GCP themselves.

Cloud Run scales to zero when there's no traffic. This saves money. But it also means that when a request arrives after a period of inactivity, the container has to "cold start" — spin up from scratch. This takes 2–5 seconds.

For most web traffic, a 2-second delay is annoying but not catastrophic. For tracking events, it can be fatal. If a user completes a purchase and immediately navigates away from the thank-you page, the sGTM server might still be cold-starting when the purchase event arrives. The event request times out before the server is ready. The conversion is lost.

The fix: Set the minimum number of instances in Cloud Run to at least 1. This keeps one instance warm at all times, eliminating cold starts. It costs roughly $10–15/month extra on GCP. For anyone running paid ads, that's a trivially small cost compared to lost conversion attribution.

If you're on managed sGTM hosting, this isn't your problem — managed platforms handle instance warm-keeping as part of the service. But if you self-hosted on GCP and set minimum instances to 0 to save money, this may be the silent killer of your tracking accuracy.

Failure Point #6: You Published the Web Container but Not the Server Container

What it looks like: Everything works perfectly in GTM Preview Mode — events arrive at the server container, CAPI fires correctly, deduplication looks good. But in Meta Events Manager, server events aren't showing up in production. Preview works. Production doesn't.

What's happening: GTM has separate publish states for the web container and the server container. Preview Mode runs against the current unpublished state of the container — so your changes look correct in preview. But production traffic runs against the last published version.

If you configured and tested your server-side CAPI tag but only published the web container — and forgot to submit and publish the server container separately — live traffic hits an older version of your server container that doesn't have the CAPI tag you just built.

This is a surprisingly easy mistake to make because GTM's web container publish flow is familiar and ingrained. The server container is a separate entity with its own publish button, and it's easy to forget it's there.

The fix: In GTM, switch to your server container workspace. Click Submit. Add a version description. Publish. Then verify in Meta Events Manager that server events start appearing for live purchases.

Going forward, any time you make changes to your server container — adding tags, modifying parameters, updating triggers — remember it needs its own publish step before those changes go live.

The Diagnostic Checklist

Run through these in order before concluding your sGTM setup is fundamentally broken:

1. Server Container Receiving Events? Open GTM Server Container Preview Mode. Browse your site. Do events arrive? If no → Failure Point #1 (request routing) or #2 (tag firing order).

2. CAPI Tag Firing on Purchases? In server preview, complete a test purchase. Does the Facebook CAPI tag fire? If no → check your CAPI tag trigger configuration.

3. Customer Identifiers Present? Click on the CAPI tag in server preview and inspect the event data. Is em (hashed email) present? Is ph (hashed phone) present? If no → Failure Point #3 (missing parameters).

4. Event ID Present in Both Places? Check event_id in your server CAPI tag. Check it in your web Pixel tag for the same purchase event. Do both have it? Do both have the same value? If no → Failure Point #4 (deduplication missing).

5. Events Consistent or Intermittent? If events sometimes appear and sometimes don't without a clear pattern → Failure Point #5 (cold start latency, relevant for self-hosted GCP setups).

6. Server Container Published? In your GTM server container, check the version history. Is there a recently published version that includes your CAPI tag? If not → Failure Point #6.

One More Thing Worth Checking

After you've worked through the above, open Meta Events Manager and look at the Diagnostics tab on your Purchase event. Meta surfaces specific warnings here — things like "Pixel events detected without corresponding server events" or "Low event match quality due to missing parameters." These aren't always obvious and they're often more specific than anything you'd find by guessing.

Meta's diagnostics won't catch everything, but they flag the most common problems in plain language. It's worth reading before concluding you've found and fixed everything.

sGTM setups that half-work are in some ways more dangerous than setups that don't work at all. When nothing arrives at your server container, the problem is obvious. When events fire but parameters are missing, or deduplication is silently broken, or cold starts are randomly dropping purchases — the numbers look close enough to real that you make decisions based on them.

The fix for each of these problems is specific and, once you know what you're looking for, not particularly difficult. The hard part is knowing they exist in the first place.

Now you do.

If you'd rather have a managed setup that handles warm instances, correct routing, and guided CAPI configuration from the start — [Servero was built for exactly this →]