How Server-to-Server Tracking Works
Server-to-Server tracking transmits conversion and event data directly between backend servers, bypassing the user's device entirely for data transmission. Instead of an SDK on the device sending event data to an external server, the app sends event data to the advertiser's own backend, which then forwards it to attribution providers, ad networks, and analytics platforms via server-side HTTP requests.
The typical S2S flow works like this: a user completes an action in the app, a purchase, registration, or any tracked event. The app sends this event to the advertiser's backend server as part of its normal operation. The backend server then constructs and sends HTTP requests to each integration partner that needs to know about the event. These requests include the event details, device identifiers, timestamps, and any additional metadata required by the receiving system.
This architecture decouples data collection from data transmission. The app collects the raw event data, but the backend controls what data is shared with whom, when it is sent, and in what format. This separation provides significant advantages in terms of data control, reliability, and privacy compliance, which is why S2S tracking has moved from a nice-to-have to a strategic priority for growth teams operating in the current privacy landscape.
Advantages Over Client-Side Tracking
The reliability advantage of S2S tracking is substantial. Client-side tracking depends on the user's device having network connectivity at the moment an event occurs, the SDK being properly initialized, and no interference from OS-level restrictions or ad blockers. If any of these conditions fail, the event data is lost or delayed. S2S tracking eliminates these dependencies, once the event reaches your backend, delivery to partners is handled by your server infrastructure with proper retry logic and error handling.
Data control is the second major advantage. With SDK-based tracking, the SDK determines what data is collected and transmitted, and updates to the SDK can change data collection behavior without the advertiser's explicit awareness. With S2S tracking, the advertiser's backend explicitly constructs each outbound request, providing full visibility and control over every data point shared with every partner. This is critical for privacy compliance, you can implement data minimization at the server level, sharing only the specific fields each partner needs.
Data enrichment is a capability unique to S2S tracking. Before forwarding event data to partners, your backend can enrich it with server-side information that the app does not have access to, subscription status from your billing system, customer segment from your CRM, lifetime value calculations from your data warehouse. This enriched data enables more sophisticated optimization and analysis than raw client-side events alone can provide.
Implementing S2S Tracking
Implementing S2S tracking requires backend engineering investment but follows a well-established pattern. Start by defining your event schema, the standardized format for events flowing from your app to your backend. This schema should include all fields that any downstream partner might need: event name, timestamp, device identifiers (GAID, IDFA, IDFV), user ID, revenue amount, currency, and custom parameters.
Build an event ingestion endpoint on your backend that receives events from your app in real time. This endpoint should validate incoming events, store them in a durable queue, and trigger the forwarding pipeline. Using a message queue (like SQS, Kafka, or RabbitMQ) between ingestion and forwarding ensures that temporary partner endpoint outages do not cause data loss.
For each integration partner, build a forwarding module that transforms your internal event format into the partner's expected format and sends it to their S2S endpoint. Each partner has different requirements, different URL structures, authentication methods, required fields, and rate limits. Document these requirements carefully and implement partner-specific error handling. Most partners provide S2S integration guides with endpoint specifications, authentication details, and example payloads.
S2S Tracking and Privacy Compliance
Server-to-Server tracking aligns naturally with privacy-first principles because it gives advertisers explicit control over data flows. Under GDPR, CCPA, and similar regulations, data controllers must know what personal data they share, with whom, and for what purpose. S2S tracking makes this transparent, every outbound request is constructed by your code, logged by your systems, and auditable by your compliance team.
Consent management integrates cleanly with S2S architecture. When a user opts out of tracking or withdraws consent, your backend can immediately stop forwarding their events to third-party partners without requiring an SDK update or app release. This server-side consent enforcement is faster and more reliable than client-side approaches that depend on SDK configuration changes propagating to every device.
Linkrunner supports S2S integration for teams that need maximum control over their attribution data flow. By combining a lightweight client-side SDK for device identification with server-side event forwarding, Linkrunner gives growth teams the accuracy of deterministic attribution with the data control and privacy compliance benefits of S2S architecture. This hybrid approach is increasingly the standard for teams that take both measurement accuracy and user privacy seriously.
When to Use S2S vs SDK Tracking
The choice between S2S and SDK-based tracking is not binary, most mature mobile operations use both. Understanding when each approach is appropriate helps you design an efficient and reliable measurement stack. SDK-based tracking is the right choice for events that require immediate device-level context: install attribution, deep link handling, device fingerprinting, and real-time engagement signals. These operations depend on data that only the SDK can access at the moment the event occurs.
S2S tracking is the better choice for post-install events that benefit from server-side enrichment, events that involve sensitive data you want to control, and high-volume event streams where client-side transmission would impact app performance. Purchase events, subscription changes, and backend-triggered events (like a payment confirmation from your billing provider) are natural candidates for S2S tracking.
The hybrid model combines both: a lightweight SDK handles install attribution and device identification, while your backend handles post-install event forwarding via S2S. This minimizes the SDK's footprint in your app while maximizing data control and reliability for downstream events. As privacy restrictions continue to tighten and client-side tracking becomes more constrained, the balance will continue shifting toward S2S for a larger share of the event pipeline.
