AppsFlyer Renews in Six Weeks: A Migration Decision Guide
Start notice work now, then compare four AppsFlyer exit paths by launch readiness, channel coverage, reporting needs, and whether a written bridge is needed.
The practical answer for a six-week exit:
- Lock the non-renewal deadline today. Your signed order form and governing agreement control it.
- Choose a full replacement if the new SDK, key events, campaign setup, and app release can be tested before the current service ends.
- Choose a written bridge if you need time to test both systems or protect coverage while users update the app.
- Choose network dashboards plus your own subscription and product data only if you can accept a narrower cross-network view.
Start non-renewal notice work immediately. Run contract review, event and report mapping, and destination setup in parallel.
For a paid-acquisition subscription app, Airbridge Core Plan is a replacement candidate when Google, Meta, Apple Ads, and TikTok cover the paid sources you need and two active third-party integrations are enough. It has a 30-day free trial, then costs $40+/mo with 500K data points included and no annual contract; its setup includes a self-serve SDK flow with predefined events and a Test Console. Teams relying on additional ad networks, more integrations, or a custom report workflow should treat those as go/no-go checks before selecting Core.
1. Can you cancel before the renewal?
Your first deliverable is a dated notice plan, not an SDK ticket. Use the executed order form, governing agreement, and amendments to fill in the dates, delivery requirements, and renewal terms for this account. Record the renewal date, notice deadline, required recipient and delivery method, planned service-end date, and requested data-access window in one shared document.
Under AppsFlyer’s German-language MSA, each Subscription Package renews for a term equal to the expiring package unless the Order Form provides otherwise or either party gives written notice at least 30 days before the term ends. AppsFlyer’s general Terms of Use state that a Subscription Package automatically renews on the same terms unless an Order Form says otherwise or either party gives written notice at least 45 days before the term ends. Your executed terms determine which provision applies to your account.
With 42 days until renewal, a 45-day notice period puts the deadline three days in the past, while a 30-day period leaves 12 days. If the contractual deadline has passed, ask AppsFlyer now to agree in writing to non-renewal or a short extension, and save its response with the order form.
Have one named owner deliver the notice through the method and to the contact specified by the governing documents. Save the sent notice, timestamp, delivery record, and written acknowledgment with the signed order form. Put the service-end date, post-term account-access date, data export window, and final export procedure in the written handoff with AppsFlyer.
Use this deadline worksheet before choosing a migration route:
| Date or decision | What to write down | Owner |
|---|---|---|
| Current term end | Calendar date and time zone in the executed order form | Finance or legal owner |
| Non-renewal deadline | The applicable notice period, delivery method, and last safe send date | Contract owner |
| Notice receipt | Recipient, sent timestamp, delivery proof, and vendor acknowledgment | Contract owner |
| Service end | Date paid service and any account access end | Finance and data owner |
| Data handoff | Exports needed, file format, retrieval steps, and access end date | Data or analytics owner |
| Bridge decision | Written extension terms and the person authorized to approve cost | Founder or budget owner |
The handoff question matters because moving an SDK does not move historical reports with it. Ask for the campaign, install, event, and revenue exports your team actually uses, then test a sample file in your warehouse or reporting tool while the current account remains available. Preserve the source reports and the export date so the team can distinguish historical AppsFlyer data from new-vendor data after the cutover.
2. Which exit path fits six weeks?
Choose the route that fits both the contract clock and the cost of a blind period. Four paths are realistic; the safest one depends on whether you can get a written bridge, whether the new production build can ship in time, and how much cross-network reporting your weekly budget decisions require.
| Route | Best fit | What you gain | Work or trade-off to accept |
|---|---|---|---|
| Full MMP replacement | The new provider covers the channels, key events, links, and reports you use, and engineering can release a tested SDK build | A continuing MMP-based view for new installs and events after the new setup is live | Rebuild SDK and partner setup, campaign links, event mappings, and reports; historical reports need a separate export plan |
| Dual-run with a written bridge | A small team needs time to compare results or let users update before ending the old service | Time to validate the new setup while the existing service remains available | The bridge's cost, term, and service scope require written approval |
| Native network reporting plus internal analytics | The team can make near-term channel decisions inside each ad account and has reliable subscription revenue and product-event data elsewhere | A narrower measurement layer while a longer replacement project continues | Cross-network comparisons, common attribution settings, and one consolidated view need manual handling or internal analysis |
| Intentional measurement gap | The team has little paid spend during the gap, can pause or cap acquisition, and accepts weaker channel-level decisions temporarily | Time to complete a careful implementation without pretending the replacement is ready | New campaign attribution and optimization signals may be incomplete until the next system is live |
A dual-run is a decision by media source, not a global switch. AppsFlyer’s migration guide says some media sources do not support measurement by more than one MMP, and others place limits on it. In that same guide, keeping both SDKs active during an Adjust-to-AppsFlyer transition enables data comparison, but AppsFlyer warns that double attribution may lead to double charges from ad networks.
SDK overlap describes which app versions contain the measurement software; parallel attribution describes whether a network sends attribution data to both MMPs. Two SDKs can coexist in an app for a transition period while the team tests event collection or supports users who have not updated. Network partner rules determine whether attribution reaches both providers, and the selected campaign setup determines how each source reports activity. For each paid source, record whether it supports two MMPs, which campaigns it covers, and how it handles attribution and billing.
Apple’s AdAttributionKit documentation describes a privacy-preserving install attribution system that sends postbacks to ad networks. For eligible install conversions, one network receives the winning postback and up to five other networks may receive nonwinning postbacks.
A written bridge is the practical fallback when the launch build, validation, or data handoff will run beyond the current term. Ask for the bridge dates, fee, service scope, renewal behavior, and data access in the signed amendment. A renewal or extension is a contractual change, so plan around it only after the authorized parties confirm it in writing.
A native-reporting route fits a team that can live with separate views for each ad network and use its subscription platform or warehouse for revenue checks. It is less useful when a founder needs one comparable cost-per-subscriber number across channels or has to move budget daily based on a common event definition. In that case, budget either for a short bridge or for a staged release that keeps the current measurement system active while the replacement is verified.
3. Which MMP fits the measurements you actually use?
Build the shortlist from dependencies, then compare providers on published setup work and feature fit. Start from the last four weeks of campaigns and reports: list every paid channel, optimization event, subscription revenue event, link destination, partner postback, dashboard, and data export. Mark each as required on day one or safe to rebuild later.
| Candidate | Published information useful to a six-week decision | Fit test before selection |
|---|---|---|
| Airbridge Core Plan | The pricing page lists a 30-day free trial, then $40+/mo, 500K data points included, no annual contracts, and Google, Meta, Apple Ads, and TikTok attribution. The Core Plan introduction says Core allows up to two active third-party integrations and describes a self-serve SDK setup using predefined events and the Test Console. | Fits teams whose paid campaigns use these four networks, whose two active third-party integrations cover their needs, and whose event setup can use the documented SDK and Test Console workflow. |
| Adjust | Adjust’s migration guide lists app setup, SDK integration and testing, historical-data export and import, app release, campaign setup, link updates, and report exploration as migration work. | Map these tasks to owners, including historical-data transfer and report setup, and schedule them against the app release. |
| Branch | Branch’s MMP migration guide calls for SDK integration, event tracking, link-domain and attribution-window setup, partner event mappings, and replacement of existing paid-channel links. It recommends keeping the current MMP SDK active for at least two weeks after release to cover users who have not updated. | Fits teams that can rebuild event, partner, and link configuration and arrange service overlap while users update. |
| Singular | Singular’s SDK Audit Report guide describes checks for sessions, in-app events, revenue, recommended revenue tracking, and deferred deep-linking status. Its Meta integration instructions describe the Meta partner connection and say differing attribution windows can create discrepancies between network and tracker reports. | Fits teams whose QA requirements include these session, event, revenue, deep-link, and partner-setting checks. |
Reserve one integration slot for the app’s subscription-revenue source, then assign the other to the tool most important to acquisition or analysis. Map every must-have partner and report against the selected plan before assigning production engineering work.
Record each finalist’s verified quote, contract term, renewal date, support level, and required integrations in one decision sheet.
For Branch, migration work includes more than adding an SDK. Its guide says to configure event mappings for partner optimization, inventory and replace links used by paid channels, and first replicate the existing MMP setup before expanding functionality. It estimates eight days for the development-team workstream in its guide; use that as a task-planning reference, then size your own release based on the app code, QA load, and release calendar.
4. What must be ready before engineering changes production?
Keep production code out of the critical path until the migration inventory names the data and campaign behavior the new SDK must preserve. The UA lead owns channel and campaign expectations, engineering owns the app and event instrumentation, analytics owns definitions and report checks, and finance or the founder owns contract and bridge approvals.
Use this checklist to get the destination configuration ready:
- Campaign inventory: Record active campaigns, channel accounts, campaign names, link types, deep-link destinations, landing pages, and every place an old tracking link appears. Include ads, web pages, email, creator briefs, QR codes, and internal campaign templates.
- Event map: List every install, trial start, subscription start, renewal, cancellation, and product event used in campaign optimization or revenue reporting. For each, write the old event name, proposed new event name, trigger, value or currency fields, sending system, and receiving partner.
- Revenue source: Map the route subscription events take into the MMP: app SDK, server-to-server events, or subscription platform. Assign one source of truth for revenue and record which event statuses and amounts the MMP should receive.
- Partner setup: List every network and partner integration, the event postbacks it receives, attribution windows, and any campaign-specific settings. Add each partner’s supported overlap settings to the inventory before choosing dual-run test campaigns.
- Reports and exports: Save the report definitions and filters behind the numbers the team uses weekly. Export historical tables while the current account is accessible, and test their column names, time zone, identifiers, and date coverage in the new analytics destination.
- App and release dependencies: Record iOS and Android app versions, SDK versions, build owners, QA devices, release approvers, and external release dates. Google Play’s staged-rollout guidance recommends monitoring crash reports and user feedback during staged rollouts of app updates; assign one owner to review both.
- Link and deep-link checks: Save current destination behavior for new installs, existing users, deferred deep links, and web fallback. Make a test case for every route that carries a paid campaign.
- Ownership and escalation: Name one accountable owner for each workstream and one decision maker for the final go/no-go. Put vendor support contacts and the team's fallback route in the same project plan.
Event names that look similar can still represent different business moments. Map the app's actual trigger rather than merely copying a label: a trial event should fire at the defined trial start, and a paid subscription event should follow the team's paid-conversion rule. Agree whether amounts include refunds, taxes, trial value, or renewals before comparing revenue reports, so the team does not mistake different definitions for an SDK defect.
Historical data and new data also have different jobs. Historical exports support trend context and cohort comparisons; the destination MMP will begin its own reporting under its event, attribution, and network setup. Preserve the raw exports and the report definitions together, and put a visible date boundary in internal dashboards so analysts do not present the old and new systems as one unbroken measurement series.
5. What should happen in parallel during the first implementation weeks?
Start the notice and bridge work on day one, then open distinct tracks for account configuration, app integration, campaign migration, and report reconstruction. Those tracks can move together once event names and partner requirements are agreed; production release waits until the app build and the high-priority validation cases pass.
Week 1: Decide the route and freeze the requirements
The contract owner confirms the applicable renewal date and sends non-renewal notice using the required process. At the same time, the UA lead and analytics owner finish the campaign, event, and report inventory, while the founder requests any bridge terms needed to preserve a dual-run window.
Select the destination based on required channels, key events, integration slots, links, and report use cases. For Airbridge Core, verify that Google, Meta, Apple Ads, and TikTok cover the paid sources in the plan and that up to two third-party integrations cover the app's current needs. Attach the selected provider’s SDK guide, partner setup instructions, and historical-data export steps to the migration board before engineering starts.
Week 2: Configure the destination and begin the app work
Create the destination app and accounts, configure the event schema, add network integrations, and recreate the core campaign structure. Engineering can add the SDK and instrument agreed events while UA rebuilds campaign links and analytics prepares the baseline reports.
Airbridge describes its Core SDK setup as self-serve: a developer installs the SDK, logs predefined events, and validates setup in the Test Console. The company estimates that setup at one to two hours in its Core Plan introduction. Treat that figure as the documented SDK task, then separately schedule QA, app release work, campaign changes, revenue checks, and report reconstruction.
Branch's migration guide provides an example of the parallel work: development integrates the SDK and events while marketing configures links and attribution settings; partner events and campaign links then need their own setup. This sequence helps a small team split work among a developer, UA owner, and analyst instead of waiting for one person to complete every task in series.
Weeks 3 and 4: Test behavior and prepare release
Use a pre-production build or test environment to verify each event trigger, its value fields, subscription revenue events, link routing, and partner postbacks. Singular's SDK audit materials identify sessions, events, revenue, and deferred deep linking as test areas; its testing instructions also recommend a clean device for install-attribution tests and a prepared list of events and attributes to verify.
Singular’s Meta integration guide says its click-through lookback window takes effect immediately for live campaigns. Singular says different attribution windows can create discrepancies between the network and tracker, so record both settings in the test sheet before interpreting a count difference.
Build and submit the production app only when engineering, UA, and analytics agree on the required test results. Google Play allows staged rollouts for app updates, and its release guidance says a staged rollout reaches a percentage of users that the developer can increase over time. That helps contain a release while the team watches results, but it also means some users can remain on an older app version while the new SDK is rolling out.
Week 5: Start a controlled campaign transition
Begin with the lowest-risk live campaigns or a limited set of links, and verify clicks, installs, events, and destination behavior before moving the full budget. Branch specifically recommends starting link transitions on lower-spend ad networks, then replacing paid-channel links and maintaining its previous MMP SDK for at least two weeks after release to cover users who have not updated.
AppsFlyer’s multiple-MMP guidance says the app needs both SDKs and each media source must support two-MMP attribution; record the supported configuration per source, then monitor spend and attributed installs alongside billing settings. Set a temporary spend cap for any campaign whose delivery depends on a signal that has not passed validation.
6. How can you validate two systems without expecting matching numbers?
Use one scorecard with the same campaigns, event definitions, date windows, and time zones, but give each system its own expected result. Attribution products can differ because media sources use different rules and because each MMP's configuration may not be identical; matching totals are not the pass condition.
| Check | What to compare | Pass condition for your team |
|---|---|---|
| App build and SDK | Version released, SDK initialized, app opens and sends a session | The expected app versions report sessions in the destination system |
| Attributed installs | A controlled campaign, test click or eligible test flow, and install record | The destination records test installs and the source campaign fields you need |
| Optimization events | Trial, purchase, and any events used by paid campaigns | Correct event fires once at the intended user action and maps to the intended partner event |
| Revenue | Test subscription event, currency, amount, and renewal or cancellation handling | Values and timing follow the agreed revenue definition and arrive in the destination report |
| Links and deep links | New install, existing user, deferred destination, and fallback route | Each test opens the expected screen or fallback page |
| Privacy reporting | Apple postback and applicable network/SKAN reporting fields | Expected eligible postbacks and available fields appear under the selected network setup |
| Operations | Export, daily report, account access, and campaign link update | Named owners can retrieve and interpret the data needed for launch decisions |
Set the pass line before opening the dashboards. For example, the team might require every critical test event to arrive with the expected event name and value, all high-spend campaign links to resolve to the correct destination, and no unexplained missing reports across two full daily reporting cycles. Set a stricter pass line whenever a missing event could interrupt subscription optimization.
Compare campaign and day-level patterns rather than forcing identical user-level counts. Meta’s native reporting and an MMP can use different credit rules; AppsFlyer explains that Meta may count conversions associated with its own ad interaction while an MMP can assign credit to other networks on the path. Singular also advises matching Meta's attribution lookback setup to the MMP configuration because different windows can create reporting discrepancies.
Keep an exceptions log with five columns: date range, campaign, metric, AppsFlyer value, destination value, and explanation or next owner. Label expected differences such as time zone, reporting delay, attribution window, channel eligibility, or event mapping. Escalate a missing test event or a broken campaign link as a defect; treat a difference between two correctly configured attribution models as a reconciliation question.
For Apple privacy attribution, set the pass condition around required postbacks and fields because Apple’s AdAttributionKit documentation says Apple-signed postbacks contain no user- or device-specific data. Apple describes a winning postback and qualifying nonwinning postbacks to ad networks for install conversions. For launch, pass when the required privacy postbacks and fields arrive and provide the signal needed for the team's campaign decisions.
7. What does the Week 5–6 go/no-go and cutover look like?
Make the cutover a recorded decision with a named approver, a backup route, and a time for checking results. Keep contract status, production readiness, and campaign readiness as separate gates; a signed notice does not mean the destination is ready, and a working SDK does not change the renewal contract.
Go when all critical gates pass
- The non-renewal notice or extension is documented, and the service-end and account-access dates are confirmed in writing.
- Required campaign channels, events, partner mappings, links, and reports are configured in the destination.
- The production build is available to users, and the app and SDK checks pass on the release version.
- Revenue events and core product events arrive with the agreed names and values.
- High-spend links and deep-link destinations work, with a tested fallback for each important route.
- The team has exported the historic reports it needs and can retrieve the destination reports.
- Each active channel's overlap or cutover configuration has been confirmed, and the budget owner has approved any temporary measurement limitation.
When the gates pass, switch the campaign links and optimization event configuration in the planned order, starting with the test or lower-spend set. Watch daily attributed installs, core event delivery, subscription revenue, spend, and link errors; expand the campaign set only after the first group behaves as expected. Keep the final AppsFlyer export, the destination's launch date, and the last old-system reporting date with the migration record.
Hold when a critical dependency remains open
If the app release is delayed, a key event is missing, a major campaign link fails, or a network does not support the expected overlap, use the signed bridge or the pre-agreed narrower reporting route. The responsible owner should state which measurement decisions remain safe, which campaigns need a spend cap or pause, and the date for the next readiness review.
Do not let the six-week calendar silently decide the migration. If a bridge cannot be secured and the destination is not ready, choose deliberately between native network reporting with internal subscription data and a temporary reduction in paid activity. That choice makes the measurement limitation visible to the founder and finance owner instead of burying it in a rushed SDK release.
FAQS
FAQ
Is six weeks enough to switch MMPs?
Sometimes. Six weeks can cover destination setup, SDK work, event mapping, campaign links, and staged testing when owners start in parallel and the app release fits the schedule. A historical report rebuild, a delayed release, or a contract issue can make a written bridge the safer route.
Can we test two MMPs at the same time?
Yes, when the media source supports two MMPs and the account is configured for it. AppsFlyer’s multiple-MMP guide says some media sources do not support two MMPs, and supported sources may require specific configurations to prevent attribution discrepancies.
Does Airbridge Core fit every AppsFlyer replacement?
No. Airbridge Core fits teams whose paid acquisition needs Google, Meta, Apple Ads, and TikTok attribution and whose integration needs fit its limit of two active third-party integrations. Its listed price is a 30-day free trial, then $40+/mo with 500K data points included and no annual contract.
Should we remove the old SDK as soon as the new one ships?
Keep the old SDK until the transition period ends and the replacement’s events are live. Branch recommends maintaining the previous MMP SDK for at least two weeks after release so users on older app versions can continue sending data, while AppsFlyer warns that overlapping attribution can create duplicate credit or charges. Set the overlap and partner configuration for your destination, then agree on a removal date and bridge coverage.
What should the team do today?
The contract owner should lock the notice deadline from the executed agreement first. Send any required notice using the contractual method, save proof and acknowledgment, request service-end and data-access dates, and assign one person to own the migration decision.
Get Started Free
See how these criteria hold up on the real thing.
