Server side tracking and metrics
2025Client-side tracking was not enough precise: ad blockers, Safari/iOS restrictions and third-party cookie loss meant unreliability and not enough data.
Why server-side
- Data loss :Ad blockers and iOS/ITP kill client-side tags before they fire. Server-side collection runs from a first-party endpoint, so events aren't blocked at the source.
- Reliability : Events are sent server-to-server, not from the browser. No dropped beacons on page unload, no race conditions, consistent payloads.
- Ownership :The data passes through infrastructure I control before it goes anywhere. I decide what's collected, what's forwarded, what's stripped.
Stack
A server-side Google Tag Manager container on Google Cloud. The site sends events to a first-party domain; the container enriches them and forwards them server-to-server to GA4, the Meta Conversions API (CAPI), Hotjar and Pinterest Ads.
The full e-commerce funnel is tracked: view_item, search, begin_checkout, add_shipping_info, add_payment_info, purchase, plus engagement events like scroll depth and CTA interactions. Meta deduplication runs on event_id, with first-party fbc/fbp cookies and a hashed external_id for cross-session matching.
Outcome
Built and deployed solo: infrastructure, event schema, server-side forwarding and identity handling. The funnel is fully instrumented on live traffic. Every step from view to checkout is captured server-to-server, where client-side tracking structurally loses data.