October 7, 2026

How to Migrate to a New MMP After Your Business Model Changes

Learn when to replace an MMP, map and validate subscription events, compare platforms, and where Airbridge Core fits for campaign-linked subscription revenue.

A migration plan for a subscription app whose revenue model changed

• Write down what changed in the way customers pay before shopping for a new MMP.
• Map trial starts, trial conversions, first payments, renewals, and refunds to clear business rules.
• Shortlist platforms against your funnel, channel, privacy, data, and budget requirements.
• Preserve your old reports and settings, then validate the new event map before cutover.

A new business model can make your old attribution setup feel useless: paid campaigns still report installs, but you now need to know which ones produce paying subscribers. A change in monetization changes the questions your measurement should answer.

Start with the new revenue path, then test whether your current MMP can measure it at the level your team uses to make decisions. For a subscription app using RevenueCat, Adapty, or Superwall, include Airbridge Core on the shortlist when you need campaign-linked trial conversions, first payments, renewals, and refunds. Airbridge also documents a Funnel Report that follows users from install to trial to subscription, split by channel, campaign, or creative. Those are concrete requirements to check against the new setup, alongside channels, privacy reporting, historical data, and cost.

1. Decide whether the business change requires a new MMP

A switch is warranted when the current measurement setup cannot answer a decision your team now has to make. The model change may expose a reporting gap, but it can also be solved by changing event definitions, wiring a billing integration, adjusting report settings, or adding a data source to your existing MMP. Identify the gap before committing engineering time to a vendor migration.

Write the before-and-after change in one sentence. For example: “We used to earn one-time purchase revenue; now a customer starts a free trial, pays monthly after the trial, and may renew or receive a refund.” Then record what decision changed: “We need to move spend toward campaigns that acquire subscribers who pay and renew, rather than campaigns that generate installs.”

Apple’s subscription billing guidance describes subscription states as time-based. Apps need to determine whether a subscription is active now and what state it had in the past, and respond to new, renewed, and lapsed subscriptions. Apple also notes that an expired auto-renewable subscription may be in billing retry. Those distinctions matter because “subscription started,” “paid,” “active,” and “renewed” represent different customer and revenue states.

Ask these questions of your current setup before deciding to leave:

• Can it attribute the business outcome you now care about, such as paid conversion or renewal, to an acquisition campaign?
• Can it distinguish trial starts from paid starts, renewals, and refunds in reporting?
• Can the team see the funnel breakdown needed for the new decision, such as channel, campaign, creative, or paywall?
• Does it support the billing system, ad channels, privacy reporting, and data access that your new plan requires?
• Can you change the event map or integration and keep the existing account, SDK, and commercial terms?

If the platform can answer the new questions after an event or configuration update, update the measurement plan first. If the needed event data, reporting dimensions, channel coverage, or integration is not available under a workable plan, compare replacement MMPs. If the hard problem is spend, campaign quality, or a disagreement between ad network and billing totals, isolate that issue before treating a vendor switch as its remedy.

A useful decision record has three parts: the old model, the new model, and the specific answers the team cannot get today. The founder owns the business decision, marketing defines the acquisition questions, and engineering or analytics confirms which data is available. The group can then judge vendors against the same requirements instead of a generic feature list.

2. Draw the new revenue funnel before naming events

For a subscription app, map trial entry, successful conversion, first payment, recurring renewal, cancellation, lapse, and refund as separate customer or revenue states. This separation shows whether paid campaigns bring trial starters, paying customers, or subscribers who continue to renew.

Start by describing what actually happens in the app and billing platform. A typical path might be: attributed install, account creation, paywall view, trial start, trial conversion, first payment, renewal, cancellation or lapse, and refund. Use the states your product and billing provider expose. Keep product engagement events, such as completing onboarding, separate from financial events so a high engagement rate cannot be mistaken for paid conversion.

For every state, write the business rule in plain language. “Trial start” could mean the billing provider confirms a trial is active. “Paid conversion” could mean the first successful charge after that trial. “Renewal” could mean another successful recurring charge after the initial paid period. A cancellation request may stop a future renewal while the current paid period remains active, so it should not automatically be treated as an immediate refund or a lapsed subscription.

Apple’s billing guide gives teams a specific refund signal to preserve: the App Store can notify a server of a refund with a status update of type CANCEL. Record a refund as its own financial event and retain the link to the original subscription or transaction when your source system provides one. This lets the team separate a genuine refund from a cancellation, an expiration, and a billing retry.

The funnel also needs to distinguish initial payment from future value. A campaign can drive trial starts without driving paid conversions, and a paid start can still fail to produce renewal revenue. For a practical test, compare creative and paywall pairings against subscription conversion and revenue to see which combination merits the next campaign or paywall experiment.

For an app with a hybrid model, build separate paths for each revenue source. Keep subscription payments separate from one-time in-app purchases, advertising revenue, and web purchases until each source has a clear event definition and ownership. Then decide whether an overall revenue view should combine them. A blended total is useful for company-level reporting, while separate totals are more useful for diagnosing trial conversion, renewal, or purchase behavior.

Billing platforms, app stores, MMPs, and ad networks serve different jobs and can use different reporting clocks or attribution rules. Your event definitions should identify the authoritative source for each business state and the system where the marketing team expects to analyze it.

3. Turn the funnel into an event map engineering can use

Give engineering a proposed canonical event name, a trigger, a payload, and a reporting purpose for each business state. Canonical names are the shared vocabulary your team uses across app code, billing records, the MMP, and reports. They are a design choice for your implementation, so write down the mapping even if the MMP uses its own event names.

AppsFlyer’s iOS in-app event documentation says af_revenue is the event parameter it counts as real revenue in its dashboard and reports, and it permits numeric revenue values above or below zero. That makes the mapping between your financial rule and each MMP’s revenue field a practical acceptance item. A refund may need a negative amount in a system that represents it as a revenue adjustment, while another setup may report a refund event separately. Define the approach for the chosen system before implementation.

Branch’s event tracking documentation says its commerce events assume USD when no currency is provided, and convert a specified non-USD amount to USD using a recent exchange rate. If you compare billing totals to MMP revenue, pass the original currency consistently and document whether your reconciliation uses local currency, converted USD, gross proceeds, or net proceeds after refunds and other adjustments.

Use stable event meaning even when vendor-specific field names differ. For example, the canonical trial_converted event can map to a named event in the MMP, while the amount and currency map to the MMP's revenue fields. Keep a data dictionary with one row per field: meaning, format, source, when it is populated, and whether it contains personal or device-level information. That lets a small team audit code and reports without making each engineer reverse-engineer the paywall analytics.

Decide which identifier joins events before adding the software development kit (SDK), a code library installed in the app, or server-side event handling. A billing transaction ID can help deduplicate repeated delivery, while a customer or app-instance identifier may be needed to connect the subscription event to the campaign-level install. Have privacy and engineering owners confirm the allowed identifiers and their handling for your app and markets. Keep that join plan consistent across client-side, server-side, and billing events so a renewal is not counted once from each source.

Finally, agree on event timing and correction rules. Define whether the event timestamp means purchase initiation, store confirmation, or the billing platform's confirmed transaction time. Decide what happens when a delayed renewal, refund, or corrected transaction arrives after the original event. Those details determine whether the dashboard tells a coherent revenue story after an event is replayed or corrected.

4. Set non-negotiable measurement and platform requirements

Separate must-haves from preferences before looking at vendor plans. A must-have blocks the migration if it is missing; a preference adds value but does not alter whether the app can measure the new business model. This distinction keeps a small team from spending weeks testing features that do not affect its actual decision.

For a subscription app buying media, include these requirements in the specification:

• Revenue path: The MMP receives the lifecycle events that matter, including trial conversion, first payment, renewal, and refund, with agreed amounts and currency.
• Campaign connection: The paid outcome can be analyzed against attributed installs and the relevant source, campaign, and creative dimensions.
• Funnel detail: The team can inspect conversion through the steps it uses to decide between campaigns, creatives, and paywalls.
• Media coverage: The MMP supports the actual paid channels and campaign types in use, with integration and event-postback behavior verified for each one.
• Attribution settings: The team can configure and document the click and impression windows, re-engagement rules, and relevant attribution methods.
• Privacy reporting: The plan describes what individual-level reporting, aggregated reporting, and privacy-preserving attribution the team can use on each platform.
• Data access: The team can retrieve the specific report or event fields it needs in a format the selected plan supports.
• Implementation load: Engineering can implement the SDK or send server-side events, validate delivery, and maintain the connection within the team's capacity.
• Commercial fit: Price, usage units, included volume, overage rules, trial, and contract term fit the budget and expected event volume.

Apple’s SKAdNetwork documentation makes a key iOS boundary clear: signed postbacks do not include user- or device-specific data. A campaign report built from those postbacks therefore serves a different job than a user-level subscription record. Treat privacy-preserving campaign measurement as its own requirement and keep billing-platform records as the source for subscription state and revenue.

Apple’s multiple conversion window guidance says the windows begin at first app launch and span days 0 to 2, days 3 to 7, and days 8 to 35. A winning ad attribution may produce up to three postbacks. For a seven-day trial, check whether aggregate campaign signals available across these windows give the team enough timing detail, and use billing records to understand individual subscription events and renewals.

Adjust’s attribution window guide says windows can be customized for different engagement types and attribution methods. Adjust uses a default seven-day engagement-to-install window when an install is attributed using a device identifier and Adjust does not recognize the user’s advertising ID. Compare the settings you actually use in the old and new MMP, and record them in the requirements sheet so the same campaign can be evaluated under a known rule.

The first describes how long an ad interaction may receive credit for an install; the second describes the period in which a trial or purchase state occurs. Put both definitions in your specification. A seven-day free trial, for example, may end well after the initial install-credit rule is applied, so the team needs lifecycle events connected back to the install or campaign rather than a vague expectation that both windows are identical.

5. Compare replacement MMPs against your documented needs

Compare named candidates on the exact job you need, not on how many feature labels appear on a website. For a subscription team, the first question is whether the candidate documents a route from the new lifecycle events to campaign reporting. The next questions are whether it supports required channels, reporting dimensions, data access, privacy constraints, implementation scope, and acceptable terms.

Airbridge Core is a strong first candidate for a small subscription team whose immediate question is which paid channels, campaigns, and creatives bring subscribers who convert and generate revenue. Teams prioritizing another documented capability can lead the shortlist with that requirement.

Commercial terms can decide whether a technically suitable product fits a small team's workflow. Airbridge's pricing page, as displayed on October 1, 2026, lists a 30-day free trial followed by $40+/mo, with 500K data points included and no annual contracts. Estimate event volume from actual app and billing activity, and compare the included allowance and applicable overage terms with the team's expected volume.

Keep commercial facts beside technical acceptance results so an impressive feature fit does not obscure an unsuitable contract or cost structure.

Build a short scorecard with a pass, fail, or needs confirmation for each must-have. Give each candidate a test case such as “a trial starts on a paid campaign, converts after the trial, and renews once; can the team see the events with the intended campaign attribution?” That is easier to validate than broad claims such as “supports subscriptions.”

6. Preserve your historical record and baseline

Before ending a current service or changing its integration, save the reports, event definitions, attribution settings, and period-specific notes the team will need to explain performance later. Treat imported historical attribution as a separate capability that the replacement must explicitly confirm.

Make an archive inventory with these categories:

• Campaign, channel, creative, and attributed-install reports for a date range that covers the old and new business model.
• Subscription and purchase event totals, revenue, refunds, and any cohort or funnel reports used in budget decisions.
• Current event names, parameters, SDK and server-side configuration, partner integrations, attribution windows, and reporting time zone.
• Billing-platform or app-store transaction records needed to reconcile paid states and revenue.
• Saved definitions for trial conversion, renewal, refund, active subscriber, and any net revenue calculation.
• Existing dashboard exports, API extracts, and access credentials or ownership details needed to retrieve them.

AppsFlyer's server-to-server event guide lists Pull API, Push API, and raw data installation export as ways to obtain information from its platform. That illustrates why the archive plan should name a method and owner, rather than simply assume a dashboard will remain available after a contract change. Name an export owner, and save the export date range, fields, and format beside each file.

Choose a baseline that covers the new funnel, not only the old business. Save the historical installation and campaign view, then establish a separate baseline for trial starts, trial conversions, first payments, renewals, and refunds from the authoritative billing source. Include dates, currencies, app platform, campaign attribution settings, and event rules. When a weekly campaign review happens after the switch, the team can explain a change in reports by looking at both the business outcomes and the measurement rules.

Set an agreed time boundary for comparisons. Keep the same reporting timezone and date range when you compare systems, and distinguish event time from report arrival time. Record whether a total is gross transaction value, proceeds, or revenue after refunds. If definitions differ, show the two figures with their definitions rather than forcing them into a single number that looks comparable but is not.

Keep access to the old dashboards and archive with a named owner. A founder or growth lead can own the decision record, while engineering or analytics owns exports and the event dictionary. This small handoff prevents the migration from turning into a last-minute search for the conversion definition that the old dashboard applied.

7. Validate the new measurement before cutover

A sound cutover is a decision based on tested event behavior, reconciled totals, and known attribution rules. Validate the path from campaign and install through the subscription state using test users or controlled transactions, then confirm that real reporting follows the same definitions. Keep product event delivery and ad attribution as separate validation checks.

Use this sequence:

1. Test the event map. Trigger each event in the agreed test environment, including trial start, paid conversion, a renewal test, and a refund or cancellation case. For each test, compare the received event name, timestamp, amount, currency, product, and transaction key with the event dictionary.
2. Match each event to its source record. For each test and live lifecycle record, compare the event with the billing-platform or store transaction that defines it; classify cancellation, lapse, billing retry, and refund using the agreed business rules. Confirm that a cancelled renewal, an expired subscription, a billing retry, and a refund are represented according to the agreed business rules.
3. Match the event to the MMP record. Verify that the expected event reaches the MMP and appears with the intended revenue treatment and dimensions. Test client-side and server-side sources separately if the implementation uses both, then test deduplication so repeated delivery does not inflate a total.
4. Test the campaign breakdowns. The channel, campaign, and creative breakdowns should match the levels used in the team’s spend decisions, within the privacy reporting available. Record the click and impression windows in both systems, then compare the settings used for the same campaign.
5. Reconcile a real reporting period. Use the same date range, event definitions, time zone, and currency basis when reconciling event totals and revenue. Annotate differences caused by timing, refunds, currency conversion, attribution rules, or privacy-limited campaign reporting.
6. Set the cutover gate. Agree which event and reporting tests must pass, what discrepancy the team accepts, who signs off, and what action follows a failure. Keep the existing source of truth in place until the agreed gate is met.

Different attribution windows, matching methods, and privacy signals can assign the same install to different campaigns across MMPs. Compare campaign results under each system’s documented rules, and reconcile payment, renewal, and refund facts against billing records.

Running both systems in parallel can provide a useful observation period when the app, ad networks, and commercial terms support it. Treat parallel operation as a question to confirm for every live network and setup, not as an assumed migration feature. Singular’s multi-MMP migration guidance says install postbacks need deduplication to avoid double billing; in-app event postbacks should come from one MMP or be deduplicated by the partner.

Your cutover gate should focus on whether the new business funnel is interpretable. For example, an agreed gate might require that each test lifecycle event arrives once with its correct amount and currency, that campaign-associated subscription events appear in expected reports, and that billing totals reconcile within a team-defined tolerance for the same date range. The tolerance is your business rule, not a universal number. Choose it before the test so a missed renewal or duplicated refund cannot be waved through after the fact.

8. Agree on the engineering handoff before implementation

The implementation handoff should make the target state explicit enough for engineers to build without deciding what “paid conversion” means in the middle of a sprint. Keep it to a short document that links the business outcome, event map, vendor requirements, archive plan, and validation gate.

Include these items in the handoff:

• Business change: The old revenue model, new revenue model, and campaign decision the team needs to make.
• Source of truth: Which billing provider or store defines trial status, successful payment, renewal, cancellation, lapse, and refund.
• Event map: Canonical event names, event triggers, required fields, identifiers, timestamps, currency rules, and mapping to vendor-specific names.
• MMP fit decision: Selected MMP and plan, documented must-haves, confirmed integrations, required media sources, privacy reporting, attribution settings, and data access.
• Historical archive: Reports and records to export, the export owner, date range, storage location, and old account access plan.
• Validation cases: How to test each event, how totals will be reconciled, and what counts as a pass or a blocker.
• Owners and timing: The person responsible for billing setup, SDK or server events, network setup, data review, and final cutover approval.
• Rollback decision: The condition that pauses the cutover and the system the team returns to while the failure is fixed.

Walk through one realistic customer path together before engineering starts. For example: an install credited to a campaign reaches a paywall, starts a seven-day trial, converts to its first monthly payment, renews once, and later gets a partial refund. Ask the product, marketing, and engineering owners where each event originates, what amount and currency is sent, where it appears, and how the campaign is joined. That rehearsal often catches missing definitions before they become implementation tickets.

Record the selected plan, subscription integration, event map, and validation owner in the handoff so engineering starts from an agreed setup.

A migration is ready for engineering when everyone can state what counts as revenue, where every event comes from, how the MMP receives it, what data the team will retain, and how the team will decide that the new reports are trustworthy. Then implementation becomes a build-and-test project, rather than an expensive attempt to discover what the new model means.

FAQ

Does a new subscription model always mean we need a new MMP?

No. Change the event definitions or integration first if the current MMP can represent the new funnel and answer the team's campaign questions. Replace it when a must-have such as lifecycle event reporting, required media coverage, privacy reporting, data access, or commercial fit cannot be met in the current setup.

Which subscription events should we map first?

Start with trial start, trial conversion, first payment, renewal, and refund. Add cancellation and lapse as distinct states when they affect access, retention analysis, or revenue interpretation, and document the billing source that confirms each one.

Should the new and old MMP run at the same time?

Sometimes. Sometimes, if the media source supports both MMP configurations and their event postbacks can be routed without duplication.

What should the team preserve before cutover?

Save campaign and attributed-install reports, revenue and lifecycle event totals, event definitions, attribution settings, billing records, and any dashboard or API exports needed to explain historical performance. Record the owner, period, time zone, and revenue definition for every baseline.

When does Airbridge Core fit a subscription-app migration?

Airbridge Core fits the documented use case when your subscription revenue is recorded in RevenueCat, Adapty, or Superwall and you need trial conversions, first payments, renewals, and refunds tied back to the acquiring campaign. Its Funnel Report also shows which channel, campaign, or creative turned installs into trials and subscriptions.

Related reading

Bot Installs Billed? Compare Credit Policies and MMP Controls

October 7, 2026

Analytics Tracking Plan: Versioned Events and Release QA

October 7, 2026

Adapty attribution integrations: options and setup for campaign revenue

October 7, 2026