Common Server-Side Tracking Mistakes (And How to Avoid Them)

Why sGTM Mistakes Are Hard to Spot

Server-side tracking errors are often more subtle than client-side errors. A broken GTM tag causes no conversions — obvious. A misconfigured sGTM setup might send 80% of events correctly while silently dropping 20%, or double-counting due to deduplication gaps, or forwarding with wrong values due to incorrect variable mapping. Here are the mistakes we encounter most frequently.

Mistake 1: Not Configuring a Custom Domain

Running sGTM on the default .run.app URL instead of a custom subdomain. This means your server is not first-party, does not set first-party cookies, and aggressive ad blockers may block requests to the Google Cloud Run domain.

Fix: Configure collect.yoursite.com (or similar) as your tagging server domain before launching. This is a requirement, not an optional enhancement.

Mistake 2: Missing Event Deduplication for Meta CAPI

Running both the client-side Meta Pixel and server-side CAPI without event deduplication. Result: Meta counts every conversion twice — inflating reported conversions and causing Meta's algorithm to misallocate budget.

Fix: Include a consistent event_id parameter in both your browser Pixel events and your server CAPI events for the same conversion. Meta uses this to deduplicate. For purchases: use the order ID as the event_id.

Mistake 3: Forwarding Events Without Consent Check

sGTM receives all events from the browser and forwards them all to GA4 and Meta — regardless of whether the user consented. Client-side Consent Mode blocks tags in the browser, but if those events are also being sent to sGTM (e.g. via the data layer), the server may forward them even when it should not.

Fix: Implement consent-based filtering in your sGTM server container. Only forward events to third-party platforms when consent_analytics and consent_ad_storage are granted. Check the consent state from the event payload and use trigger exceptions in the server container.

Mistake 4: Incorrect GA4 Client ID Handling

Not configuring the sGTM GA4 client to set and read first-party cookies. The GA4 client in sGTM can set the _ga cookie server-side (bypassing ITP) — but only if configured to do so. Without this, the browser-set _ga cookie expires in 7 days on Safari, defeating a key purpose of server-side tracking.

Fix: In the GA4 client configuration in sGTM, enable "Serve cookie", set domain to your root domain, and set a 2-year expiration.

Mistake 5: Sending Events With Missing User Data to Meta CAPI

sGTM forwards purchase events to Meta CAPI without including hashed customer data (email, phone). The result: low Event Match Quality (2-3 out of 10), meaning most conversions cannot be matched to Meta users and are effectively unattributed.

Fix: Ensure your data layer push for purchase events includes customer email (even hashed). The hashing can be done in sGTM if your data layer includes the raw email — sGTM has a SHA-256 hashing function available. Include at minimum: hashed email, IP address, user agent, fbp cookie, and fbc cookie.

Mistake 6: Not Monitoring Server Health

Deploying sGTM and then not monitoring it. Cloud Run instances can fail, scaling limits can be hit, and server errors can cause events to drop — often without obvious symptoms until someone notices a conversion count drop weeks later.

Fix: Set up Cloud Run monitoring and alerts. Alert on: error rate above 1%, p95 latency above 500ms, and request count drops of more than 20% versus the previous day's average.

Mistake 7: Forgetting to Exclude Internal Traffic

Not implementing internal traffic filtering in sGTM. Your office's browsing, QA testing, and developer activity all generate events in the server container and get forwarded to GA4 and Google Ads.

Fix: Add a trigger exception in your sGTM tags that checks the IP address (available via the request headers in sGTM) and blocks events from known internal IP ranges.

Summary

Server-side tracking mistakes range from "data quality" issues (missing deduplication, low EMQ) to "compliance" issues (forwarding without consent) to "reliability" issues (no monitoring). Build a setup checklist that covers all seven areas before declaring your server-side implementation production-ready.

See our Server-Side Tracking service for a correctly configured implementation.

Think your server-side setup has issues? Contact Adslytics for an audit.