What is server-to-server (S2S)?

Why S2S is more reliable

Client-side tracking depends on code running in a browser or app, which means it can be blocked, gated by consent, delayed by a slow connection, or simply fail because the user navigated away.

A server-to-server call has none of those failure modes. Your backend calls the destination directly, the request either succeeds or returns an error you can see and retry, and nothing about the user's device affects it.

For anything that must be accurate — revenue events especially — this difference is decisive.

What it requires

• Authentication, since the request is not coming from a session the destination recognises.
• An identifier to join on, which is the hard part when the client-side context is not available server-side.
• Idempotency. Retries are normal, so a de-duplication key is required or events double-count.
• Error handling and retry, which client-side tracking gets away without.
• Engineering time, which is the real cost — S2S is not a snippet.

S2S and privacy

Moving data server-side gives you control over what leaves your systems, which is a genuine privacy improvement — you can decide exactly which fields are shared rather than letting a third-party script observe whatever is on the page.

It does not, however, remove the obligation. Consent still governs what you may send, and sending personal data server-side without a lawful basis is exactly as unlawful as collecting it client-side. S2S changes the mechanism and not the rules, which is a distinction some implementations have got wrong.