Server-side tracking

Check where events originate. The network panel shows requests going to your own domain, such as `/collect`, and then your server forwards to the vendor with a server-to-server POST. Count events at both hops, since a gap means the forwarder is dropping or failing.

Log the forwarding results: 2xx, 4xx, timeouts. Watch the latency added to the request path if the forward is synchronous.

A WooCommerce store forwards `purchase` events from its order-complete hook. The browser tag recorded 410 orders last month, while the server hook sent 447, matching the store's 447 orders. The other 37 buyers had blockers or closed the tab before the thank-you page loaded.

The team sends both and gives each event the order number as an event id, so the platform deduplicates them to 447 rather than 857.

Server-side tracking sends from a server you control. Client-side tracking sends from the browser. The server version sees facts only the server knows, such as refunds, but not scroll or viewport unless the page reports them. It also moves data onto your infrastructure, so the privacy duties stay with you.

Forwarding without checking consent. Sending both paths and double-counting. Faking the visitor's IP and user-agent. Treating it as invisible to blockers, when a first-party endpoint can still be matched by path. Blocking checkout on a slow forward. Losing events in a crash because there is no retry queue.

Start with the events that matter most, like orders, and send them from the server with an event id. Queue and retry the forward, and keep the consent state attached to each event.