What is a postback?

How a postback works

A postback is an HTTP request from your server, or your measurement provider's, to the receiving platform's endpoint, carrying the event and whatever identifiers the two parties have agreed to exchange.

The important property is that it does not involve the user's device or browser. Nothing can block it, no consent banner gates it, and it does not depend on a page loading. That reliability is why postbacks carry the events that matter commercially, while client-side tags carry the ones that are merely useful.

What a postback usually carries

• The event. Install, purchase, subscription, or a custom event.
• A campaign identifier, so the receiving platform can credit the right campaign.
• A value, where the event has one — revenue, or a conversion value.
• A timestamp, which is what makes attribution windows enforceable.
• A de-duplication key, so a retried request is not counted twice.

How SKAdNetwork changed the model

Conventional postbacks fire immediately and carry a user-level identifier. SKAdNetwork postbacks do neither.

They come from Apple rather than from your servers, they are deliberately delayed by a randomised timer, and they carry no user identifier — only a campaign identifier and a coarse conversion value, and even that is withheld when crowd anonymity thresholds are not met.

The consequence is that a SKAN postback cannot be joined to anything on your side. It is an aggregate signal that arrives late, and treating it as a delayed version of a normal postback is the most common source of confused iOS reporting.