Kochava Migration

This guide is for teams moving from Kochava (SmartLinks) to WarpLink: mapping SmartLink parameters, exporting existing links and data, and swapping the Kochava SDK for the WarpLink SDK on each platform, carrying over deep linking, install attribution, and analytics. It assumes a WarpLink account and app are already set up.

For the provider-agnostic playbook (planning, domains, cutover, decommissioning), see the general migration guide. This page covers only what is specific to leaving Kochava.

Concept Mapping

1. Export Your Links

Links via API. Kochava's Links API (https://links.api.kochava.com/v1, header auth Authentication-Key: {MyUserAPIKey}) exposes GET /links to list your SmartLinks with filtering and pagination, and GET /links/{id} to fetch one. Returned fields include id, guid, name, click_url, impression_url, custom_params, routes_by_app, destination_url, reengagement_url, and native_link. There is no documented bulk CSV export of link configurations, so plan to page through GET /links and reconstruct a spreadsheet yourself.

Historical click and attribution data. A separate Reporting API accepts time_start/time_end and returns CSV or JSON, with an option to have Kochava deposit reports directly into a customer-owned S3 bucket instead of polling.

2. Recreate Your Links

Recreate each SmartLink as a link in WarpLink via the dashboard or the REST API.

Parameter Mapping

Kochava's deep link macro names are case-sensitive: the placeholder in the click URL (for example {insert_deeplink_here}) must match the destination string exactly. When you move that value into ios_url or android_url, drop the macro syntax and put the resolved app-scheme path directly in the field.

Create via API

curl -X POST https://api.warplink.app/v1/links \
  -H "Authorization: Bearer wl_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "destination_url": "https://yourapp.com/product/123",
    "ios_url": "myapp://product/123",
    "android_url": "myapp://product/123",
    "og_title": "Check out this product",
    "utm_campaign": "spring_sale"
  }'

3. Swap the SDK

// Package.swift
dependencies: [
    .package(url: "https://github.com/WarpLinkApp/warplink-ios-sdk", from: "1.2.0")
]

4. Update SDK Initialization

import KochavaMeasurement

let measurement = Measurement.shared
measurement.start(appGUIDString: "_YOUR_APP_GUID_")

import WarpLink

WarpLink.configure(
    apiKey: "wl_live_yoursdkkeyhere000000000000000000",
    options: WarpLinkOptions(onLink: { result in
        if case .success(let link) = result, let link {
            navigate(to: link) // taps AND deferred installs (check link.isDeferred)
        }
    })
)

5. Update Domain Configuration

- applinks:your-brand-name.smart.link
+ applinks:yourapp.aplnk.to

smart.link is Kochava-owned infrastructure. Every SmartLink domain, including a branded your-brand-name.smart.link subdomain, is provisioned by Kochava's Client Success team on Kochava's own infrastructure, and Kochava hosts the AASA and Digital Asset Links files for it directly. There is no documented option for a fully customer-owned root domain pointed at Kochava through your own DNS. That means migrating off Kochava is not a DNS repoint: plan for a new link domain on WarpLink from day one, and update every published link (ads, emails, social bios, QR codes, App Store metadata) to the new URL rather than expecting the old one to carry over. Whether Kochava continues serving your smart.link subdomain after you cancel is not documented; confirm directly with Kochava before assuming old links stay live during your transition window.

Moving to a custom domain on WarpLink instead of your app's yourapp.aplnk.to subdomain? Declare it to the SDK too: linkDomains at configure(), or the WarpLinkDomains plist key / app.warplink.DOMAINS manifest entry. See Use it in your app.

Keep your existing Kochava Associated Domains and App Links entries in place alongside the new WarpLink ones while you cut over, so links already distributed keep resolving on-device until every surface is updated to the new domain.

If Android App Links fail to verify after cutover, the most common causes are a signing-key fingerprint mismatch between assetlinks.json and the APK's actual signature (especially with Play App Signing re-signing), a missing android:autoVerify="true", or assetlinks.json being served via a redirect instead of a direct response.

6. Migrate Deep Link Handling

The onLink callback set in step 4 already receives resolved links for cold start, warm start, and deferred installs.

func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
    WarpLink.continue(userActivity)
}

7. Migrate Deferred Deep Links

WarpLink runs the deferred deep link check automatically from configure(). The match arrives in the same onLink callback, flagged with isDeferred. There is no separate deferred call to port.

Kochava treats deep links and deferred deep links the same way from an SDK perspective: install-state at click time is the only difference, and both flow through the same deep link processing call rather than a separate deferred callback. There is nothing further to remove beyond the calls deleted in step 6.

options: WarpLinkOptions(onLink: { result in
    guard case .success(let deepLink) = result, let deepLink else { return }
    if deepLink.isDeferred {
        print("Match confidence: \(deepLink.matchConfidence ?? 0)")
    }
    navigate(to: deepLink)
})

To run the check manually instead, set the deferred opt-out flag and call checkDeferredDeepLink() yourself (see the deferred deep link guides for iOS, Android, React Native, and Flutter).

8. Attribution and Reporting

WarpLink attributes an install to the link that drove it through a match cascade: an exact referrer signal (Play Install Referrer) on Android, an enriched probabilistic match on both platforms, and a device ID (IDFV) check on iOS that recognizes an install asking again, with a confidence score on every result. See the platform attribution guides for iOS, Android, React Native, and Flutter for match types, confidence bands, and privacy details.

Kochava's own case-sensitivity warning for deep link macros (the placeholder name in the click URL must match the destination string exactly) is a common source of broken links when hand-porting an existing SmartLink into a new provider's parameter syntax. Double-check every ported link's destination once it is live on WarpLink, not just its configuration.

Testing Checklist

After migration, verify on each platform:

• SDK initializes: enable debug logging and check console output
• Deep links open the app: tap a WarpLink URL on a physical device
• Deep link data resolves: destination and custom parameters are correct
• Deferred deep links work: click link, install, verify match. An uninstall is enough to retest on either platform, because the completion marker goes with the app. That second install is reported as a reinstall and still counts as an install
• AASA/assetlinks verified: curl https://yourapp.aplnk.to/.well-known/apple-app-site-association
• Error handling: test invalid URLs, expired links, no connectivity
• Every ported deep link macro resolves to the correct destination, not just the literal placeholder string
• All Kochava code removed: no remaining imports or dependencies
• Clean build: no compilation errors

Next Steps

• General migration guide: the provider-agnostic playbook for planning, domains, cutover, and decommissioning.
• Quickstart: create your first link and get an SDK key.
• iOS SDK, Android SDK, React Native SDK, and Flutter SDK: full setup and API reference.
• Kochava alternative for small app teams: how WarpLink compares to Kochava.