How to run two MMP SDKs in parallel

What is a parallel run?

A parallel run is a period when the old and new MMP SDKs ship in the same app build, so you can compare installs and events side by side before moving bidding and postbacks to the new tool.

Parallel run: both SDKs initialise and record data, while only one of them is the source of truth for each ad network and for SKAN.

Dual-MMP support: an ad network's ability to receive attribution data from two MMPs for the same app at the same time.

Is running two MMP SDKs supported?

Partly. AppsFlyer and Singular both publish dual-MMP guidance, but not every network supports two MMPs, and on iOS only one MMP can receive SKAN postbacks.

AppsFlyer's "Measuring attribution with multiple MMPs" says side-by-side measurement needs both SDKs in the app and media sources configured for two MMPs, and that not all media sources support it. Singular's Attribution Measurement During MMP Migration page gives a per-network table.

No published guidance was found from Adjust, Branch, Kochava or Tenjin on running their SDK alongside another MMP's SDK.

Where parallel runs double count

Two vendors warn about duplicates in their own migration guides.

• AppsFlyer: its Adjust to AppsFlyer migration guide offers two options: remove the Adjust SDK in the release that adds AppsFlyer (marked recommended), or keep both for a transition period, which it notes can cause double attribution and double charges with ad networks.
• Airbridge: its migration guide says the previous MMP's SDK, postback settings and SAN attribution partner setting must be removed, or "events may be counted twice across Airbridge and the previous MMP".
• Meta: for value optimisation, Meta asks advertisers to send each event through one channel only (the Facebook SDK, an MMP or the Conversions API).

The practical reading: both SDKs can record, but each network should get postbacks from one MMP at a time. If two MMPs both claim the same install for a network, see why an install gets claimed by two networks.

One SDK must own SKAN conversion values

On iOS, two SDKs setting conversion values will overwrite each other. Several vendors say so directly.

• Adjust: the iOS SDK communicates with SKAdNetwork by default; call disableSkanAttribution before SDK initialisation to switch it off.
• AppsFlyer: its SKAN FAQ says mismatched conversion values are usually caused by another SDK in the app that can set conversion values.
• Branch: the SDK is opted in to SKAN by default, and 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: only one SDK can manage SKAdNetwork conversion values in the same app.

A fine conversion value is a number from 0 to 63, so two SDKs writing different schemas produce meaningless postbacks. Decide before release which SDK owns SKAN during the run, and switch ownership once, at cutover. The SKAN remapping guide covers moving the schema.

What to compare during the run

Compare trends, not exact matches. Two MMPs with different attribution windows and rules will not agree to the install.

• Installs per network per day, for networks where both MMPs are connected.
• Organic versus paid split, which shows whether one tool is claiming more installs.
• Key in-app events and revenue, checked against your own backend.
• Android referrer data: both SDKs read the same Play Install Referrer, which Google keeps for 90 days.
• Deep link routing, if links are moving to a new domain at the same time.
• Postback delivery on the new MMP for each network you plan to move.

Write down acceptable gaps per metric before the run starts, so the cutover decision is not made on feel.

When to stop

The migration planner pencils in 2 to 4 weeks for the run. That range comes from Google's 7 to 14 day Smart Bidding learning phase and Meta's guidance that ad sets usually exit learning after about 50 results in a week.

Stop when all of these are true:

1. Daily install and event trends on the new MMP track the old one within the gaps you agreed.
2. Every network, affiliate and agency is set up on the new MMP (see telling ad networks and partners).
3. Enough active users run the app version with the new SDK.
4. The old contract's notice deadline is still ahead of you.

Then cut over, and remove the old SDK in the next release. Running both longer than needed adds SDK weight and, at networks that receive both, a risk of duplicate charges. The switch timeline guide shows where the run sits in the full plan, and the checklist tracks each step.

If the terms are new, this postback explainer covers what each MMP sends to networks.