What Is Server-Side Tracking?

Server-side tracking sends analytics events from your backend instead of the visitor's browser — your webhook handler, your signup endpoint, your job queue, posting directly to the collector. No script involved, nothing for ad blockers to block, no tab-close race conditions. It is the right tool for a specific class of events, and a poor replacement for the rest.

What server-side does better

• Money: payments belong in webhooks — Stripe's invoice.paid, order confirmations, refunds. Client-side purchase events die to redirects exactly when accuracy matters most.
• State changes: subscription upgrades, plan expirations, referral qualifications — things that happen in your database, sometimes with no browser open at all.
• Verified data: the server knows the real amount, the real plan, the deduplicated order_id. The browser knows what a possibly-broken script computed.

What it structurally cannot see

Behavior. The server never sees scrolls, clicks, interaction latency, rage-refreshes, or the JavaScript error that killed the checkout. Pure server-side analytics produces beautiful conversion logs with no explanation layer — you know what happened, never why. (It also reintroduces an IP-handling burden: the server sees raw request metadata that a data-minimizing pipeline must consciously discard.)

The join is the architecture

The standard pattern uses both sides against one record: the browser tracker captures behavior and context (pageviews, performance, first-touch UTM), identify() at signup names the visitor, the visitor ID gets persisted server-side — and from then on, backend events join the same timeline. Clycyo's collect API takes the identical payload from either side; the full pros-and-cons treatment covers the edge cases.

Decision rule: if the event involves money or database state, send it from the server; if it involves human behavior, observe it where the human is.