Server-side tracking
Sending confirmed events from the backend, where ad blockers, closed tabs, and flaky browser requests cannot swallow the outcome.
See it
What it is
Server-side tracking sends events from your backend to an analytics or ad API instead of relying on browser JavaScript to deliver them. It fits facts the server can confirm, such as an account being created, an invoice being paid, or a job finishing. Ad blockers and closed tabs cannot cancel a request the backend owns. The named endpoints for this are Meta's Conversions API, Google's GA4 Measurement Protocol, and the server SDKs shipped by product analytics tools.
Reach for it when an event affects revenue, billing, lifecycle messaging, or a forecast. Browser events still help with page context and interaction, so many systems use both: the browser records intent and the server records the authoritative outcome.
Gotcha: sending from a server does not make tracking anonymous, consent-free, or automatically accurate. Retries can duplicate events, and emitting the same outcome from browser and backend can double it again. Use a stable event id for deduplication, honor the user's privacy state on the server, and pass only the campaign or device context you deliberately collected.
Ask AI for it
Implement server-side purchase tracking from Stripe to PostHog. Verify Stripe's webhook signature, handle checkout.session.completed only when payment_status is paid, and call the PostHog Node SDK with the account id as distinct_id plus order_id, value, currency, plan, and source properties. Persist the Stripe event id before sending so webhook retries are idempotent, reuse that id as the analytics event id for deduplication, honor the account's analytics opt-out, flush the SDK before a serverless function exits, and add tests for retries, invalid signatures, and delayed payment success.