Sync Amplitude cohorts to AppsFlyer

What it is

AppsFlyer is a mobile attribution and marketing analytics platform that ad networks read audiences from for targeting and suppression. Amplitude's cohort sync to AppsFlyer takes a cohort defined by product behavior - install without activation, high-value repeat purchaser, churned-but-reachable - and syncs its current membership into AppsFlyer on a schedule, keyed to device identifiers AppsFlyer's SDK already tracks.

This is specifically a device/user-audience push, not an events integration - if you also want raw event-level data flowing between the two systems (for attribution modeling on Amplitude's side, for example), that is a separate AppsFlyer source/postback configuration, not this destination.

When you need it

• A mobile growth team wants to suppress ad spend against users who already converted or reached a high-value state, and "converted" is a product-behavior definition (not just "has the app installed") that only Amplitude's event data can define precisely.
• You're building a retargeting audience for users who installed but never reached activation, and the activation definition already exists as an Amplitude funnel or cohort - resyncing that same logic by hand in a second tool is exactly the duplicated-definition problem cohort sync avoids.
• Marketing wants the audience to refresh automatically as user behavior changes, rather than a one-time device-ID list export that goes stale the day after it's uploaded.

Implementation, done properly

1. Confirm device ID collection is configured correctly in your mobile SDK implementation first - AppsFlyer cohort sync depends on a matchable device identifier existing on both the Amplitude and AppsFlyer side for the same install, so any device-ID mismatch upstream will silently cap how much of the cohort can ever sync.
2. Define and save the cohort in Amplitude exactly as you would for internal analysis, confirming its size and composition look right before attaching any destination.
3. Add AppsFlyer as a data destination in Amplitude and authenticate it with the credentials AppsFlyer's audience API requires (exact scopes and any minimum-plan requirement for cohort sync should be confirmed against current Amplitude and AppsFlyer documentation, since both vendors adjust API and tier gating independently of each other).
4. Attach the destination to the specific cohort and set a sync cadence appropriate to campaign pacing - a suppression list for active ad spend usually wants a tighter refresh than a quarterly win-back retargeting audience.
5. In AppsFlyer, connect the synced audience to the specific ad network integration or retargeting partner campaign, and confirm the audience type (retargeting vs. suppression) is configured correctly on the AppsFlyer side - a suppression audience wired in as a targeting audience produces the opposite of the intended spend outcome.

How to verify it worked

1. Check Amplitude's sync log for the cohort/destination pair and confirm the last run succeeded, noting the reported synced-member count.
2. In AppsFlyer, open the corresponding audience and confirm its size is in a plausible range relative to Amplitude's count - a large shortfall usually means a device-ID matching gap, most often from users who converted on a platform or SDK version where identifier collection wasn't fully wired up.
3. Trigger the cohort-qualifying behavior on a test device with AppsFlyer's SDK attached, wait one sync interval, and confirm the test device shows up in the AppsFlyer audience.
4. If the audience feeds a live suppression list, spot-check that a user who should be suppressed is not appearing in active ad impressions for the campaign in question - a suppression audience that fails silently just looks like normal ad spend, which is why this check has to be deliberate rather than assumed.

Related: Building behavioral cohorts in Amplitude · Fixing device ID regeneration · Use case: one funnel from ad click to activated user