L'intégration du SDK Android pour les marketeurs

Vous pouvez envoyer un revenu avec n'importe quel évènement in-app. Veillez à utiliser le paramètre af_revenue pour inclure le revenu. C'est le seul paramètre d'événement qu'AppsFlyer comptabilise comme revenu réel que ce soit dans les données brutes ou le tableau de bord. Pour plus de détails, cliquez ici.

Pour les instructions à l'attention des développeurs, voir les revenus de logging.

Le SDK AppsFlyer effectue une vérification au niveau du serveur pour les achats in-app. La validation d'un achat in-app envoie automatiquement un évènement d'achat in-app à AppsFlyer. Le fait d'envoyer vous-même cet évènement crée un rapport d'évènements en double.

Si votre app fait partie de la verticale des voyages, du gaming ou du E-commerce, consultez notre liste des événements in-app recommandés selon le secteur d'activité.

Pour les utilisateurs qui n'ont pas installé votre app, OneLink détecte le type d'appareil et les redirige vers la bonne destination, par exemple Google Play, l'App Store d'Apple, l'app store tiers ou une page web. Cette action se base sur les paramètres de votre template OneLink. En savoir plus

Pour les utilisateurs qui ont installé votre app, OneLink ouvre l'app. En plus de l'ouverture de l'app, vous pouvez deep linker les utilisateurs à une activité ou page spécifique de l'app. Cela nécessite que votre développeur implémente le deep linking unifié (DLU).

Remarque :

• Le DLU nécessite un SDK V6.1 et +
• Les clients qui utilisent déjà OneLink pour le deep linking peuvent utiliser la méthode traditionnelle, plutôt que le DLU.

Consultez notre guide de configuration du deep linking avec OneLink.

Pour les utilisateurs qui n'ont pas installé votre app, OneLink détecte le type d'appareil et les redirige vers la bonne destination : Google Play, l'App Store d'Apple, l'app store tiers ou la page web. Une fois que l'utilisateur a lancé l'app, vous pouvez utiliser le deep linking différé pour qu'il soit redirigé vers une activité ou page spécifique de l'application.

Cela nécessite que votre développeur implémente le deep linking unifié (DLU).

Remarque :

• Le DLU nécessite un SDK V6.1 et +
• Les clients qui utilisent déjà OneLink pour le deep linking différé peuvent utiliser la méthode traditionnelle au lieu du DLU.

Consultez notre guide sur le deep linking différé pour en savoir plus.

AppsFlyer prend en charge la mesure des campagnes de notification push pour l'ensemble des fournisseurs, et peut également accepter les développeurs qui utilisent les services directs de notification push de Google Cloud Messaging ou Apple. Les conversions, qui correspondent aux ouvertures d'app issues de messages de notification push, s'affichent dans le tableau de bord de retargeting.

Vous pouvez utiliser OneLink pour mesurer le réengagement des utilisateurs via notifications push. Pour infos consultez notre guide sur comment mesurer les campagnes de réengagement via notifications push.

Avec AppsFlyer, vous pouvez attribuer des installations pour des applications Android out-of-store. Cela vous permet de promouvoir vos applications et de toucher de plus larges audiences sur les marchés où Google Play n'est pas disponible. 

Pour plus de détails sur la façon d'attribuer des installations pour les applications out-of-store, cliquez ici.

Dans les campagnes de pré-installation, les propriétaires d'applications peuvent demander aux fabricants d'appareils de pré-installer leurs applications sur les appareils avant leur départ de l'usine.

Avec AppsFlyer, vous pouvez facilement attribuer les installations d'applications pré-installées. Lorsque les utilisateurs lancent votre application pour la première fois, AppsFlyer attribue l'installation au fabricant en tant que source média.

Pour plus de détails, veuillez cliquer ici.

Pour connaître la façon de configurer la mesure des désinstallations, cliquez ici.

Si vous souhaitez recevoir la confirmation que la demande a bien été reçue par les serveurs AppsFlyer, implémentez le port d'écoute AppsFlyerRequestListener.

La méthode de callback onRequestSuccess() est appelée toutes les 200 response (200 réponses) dans le cadre d'une demande d'attribution effectuée par le SDK.

La méthode de callback onRequestFailure(String error) est appelée pour toute autre réponse et renvoie la réponse sous forme de chaîne d'erreur.

Exemple d'implémentation

AppsFlyerLib.getInstance().start(getApplicationContext(), "devKey", new AppsFlyerRequestListener() {
            @Override
            public void onSuccess() {
                Log.d(LOG_TAG, "Launch sent successfully, got 200 response code from server");
            }
            @Override
            public void onError(int i, @NonNull String s) {
                Log.d(LOG_TAG, "Launch failed to be sent:\n" +
                                "Error code: " + i + "\n"
                                + "Error description: " + s);
            }
        });

AppsFlyerLib.getInstance().start(this, "devKey", object : AppsFlyerRequestListener {
            override fun onSuccess() {
                Log.d(LOG_TAG, "Launch sent successfully")
            }
            override fun onError(errorCode: Int, errorDesc: String) {
                Log.d(LOG_TAG, "Launch failed to be sent:\n" +
                        "Error code: " + errorCode + "\n"
                        + "Error description: " + errorDesc)
            }
        })

En cas d'erreur lors de l'enregistrement de l'événement in-app, un code d'erreur et une description de la chaîne sont fournis, comme indiqué dans le tableau qui suit.

L'API setAdditionalData est requise pour l'intégration au niveau SDK avec plusieurs plates-formes partenaires externes, dont Segment, Adobe et Urban Airship.
Utilisez cette API uniquement si l'article d'intégration de la plate-forme indique spécifiquement que l'API setAdditionalData est requise.

Exemple de code setAdditionalData :

HashMap<String,Object> CustomDataMap = new HashMap<>();
CustomDataMap.put("custom_param_1","value_of_param_1");
AppsFlyerLib.getInstance().setAdditionalData(CustomDataMap);

val customDataMap = HashMap<String, Any>()
customDataMap.put("custom_param_1","value_of_param_1")
AppsFlyerLib.getInstance().setAdditionalData(customDataMap)

Les propriétaires d'app qui utilisent des App Links pour le deep linking (sans OneLink), et qui ont un domaine associé à leur app, peuvent attribuer des sessions initiées à partir de ce même domaine grâce à la méthode appendParametersToDeepLinkingURL.

Prenons comme exemple un utilisateur qui lance une recherche sur Google puis clique sur votre domaine, www.example.com :

• Si l'utilisateur n'a pas encore installé l'application, il est dirigé vers le site (www.example.com).
• Si l'utilisateur a installé l'app sur son appareil, il est deep linké à l'application qui est associée à www.example.com. La session est attribuée à la source média (paramètre pid ) qui est spécifiée dans appendParametersToDeepLinkingURL.

Voir la référence du SDK Android pour plus d'informations.

Remarque : les bannières intelligentes permettent aux propriétaires d'app d'augmenter la conversion des visiteurs d'un site en utilisateurs d'app.

Par défaut, il doit s'écouler au moins 5 secondes entre deux lancements d'apps pour que cela soit considéré comme deux sessions distinctes (pour en savoir plus sur le comptage de session).

Utilisez l'API suivante pour définir la durée minimale entre les sessions :

AppsFlyerLib.setMinTimeBetweenSessions(int seconds);

Le fait de définir une valeur élevée à la durée personnalisée entre les lancements peut avoir un impact négatif sur les API qui s'appuient sur les données de session, comme le deep linking.

Vous pouvez signaler de nouvelles sessions utilisateur à l'aide de cette méthode de SDK. Par exemple, cela peut être utile pour les applications utilitaires qui s'exécutent en arrière-plan.

Utilisez cette API dans la fonction onCreate() de votre activité :

public void logSession(Context context);

Exemple d'utilisation :

AppsFlyerLib.getInstance().logSession(context);

Certains services tiers tels que les prestataires de services de messagerie encapsulent des liens dans des emails avec leurs propres domaines d'enregistrement des clics. Certains vous permettent même de définir vos propres domaines d'enregistrement des clics. Si OneLink est encapsulé dans de tels domaines, il est possible que ses fonctionnalités soient limitées.

Pour résoudre ce problème, vous pouvez utiliser l'API setResolveDeepLinkURLs. Utilisez cette API pour obtenir le OneLink des domaines de clic qui lancent l'application.  Assurez-vous d'appeler cette API avant d'initialiser le SDK.

Par exemple, vous avez trois domaines de clic qui redirigent vers votre OneLink : https://mysubdomain.onelink.me/abCD. Utilisez cette API pour obtenir le OneLink vers lequel vos domaines de clic redirigent.  Cette méthode d'API reçoit une liste de domaines que le SDK résout. Ajoutez le code suivant avant l'initialisation du SDK.

AppsFlyerLib.getInstance().setResolveDeepLinkURLs("clickdomain.com", "myclickdomain.com", "anotherclickdomain.com");

Le code ci-dessus vous permet d'utiliser votre domaine de clic tout en conservant les fonctionnalités de OneLink. Les domaines de clic sont responsables du lancement de l'application. En retour, l'API obtient le OneLink de ces domaines de clic. Vous pouvez ensuite utiliser les données de ce OneLink pour le deep linking et personnaliser le contenu de l'utilisateur.

Avec AppsFlyer, vous pouvez mesurer les notifications push dans le cadre de campagnes de retargeting.

Pour activer cette fonctionnalité, appelez la méthode sendPushNotificationData dans la méthode onCreate de chaque activité lancée à la suite d'un clic sur la notification :

AppsFlyerLib.getInstance().sendPushNotificationData(this);

Pour plus d'informations concernant la mesure des notifications push, veuillez lirececi.

Le fait de permettre à vos utilisateurs existants d'inviter leurs amis et contacts en tant que nouveaux utilisateurs de votre application peut être un facteur de croissance important pour votre application. Avec AppsFlyer, vous pouvez attribuer et enregistrer les installations provenant d'invitations utilisateur au sein de votre app.

Pour obtenir plus d'informations, reportez-vous à l'article concernant l'attribution des invitations utilisateur.

Un ID AppsFlyer est créé pour chaque nouvelle installation d’une application. Vous pouvez utiliser l'ID AppsFlyer à différentes fins :

• Envoyez des événements in-app serveur à serveur.
• Faites correspondre l'ID AppsFlyer et les enregistrements utilisateur dans vos systèmes en arrière-plan.
• Mappez les entrées au moment de la fusion des données de l'API Pull et de l'API Push.

Utilisez l’API suivante pour obtenir l’ID AppsFlyer :

public String getAppsFlyerUID(Context context);

Exemple d'utilisation :

String appsFlyerId = AppsFlyerLib.getInstance().getAppsFlyerUID(this);

Pour définir votre ID Utilisateur-Client :

public void setCustomerUserId(String id);

Exemple d'utilisation :

AppsFlyerLib.getInstance().setCustomerUserId("myId");

Nous vous recommandons de définir l'ID utilisateur du client au début du flux de l'app, car il est uniquement associé aux évènements rapportés après son installation :

• Si setCustomerUserId est appelé avant start, l'ID utilisateur du client apparaîtra dans les rapports de données brutes relatifs aux installations et aux évènements.
• S'il est défini après, l'ID utilisateur du client est uniquement associé aux évènements enregistrés après la définition de l'ID utilisateur du client.

Pour éviter de redéfinir la valeur de l'ID utilisateur du client après le premier lancement et réduire le nombre d'appels à votre serveur afin d'obtenir l'ID utilisateur du client, vous pouvez vérifier si sa valeur est vide ou non en utilisant :

AppsFlyerProperties.getInstance().getString(AppsFlyerProperties.APP_USER_ID)

Pour plus d’informations sur l’ID Utilisateur-Client, cliquez ici.

Il est possible d'attendre que le customerUserID soit défini pour lancer l'initialisation du SDK.

Pour indiquer que le SDK doit retarder l'initialisation dans l'attente de l'ID utilisateur du client, appelez :

AppsFlyerLib.getInstance().waitForCustomerUserId(true);

immédiatement avant la méthode init(). Le reste de l'initialisation du SDK doit rester inchangé.

Une fois le customerUserID fourni, appelez

AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this);

afin de fournir au SDK l'ID utilisateur du client approprié et de déclencher le SDK.

Le code doit apparaître comme suit :

public class AFApplication extends Application {
  private static final String AF_DEV_KEY = "qrdZGj123456789";
  @Override
  public void onCreate() {
    super.onCreate();
    AppsFlyerConversionListener conversionDataListener = 
    new AppsFlyerConversionListener() {
      ...
    };
    AppsFlyerLib.getInstance().waitForCustomerUserId(true);
    //WARNING! Removing above line doesn't cancel its effect.
    // Replace with this to stop waiting for CUID:
    // AppsFlyerLib.getInstance().waitForCustomerUserId(false);
    AppsFlyerLib.getInstance().init(AF_DEV_KEY, getConversionListener(), getApplicationContext());
    AppsFlyerLib.getInstance().start(this);
    // Do your magic to get the customerUserID
    // ...
    // any AppsFlyer SDK code invoked here will be discarded
   //Call the following API once the customerUserID is available:
 AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this);
  }
}

class AFApplication: Application() {
 private val afDevKey = ""

 override fun onCreate() {
  super.onCreate()
  val conversionDataListener = object: AppsFlyerConversionListener {
   ...
  }
  AppsFlyerLib.getInstance().waitForCustomerUserId(true);
  //WARNING! Removing above line doesn't cancel its effect.
  // Replace with this to stop waiting for CUID:
  // AppsFlyerLib.getInstance().waitForCustomerUserId(false);
  AppsFlyerLib.getInstance().init(afDevKey, conversionDataListener, this)
  AppsFlyerLib.getInstance().start(this)
  // Do your magic to get the customerUserID
  // ...
  // any AppsFlyer SDK code invoked here will be discarded
  // Call the following API once the customerUserID is available:
  AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this)
 }
}

Pour en savoir plus sur la façon de retarder l'initialisation du SDK jusqu'à ce que l'ID utilisateur du client soit disponible, cliquez ici.

AppsFlyer collecte automatiquement le google_advertising_id depuis la version 4.8.0 du SDK.

L'obligation de collecte de l'ID Google Advertising s'applique uniquement aux versions 4.7.X et supérieures du SDK.

Un identifiant unique d'appareil au minimum doit être collecté pour activer l'attribution. Les identifiants suivants sont disponibles : GAID, ID Android, IMEI et OAID.

GAID - Google Advertising ID

Recueilli automatiquement dans les apps qui contiennent les services Google Play. Si le GAID est disponible, l'IMEI et l'ID Android ne doivent PAS être collectés par l'app afin d'éviter toute violation de la réglementation Google Play.

Numéro IMEI et ID Android

Désactivé par défaut.Peut être collecté UNIQUEMENT pour les apps qui ne contiennent AUCUN service Google Play.
Remarque : depuis Android 10 (niveau 29 de l'API), sorti fin 2019, l'accès au paramètre IMEI est restreint.

Pour envoyer ces ID à AppsFlyer :

1. Sur l'application ouverte, collectez l'IMEI et / ou l'ID Android de l'appareil.
2. Appelez les API suivantes AVANT d'appeler la méthode start :
   

   AppsFlyerLib.getInstance().setImeiData("IMEI_HERE");
   AppsFlyerLib.getInstance().setAndroidIdData("ANDROID_ID_HERE");

OAID - Open Advertiser Identifier

Guide de mise en œuvre de l'OAID

Désactiver la collecte d'ID d'appareil

Les développeurs peuvent choisir de ne pas collecter les IMEI, ID Android et OAID en utilisant les API suivantes :

AppsFlyerLib.getInstance().setCollectIMEI(false);
AppsFlyerLib.getInstance().setCollectAndroidID(false);
AppsFlyerLib.getInstance().setCollectOaid(false);

Dans certains cas extrêmes, vous pouvez décider d'arrêter toute identification via SDK en raison d'une mise en conformité juridique ou relative à la vie privée. L'API stop permet cette interruption. Une fois cette API appelée, le SDK cesse de fonctionner et ne communique plus avec les serveurs AppsFlyer.

AppsFlyerLib.getInstance().stop(true, getApplicationContext());

AppsFlyerLib.getInstance().stop(true, applicationContext);

Il existe différents scénarios d'exclusion d'utilisateurs. Nous recommandons vivement de suivre les instructions exactes du scénario qui correspond à votre application.

Le SDK peut être réactivé en appelant :

AppsFlyerLib.getInstance().stop(false, getApplicationContext());
AppsFlyerLib.getInstance().start(getApplicationContext(), <AF_DEV_KEY>);

AppsFlyerLib.getInstance().stop(false, applicationContext);
AppsFlyerLib.getInstance().start(applicationContext, <AF_DEV_KEY>);

N'appelez pas start si stop est défini sur true. Vous pouvez vérifier l'état actuel du SDK en appelant :

AppsFlyerLib.getInstance().isStopped() // returns true if SDK is stopped, false otherwise

AppsFlyerLib.getInstance().isStopped // returns true if SDK is stopped, false otherwise

Utilisez cette API lors de l'initialisation du SDK pour anonymiser explicitement les installations, les évènements et les sessions d'un utilisateur :

public void anonymizeUser(boolean isDisabled);

Exemple d'utilisation :

AppsFlyerLib.getInstance().anonymizeUser(true);

L'identification peut être redémarrée en appelant anonymizeUser réglé sur false.

Dans certains cas, les annonceurs peuvent choisir de cesser le partage de données de niveau utilisateur avec des réseaux publicitaires/partenaires pour certains utilisateurs. Parmi les motifs on retrouve : 

• Les politiques de confidentialité telles que la CCPA ou le RGPD
• Les mécanismes de retrait des utilisateurs
• La concurrence avec certains partenaires (ad networks, tiers)

AppsFlyer fournit deux méthodes d'API pour arrêter le partage de données avec l'ensemble des partenaires ou avec certains d'entre eux :

• setSharingFilter: utilisé par les annonceurs pour déterminer quels (un ou plusieurs) réseaux / partenaires intégrés seront exclus de l'obtention des données.
• setSharingFilterForAllPartners: utilisé par les annonceurs pour exclure tous les réseaux / partenaires de l'obtention des données.

Ces méthodes de filtrage sont prises en charge à partir de la version 5.4.1 du SDK.

La méthode de filtrage doit être appelée à chaque fois que le SDK est initialisé et affecte la session entière.  Si un délai est requis pour déterminer si vous devez définir les filtres de partage, mieux vaut retarder l'initialisation du SDK. 

Lorsque la méthode est activée avant le premier appel start :

• Les utilisateurs des SRN sont attribués comme organiques, et leurs données ne sont pas partagées avec les partenaires intégrés.
• Les utilisateurs des réseaux publicitaires par clic (non-SRN) sont attribués correctement dans AppsFlyer, mais ne sont pas partagés avec ceux-ci via postback, API, rapport de données brutes, ou toute autre méthode.

Actuellement, les données de désinstallation ne peuvent pas être filtrées à l'aide de ces méthodes. Vous pouvez toutefois arrêter d'envoyer des événements de désinstallation aux partenaires en utilisant leurs pages de configuration dans AppsFlyer.