AppsFlyer

Adapty échange des données avec AppsFlyer dans les deux sens. AppsFlyer indique à Adapty quelle campagne a amené chaque utilisateur. Adapty indique à AppsFlyer ce que cet utilisateur a payé — achats, renouvellements, essais et remboursements, avec les détails de revenus et de produits associés.

• Visualisez l’ensemble du cycle de vie de l’abonnement, pas seulement le premier achat. Les renouvellements et les conversions d’essai sont des événements store, sans session d’application pour que le SDK côté client d’AppsFlyer puisse les signaler. Adapty reçoit les événements d’abonnement côté serveur et les transmet à AppsFlyer, de sorte que les chiffres de campagne continuent de se mettre à jour bien après l’installation initiale. Les remboursements suivent le même chemin, et AppsFlyer les déduit des revenus de campagne.
• Optimisez vos campagnes publicitaires avec les données d’événements d’abonnement. AppsFlyer relaie les événements d’achats intégrés depuis Adapty vers vos réseaux publicitaires sous forme de postbacks. Les services qui gèrent votre budget publicitaire peuvent ainsi optimiser sur ce que les utilisateurs ont réellement payé.
• Filtrez les analyses Adapty par campagne. Adapty enregistre l’attribution AppsFlyer sur chaque profil, jusqu’au niveau du groupe d’annonces et de la création, et les graphiques d’abonnement peuvent être filtrés par ces données.
• Affichez un paywall différent par campagne. Les segments Adapty filtrent sur les mêmes champs d’attribution — campagne, groupe d’annonces et création. Utilisez un segment comme audience pour faire correspondre le paywall à l’annonce qui a amené l’utilisateur.

Fonctionnement de l’intégration

Adapty reçoit les données d’attribution d’AppsFlyer et lui renvoie les événements d’abonnement. Les deux dépendent d’une seule valeur : l’AppsFlyer ID, une chaîne générée par AppsFlyer au premier lancement de votre application.

1. Quand l’utilisateur installe votre app, le SDK AppsFlyer lui attribue un identifiant unique.
2. Votre app transmet cet identifiant à Adapty, qui le stocke dans le profil de l’utilisateur sous la clé appsflyer_id.
3. Votre app transmet également les données d’attribution AppsFlyer à Adapty, qui les enregistre sur le même profil.
4. Plus tard, quand l’utilisateur déclenche un événement d’abonnement — par exemple, il démarre un essai ou achète un produit — les serveurs d’Adapty envoient l’événement à l’API S2S d’AppsFlyer avec le même appsflyer_id.
5. AppsFlyer associe cet identifiant à l’installation qu’il a déjà attribuée, de sorte que l’achat hérite de la campagne et de la source média de cette installation.

Instructions de configuration

Avant de commencer :

• Confirmez que votre offre AppsFlyer accepte les événements S2S in-app. Le forfait d’entrée de gamme Zero d’AppsFlyer ne le prend pas en charge : son API rejette chaque événement envoyé par Adapty avec un 403 Forbidden.
• Intégrez le SDK AppsFlyer dans votre application. L’identifiant AppsFlyer dont dépend l’intégration n’existe qu’après l’initialisation de ce SDK. Une intégration côté serveur seule ne génère pas cet identifiant.
• Désactivez toutes les autres intégrations d’attribution. Adapty n’accepte qu’une seule source d’attribution par profil et ne peut pas écraser une valeur existante. Sur iOS, l’attribution Apple Ads non organique est toujours prioritaire — consultez Sélectionner une source d’attribution unique.

Créer un token S2S dans AppsFlyer

Adapty s’authentifie auprès de l’API S2S d’AppsFlyer avec un token que vous créez. Seuls les admins AppsFlyer peuvent accéder à la page Tokens, demandez donc à l’un d’entre eux de créer le token si votre compte n’est pas admin. Passez directement à Configurer Adapty si vous en avez déjà un.

1. Connectez-vous à AppsFlyer.

2. Cliquez sur votre nom de compte en haut à droite et ouvrez le Security center.

   

3. Sur la page Manage your account security, trouvez la carte AppsFlyer API and S2S tokens et cliquez sur Manage your AppsFlyer tokens. La page Tokens s’ouvre.

4. Cliquez sur New token.

   

5. Saisissez un Name pour le token. Ce nom est uniquement pour votre référence et peut être modifié ultérieurement.

6. Sélectionnez le type de token S2S. Tout autre type rompra l’intégration.

7. Cliquez sur Create new token.

8. Retrouvez votre nouveau token dans la liste. AppsFlyer masque la valeur, alors cliquez sur l’icône de copie dans la colonne Token pour la récupérer.

   

Configurer Adapty

1. Ouvrez Integrations > AppsFlyer dans l’Adapty Dashboard.
2. Activez le bouton AppsFlyer.
3. Si vous avez déjà connecté votre app à l’App Store, le champ iOS App ID est automatiquement renseigné avec l’identifiant Apple numérique de votre app. S’il est vide, connectez d’abord votre compte App Store. Android ne nécessite pas de champ équivalent.
4. Collez le token S2S dans le champ Production de S2S key for iOS, S2S key for Android, ou des deux.
5. Renseignez les champs Sandbox pour que les achats de test ne viennent pas polluer vos données de production — voir Garder les données sandbox hors de la production.

6. Sous How the revenue data should be send, choisissez quelle valeur de revenus Adapty envoie en tant que af_revenue. Les trois options correspondent aux vues de revenus d’Adapty Analytics, votre choix détermine donc la vue avec laquelle vos chiffres AppsFlyer doivent correspondre.

7. Configurez les options restantes :

8. Renommez ou désactivez des événements individuels dans la section Events names — voir Noms des événements.

   

9. Cliquez sur Save.

Exclure les données sandbox de la production

Pour éviter que les achats de test ne se retrouvent dans vos chiffres réels, envoyez-les vers une application AppsFlyer distincte. Enregistrez une deuxième application pour vos builds de développement, puis collez son token dans le champ Sandbox de chaque section de plateforme.

Adapty achemine chaque transaction selon son environnement — les achats réels vers l’application dont le token est dans Production, et les achats de test vers celle dans Sandbox. Pour tout regrouper dans une seule application, collez simplement le même token dans les deux champs.

Les achats effectués lors des revues App Store et via TestFlight sont des transactions sandbox, même si elles s’exécutent sur une version de production. Adapty envoie ces achats avec la clé Sandbox.

Configurer le code de votre application

1. Enregistrez un callback de conversion auprès du SDK AppsFlyer. Sur iOS, implémentez le protocole AppsFlyerLibDelegate ; sur Android, l’interface AppsFlyerConversionListener ; sur Unity, l’interface IAppsFlyerConversionData. Sur React Native et Flutter, passez un handler à la méthode onInstallConversionData à la place.
2. Attendez qu’AppsFlyer appelle ce callback. AppsFlyer attribue chaque installation sur ses propres serveurs, donc le résultat parvient à votre application de manière asynchrone plutôt qu’au lancement. Le SDK rappelle le callback à chaque session ultérieure.
3. Dans le callback, récupérez l’identifiant AppsFlyer de l’utilisateur avec getAppsFlyerUID et transmettez-le à Adapty avec setIntegrationIdentifier(). Les événements d’Adapty n’atteignent le bon utilisateur AppsFlyer qu’avec cette valeur.
4. Dans le même callback, transmettez les données d’attribution d’AppsFlyer à Adapty avec updateAttribution(). Cela indique à Adapty quelle campagne a généré l’installation. Sur iOS et Android SDK 4.1 et versions ultérieures, la méthode s’appelle updateExternalAttribution().
5. Attendez la résolution de Adapty.identify() plutôt que de l’exécuter en parallèle des étapes 3 et 4. Adapty crée un profil anonyme à l’activation, puis bascule vers le profil identifié une fois que identify() est résolu. Un appsflyer_id défini pendant ce basculement ne survit pas toujours à celui-ci.

Pour la séquence complète, voir l’ordre des appels dans les SDK iOS, Android, React Native, Flutter, Unity, Capacitor et Kotlin Multiplatform.

class YourAppsFlyerLibDelegateImplementation {
    // Find your implementation of AppsFlyerLibDelegate
    // and update onConversionDataSuccess method:
    func onConversionDataSuccess(_ conversionInfo: [AnyHashable : Any]) {
        let uid = AppsFlyerLib.shared().getAppsFlyerUID()
        Adapty.setIntegrationIdentifier(.appsflyerId(uid))
        Adapty.updateExternalAttribution(conversionInfo, provider: .appsflyer)
    }
}

val conversionListener: AppsFlyerConversionListener = object : AppsFlyerConversionListener {
    override fun onConversionDataSuccess(conversionData: Map<String, Any>) {
        val uid = AppsFlyerLib.getInstance().getAppsFlyerUID(context)
        Adapty.setIntegrationIdentifier(AdaptyIntegrationIdentifier.appsflyerId(uid)) { error ->
            if (error != null) {
                // handle the error
            }
        }
        Adapty.updateExternalAttribution(conversionData, AdaptyExternalAttributionProvider.APPSFLYER) { error ->
            if (error != null) {
                //handle the error
            }
        }
    }
}

appsFlyer.onInstallConversionData(installData => {
    appsFlyer.getAppsFlyerUID(async (error, appsFlyerUID) => {
        if (error) {
            // handle the error
            return;
        }
        try {
            await adapty.setIntegrationIdentifier('appsflyer_id', appsFlyerUID);
            await adapty.updateAttribution(installData, 'appsflyer');
        } catch (error) {
            // handle `AdaptyError`
        }
    });
});

// ...
appsFlyer.initSdk(/*...*/);

AppsflyerSdk appsflyerSdk = AppsflyerSdk(<YOUR_OPTIONS>);

appsflyerSdk.onInstallConversionData((data) async {
    try {
        final appsFlyerUID = await appsFlyerSdk.getAppsFlyerUID();

        await Adapty().setIntegrationIdentifier(
          key: "appsflyer_id",
          value: appsFlyerUID,
        );

        await Adapty().updateAttribution(data, source: "appsflyer");
    } on AdaptyError catch (adaptyError) {
        // handle the error
    } catch (e) {
        // handle the error
    }
});

appsflyerSdk.initSdk(
    registerConversionDataCallback: true,
    registerOnAppOpenAttributionCallback: true,
    registerOnDeepLinkingCallback: true,
);

using AdaptySDK;
using AppsFlyerSDK;

// before SDK initialization
AppsFlyer.getConversionData(this.name);

// in your IAppsFlyerConversionData
void onConversionDataSuccess(string conversionData) {
    string appsFlyerId = AppsFlyer.getAppsFlyerId();

    Adapty.SetIntegrationIdentifier(
      "appsflyer_id",
      appsFlyerId,
      (error) => {
        // handle the error
    });

    Adapty.UpdateExternalAttribution(
      conversionData,
      "appsflyer",
      (error) => {
        // handle the error
    });
}

Vérifier l’intégration

1. Déclenchez un achat sandbox et ouvrez le Event Feed de votre application. Chaque tentative de livraison y apparaît. Pour lire la réponse d’AppsFlyer à une tentative échouée, survolez la ligne correspondante.
2. Dans AppsFlyer, ouvrez Settings > SDK Integration Tests > Live Events et sélectionnez votre appareil de test. Live Events liste les événements S2S dès leur arrivée, bien avant qu’ils n’atteignent le tableau de bord Activity d’AppsFlyer.
3. Ouvrez le tableau de bord Activity de votre application et confirmez l’événement, ses revenus et sa source média. Comptez environ une heure — les événements S2S n’atteignent pas ce tableau de bord immédiatement.

Structure des événements AppsFlyer

Adapty envoie une requête POST par événement vers https://api3.appsflyer.com/inappevent/{app_id}, avec le token S2S dans l’en-tête authentication. L’API 2 utilise https://api2.appsflyer.com/inappevent/{app_id}.

{
  "appsflyer_id": "1699887556000-6192770",
  "eventName": "af_subscribe",
  "eventTime": "2026-03-01 12:00:00",
  "eventValue": "{\"af_content_id\":\"yearly.premium.6999\",\"af_order_id\":\"GPA.3383-4699-1373-07113\",\"store_country\":\"US\",\"profile_country\":\"US\",\"af_content_type\":\"in_app\",\"af_revenue\":\"9.9900\",\"af_currency\":\"USD\",\"af_quantity\":\"1\"}",
  "os": "17.0.1",
  "bundleIdentifier": "com.example.app",
  "customer_user_id": "user_12345",
  "eventCurrency": "USD",
  "ip": "192.168.100.1",
  "advertising_id": "00000000-0000-0000-0000-000000000000",
  "idfa": "00000000-0000-0000-0000-000000000000",
  "idfv": "00000000-0000-0000-0000-000000000000",
  "att": "3"
}

eventValue contient l’achat lui-même. Les quatre derniers paramètres n’apparaissent que sur les événements qui génèrent des revenus :

Noms des événements

Par défaut, Adapty associe ses événements générateurs de revenus aux noms d’événements standard d’AppsFlyer, plutôt que de les envoyer sous ses propres noms en tant qu’événements personnalisés. C’est important si vous transmettez des événements aux réseaux publicitaires : un réseau réagit aux noms standard qu’il reconnaît déjà, ce qui vous évite d’avoir à créer un mappage pour chacun d’eux.

Tous les autres événements Adapty conservent leur propre nom, par exemple subscription_refunded. Dans la section Events names de la page d’intégration AppsFlyer, renommez les événements ou désactivez ceux dont vous n’avez pas besoin. Pour la liste complète de ce qu’Adapty peut envoyer, consultez Événements.

Limitations

• Un profil sans appsflyer_id ne génère aucun événement. AppsFlyer associe un événement à l’installation qui a généré l’ID, et lit la campagne depuis cette installation. Adapty n’envoie rien sans cet identifiant, et l’Event Feed signale ces profils — voir Les événements n’atteignent pas AppsFlyer.
• Pas de renvoi des données historiques. Adapty transmet les événements à partir du moment où vous activez l’intégration. Les achats passés n’atteignent jamais AppsFlyer.
• Les détails de l’appareil restent vides dans les données brutes AppsFlyer. Un événement S2S ne contient que ce que la requête transporte. Device Model, Device Category, Language, Operator, WIFI, App Version et App Name n’ont pas de paramètre S2S, donc rien de ce qui est envoyé de cette façon ne peut les renseigner.

Résolution des problèmes

• Les événements n’arrivent pas dans AppsFlyer
• Les achats apparaissent comme organiques
• Les anciens événements arrivent avec la date d’aujourd’hui
• Les renouvellements tombent au mauvais jour
• Les revenus dans AppsFlyer ne correspondent pas à Adapty Analytics
• Failed to authenticate dans l’Event Feed
• access_level_updated apparaît comme échoué dans l’Event Feed

Les événements n’arrivent pas dans AppsFlyer

Ouvrez d’abord l’Event Feed. Une livraison échouée affiche l’erreur renvoyée par AppsFlyer. Ces causes en expliquent la plupart :

• Le profil n’a pas d’appsflyer_id. Vérifiez que votre application appelle getAppsFlyerUID et passe le résultat à setIntegrationIdentifier sur chaque plateforme — voir Configurer le code de votre application.
• L’identifiant de l’application pour cette plateforme est manquant. AppsFlyer identifie chaque application par son ID, donc Adapty n’envoie rien sans lui. Les événements iOS nécessitent un iOS App ID sur la page d’intégration ; les événements Android nécessitent le nom de package dans App settings > Android SDK — voir Configurer Adapty.
• L’achat est une transaction sandbox et la clé Sandbox est vide. Voir Garder les données sandbox hors de la production.
• L’événement est désactivé dans la section Events names.

Une livraison réussie ne garantit pas qu’AppsFlyer conserve l’événement. AppsFlyer renvoie 200 OK pour toute requête bien formée, puis supprime les événements dont l’appsflyer_id ne correspond à aucune installation réelle.

Les achats apparaissent comme organiques

Chaque appsflyer_id identifie une installation, et chaque événement portant cet identifiant hérite de l’attribution de cette installation — la campagne qui l’a générée, ou aucune si l’installation était organique. AppsFlyer a besoin de 20 à 30 secondes ou plus pour attribuer une nouvelle installation. Un événement qui arrive avant ce délai n’a aucune attribution à hériter, et AppsFlyer le marque comme organique non attribué.

Attendez-vous à ce que les achats effectués au premier lancement soient signalés comme organiques — des essais qui démarrent dans les secondes suivant le lancement de l’application. Pour l’éviter, retardez suffisamment votre paywall pour qu’AppsFlyer ait le temps de terminer le traitement de l’installation.

Si chaque événement apparaît comme organique, et pas seulement l’achat occasionnel au premier lancement, la cause est l’attribution plutôt que le timing : une autre source a revendiqué le profil en premier. Voir Sélectionner une source d’attribution unique.

Les anciens événements arrivent avec la date d’aujourd’hui

Les événements peuvent parvenir à Adapty en retard pour deux raisons :

• Lorsque App Store Server Notifications affiche Delayed dans App Store Connect, Apple met ses notifications en file d’attente. Un renouvellement parvient alors à Adapty bien après qu’il se soit produit — voir App Store Server Notifications affiche « Delayed ».
• Les événements antidatés sont transmis dès que l’option Exclude historical events est désactivée.

AppsFlyer n’accepte pas les horodatages anciens de ce type. Pour garantir un traitement cohérent des événements, Adapty remplace eventTime par l’heure actuelle pour tout événement datant de plus de 26 heures. Cette réécriture ne peut pas être désactivée.

Les renouvellements sont enregistrés au mauvais jour

Apple notifie Adapty des renouvellements et des conversions d’essai avant qu’ils ne se produisent, et Adapty les transmet immédiatement avec l’eventTime futur inchangé. AppsFlyer conserve un horodatage futur uniquement s’il tombe le jour de réception — un renouvellement daté de demain se voit attribuer l’heure d’arrivée d’aujourd’hui à la place.

Activez Delay events with a future datetime dans les paramètres d’intégration. Adapty retient alors chaque événement jusqu’à sa date d’échéance, afin qu’AppsFlyer enregistre la date annoncée par Apple. Voir Horodatages d’événements avec des dates futures.

Les revenus dans AppsFlyer ne correspondent pas à Adapty Analytics

Adapty et AppsFlyer comptabilisent les mêmes achats de manière différente. Ces différences expliquent la quasi-totalité des écarts constatés.

• Le tableau de bord Overview d’AppsFlyer regroupe les revenus par date d’installation ; les graphiques d’Adapty les regroupent par date d’événement. Dans AppsFlyer, un renouvellement de juillet issu d’une installation de janvier est comptabilisé en janvier. Comparez ce tableau de bord avec l’analyse de cohortes d’Adapty, qui regroupe également les revenus par mois d’installation. Les rapports de données brutes d’AppsFlyer regroupent par date d’événement — comparez-les plutôt avec les graphiques d’Adapty.
• Les achats issus de profils sans appsflyer_id n’atteignent jamais AppsFlyer. Ils restent dans Adapty Analytics. Voir Les événements n’arrivent pas dans AppsFlyer.
• AppsFlyer n’affiche que la donnée de revenu sélectionnée dans Adapty. Le paramètre How the revenue data should be send détermine si Adapty envoie le revenu brut, les revenus nets de commission ou le revenu net. Comparer cela avec une autre vue d’Adapty Analytics génère un écart égal à la commission, la taxe, ou les deux.
• Adapty utilise le fuseau horaire de reporting de votre application ; AppsFlyer reçoit l’heure UTC. Les intégrations reçoivent toujours des horodatages UTC, quelle que soit la valeur définie dans App Settings. Un achat à 23h30 UTC le 1er juillet apparaît le 2 juillet dans Adapty si votre fuseau horaire de reporting est +02:00.
• AppsFlyer ne dispose pas des événements historiques. Il y a deux causes probables. Avec Exclude historical events activé, l’historique AppsFlyer d’un utilisateur commence à son premier lancement d’une version intégrant Adapty. De plus, Adapty ne renseigne jamais rétroactivement les événements traités avant l’activation de l’intégration.
• Les achats sandbox sont envoyés à l’application AppsFlyer identifiée par la clé Sandbox. Si c’est l’application de production, les achats de test gonflent ses revenus. Voir Garder les données sandbox hors de la production.
• Les événements désactivés dans l’intégration n’atteignent jamais AppsFlyer. Adapty Analytics les comptabilise quand même. Vérifiez la section Events names — désactiver subscription_renewed supprime l’essentiel des revenus pour toute application établie.

Failed to authenticate dans le flux d’événements

AppsFlyer rejette les identifiants lorsqu’ils ne correspondent pas à la version de l’API. L’API 2 attend une Dev key ; l’API 3 attend un token S2S. Changer de version sans remplacer la clé génère cette erreur à chaque événement.

Créez un nouveau token dans l’AppsFlyer Security Center et collez-le dans les champs S2S key, ou suivez Passer de l’API AppsFlyer S2S 2 à 3.

access_level_updated s’affiche comme échoué dans le flux d’événements

access_level_updated est un événement réservé aux webhooks. Adapty ne l’envoie jamais à cette intégration. Mais Adapty enregistre un résultat pour chaque intégration activée, et un événement non pris en charge est affiché comme un échec.