Guide d'intégration du SDK iOS pour les marketeurs

Arrière-plan

À partir d'iOS 14.5, la collecte de l'IDFA nécessite le consentement de l'utilisateur En pratique, cela signifie que l'accès à l'IDFA est régi par la App Tracking Transparency(ATT). Sur les appareils iOS 14+, le SDK utilise l'infrastructure ATT pour accéder à l'IDFA de l'appareil. 

Pour une introduction à l'ATT, voir la section Principes de l'ATT.

Lorsque l'attribution se produit à l'aide de l'IDFA, il est important que ce dernier soit envoyé lors du premier lancement. C'est la raison pour laquelle le SDK fournit l'utilitaire waitForATTUserAuthorization.

Aperçu de waitForATTUserAuthorization

waitForATTUserAuthorization permet de configurer le temps d'attente du SDK avant d'obtenir le consentement ATT, période pendant laquelle l'envoi des données à AppsFlyer sera suspendue.

Lorsqu'un utilisateur lance l'app, le statut de l'ATT est notDetermined (non défini). Pendant le temps d'attente waitForATTUserAuthorization :

• Le SDK met en file d'attente l'événement de lancement et les événements in-app consécutifs en mémoire, de la même manière que les événements hors ligne sont enregistrés.
• Si l'utilisateur donne son accord pour l'ATT (collecte IDFA) :
  • Le SDK ajoute l'IDFA aux événements mis en cache.
  • Le SDK se lance et envoie les événements mis en cache accompagnés de l'IDFA (sans attendre la fin du délai d'expiration).
• Si l'utilisateur ne donne pas son accord pour l'ATT :
  • Le SDK se lance et envoie les événements mis en cache mais sans l'IDFA (et sans attendre la fin du délai d'expiration).
• Si le délai d'attente est écoulé et que le statut ATT reste notDetermined :
  • Le SDK démarre et envoie des événements mis en cache sans IDFA.

Attention

• Appeler requestTrackingAuthorization sans définir waitForATTUserAuthorization entraînera l'envoi de lancements et d'événements sans IDFA pour les appareils iOS 14+.
• Si l'utilisateur déplace l'app en arrière-plan durant le temps d'attente :
  • Le minuteur se met en pause jusqu'à ce que l'app revienne au premier plan.
  • Les événements sont mis en mémoire cache.
• Si l'utilisateur arrête l'app/l'application est supprimée pendant le délai d'attente :
  • Le minuteur redémarre lorsque l'app est à nouveau lancée.
  • Les événements mis en cache sont perdus.

Vous pouvez personnaliser la boîte de dialogue de consentement ATT. Un message énonçant clairement l'objet de la demande pourrait contribuer à augmenter le taux d'acceptation des utilisateurs.

Notez ce qui suit lors de la création de votre message :

• Utilisez une formulation qui explique au mieux à vos utilisateurs pourquoi l'app leur demande leur consentement.
• Expliquez aux utilisateurs comment leurs données seront utilisées. Pour en savoir plus sur la confidentialité et l'utilisation des données, cliquez ici.

Une fois votre texte terminé, envoyez-le à votre développeur avec ces instructions.

Pour voir quelques exemples externes boîte de dialogue de consentement ATT, cliquez ici.

SKAdNetwork est une classe utilisée par iOS qui valide les installations d'app pilotées par les annonceurs. Le processus de validation de l'installation d'une app implique l'app source et l'app annoncée. 

Une app source est une app qui participe à des campagnes publicitaires en affichant des publicités signées par un ad network. La configuration de votre app pour l'affichage de publicités sort du cadre du SDK AppsFlyer. Pour configurer, suivez les instructions d'Apple.

Pour l'app annoncée (l'app avec le SDK AppsFlyer), la solution AppsFlyer SKAdNetwork utilise SKAdNetwork pour fournir le postback d'attribution pendant qu'AppsFlyer collecte, traduit et agrège les données, tout en préservant la vie privée des utilisateurs. Lors du premier lancement de l'app, la plate-forme AppsFlyer utilise la configuration définie par le marketeur pour indiquer au SDK comment définir la valeur de conversion SKAdNetwork.

Pour utiliser la Solution SKAdNetwork :

• Le marketeur doit configurer la mesure de SKAdNetwork dans AppsFlyer . Le développeur ne doit effectuer aucune tâche.
• Le SDK AppsFlyer appelle automatiquement les API SKAdNetwork nécessaires.
• Assurez-vous de désactiver les appels SKAdNetwork dans d'autres SDK lorsque vous utilisez AppsFlyer pour l'attribution de SKAdNetwork.
• Aucune autre action ou procédure d'inscription n'est requise de la part du développeur ou du marketeur dans l'App Store. 

Pour désactiver l'attribution de SKAdNetwork, vous devez demander à votre développeur de la désactiver dans le SDK . 

Vous pouvez envoyer des revenus 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 logging revenue.

Le SDK AppsFlyer fournit 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 double rapport d'évènements.

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. Ceci est basé sur les paramètres de votre template OneLink. En savoir plus

Remarque : la détection et la redirection d'appareil ne requièrent pas le SDK AppsFlyer. Par contre, le SDK est nécessaire pour le deep linking.

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, par exemple Google Play, l'App Store d'Apple, l'app store tiers ou une 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.

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

Si vous souhaitez recevoir la confirmation que le SDK a bien démarré et que l'information a bien été reçue par les serveurs AppsFlyer, implémentez le gestionnaire startWithCompletionHandler. Vous pouvez ensuite appliquer cette logique pour gérer le succès ou l'échec du suivi du lancement du SDK.

Exemple d'implémentation

[[AppsFlyerLib shared] startWithCompletionHandler:^(NSDictionary<NSString *,id> *dictionary, NSError *error) {
        if (error) {
            NSLog(@"%@", error);
            return;
        }
        if (dictionary) {
            NSLog(@"%@", dictionary);
            return;
        }
    }];

 AppsFlyerLib.shared()?.start(completionHandler: { (dictionnary, error) in
            if (error != nil){
                print(error ?? "")
                return
            } else {
                print(dictionnary ?? "")
                return
            }
        })

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 vous permet d'ajouter des données personnalisées aux événements envoyés par le SDK. Elle est généralement utilisée pour l'intégration au niveau du SDK avec plusieurs plateformes partenaires externes, notamment Segment, Adobe et Airship.

Exemple de code setAdditionalData :

NSDictionary* customDataMap = [[NSDictionary alloc] initWithObjectsAndKeys:@"value_of_param_1", @"custom_param_1", nil];
[[AppsFlyerLib shared] setAdditionalData:customDataMap];

let customDataMap: [AnyHashable: Any] = [
  "custom_param_1" : "value_of_param_1"
]
AppsFlyerLib.shared().customData = customDataMap

Les propriétaires d'app qui utilisent des liens universels 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'app, 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.

Consultez la référence du SDK iOS 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 shared].minTimeBetweenSessions = <your_custom_time_in_seconds>;

AppsFlyerLib.shared().minTimeBetweenSessions = <your_custom_time_in_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.

Non disponible pour iOS. 

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.

[AppsFlyerLib shared].resolveDeepLinkURLs = @[@"example.com",@"click.example.com"];

AppsFlyerLib.shared().resolveDeepLinkURLs = ["example.com", "click.example.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 handlePushNotificationData dans AppDelegate.m.

-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
[[AppsFlyerLib shared] handlePushNotification:userInfo];
}

func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
    AppsFlyerLib.shared().handlePushNotification(userInfo)
}

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.

Attention ! La cross-promotion par IDFV nécessite les versions 6.0.2 et + du SDK. L'IDFV est collecté automatiquement sans aucune autre action de la part du développeur.

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

• Envoyez des événements in-app serveur à serveur.
• Faites le correspondre avec les enregistrements d'utilisateurs dans vos systèmes en arrière-plan.
• Mappez les entrées lors de la fusion des données de l'API Pull et de l'API Push.

Utiliser l’API suivante pour obtenir l’ID unique :

NSString *appsflyerId = [AppsFlyerLib shared].getAppsFlyerUID;

let appsflyerId = AppsFlyerLib.shared().getAppsFlyerUID()

Pour définir votre ID Utilisateur-Client :

[AppsFlyerLib shared].customerUserID = @"my user id";

AppsFlyerLib.shared().customerUserID = "my user id"

Dans iOS, l'ID utilisateur du client doit être défini à chaque lancement d'app. 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 :

NSString *customerUserID = [AppsFlyerLib shared].customerUserID;

let customerUserID = AppsFlyerLib.shared().customerUserID

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

Il est possible d'attendre que l'ID utilisateur client soit défini pour lancer l'initialisation du SDK. Ceci est utile si vous souhaitez que les données d'installation et d'événement contiennent votre ID utilisateur client.

Implémentez le code suivant :

- (void)applicationDidBecomeActive:(UIApplication *)application {
    NSString *customUserId = [[NSUserDefaults standardUserDefaults] stringForKey:@"customerUserId"]; // Your custom logic of retrieving CUID
    if (customUserId != nil && ![customUserId  isEqual: @""]) {
        [AppsFlyerLib shared].customerUserID = customUserId; // Set CUID in AppsFlyer SDK for this session
        [[AppsFlyerLib shared] start]; // Start
    }
}

func applicationDidBecomeActive(_ application: UIApplication) {
        let customUserId = UserDefaults.standard.string(forKey: "customUserId")  //  your logic to retrieve CUID
        if(customUserId != nil && customUserId != ""){
            AppsFlyerLib.shared().customerUserID = customUserId // Set CUID in AppsFlyer SDK for this session
            AppsFlyerLib.shared().start() // Start
        }
    }

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.

Vous pouvez retarder l'initialisation du SDK et l'envoi de données jusqu'à ce que l'utilisateur donne son consentement (par exemple, pour le RGPD ou le COPPA).

Remarque : ceci est sans rapport avec l'ATT introduit dans l'iOS 14. 

Pour retarder l'initialisation du SDK :

1. Empêchez la session d'être envoyée sur la transition arrière-plan/premier plan. Avec la méthode sendLaunch() (qui sera appelée sur chaque applicationDidBecomeActive - conformément à la section 3.3), encapsulez l'appel pour appeler start avec une vérification de la condition. Par exemple :
   
   

   -(void)sendLaunch:(UIApplication *)application {
       if (consent_given) { // check the condition
           [[AppsFlyerLib shared] start]; // Start
       }
   }

2. Envoyez la session dès que la temporisation ne se justifie plus (juste après le changement de condition).  Appelez start lorsque vous êtes prêt à envoyer les données de la première session. Par exemple :
   
   

   ...
   consent_given = YES; // change the condition
   [[AppsFlyerLib shared] start]; // Start
   ...

Dans certains cas extrêmes, vous pouvez vouloir arrêter tout enregistrement de données via le SDK en raison de la conformité aux exigences légales et relatives à la vie privée. La propriété isStop le permet. Une fois cette propriété définie sur true, le SDK cesse de fonctionner et ne communique plus avec les serveurs AppsFlyer.

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.

[AppsFlyerLib shared].isStopped = true;

AppsFlyerLib.shared().isStopped = true

Dans chaque événement, le SDK peut être réactivé en appelant la même API, avec la valeur false.

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

[AppsFlyer shared].anonymizeUser = YES;

AppsFlyerLib.shared().anonymizeUser = true

Les données de connexion peuvent être redémarrées en réglant anonymizeUser sur false.

Utilisez le SDK en mode strict pour supprimer complètement la fonctionnalité de collecte IDFA et les dépendances de l'infrastructure AdSupport (par exemple, dans le cadre du développement d'une app destinée aux enfants).

Note : IDFV reste disponible.

Dans votre Podfile, remplacez la dépendance AppsFlyerLib par :

pod 'AppsFlyerFramework/Strict','6.2.3'

Pour désactiver les infrastructures AdSupport et iAd, le SDK fournit les paramètres suivants :

• disableCollectASA = true. En savoir plus
• disableAdvertisingIdentifier = true. En savoir plus

Pour désactiver les infrastructures de publicité :

[AppsFlyerLib shared].disableCollectASA = YES
[AppsFlyerLib shared].disableAdvertisingIdentifier = YES;

AppsFlyerLib.shared().disableCollectASA = true
AppsFlyerLib.shared().disableAdvertisingIdentifier = true

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 empêcher le partage de données avec certains (un ou plusieurs) réseaux/partenaires intégrés.
• setSharingFilterForAllPartners : utilisé par les annonceurs pour empêcher le partage de données avec tous les réseaux/partenaires intégrés.

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 nécessaire pour déterminer si vous devez définir les filtres de partage, retardez l'initialisation du SDK. 

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

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

Actuellement, les données de désinstallation ne peuvent pas être filtrées par 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.