What is a Postback in Mobile Attribution?

Postbacks are server-to-server notifications that confirm conversions happened. Learn how they work in SKAN, MMPs, and traditional attribution.

Justin Sampson
What is a Postback in Mobile Attribution?

What is a Postback in Mobile Attribution?

A postback is a server-to-server notification that confirms a conversion happened.

When someone installs your app from an ad, the ad network needs to know. Postbacks deliver that information automatically, without user involvement.

They're the communication layer that makes mobile attribution work.

How Postbacks Work

The basic flow:

  1. User clicks an ad from Network A
  2. User installs your app from the App Store
  3. Your MMP attributes the install to Network A
  4. MMP sends a postback to Network A confirming the install
  5. Network A receives the data and credits the campaign

This happens entirely server-to-server. The user never sees it. No pixels, no cookies, no client-side tracking.

Postbacks replace the need for ad networks to track users directly. Instead, your attribution provider (MMP) acts as the source of truth and notifies relevant parties.

Types of Postbacks

There are two main categories in mobile app attribution:

1. MMP Postbacks

Your Mobile Measurement Partner sends these when attribution events occur.

Common postback triggers:

  • Install
  • First open
  • Registration
  • Purchase
  • Subscription
  • Any custom in-app event you configure

These postbacks go to ad networks, analytics platforms, internal systems, or anywhere you need attribution data.

Example data included:

  • Click ID
  • Install timestamp
  • Campaign details
  • Event name and value
  • Device type and OS

MMP postbacks provide real-time, granular data for users who opted into tracking via ATT.

2. SKAN Postbacks

Apple sends these for iOS installs that didn't opt into ATT tracking.

Key differences from MMP postbacks:

  • Sent by Apple, not your MMP
  • Delayed 24-72 hours (privacy mechanism)
  • No user-level identifiers
  • Limited to conversion value (0-63) and campaign ID
  • Aggregated rather than individual

SKAN postbacks arrive at ad networks, which then share the data with your MMP for reporting.

SKAN Postback Structure

SKAN postbacks contain minimal data:

Fields included:

  • Campaign ID (source identifier)
  • Conversion value (0-63)
  • Timestamp (randomized within 24-hour window)
  • Ad network identifier
  • Coarse conversion value (SKAN 4.0 only)

Fields not included:

  • User ID
  • Device ID
  • Exact install time
  • User location
  • Any personally identifiable information

The privacy constraints mean you can't connect a SKAN postback to a specific user. You can only see aggregated campaign performance.

SKAN 4.0: Multiple Postbacks

SKAN 4.0 introduced up to three postbacks per install:

Postback 1 (0-2 days):

  • Arrives 2-3 days after install
  • Includes fine conversion value (0-63)
  • Includes coarse value (low/medium/high)

Postback 2 (3-7 days):

  • Arrives 7-8 days after install
  • Includes coarse value only

Postback 3 (8-35 days):

  • Arrives 35-36 days after install
  • Includes coarse value only

Each postback measures a different window, giving you visibility into user behavior across a full month instead of just the first 48 hours.

Postback URLs

Ad networks provide postback URLs where they want to receive data.

Example format:

https://tracking.adnetwork.com/postback?
  click_id={click_id}
  &event_name={event_name}
  &event_value={event_value}
  &timestamp={timestamp}

Your MMP populates the parameters with actual data when sending the postback.

You configure these URLs in your MMP dashboard for each integrated partner.

Real-Time vs. Delayed Postbacks

MMP postbacks: Near real-time (typically within seconds of the event occurring)

SKAN postbacks: Delayed minimum 24 hours, often 48-72 hours

The delay impacts optimization:

  • Real-time postbacks enable immediate bidding adjustments
  • Delayed postbacks require algorithmic prediction and broader optimization windows

This is why ATT opt-in data remains valuable even at 15-25% opt-in rates. Real-time feedback enables faster campaign iteration.

Postback Security

Postbacks use several security mechanisms:

HTTPS encryption: All postback URLs should use HTTPS to prevent data interception.

Signature verification: MMPs often include cryptographic signatures to verify postbacks are authentic.

Allowlisting: Systems only accept postbacks from known IP ranges.

Click ID validation: Postbacks reference specific clicks that networks can verify against their logs.

These prevent fraud where bad actors might attempt to send fake postbacks claiming conversions that didn't happen.

Event Postbacks

Beyond install postbacks, you can configure event postbacks for in-app actions:

  • Purchase
  • Subscription start
  • Level completion
  • Registration
  • Add to cart
  • Any custom event

Event postbacks let ad networks optimize toward post-install goals, not just installs.

To set up event postbacks:

  1. Define the event in your MMP
  2. Implement SDK code to track when it occurs
  3. Configure which partners should receive postbacks for this event
  4. Map event parameters (like revenue value) to postback parameters

Postback Discrepancies

Postback data doesn't always match what ad networks report. Common reasons:

Attribution methodology differences: Networks might self-attribute installs your MMP assigns elsewhere.

Timing differences: Networks report by click date, MMPs by install date.

Fraud filtering: MMPs filter suspicious installs that networks count.

Delayed postbacks: SKAN postbacks arrive days later, causing temporary mismatches.

Small discrepancies (5-10%) are normal. Large gaps indicate configuration issues.

Setting Up Postbacks

Configuration happens in your MMP dashboard:

  1. Enable partner integration for each ad network
  2. Add postback URLs provided by the network
  3. Configure event mappings (which events trigger postbacks)
  4. Set up parameter mapping (what data gets sent)
  5. Test using network validation tools

Most major ad networks have pre-built integrations with MMPs, making setup largely automated.

FAQs

What is a postback?

A postback is a server-to-server notification that confirms a conversion occurred. It sends attribution data from one system (like an MMP or Apple) to another (like an ad network) without requiring user interaction.

How do SKAN postbacks work?

SKAN postbacks are sent by Apple to ad networks after a delay. They include campaign ID, conversion value, and timestamp but no user-level identifiers. The delay ranges from 24-72 hours to protect privacy.

What's the difference between SKAN postbacks and MMP postbacks?

SKAN postbacks are sent by Apple with aggregated, delayed data. MMP postbacks are sent by your attribution provider with real-time, user-level data for users who opted into tracking via ATT.

Why are SKAN postbacks delayed?

Apple delays SKAN postbacks by 24-72 hours as a privacy mechanism. The random delay makes it harder to correlate postbacks with specific users or behaviors, protecting user anonymity.

Can you send postbacks to multiple partners?

Yes. You can configure your MMP to send postbacks to every integrated ad network, analytics platform, or internal system that needs attribution data. Each partner gets only the data relevant to their attributed users.


Postbacks are the infrastructure that makes mobile attribution function. They're invisible to users but essential for measuring and optimizing app marketing campaigns across platforms.

postbackattributionSKANserver-to-serverconversion tracking

Related Resources