Les événements in-app riches : aperçu

Pour pouvoir envoyer les événements in-app de votre choix, votre développeur doit implémenter du code dans votre app. Les noms et les paramètres d'événement sont classés comme suit :

• Prédéfinis : ce sont des noms d'événement et des paramètres d'événement couramment utilisés parmi différentes apps. Nous vous recommandons fortement d'utiliser des noms d'événement et des paramètres d'événement prédéfinis autant que possible pour les raisons suivantes :
  • Les noms prédéfinis permettent de mapper automatiquement les événements aux partenaires. 
  • Si AppsFlyer décide de modifier le nom ou le paramètre d'un évènement, votre implémentation est rétrocompatible.
• Personnalisés : il s'agit de noms d'événements et de paramètres que vous définissez pour des scénarios utilisateur spécifiques qui se produisent dans votre app. Vous pouvez utiliser n'importe quel nom d'événement ou chaîne de nom de paramètre personnalisée, mais n'oubliez pas que les événements personnalisés doivent être gérés par votre développeur. Voir Conseils et Limitations.

Chaque fois que vous envoyez des événements in-app, par exemple un achat ou une réservation de vol, vous envoyez également les revenus associés. Le seul paramètre qui génère des revenus dans les événements in-app estaf_revenue

• Enregistrement des revenus dans le SDK
• Enregistrement des revenus dans Unity

Vous pouvez également enregistrer des revenus négatifs si un utilisateur annule un achat ou si vous effectuez un remboursement. Pour enregistrer des revenus négatifs, il vous suffit d'ajouter le signe moins (-) à la valeur de revenu que vous transmettez à af_revenue.

af_revenue est le seul paramètre qui totalise le revenu de vos utilisateurs. Veillez à toujours l’utiliser avec des événements in-app qui représentent les revenus réels associés à votre logique métier.

af_revenue peut également avoir des valeurs de revenus négatives si vous suivez des évènements comme les transactions annulées ou les remboursements.

La valeur des revenus ne doit contenir que des chiffres (et un point décimal, si nécessaire) :

• N 'incluez pas d'autres caractères ou ne formatez pas la valeur des revenus d'une autre manière. Cela signifie qu'il n'y a pas de virgules, de signes monétaires (exemple $), de caractères spéciaux ni de texte.
• AppsFlyer fournit une valeur de revenu avec une précision allant jusqu'à cinq décimales.
• La plage de cette valeur doit être comprise entre -10 000 $ et +10 000 $, ou le montant équivalent dans la devise d'origine. Les montants en dehors de cette plage sont affichés dans les rapports de données brutes mais pas dans les rapports agrégés.
• Exemple : 1234.56
• Lorsque les revenus sont envoyées sous forme de chaîne, la valeur entre guillemets doit être valide. Par exemple : 1234.56

Remarque :

• AppsFlyer affiche le revenu exact envoyé par le SDK. Cela n'inclut pas de calcul de TVA ni de commissions sur l'App Store, etc., sauf si ceux-ci ont été inclus par le développeur côté SDK avant l'envoi à AppsFlyer.

af_currency représente la devise indiquée dans af_revenue (ou af_price). Si af_currency ne figure pas dans les paramètres de l’événement, AppsFlyer l'envoie avec la valeur par défaut USD.

Vous pouvez utiliser af_price comme paramètre monétaire qui ne sera pas considéré comme revenu (par exemple, dans un événement « Ajouter au panier »). Ce paramètre renvoie au prix de chaque article individuel. Le montant total des achats s’affiche sous le paramètre af_revenue.

Devise du revenu

Il est important de comprendre comment AppsFlyer gère les paramètres et conversions des devises.

AppsFlyer gère la différence entre la devise des paramètres de l'app et la devise des événements in-app en utilisant la conversion de devise.

Le diagramme ci-dessus illustre le processus suivant :

1. Les événements in-app sont envoyés - la devise est différente pour chaque événement
2. AppsFlyer échange toutes les devises en USD
3. AppsFlyer traite les données de revenus
4. Les données de revenus dans le tableau de bord s'affichent dans la devise des paramètres de l'app
5. AppsFlyer remplit les données de revenus dans les rapports de données brutes dans la devise des paramètres d'événement et d'app.

AppsFlyer utilise Open Exchange Rates pour la conversion de devise. Le taux de change est mis à jour toutes les heures. Chaque fois qu’AppsFlyer effectue une conversion de devise, le taux de change effectif l'heure précédente est utilisé.

Conversion de devise

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"category_a");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"EUR");
AppsFlyerLib.getInstance().trackEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue);

Affichage de la devise

La devise est définie dans les paramètres de l'app. La devise que vous définissez dans les paramètres de l’app est la devise qui apparaît dans le tableau de bord. Quelle que soit la devise que vous envoyez aux événements in-app, les revenus du tableau de bord apparaissent toujours dans la devise définie dans les paramètres de l'app.

Une fois que vous avez déterminé les événements in-app à mesurer, utilisez notre générateur d'événements in-app pour définir les événements et les paramètres comme indiqué ci-dessous :

1. Sélectionnez le nom d'événement qui convient le mieux au scénario que vous souhaitez enregistrer.
2. Sélectionnez les paramètres d'événement que vous souhaitez associer à l'événement. Choisissez des paramètres qui donneront un contexte supplémentaire à l'événement et enrichiront les données.
3. Téléchargez le fichier terminé à partir du générateur d'événements in-app, et transmettez-le à votre développeur.

Le tableau suivant fournit des liens vers des articles qui présentent des exemples et des flux d'événements in-app typiques que nous suggérons d'enregistrer par secteur.

Secteur	Titre de l'article
	Événements recommandés pour les apps de gaming
	Événements recommandés pour les apps de eCommerce
	Événements recommandés pour les apps de divertissement
	Événements recommandés pour les apps de gestion financière et bancaire
	Événements recommandés pour les apps de prêt P2P
	Évènements d'app de formation en ligne recommandés
	Événements recommandés pour les apps de transport
	Événements recommandés pour les apps de réservation de vols
	Événements recommandés pour les apps de réservation d'hôtels
	Événements recommandés pour les apps de soins de santé
	Événements recommandés pour les apps de télécommunication
	Événements recommandé pour les apps de portefeuille électronique
	Événements recommandés pour les paris sportifs

Les événements in-app sont attribués à la source média responsable de l'installation pendant la durée vie de l'utilisateur. Les données d'événement sont présentées sous forme de données Life Time Value ou d'activité. 

Vous pouvez consulter les données de vos événements in-app à ces endroits :

• Page de présentation du tableau de bord  affiche les performances d’acquisition d’utilisateurs LTV (UA) en temps réel. Remarque : cela inclut le revenu divisé entre les utilisateurs organiques et non organiques signalés via des événements in-app, et le retargeting des revenus attribués en double.
• Page des événements : affiche les performances des événements in-app LTV sur l'ensemble des sources média
• Page Activité : affiche les activités in-app pour la plage de dates sélectionnée.
• Rapport de données brutes d'évènements in-app : affiche les données d'activité, c'est-à-dire une liste chronologique des actions effectuées par votre base d'utilisateurs. Ce rapport inclut les valeurs des paramètres d'événement, par exemple :

  {
    "af_level":"10",
    "af_score":"3387",
    "arena":"7",
    "char_type":"paladin"
  }

  Notez que les rapports de données brutes sont une fonctionnalité premium.

Gardez à l’esprit les points suivants lorsque vous définissez les noms d’événements et les paramètres dans l’app :

• Pour assurer la cohérence des données dans les rapports de données brutes, nous recommandons de définir et d'utiliser les mêmes noms et structures d'événements in-app sur toutes les plate-formes.
• Utilisez un nombre minimal d’événements pour faciliter la comparaison de la qualité des utilisateurs issus de différentes sources.
• Il est important de protéger la vie privée de vos utilisateurs. Ne remplissez pas les valeurs d'événements in-app avec des informations restreintes susceptibles de les identifier directement. Cela concerne par exemple, l'adresse e-mail, le nom, le numéro d'identité et, à certains endroits, le code postal. Pour plus d'informations sur les données restreintes, lisez la politique de confidentialité des services.
• AppsFlyer collecte l'adresse IP des appareils lors des engagements. Dans certaines juridictions ou certains scénarios d'utilisation, l'adresse IP peut être considérée comme une IPP. Nous utilisons l'adresse IP pour dériver la situation géographique de l'appareil à un niveau large (ville, district), mais pas l'adresse spécifique. Si nécessaire, vous pouvez sélectionner Masquer les adresses IP afin que ces dernières n'apparaissent pas dans les rapports de données brutes. 
• Les événements in-app sont la seule source de données de revenu dans AppsFlyer. Vous pouvez associer une valeur de revenu spécifique à chaque événement et la visualiser sur le tableau de bord de votre application. En savoir plus sur les paramètres de monétisation.

  

Gardez à l’esprit les points suivants lorsque vous définissez les noms d’événements et les paramètres dans l’app :

• Nous vous recommandons d'utiliser uniquement des caractères alphanumériques en minuscule (a-z et 0-9) pour les noms de vos évènements in-app. Les noms d'évènements sont sensibles à la casse, ce qui signifie que af_purchase et af_PURCHASE sont deux évènements différents dans les données brutes. Cependant, dans les rapports agrégés (ex : aperçu, événements), ils peuvent s'afficher comme étant un même événement. 
• Il y a une limite de cardinalité de 300 événements uniques par jour. En savoir plus
• Les utilisateurs uniques ne sont comptabilisés que pour les 100 premiers événements après l'installation de l'app.
• Les noms d'événement ne peuvent pas commencer par les caractères suivants : " = + -
• Les valeurs des événements ne doivent pas contenir le caractère +, sauf dans les URL encodées, ou encodées via ASCII.
• Les noms d’événements ne peuvent pas contenir d’espaces vides. Vous pouvez utiliser des espaces soulignés (tirets du bas) avant ou après le nom de l'événement.
• Les valeurs des événements ne doivent pas dépasser 2000 caractères, où elles seront tronquées dans les rapports de données brutes. 
• Si vous incluez l'URL de référence en tant que valeur d'événement, elle doit être codée.
• Facebook impose des limitations pour les noms et paramètres des événements. Pour en savoir plus sur ces restrictions, cliquez ici.

Vous pouvez transmettre les valeurs de revenu avec n'importe quel nom de paramètre et événement. Cependant, pour enregistrer les revenus (revenus négatifs inclus) dans les données brutes et agrégées d'AppsFlyer, vous DEVEZ OBLIGATOIREMENT utiliser le paramètre af_revenue. Pensez à toujours l’utiliser avec les évènements représentatifs d'une génération de revenus avérés dans votre activité.

af_currency représente la devise indiquée dans af_revenue (ou af_price). Si af_currency ne figure pas dans les paramètres de l’événement, AppsFlyer l'envoie avec la valeur par défaut USD.

Pour plus de détails sur le paramètre af_revenue, consultez le guide d'attribution de revenu.

Les événements in-app sont attribués à la source média via laquelle l’app a été installée.

Lors de l’installation d’une app (premier lancement), AppsFlyer utilise diverses méthodes d’attribution pour déterminer l’attribution de l’installation. En parallèle, le SDK AppsFlyer crée un nouvel ID AppsFlyer unique, qui est associé aux informations d’attribution.

Chaque événement in-app effectué par la suite avec le même appareil dans l’application aura cet ID. Cela permet à AppsFlyer d’attribuer l’événement à la source média d’origine. Les annonceurs peuvent l’utiliser pour suivre le parcours complet de l’utilisateur dans leur app.

Les événements d’utilisateurs récemment soumis au retargeting peuvent être attribués en double double.

AppsFlyer attribue les événements des installations attribuées comme organiques dans les cas suivants :

• Plus de 24 mois se sont écoulés depuis la date d'installation
• Les conditions de la source média impliquent la suppression des données au niveau de l’utilisateur
• L’utilisateur supprime les données de l’app stockées sur l’appareil, forçant la création d’un nouvel ID AppsFlyer.

Si un utilisateur initie un évènement lorsque la connexion Internet est indisponible, Appsflyer est capable de l'enregistrer. Le fonctionnement est le suivant :

1. Le SDK envoie les événements aux serveurs AppsFlyer et attend une réponse positive.
2. Si le SDK ne reçoit pas une réponse positive, l'événement est stocké dans le cache.
3. Une fois la réponse positive suivante reçue, l'événement stocké est renvoyé au serveur.
4. S'il y a plusieurs événements dans le cache, ils sont envoyés au serveur les uns après les autres.

Les événements in-app complexes permettent d'envoyer plusieurs événements en une seul appel API.

Ils sont pratiques pour regrouper visuellement plusieurs actions d'utilisateur étroitement liées les unes aux autres (comme l'ajout au panier de plusieurs produits en une seule session).
Exemple :

{
  "af_revenue":"50.87",
  "af_currency":"USD",
  "af_receipt_id":"57601333",
  "product":[ 
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1177_8185",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"0153_9077",
	 "af_price":"14.99",
	 "af_quantity":"1"
   }
  ]
}

Vous pouvez combiner plusieurs éléments en une même transaction. Plutôt que d'utiliser des valeurs uniques par paramètre d’événement, vous pouvez avoir plusieurs éléments décrivant la transaction, séparés par des virgules.   Le format doit être une chaîne JSON.

"{\"af_content_id\": [\"123\",\"988\",\"399\"], \"af_quantity\": [\"2\",\"1\",\"1\"], \"af_price\": [\"25\",\"50\",\"10\"], \"af_revenue\": \"110\", \"af_currency\": \"USD\"}"

Nous utilisons un mécanisme de déduplication d'événements in-app. Il vérifie tous les événements in-app afin de savoir si un événement in-app identique provenant du même appflyer_id est apparu moins de 10 secondes auparavant. Si un tel événement est trouvé, le mécanisme supprime le doublon.

Deux événements sont considérés comme identiques si les champs suivants sont identiques dans les deux événements :

• Nom de l'événement
• Valeur de l'événement
• ID d'app
• ID AppsFlyer

AppsFlyer conserve les données brutes des utilisateurs pendant 24 mois, sauf indication contraire, obligation ou autorisation légale. Certains SRN/partenaires exigent des fournisseurs d'attribution, y compris AppsFlyer, qu'ils suppriment les données relatives aux utilisateurs liées aux SRN/partenaires avant l'expiration de la période de 24 mois.

Après suppression, les événements liés aux utilisateurs supprimés s'affichent en tant qu'événements organiques. Les données agrégées passées ne sont pas affectées. Pour plus d'informations, reportez-vous à la rubrique Obligations de conservation et de suppression des données.

• Le SDK Android et le SDK iOS ajoutent automatiquement le paramètre OS (système d'exploitation).
• Avec l'API S2S, depuis le 1er juillet 2021 vous devez envoyer le paramètre OS (système d'exploitation) pour les apps iOS. Si vous n'envoyez pas ce paramètre, les données sont considérées comme provenant d'un utilisateur iOS 14.5 et cela affecte la mise à disposition des données brutes.