The MMP RFP Checklist to Run Before You Switch Vendors

Most studios that switch mobile measurement partners do it for the same reason: a pricing renewal comes in higher than expected, a sales conversation with a competitor promises a better rate, and the decision gets framed as a commercial one before anyone runs a proper MMP RFP checklist against the technical and operational risk of moving. That ordering is backwards. Pricing is the easiest variable to compare across vendors. Migration risk, data continuity, support quality: those are what actually determine whether the switch was worth making, and they're also the items most RFP processes skip past on the way to a rate comparison.

Start with data continuity, not features

The first section of any MMP RFP checklist should cover what happens to historical data, not what the new platform can do going forward. Every vendor's dashboard looks broadly similar from a sales demo. What differs, and what a demo won't surface, is how cleanly a studio can carry forward cohort history, along with attribution windows already in flight and the fraud-detection baselines that took months to calibrate on the outgoing platform.

• Ask explicitly whether historical attribution data migrates, or whether the new platform starts a fresh baseline on cutover, which effectively resets trend analysis for a period after the switch.
• Confirm how in-flight attribution windows are handled during the transition, since a user who clicked an ad on the old SDK and converts after cutover needs a defined rule, not a gap.
• Ask what happens to raw event-level data retention.
• Ask whether that data is exportable in a format that does not lock the studio into that vendor's own reporting layer permanently.

Treat the SDK migration as an engineering project, with a real timeline

The second section has to be honest about implementation cost, because this is where RFP processes are most consistently optimistic. Swapping an MMP SDK touches every platform a studio ships on. It touches every ad network integration reporting back to that SDK, and every internal dashboard someone built against the old vendor's data schema.

A realistic MMP RFP checklist forces a studio to get specific answers on:

• Engineering hours required for SDK integration across each platform (iOS, Android, and any additional platform the studio ships to), not a vendor's marketing estimate of "typically two weeks".
• Which ad network integrations need to be individually re-verified post switch, since a broken postback to even one meaningful network can silently understate performance for that channel until someone notices.
• Whether a parallel-run period is supported, where both the old and new SDK report simultaneously for a defined window, so the studio has a like-for-like comparison before fully cutting over.
• How the vendor reacts to the parallel-run question. A vendor unwilling to support one at all is itself a useful data point about how confident they are in a clean migration.

This kind of scrutiny matters more now than it did a few years ago. Attribution itself has grown more fragmented since ATT and SKAdNetwork's successor changed what a postback can even tell a UA team, a shift covered in more depth in this desk's look at holdout-based measurement in Incrementality Testing for Mobile Games You Can Afford; a vendor switch that goes wrong inside an already fragmented measurement environment compounds two problems instead of solving one.

Pressure-test support and escalation, not just the sales team

The final section of the checklist should have nothing to do with the platform itself. It should be about what happens when something breaks at 11pm on a Friday during a major UA push, because that is the moment that actually tests a measurement vendor relationship, not the sales cycle.

• Ask for the actual support SLA in writing, not a verbal assurance, including response time by severity level.
• Ask who the point of contact is post-sale, and whether it is the same team that ran the sales process or a separate, harder-to-reach support function.
• Ask an existing customer, ideally one of comparable scale and genre, how an actual incident was handled.
• Don't rely on the vendor's own reference list without independently verifying which customers are genuinely representative.

Read the contract for the next switch, not just this one

One checklist item is easy to skip, because it's uncomfortable to think about while signing a new contract: what the new agreement says about switching away from this vendor in turn. Multi-year commitments and data-export clauses, plus minimum-spend commitments that only reveal their true cost at renewal time, are exactly the terms an MMP RFP checklist should price in before signature rather than discover at renewal.

• Check the contract length and any auto-renewal clause, and confirm what notice period is required to exit without penalty.
• Confirm in writing, not just verbally, that raw event-level data remains exportable throughout the contract term.
• Confirm the same for after termination, not only during an active subscription.
• Ask whether minimum-spend or minimum-volume commitments step up over the contract term, since an attractive year-one rate that increases significantly by year three changes the real total cost of the switch being evaluated today.

A vendor confident in its own product doesn't usually need an onerous exit clause to keep a customer. A long lock-in period paired with a vague data-export commitment is itself a signal, and it deserves weighing alongside anything the sales team says in the room.

Price last, not first

Score continuity first. Then migration cost, then support. By the time you reach pricing it has become a much smaller variable in the decision than it looked at the start of the process, because a cheaper MMP that costs three months of engineering time to migrate cleanly, and introduces a support gap during peak season, isn't actually the cheaper option once you calculate total cost properly. Running the checklist in this order, continuity, migration, support, price, is what separates a studio that switches vendors well from one that just switches vendors.

The studios best positioned for the switch after this one, whenever it comes, are the ones treating this checklist as a standing document they update after every vendor conversation, not a one-off exercise built from scratch under renewal-deadline pressure.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• The MMP Migration Checklist to Run Before You Switch
• Migrating 30 live games to a new MMP: Tripledot's Adjust move, and what to ask before you switch