The Events Nobody Was Sending (Sugar Babies, Part Four)

The Setup

By the time this audit ran, the Sugar Babies Google Ads account had already been rebuilt once (part one) and the storefront upgraded in place (part three). The server-side tracking spine was real: a first-party subdomain, a web container and a server container, GA4, Google Ads, and Meta CAPI all routed through it.

Purchases flowed cleanly through every layer. Which is exactly why nobody had looked closer. A container that fires Purchase looks healthy.

What Was Broken

Ten days of server traffic told a different story. Page views: over 31,000. Purchases: 74, consistent with order volume. Add-to-carts: two. View-items: 38, on a store where the honest number should have been in the thousands.

The stack was profitable and lying by omission.

The cascade from that gap is bigger than a broken funnel report. Google Ads’ upper-funnel conversion signals fired off those events, so Smart Bidding was optimizing on Purchase alone. Meta CAPI’s mid-funnel events fired off the same starved source, so retargeting audiences and lookalike seeds were degraded. Both platforms were working with a fraction of the signal the brand thought it was sending.

The root cause was almost anticlimactic: the custom Shopify pixel feeding the server-side stack subscribed to exactly one event, checkout completed. Nothing ever pushed product views, add-to-carts, checkout starts, payment info, or search into the first-party path. The events were not broken. They were never sent.

What I Did

Shipped a second Customer Events pixel that subscribes to the missing funnel events and routes them through the same first-party domain, leaving the working purchase pixel untouched. Isolated blast radius: if the new pixel had misbehaved, Purchase kept flowing.

Verified the same night: an add-to-cart placed on the live storefront arrived at the server container and returned 200. Along the way, two pending server-container template updates got applied and published, and outgoing request logging got turned on so the next silent failure has somewhere to show up.

The restored volume held, and it is measured, not promised. On the ad account’s GA4 import, the add-to-cart conversion action had recorded fewer than two ad-attributed add-to-carts in the entire month before the diagnosis. The first ten days after the fix carried 143. The first full month carried 509. Same conversion action, same attribution basis, pulled read-only from the account on July 10.

The Number Worth Keeping

The same audit measured what the first-party routing was worth. Over the ten-day window, 31.7% of all events reached the platforms only because the server-side path saved them from browser tracking prevention. For purchases specifically, the platform’s recovery readout was 50%.

That is the entire ROI case for server-side tracking, measured on a live store instead of asserted in a sales deck.

What I Did Not Claim

The Meta mid-funnel events ride a different client inside the server container and were scoped as the next phase, not silently bundled into this win. And the ROAS effect of restored bidding signal takes weeks to compound, so this case study claims the signal restoration and the restored event volume, both verified in-account, and not a revenue number, which would be guessing.

The Takeaway

Server-side tracking fails politely. Nothing errors, dashboards stay green, and the one event that proves the concept keeps firing while the ones that feed your bidding quietly flatline. The health check is not “is Purchase recording.” It is “does every funnel event show the volume the storefront does.”

Not sure what your stack is silently skipping? That is what the tracking audit finds.