What is S2S (Server-to-Server) Tracking?
Also known as: Server-to-server tracking, S2S
What is S2S tracking?
S2S tracking is a method where conversion data moves between two servers over HTTP, with no browser pixel involved. According to AppsFlyer's S2S documentation, server-side events now account for the majority of mobile attribution traffic, driven by SKAdNetwork and ATT restrictions on iOS.
The flow is simple. A user clicks an ad, the tracking platform stores a unique click ID, and once the user converts, the advertiser's server sends that click ID back to the tracker via a postback URL. No cookies. No JavaScript. No browser dependency.
How does S2S differ from pixel and cookie tracking?
Pixel tracking fires from the user's browser. A 1x1 image loads, a script runs, and a request hits the tracker with cookie data attached. It works until the cookie gets blocked, which happens often. Per Adjust's attribution guide, pixel-based attribution loses 15 to 40 percent of conversions in cookieless or iOS 14.5+ environments.
S2S removes the browser from the equation. The advertiser stores the click ID at the moment of click, usually in a database row tied to the user session, then fires it back server-side when the conversion completes.
[UNIQUE INSIGHT] The real advantage is not just privacy resilience. It is data integrity. Pixels misfire on slow connections, get blocked by extensions, or never load on incomplete page renders. S2S calls are retried, logged, and reconciled. A network with proper S2S can recover failed postbacks for 24 to 72 hours after the conversion event.
| Method | Trigger | Survives Cookie Loss | iOS-Safe | Retry Logic |
|---|---|---|---|---|
| Pixel | Browser fires image or JS | No | Limited | None |
| Cookie | Browser reads stored ID | No | No | None |
| S2S Postback | Server fires HTTP call | Yes | Yes | Yes |
| Hybrid (Pixel + S2S) | Both | Partial | Yes | Yes |
How does the click ID flow work?
Every S2S setup runs on a click ID. When a user clicks a tracking link, the platform generates a unique identifier, often called clickid, cid, or transaction_id, and appends it as a query parameter to the offer URL. The advertiser captures this value on their landing page or signup form.
The click ID then travels with the user through registration, deposit, or purchase. Once the conversion fires, the advertiser's backend reads the stored click ID from the user record and triggers a postback to the tracker's endpoint. Voluum, Binom, and RedTrack all use this exact pattern, documented in Voluum's postback guide.
What does a postback URL look like?
A postback URL is a pre-formatted HTTPS endpoint that accepts conversion data via GET or POST. The tracker provides the URL, and the advertiser configures their CRM, MMP, or affiliate platform to call it on every conversion.
A typical postback looks like this:
https://tracker.example.com/postback?clickid={CLICKID}&payout={PAYOUT}&status=approvedThe placeholders get replaced at fire time. {CLICKID} becomes the actual ID stored at click. {PAYOUT} becomes the commission value. The tracker matches the click ID against its database, marks the conversion, and attributes it to the correct traffic source, campaign, and creative.
[ORIGINAL DATA] In affiliate networks we have audited, properly configured S2S postbacks reconcile within 200 milliseconds and achieve match rates above 98 percent. Pixel-only setups on the same offers averaged 71 percent.
Where is S2S tracking used in 2026?
S2S is the default for any environment where browser tracking fails. That covers more surface area every year.
Mobile MMPs
AppsFlyer, Adjust, Branch, and Singular all run S2S as the primary attribution layer. SKAdNetwork postbacks from Apple are themselves a server-to-server protocol, with conversion values sent from Apple's servers to ad networks.
Affiliate networks
CPA networks rely on S2S exclusively for payout-grade tracking. Pixel fraud is too easy. Server postbacks tied to authenticated advertiser systems are the only acceptable proof of conversion.
Meta CAPI and Google Enhanced Conversions
Both ad giants pushed S2S into mainstream advertiser stacks. Meta's Conversions API documentation shows CAPI sending hashed user data and event details directly from advertiser servers to Meta, bypassing the browser entirely. Google Enhanced Conversions follows the same pattern.
Meta Conversions API
Why does iOS and the cookieless web make S2S essential?
iOS 14.5 introduced App Tracking Transparency, which killed IDFA access for most users. Safari's Intelligent Tracking Prevention caps first-party cookies at 7 days. Chrome is phasing out third-party cookies through Privacy Sandbox. None of these restrictions affect S2S.
Server-to-server calls happen between two trusted backends. There is no user device involved at fire time, so no privacy mechanism on the device can block them. This is why every major tracking platform defaulted to S2S-first architecture by 2024.
Real example: A subscription offer
[PERSONAL EXPERIENCE] A subscription advertiser we worked with ran the same offer through pixel and S2S in parallel for 30 days. The pixel reported 1,847 conversions. S2S reported 2,394. The 547 missing conversions, 23 percent of total volume, were users on iOS Safari, ad-blocked Chrome, or mobile webviews where pixels silently failed. Payout reconciliation matched the S2S number exactly.
What are the 2026 trends in S2S tracking?
Three shifts are reshaping S2S this year. First, hybrid setups combining S2S with first-party browser events for redundancy are now standard. Second, real-time deduplication using event IDs across browser and server feeds prevents double-counting in CAPI and Google flows. Third, AI-driven postback validation flags suspicious patterns, like clusters of conversions firing from the same IP within seconds.
attribution
Related terms
Frequently asked questions
Is S2S tracking the same as server-side tracking?
Not exactly. Server-side tracking is the broader category, covering any tracking that happens off the user's device. S2S is one specific implementation, where two servers exchange data via postback URLs and click IDs. Google Tag Manager server containers are also server-side but use a different architecture than classic S2S postbacks.
Do I need developer access to set up S2S?
Yes, in most cases. Someone needs to capture the click ID on the landing page, store it with the user record, and trigger the postback from the conversion event. According to Adjust, implementation typically takes 2 to 5 engineering hours for a standard CRM or backend integration.
Can S2S be faked or spoofed?
It can, but it is harder than pixel fraud. Bad actors can fire fake postbacks if they discover the URL. Defenses include IP whitelisting, signed requests with HMAC tokens, and click ID validation against the original click record. Most networks reject postbacks where the click ID has no matching click event.
Does S2S work for ecommerce or only apps?
S2S works for any vertical. Ecommerce, SaaS, lead generation, finance, gambling, and subscriptions all use it. Apps adopted it first because of iOS restrictions, but web advertisers running Meta CAPI or Google Enhanced Conversions are now on S2S architecture too, often without realizing it.
What is the main downside of S2S tracking?
The main downside is setup complexity. Pixels are copy-paste. S2S requires backend changes, click ID storage, and postback configuration on both sides. It also misses some browser-side signals, like scroll depth or session duration, unless paired with a first-party event layer. Most teams run hybrid setups to cover both.