How to remap SKAN conversion values when you switch MMP

What does remapping SKAN conversion values mean?

Remapping SKAN conversion values means rebuilding your conversion value schema in the new MMP and moving control of Apple's conversion value calls from the old SDK to the new one, so every install is measured by exactly one schema.

Conversion value schema: the mapping that turns in-app events and revenue into Apple's fine values (0 to 63) and coarse values (low, medium, high) for each conversion window.

It is a small part of the switch in effort, but mistakes here are silent: postbacks still arrive, they just mean the wrong thing.

Can two SDKs set conversion values at the same time?

No. Every vendor that documents this says only one SDK or party should manage SKAN conversion values in an app, and a second one causes mismatched values.

What the vendors say, in their own docs:

• Adjust: the iOS SDK "communicates with SKAdNetwork by default". Call disableSkanAttribution before SDK initialisation to switch it off.
• AppsFlyer: "Only one SDK can trigger sending SKAN postbacks to partners", and mismatched values are usually caused by another SDK that can set them (AppsFlyer FAQ).
• Branch: the SDK is opted in to SKAN by default. Branch says to opt out if a third-party library handles SKAN.
• Kochava: "Only one party should send conversion data to SKAdNetwork for a given app."
• Singular: "You can only have one SDK managing SKAdNetwork conversion values in the same app."
• Tenjin: you must call its SKAN methods manually in the SDK, so it does nothing until you do.

The practical rule: switch SKAN handling off in the old SDK in the same release that switches it on in the new one. If both SDKs stay in the app for a parallel run, only one of them owns SKAN.

SKAN postbacks go to one MMP only

Singular's migration page states it plainly: "SKAN postbacks can only be sent to one MMP. Even if both SDKs are integrated, only one MMP receives SKAN conversions."

That means a parallel run gives you two views of non-SKAN attribution, but not two views of SKAN. Decide in advance which MMP is the SKAN source of truth for each week of the switch, and note it in your migration plan.

Rebuild the schema in the destination

Export or screenshot the old schema before you lose access, then rebuild it where the new MMP configures it:

Keep the same event meanings where you can. If the new schema reorders events, your historical SKAN reports and the new ones will not line up, which matters for the historical data you keep.

Reconnect Meta

Meta reads your schema from the MMP through "Import from partner app" in Events Manager, so the old MMP's URL must be replaced.

• Adjust: no URL to copy. Meta "automatically pulls" the mapping once it is saved, and Adjust appears as the connected partner.
• AppsFlyer: copy the MMP connection URL and paste it into "Import from Partner App". AppsFlyer says this also tells the Facebook SDK to stop setting values. If SKAN measurement is turned off in AppsFlyer, Meta can no longer get the mapping.
• Branch: paste the Branch URL. At least one value must be mapped or Meta receives an empty response, and the endpoint does not support revenue buckets or event counts.
• Singular: paste the Singular MMP URL. Meta pulls the latest model roughly once an hour.

Singular warns that changing a conversion model takes up to 48 hours, includes a 24-hour gap with no conversion values, and causes Facebook to pause campaigns for 24 hours (Singular docs). Treat a schema change as a campaign event, not a settings tweak.

Meta also advises against decreasing conversion values or using lock windows, and says lock windows are not currently supported in Events Manager. Design the new schema without locks if Meta is a major channel.

Reconnect Google

Google lets you set up a SKAN schema through Google Analytics, an App Attribution Partner or the Google Ads API, and advises choosing one place. During a switch, make sure only the new source is active.

Two Google limits to design around:

• Google's modelling uses fine values only; it does not support SKAN 4 coarse values.
• Fine values are sent only when Apple's highest privacy threshold is met.

Time the cutover around the windows

Conversion windows: SKAN 4 has three windows measured from first launch: days 0 to 2, 3 to 7 and 8 to 35.

Each postback also waits a random delay after its window ends: 24 to 48 hours for the first, 24 to 144 hours for the second and third. Worked from Apple's numbers, the third postback for an install can arrive around day 36 to 41.

What that means for planning:

• An install measured under the old schema can keep producing postbacks for over five weeks after the cutover release.
• A user who updates the app mid-window may send later postbacks with values set under the new schema for an install that began under the old one.
• Pick one cutover date, tied to an app release, and label reports on either side of it.
• Avoid stacking other campaign changes on the same week, given Meta's 24-hour pause on model changes.

The timeline guide shows where this sits in the wider switch. The attributiondebugger guide to SKAN 4 postbacks explains each postback field.

This definition of a conversion value covers fine and coarse values in more depth.