Analytics Data Migration for Deep Linking Platforms

Switching deep linking platforms is not just about updating SDKs and redirect rules. Your analytics data, the click counts, attribution records, conversion funnels, and campaign performance history, lives on the old platform. If you do not plan for data migration, you lose historical context and start from zero on the new platform.

This guide covers how to handle analytics data during a deep linking platform migration: what to export, how to maintain reporting continuity, and how to set baselines on your new platform. For the overall migration timeline, see migration timeline planning. For risk mitigation, see migration risk mitigation.

What Analytics Data to Migrate

Data You Can Export

Most deep linking platforms allow exporting:

• Click data: Timestamps, URLs, referring sources, device information.
• Attribution data: Install attributions, campaign IDs, source/medium.
• Conversion events: Post-install events that were tracked via the SDK.
• Campaign summaries: Aggregated performance metrics per campaign.

Data You Cannot Migrate

Some data is platform-specific and cannot be transferred:

• Real-time attribution state: The mapping between active sessions and pending attributions.
• Deferred link match queues: Pending click-to-install matches that have not resolved yet.
• Platform-internal IDs: User IDs and session IDs that are specific to the old platform's system.

What to Prioritize

Focus on exporting:

1. Campaign performance history (at minimum, monthly aggregates by campaign, source, and medium). This is essential for year-over-year comparisons.
2. Attribution records for the last 30-90 days. These are the most recent and relevant.
3. Conversion funnel data for baseline comparison after migration.

Export Strategies

API Export

Most platforms provide REST APIs for data export:

// Generic pattern for exporting analytics data via API
async function exportAnalyticsData(startDate, endDate) {
  const campaigns = await oldPlatformApi.get('/campaigns', {
    params: { from: startDate, to: endDate },
  });

  const results = [];
  for (const campaign of campaigns) {
    const stats = await oldPlatformApi.get(`/campaigns/${campaign.id}/stats`, {
      params: { from: startDate, to: endDate, granularity: 'daily' },
    });

    results.push({
      campaignId: campaign.id,
      campaignName: campaign.name,
      source: campaign.source,
      medium: campaign.medium,
      stats: stats.data,
    });
  }

  return results;
}

Export data in a portable format (CSV or JSON). Do not rely on the old platform's dashboard for historical access after canceling your subscription.

Dashboard Export

If the platform offers CSV/Excel export from the dashboard:

1. Export each report type (clicks, installs, events, campaigns).
2. Use the maximum date range available.
3. Export at the finest granularity available (daily rather than monthly).
4. Save the files with descriptive names and date ranges.

Third-Party Analytics

If your analytics are in a third-party system (Google Analytics, Amplitude, Mixpanel), the deep linking platform migration has less impact. Your event data in the analytics platform is independent of the deep linking platform. You only lose the deep linking platform's own analytics views.

Ensure your new platform's SDK sends the same event names and properties as the old one, so your third-party analytics reporting remains consistent.

Maintaining Reporting Continuity

The Gap Problem

During migration, there is a period where:

• Some users are on the old SDK (old platform attribution).
• Some users are on the new SDK (new platform attribution).
• Some links use the old platform's redirect.
• Some links use the new platform's redirect.

This creates a gap in unified reporting. Neither platform shows the complete picture.

Solution: Parallel Tracking

During the migration window, send analytics events to both platforms:

// Dual-tracking during migration
fun trackEvent(eventName: String, properties: Map<String, Any>) {
    // Track on the old platform (until fully migrated)
    oldPlatformSDK.track(eventName, properties)

    // Track on the new platform
    newPlatformSDK.track(eventName, properties)
}

Run parallel tracking for 2-4 weeks. This gives you:

• Overlapping data for validation (both platforms should show similar numbers).
• Continuity for stakeholders who rely on the old platform's dashboard.
• Time to verify the new platform is capturing everything correctly.

Baseline Comparison

Before migrating, establish baselines from the old platform:

Baseline metrics (last 30 days, old platform):
  Total clicks: 150,000
  Total installs: 12,000
  Click-to-install rate: 8.0%
  Deferred link match rate: 76%
  Top campaign: "summer_sale" (3,200 installs)
  Top source: "email" (4,500 installs)

After migrating to the new platform, compare:

First 30 days on new platform:
  Total clicks: 148,000 (expected: ~150,000)
  Total installs: 12,500 (expected: ~12,000)
  Click-to-install rate: 8.4%
  Deferred link match rate: 82%

If the new platform shows significantly different numbers, investigate. Differences of 5-10% are normal (different attribution models, different match algorithms). Differences of 20%+ suggest a configuration issue.

Handling Attribution Windows

Attribution in Transition

When you switch platforms, there are installs in the pipeline:

• User clicked a link on the old platform 3 days ago.
• User installs the app today, after the migration.
• Which platform attributes the install?

If the old SDK is still in the app: The old platform attributes it. This is correct. If the new SDK replaced the old one: The new platform cannot attribute it because the click was recorded on the old platform.

Best Practice

Keep the old SDK in the app (disabled for new event tracking, but still able to resolve pending attributions) for one attribution window cycle (typically 7-30 days) after migration. Then remove it.

// During migration: old SDK resolves pending attributions only
if (isMigrationPeriod) {
    oldSDK.resolveAttributionOnly() // No new event tracking
    newSDK.initialize() // Full tracking
}

Data Format Mapping

When importing historical data to the new platform (if supported), map the fields:

Old Platform Field	New Platform Field	Notes
campaign_id	campaign	May need renaming
media_source	source	Same concept, different name
sub1, sub2, sub3	custom_params	Different parameter structure
af_status	attribution_type	Platform-specific values
install_time	attributed_at	Same data, different field name

Create a mapping document before migration. This ensures historical imports map correctly.

Post-Migration Validation

After migration, validate the analytics pipeline:

1. Click tracking: Create test links on the new platform. Click them. Verify clicks appear in the dashboard within minutes.
2. Attribution: Install the app from a test link. Verify the install is attributed to the correct campaign.
3. Deferred deep linking: Click a test link, install, open the app. Verify the deferred link resolves and the attribution includes the deep link context.
4. Event tracking: Trigger post-install events (purchase, sign-up). Verify they appear in the dashboard with correct attribution.
5. Revenue tracking: If you track revenue, verify amounts match between your app and the platform's dashboard.

Tolinku Analytics Migration

Tolinku's analytics provides real-time click, install, and conversion tracking from the moment you start using the platform. For historical data, you can import CSV data from your previous platform to maintain continuity.

The Tolinku SDK sends standard event properties that map cleanly to third-party analytics platforms (Google Analytics, Amplitude, Mixpanel), so your existing analytics pipelines continue to work.

For the overall migration plan, see migration timeline planning. For running both platforms in parallel, see parallel running during migration.