Running the old and new SDK side by side

What you ship

You release a single build with two SDKs inside. Both initialise at launch, and every event you care about is sent to each of them. Three details decide whether the comparison is fair.

• Same events, same moment. Fire each event to both SDKs from one place in the code. If "purchase" is sent to one on the confirmation screen and to the other from the server, the totals will never match.
• Same consent handling. Whatever the user's privacy choice is, pass it to both SDKs in the same way.
• One owner of the deep link. Only one SDK should route an incoming link to a screen. Leave routing with the old SDK until cutover.

How to avoid double counting

The risk in a parallel run sits outside your app. If both MMPs send the same install or purchase to an ad platform, the platform may count it twice. Check each platform's documentation. Keep it simple: during the parallel run the old MMP stays connected to your ad channels and keeps sending postbacks. The new MMP only collects and reports.

This means the new MMP will label most installs as organic for now, because your ads still carry the old links. That is expected. In this phase you are checking counts, and attribution comes later.

What to compare, in order

1. New installs per day, per platform. Leave out existing users who updated: the new SDK has never seen their devices and may record their first open as an install.
2. Each key event per day. Trials, purchases, sign-ups. Check count and revenue amount.
3. Attributed installs for one test channel. Move a single low-budget campaign to a new-MMP link and see whether its installs are credited as you expect.

Compare the same calendar days in the same time zone and currency, and only for app versions that contain both SDKs. A small steady gap is normal, because the two products define and deduplicate events slightly differently. The glossary entry on discrepancy lists the usual causes.

Signs that something is wrong

When to stop and what to do next

End the parallel run when the gap has been stable for at least a week and you can explain it. Then schedule the cutover one channel at a time: move that channel's tracking links and reconnect the channel on the same day, then watch it before the next. Keep the old SDK in the app for one more release after that, in case you need to roll back, and then remove it.

While both SDKs run you pay both vendors. If the new one bills by event volume, the parallel weeks count toward that bill too, so check how its trial or first month treats them.