Leaving Kochava: a 7-step MMP migration checklist
Archive Kochava reports, rebuild attribution in Airbridge, and follow seven steps for events, links and testing; optional IDs affect first-event counts.
Kochava migration: save the source records, then rebuild destination attribution.
- Export the Kochava reports and any data your account can access into a source archive before the billing cutoff.
- Rebuild event names, SDK collection, partner connections, and campaign links in the destination.
- Treat Airbridge identifier upload as optional first-event classification, not report-history transfer.
- Test events, attributed installs, and link routing before shifting live campaigns.
If your Kochava renewal is approaching, separate the work into two tracks: preserve the records you already rely on, then configure and validate the new mobile measurement partner (MMP). Kochava's exports give your team a source archive; the documented Airbridge migration guide describes a seven-step destination setup, from app registration and event taxonomy through SDK testing, reporting, and release.
The practical answer to “what migrates cleanly?” is: reports and configuration move into your archive, destination attribution setup gets rebuilt, and identifiers may be imported for a specific first-event purpose. Airbridge's migration FAQ says imported device and user IDs determine whether an event is a first event.
Airbridge says marketer and developer tasks in its seven-step migration can run in parallel, and the order and timing vary by situation (migration guide).
Archive Kochava records before the cutoff
A Kochava export is a saved record of what your old setup reported. A destination MMP needs its own app configuration, event collection, partner connections, and links, so treat those as rebuild tasks.
| Work item | Preserve from Kochava | Rebuild in the destination |
|---|---|---|
| Reporting | The Install, Event, Campaign Summary, Network Summary, Cost, and SKAdNetwork reports your team uses | New report views, filters, access, and recurring review |
| Event measurement | Event names, meanings, parameters, revenue treatment, and example payloads | Destination event taxonomy and app code that sends each event |
| Attribution rules | The configured attribution windows, eligibility rules, and model settings your team uses | The destination settings your team selects and records before comparing reports |
| Campaign setup | Partner names, account IDs, and event-to-partner postback mappings, meaning install or event notifications sent to ad partners | Destination-side partner integrations and postbacks |
| Links | Current tracking links, campaign names, destinations, and deep-link routes to specific app screens | New destination links or converted links, then routing tests |
| Identifiers | Prior device IDs or user IDs only when they serve a defined first-event use case | Optional identifier upload using the destination's required file format |
| Data pipelines | Raw-data extracts, query definitions, field selections, delivery schedule, and warehouse destination | New destination reporting or data pipeline appropriate to the plan and workflow |
Kochava's Reports Overview lists Click, Event, Install, Campaign Summary, Network Summary, Cost, and SKAdNetwork reports among its report types. Those are useful source records for recreating a weekly acquisition review, validating past campaign totals, and retaining context for decisions already made.
Build the source-side archive before renewal
Make one person accountable for the archive, usually the growth lead or analyst, and give engineering a separate list of setup records. Kochava describes report exports in CSV or JSON, delivered by email link or direct download, while its Kochava Query documentation describes pulling data from the platform or syndicating it to an AWS S3 bucket or SFTP server.
Use this inventory as your pre-cutoff checklist:
- Save the recurring KPI reports. Export the Install, Event, Campaign Summary, Network Summary, and Cost reports that support your current weekly or monthly meeting. Include SKAdNetwork reports when your team uses them. Keep each report's date range and applied filters with the file.
- Save the detailed event records your analysis needs. Kochava's report documentation describes configurable Click, Event, and Install reports. Choose the columns your team uses, such as campaign name, event details, and install or click context, then export a small test file and confirm it opens correctly before running the full date range.
- Copy the data feeds and query setup. Record the Kochava Query definitions, selected fields, scheduled delivery cadence, target S3 bucket or SFTP location, and the owner who can access the feed. Save the extracts your business needs in a company-controlled location, not in a departing employee's account.
- Record app and platform identifiers. List each app, package or bundle identifier, platform, production environment, and the Kochava app or account identifier used by integrations. This gives the destination setup owner a source of truth when registering the new app.
- Document events and revenue rules. Export or write down the event names, parameters, trigger points, revenue values, and currency treatment that drive subscription reporting. Include any version-specific names or event mappings that exist in the app.
- Capture current attribution configuration. Save the configured lookback windows, attribution rules, and any re-engagement or reinstall settings shown in your current account. Add a screenshot or dated configuration export to the archive so later report comparisons use the correct setup context.
- Inventory partner connections and postbacks. Record which media channels receive install or in-app event notifications, the event-to-notification mapping, account IDs, and who controls each partner account. Add the current self-attributing network (SAN) partner designation where it applies.
- Inventory live links and destinations. Export or copy active tracking links with their campaign names, destination URLs, deep-link targets, and owners. Flag links embedded in ads, email, QR codes, influencer briefs, or owned web pages because those placements need a deliberate replacement plan.
- Preserve report and feed access details securely. Record who can retrieve the archive and where it is stored. Keep passwords, API tokens, and secrets in your approved secret manager and rotate vendor credentials when the old integration is retired.
- Record your account's confirmed cutoff. Write down the renewal date, export access, and retention or delivery terms that Kochava confirms for your account. Assign each export a due date before that cutoff.
A clear folder structure helps a small team find the right artifact during a late-night launch check. One useful pattern is source-archive / app / platform / artifact-type / date-range, with a short README that names the owner, timezone, report filters, and file format for each export.
Treat device and user identifiers as sensitive records while creating this archive. The Federal Trade Commission's business guide to personal information advises businesses to know where personal information is stored, limit access to employees who need it, and keep only information needed for the business. Apply that guidance by using a restricted company folder, naming an expiration or deletion owner, and avoiding extra copies in personal drives or chat attachments.
Step 1: Prepare the destination event taxonomy
The marketer should define what each event means before a developer wires it into the app. Airbridge lists app registration and event-taxonomy preparation as required first-step work, which gives the team a concrete handoff before code changes begin.
Start with the customer action and the business question it answers. For a subscription app, the action may be a trial start, paid subscription start, renewal, or cancellation. These are example business events, so use the events your product actually sends and your team actually reviews.
| Business action | Write down before implementation | Why the mapping matters |
|---|---|---|
| Sign-up completed | The trigger that confirms account creation and any plan or product identifier recorded with it | Separates account creation from starting a trial or purchase |
| Trial started | The trigger that confirms a trial began, product or plan identifier, and any available trial length | Gives acquisition reporting a consistent definition of trial conversion |
| Subscription started | The paid-start trigger, product identifier, amount, and currency when available | Lets the team interpret revenue against the campaign that brought the user |
| Renewal | The renewal trigger and the product, amount, currency, and renewal period your app records | Keeps recurring revenue distinct from a first paid conversion |
| Cancellation | The cancellation action and whether it means a user request or an ended subscription | Prevents teams from treating two different lifecycle moments as one event |
For every event, record the source name, destination name, trigger, parameters, example value, and owner in a mapping sheet. Keep names and parameter types consistent across iOS and Android, and include one sample record from each platform for engineering to use in QA.
Archive the attribution settings alongside the taxonomy. Record the currently selected model and every lookback-window value that applies to your account, then decide which corresponding destination rules the team intends to use. A report comparison only answers a useful question when both sides use the date range, event meaning, and attribution settings the team expects.
Kochava's report documentation describes customizable Click, Event, and Install reports, so preserve the columns and definitions behind the views your team relies on. The destination event map is the working specification for rebuilding those views; a CSV of prior rows is the historical reference.
Step 2: Give engineering an SDK and test handoff
The developer's task is to install the destination software development kit (SDK), the code package that sends app events to the MMP, configure event collection and deep links, and test each platform before the new build goes live. Airbridge lists SDK installation and per-platform testing as a required step in its migration sequence.
Give engineering one ticket per platform with the following handoff:
- Register the app and identify the production app record. Share the destination app configuration, the production package or bundle identifier, environment, and the approved event map. Route QA events to the destination app record selected for the production app.
- Install and initialize the SDK. Follow the current platform-specific Airbridge integration instructions. Record the SDK version and the build in which it was added, then confirm the SDK initializes in the test app.
- Implement the mapped events. Wire each product action to its agreed destination event and parameters. Test the actual in-app action, not just a button or code path that users never reach.
- Add destination deep-link handling. Carry over the link destinations and in-app screens from the source inventory. On iOS, Airbridge's deep-link SDK instructions describe collecting the deep-link open and handling the link so the app routes to its intended screen.
- Run install and event checks separately. Use the destination's testing tools to confirm an install and then trigger each event in the event map. Save screenshots or test results with the build number and device platform.
For an iOS organic-install check, Airbridge's iOS SDK testing guide directs teams to install and launch the app on a test device, then check the App Real-time Logs for install details. The guide says the details can take up to 10 minutes to appear. Its testing checklist also asks teams to confirm SDK installation and address the App Tracking Transparency prompt on the test device, conditions that can affect what a test shows.
Test links on an actual device as well as a simulator or preview. Airbridge's iOS deep-link testing instructions use a test link to check whether the app opens and redirects to the intended in-app location. For Android deep links, the Airbridge Android quickstart describes handling links through an Activity and its intent filter; assign an Android device test that follows the link into the expected screen.
A useful handoff is a short pass/fail record for each platform: build number, test device, install result, each event name and parameters checked, link used, destination screen, and tester. When a check fails, fix the app mapping or link handling, run the same test again, and attach the new result to the ticket.
Step 3: Coordinate the Kochava settings cutover
Schedule removal of the old SDK, postbacks, and SAN designation alongside the destination SDK installation. Airbridge's migration guide assigns cleanup of the previous MMP to the developer and lists those three tasks in the same required step.
Use a cutover checklist that names both the person making the change and the time it takes effect:
- Remove the Kochava SDK from the app build that will ship with the destination SDK.
- Remove Kochava postback settings that would continue forwarding events after the new measurement setup starts.
- In each applicable SAN channel, change the attribution-partner designation from Kochava as part of the coordinated migration.
- Confirm which destination integration now receives event and install signals, then record the change in the channel setup inventory.
- Keep the previous account's reports available to the archive owner for historical review under your account terms.
This timing protects measurement integrity. Airbridge says that leaving previous-MMP postbacks or SAN integrations active can result in events counted across both systems or duplicate media optimization. Assign one technical owner to make the changes, and have the marketer verify the matching partner configuration before campaigns are directed to the new setup.
The change is best treated as a planned cutover, not an early cleanup task. Keep old campaign references in the archive, but make the active attribution partner and postback destination match the system your team is using after the cutover.
Step 4: Decide whether identifier upload is useful
Identifier upload is optional. Airbridge recommends considering it when you have prior identifiers or want to smooth the change in first-event counts after onboarding; its identifier import guide explains that importing identifiers can reduce the difference in those numbers.
For a subscription app team optimizing paid acquisition, use this decision path:
- Choose device IDs when app-campaign measurement or ad-spend reconciliation is the goal. Airbridge's identifier guide lists Device ID for those use cases and says it affects first events for app events.
- Add user IDs when they serve the selected migration use case. Airbridge's migration FAQ says a team does not have to import both device IDs and user IDs. The FAQ says imported IDs determine first-event status, while event counts in Airbridge reports and raw-data exports remain unchanged.
- Plan the upload with campaign owners. Airbridge's migration guide instructs teams to pause campaigns and promotions while identifiers are uploaded.
Follow the current file instructions rather than repurposing a Kochava report export as an identifier file. Airbridge's CSV requirements separate device IDs from user IDs, place the data in column A starting at A1, limit each file to 200 MB, and give each ID type its own filename pattern. The guide recommends using identifiers collected within the last 12 months, with the period adjustable to the campaign.
For device-ID files, the guide requires version 4 UUID format. For user-ID files, values must not have spaces or double quotation marks at the beginning or end. Use the import page's current instructions to prepare only the selected identifiers and event files; keep the import restricted to the necessary project users and remove working copies according to your data-retention practice.
The FTC's security guide recommends limiting vendors' and contractors' access to sensitive personal information to what their services require. Apply the same least-access approach to identifier files: name one owner, use a restricted company folder, and record where working copies are stored and when the team will delete them.
Step 5: Reconnect channels and replace old tracking links
The marketer and developer can reconnect media channels in parallel with app testing when their shared configuration is ready. Airbridge's migration guide says to connect media channels to collect data and use tracking links for non-SAN channels.
Work through the channel inventory one integration at a time:
- Reconnect each channel in the destination. Record the account or app-level connection used, the events the channel receives, and the person with access to its dashboard.
- Create or convert campaign links. Airbridge says teams that want to keep using previous-MMP links should convert them into Airbridge tracking links. Preserve the campaign name, destination, and deep-link target, then replace the old URL in each live placement.
- Test the routing path. Open the new link on a device with the app installed and verify the intended screen. Test the path for an app-not-installed user where that flow applies, and check the campaign and link information in the destination.
- Reconnect other tools selectively. Airbridge lists third-party solutions and data storage as conditional connections in the migration guide. Rebuild the integrations the team still uses and assign an owner to each.
- Complete SKAN setup when applicable. If the team continues to measure iOS campaigns with SKAdNetwork, Airbridge's guide directs the team to set up SKAN authentication and related configuration before launch.
Airbridge recommends verifying data flow through integrations and tracking links before live campaigns. That means checking the whole path: the ad or placement uses the new link, the link opens the expected app screen, and the intended event or install appears in the destination.
Step 6: Rebuild the reports your team uses
Start with decisions, then rebuild only the reporting views that support them. Kochava's report list provides a practical matching inventory; Airbridge's migration guide makes performance-report setup a required marketer step and calls out reports, Sharelinks, and Raw Data Export.
| Kochava source view | Destination reporting task | Archive or pipeline note |
|---|---|---|
| Install and Campaign Summary | Rebuild the acquisition view your team uses to review attributed installs and campaign outcomes | Keep the original exports with dates, filters, and attribution settings |
| Event and revenue views | Recreate the trial, paid-start, renewal, and other event views in the destination taxonomy | Match event definitions and revenue treatment before comparing totals |
| Network Summary and Cost | Rebuild the channel-spend view used in budget reviews | Record the date range and cost data source with the report |
| SKAdNetwork | Configure the corresponding iOS reporting workflow when the app uses SKAN | Save the old SKAN report with the campaign period it represents |
| Warehouse or analyst query | Connect a destination data workflow that fits the team's plan and analytics needs | Keep Kochava Query definitions and old extracts in the source archive |
Airbridge Core includes report export to Google Sheets and CSV. Its product details distinguish those report-level exports from raw-data export; Airbridge lists raw-data export with Growth. If your existing analyst workflow needs event-level data for a warehouse, choose the destination capability that matches that need before you design the pipeline around a report CSV.
For each rebuilt report, name the owner and review cadence. Record the date range, event definitions, timezone, and audience beside the report so the team can interpret changes consistently.
Reconcile a small set of known periods before rebuilding every dashboard. Choose one completed week, one campaign, and the subscription events your team uses to judge acquisition quality. Compare the archived Kochava output with the destination report using matching dates and definitions, then write down the reasons for differences that follow from changed event names or attribution configuration.
Step 7: Use a release gate before campaigns move
Release only after the app build and campaign setup agree on the new source of attribution. Airbridge's migration guide places app release after the preceding migration tasks and recommends checking integration and tracking-link data flow before live campaigns.
Use this release gate with the marketer and developer both present:
- App identity: The destination project contains the correct iOS and Android app records, and the test build reports to the intended app.
- Install collection: A test install appears in the destination's test or real-time view. For iOS, account for the documented delay of up to 10 minutes when checking App Real-time Logs.
- Event collection: The team triggers each mapped subscription event on each supported platform and sees the expected event name and usable parameters in the destination.
- Link routing: Campaign links open the intended app or fallback destination, and deep links route to the correct screen.
- Partner data flow: Every active channel is connected to the destination, and a test or integration check confirms data reaches the expected destination view.
- Duplicate-signal cleanup: Kochava postbacks and SAN partner settings have been updated as planned, so the team does not leave both MMP configurations directing optimization at the same time.
- Identifier upload: If used, upload is complete, campaigns and promotions can resume, and the team knows that imported IDs affect first-event classification rather than historical report rows.
- Reporting access: The acquisition and subscription views are ready for the people who make spend decisions, and the archive remains available for historical comparison.
- Cutover owner and time: The marketer records the point when campaigns switch to the new destination, and engineering records the production build that contains the new SDK.
Use one agreed cutover time in the migration ticket and have both owners confirm their tasks. If a test fails, hold the affected campaign change, fix the configuration or app behavior, and rerun the failed check. That gives a lean team a specific pass condition without assuming that a vendor migration will finish within a particular number of days.
FAQ
Does Kochava attribution history transfer into Airbridge?
Treat Kochava reports and raw-data extracts as an archive, and rebuild attribution setup in the destination. No. Keep Kochava reports and raw-data extracts as source records. Airbridge's migration FAQ says imported identifiers classify first events, while event counts in Airbridge reports and raw-data exports remain unchanged.
Do I need to upload both device IDs and user IDs?
No. Airbridge says identifier upload is optional, and its FAQ says both types are not required. Start with device IDs when ad-spend reconciliation or app-campaign optimization is the use case, then follow the file requirements and pause campaigns during upload.
Can I keep using Kochava tracking links?
Yes, convert previous-MMP links into Airbridge tracking links when you want to keep using them. Test each converted URL and its app destination before replacing links in live placements.
Can Airbridge Core export raw event data to my warehouse?
No. Core includes report export to Google Sheets and CSV; Airbridge lists raw-data export with Growth. Choose the report export for shared KPI views and match a raw-data workflow to the warehouse requirement.
Get Started Free
See how these criteria hold up on the real thing.
