SKAN is a conversion value, not a click id

Conversion values are bits

The install is attributed to a signed ad, not to an IDFA you stored. The postback carries network, campaign or source identifier, and a conversion value you updated from the app. Map revenue buckets or funnel depth to the bits you have. Changing the map mid-campaign compares two currencies. Version the schema.

A schema that encodes a user id is a policy problem and will not survive the postback anyway. Fine values in the older 0 through 63 range are six bits. Do not treat 63 as a lucky Purchase. It is whatever you mapped it to. A mapper that assumes 0 through 63 forever will misread a coarse postback as a random integer.

SKAN 4 coarse values, without overclaiming later versions

SKAN 4 added multiple postbacks and coarse values (low, medium, high) under crowd anonymity. Fine values still exist when Apple has enough crowd. That is the versioning you can stand on. Do not claim a later SKAN generation in a measurement spec unless Apple shipped it and you actually instrumented it.

Adjust and AppsFlyer decode values you configured in their UI. They cannot turn SKAN into a click id. They cannot invent an IDFA the OS withheld. Do not wait for the MMP to magically emit fbclid on an iOS install after ATT. Pixellint has no SKAN pack. Do not invent vendor.adjust.skan_version.

Postbacks wait

SKAN postbacks wait. They arrive late. Optimizing a day-0 campaign on SKAN day-0 data is how you overreact. Pair with MMP cohort reports that you already distrust on iOS, and say so. You will not join a postback to an email in a warehouse the way you join an MMP click id.

Update conversion values in the app as the user does things you care about, under the window Apple allows. A single update to 63 on first open wastes the schema. Delayed postbacks are not a bug in the MMP S2S client. They are the product. Finance-style day-0 ROAS will not come from SKAN alone.

Not MMP S2S and not a pixel

Do not POST a conversion value to s2s.adjust.com/event and expect Apple to see it. Do not paste a SKAN postback into pixellint validate url and expect gdpr_consent checks. Different artifact, different hop (often the ad network, not your thank-you page).

MMP S2S is your event: app_token, event_token, device id. SKAN is Apple's signed postback. Ship both. Report them as two views. Do not subtract one from the other and call the remainder fraud. Do not double-count the same install as a web pixel plus SKAN plus a guessed IDFA.

https://s2s.adjust.com/event?s2s=1&event_token=f0ob4r&app_token=4w565xzmb54d&idfa=D2CADB5F-410F-4963-AC0C-2A78534BDF1E

Web-to-app

A web click into the store is not automatically a SKAN source. You still need the right network setup and often an MMP to bridge. The web click may have a click id. The iOS install may only have SKAN. Do not drop the web click id because SKAN exists. Do not skip SKAN because the MMP still has Android GAID.

You cannot paste a SKAN postback into a pixel validator. Walk a click from ad to store to first open on a device that did not have the app. Anything less is a unit test of the SDK, not of the campaign. Keep fbclid or gclid on the web hop, send them on the app event if you still have them, and let SKAN report what Apple will still attribute.

Check the artifact

Paste the pixel URL or JSON body into the playground. Same engine as pixellint validate. Nothing leaves the tab.