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

En bref : enregistrez les événements in-app riches post-installation (tels que la connexion, l'inscription ou l'achat in-app) attribués aux sources média et aux campagnes.

 Lectures connexes

Ces articles vous fourniront une vision complète de l'utilisation des événements in-app :

Pourquoi enregistrer des évènements in-app ?

Les événements in-app donnent un aperçu de ce qui se passe dans votre app et constituent l'outil idéal pour déterminer la valeur des utilisateurs de l'app et la qualité du trafic en provenance de différentes sources média. L'enregistrement des évènements in-app vous permet de mesurer les KPI tels que le ROI (retour sur investissement) et la LTV (lifetime value, durée de vie).

Lorsque vos utilisateurs valident une inscription, complètent un tutoriel, ajoutent un article au panier ou font des achats, les données d’évènements in-app peuvent alors enregistrer les évènements accompagnés de leurs détails. L'implémentation d'événements in-app est obligatoire à toutes les fins d'analyse post-installation.

À propos des événements in-app

Un événement in-app comprend un nom d'événement et peut inclure des paramètres d'événement. Lorsque vous ajoutez des paramètres d'événement à un événement in-app, ce dernier devient un événement in-app riche. Les paramètres d'événement vous fournissent plus de contexte et d'informations sur l'événement en cours. Par exemple, en plus de savoir qu'un utilisateur a effectué une réservation, les paramètres d'événement vous donnent accès à des détails tels que le type d'achat, la destination et les revenus.

travel.png

Événements prédéfinis et personnalisés

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.

Évènements générateurs de revenus

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

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.

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. 

af_revenue peut également générer des valeurs de revenus négatives si vous suivez des évènements tels que des transactions annulées ou des remboursements.

Remarque :

  • Veillez à ne pas formater la valeur de revenu. La valeur du revenu ne doit pas contenir de séparateurs de virgule, de devises, de caractères spéciaux ou de texte. Un événement de revenu sera par exemple 1234.56. AppsFlyer fournit une valeur de revenu avec une précision allant jusqu'à cinq décimales.
  • 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.

revenue_normalization_flow.png

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

 Exemple

Dans les paramètres de votre app, vous définissez la devise sur GBP. Un utilisateur français achète un produit via votre app. Le prix est indiqué en EUR (€). L’événementin-app que vous envoyez à AppsFlyer ressemble à ceci :

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);

Dans ce cas, AppsFlyer convertit les revenus de EUR en USD, puis en GBP. Supposons que le taux de change soit 1 = 1,13 $. 200 € deviennent 226,85 $. Ensuite, AppsFlyer convertit les USD en GBP. Supposons que le taux de change soit de 1 $ = 0,78 £. Donc 226,85 $ deviennent 176,92 £.

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.

 Exemple

Supposons que vous envoyiez des événements in-app avec des devises différentes de celle définie dans les paramètres de l'app, voire sans aucune devise. Dans cet exemple, la devise dans les paramètres de l’application est définie sur GBP.

Vous envoyez trois événements in-app à AppsFlyer.

  1. L'événement A a un revenu de 234 et la devise GBP.
  2. L'événement B a un revenu de 171 et la devise EUR.
  3. L’événement C a un revenu de 171 et aucune devise n'est spécifiée.

Données de revenus dans le tableau de bord

Le revenu qui apparaît dans le tableau de bord est la valeur convertie de la devise en USD de l’événement in-app, puis dans la devise des paramètres de l’app.

Si aucune devise n'est spécifiée dans l'événement, AppsFlyer utilise la devise USD par défaut. Le tableau de bord affiche l’événement et les revenus de la façon suivante :

In-Apps Events Utilisateurs uniques Nombre d'Actions Revenu
A 1 1 234 £
B 1 1 149,4 £ - converti de EUR en USD puis en GBP.
C 1 1 132,9 £ - USD par défaut étant donné qu'aucune devise n'est spécifiée. Converti de USD en GBP directement.

Données sur les revenus dans les rapports de données brutes

Si vous définissez la devise sur GBP dans les paramètres de l'app mais que vous envoyez des événements in-app avec différentes devises, le rapport de données brutes affiche les revenus dans la devise des paramètres de l'app ainsi que dans la devise de l'événement in-app.

Si vous définissez la devise sur GBP dans les paramètres de l'app mais que vous envoyez des événements in-app sans devise, le rapport de données brutes affiche les revenus dans la devise paramétrée dans l'app, et en USD.

Le rapport de données brutes des événements in-app affiche l'événement et les revenus de la façon suivante :

Événement Revenu de l'évènement Devise du revenu des évènements Revenus de l'événement en GBP
A 234 GBP 234
B 171 EUR 149,4 £ - converti de EUR en USD puis en GBP.
C 171 USD 132,9 £ - USD par défaut étant donné qu'aucune devise n'est spécifiée. Converti de USD en GBP directement.

Envoi d'événements

Vous pouvez envoyer des événements in-app à AppsFlyer de différentes manières :

  • SDK AppsFlyer : il s'agit du moyen le plus courant d'envoyer des événements. Vous pouvez envoyer des événements in-app riches qui enregistrent les actions de l'utilisateur dans l’app avec des API d'événements in-app AppsFlyer au niveau du SDK.
  • API de serveur à serveur : utilisez l'API de serveur à serveur pour envoyer directement à AppsFlyer des événements qui se produisent en dehors de l'app mobile. Par exemple, si un utilisateur est actif sur les interfaces web et mobile, vous pouvez enregistrer des événements provenant des deux sources puis les attribuer au même utilisateur dans AppsFlyer. Il peut s'agir d'un événement in-app ou d'un autre événement, comme les événements de site, événements de centre d'appels ou bien encore les achats dans votre boutique de matériaux de construction.
  • Validation de la réception : il s'agit d'un mécanisme sécurisé où la plate-forme de paiement, par exemple Apple ou Google, vérifie que l'achat in-app a eu lieu comme indiqué. La validation de l'achat est le tout premier outil pour empêcher les événement de revenus frauduleux. Cela vous permet également de voir le revenu réel et d'éliminer les achats in-app incomplets. 
  • Apps hybrides : combinent des vues natives et du contenu HTML, et peuvent également enregistrer des événements in-app. Cependant, étant donné que le SDK peut uniquement envoyer des événements du côté natif, les développeurs doivent transférer toutes les données d'événement au code natif.

Configuration des événements in-app

Le processus de configuration des événements in-app nécessite que le marketeur et le développeur travaillent ensemble, de la façon suivante :

Étape Role Tâche Détails

1

Marketeur

Déterminez les événements in-app à mesurer. Définissez et communiquez les noms et les paramètres des événements à votre développeur.  

Nous vous recommandons de démarrer par 3 à 5 événements, que vous pourrez utiliser comme KPI pour mesurer la qualité de vos utilisateurs (par exemple : les achats, l'inscription et le partage). Les paramètres d'événement sont facultatifs, et vous pouvez utiliser n'importe quel paramètre d'événement avec n'importe quel nom d'événement.

Voir Événements recommandés par secteur d'activité pour les événements in-app typiques.

2 Développeur

Implémenter le code dans votre app, le cas échéant. 

La documentation destinée aux développeurs est disponible ici.

3 [Facultatif] Marketeur Travaillez en collaboration avec votre développeur pour définir le champ ID utilisateur du client (CUID)

Ce champ permet d'enrichir les données sur les événements in-app en comparant les données d'attribution AppsFlyer avec vos autres données qui utilisent le CUID comme clé.

4 [Facultatif] Marketeur Mapper les événements vers les partenaires concernés dans le tableau de bord.  Il s'agit d'une tâche permanente, qui dépend des partenaires avec lesquels vous êtes intégré.

Définissez un événement in-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.

 Exemple

Le marketeur d'une app de commerce électronique souhaite enregistrer le type de contenu que les utilisateurs consultent, afin d'identifier les catégories les plus populaires et de relier les consultations de produits aux ventes de produits.

Le tableau suivant est un exemple de structure d'événement que le marketeur transmet au développeur :
Nom de l'événement Paramètres d'événement Valeurs de paramètre Quand l'événement est-il déclenché ?
af_content_view af_price Prix du produit

Lorsqu'un utilisateur consulte la page d'informations d'un certain produit

af_content_type Nom de la catégorie de produit, par exemple, chaussures
af_content_id

ID du produit, par exemple, SKU

Afficher des données d’événement in-app

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.

Nos conseils

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.

    revenue_data.png

Limites

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 minuscules (a-z et 0-9) pour vos noms d'é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 distincts dans les données brutes. Cependant, dans les rapports agrégés (ex : aperçu, événements), ils peuvent être affichés comme étant un seul é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 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.
  • Nous recommandons de ne pas dépasser 1000 caractères pour les valeurs d'événement. 
  • Si vous incluez l'URL de référence en tant que valeur d'événement, elle doit être codée.
  • Facebook possède des limites spécifiques concernant les noms et les paramètres des événements. Pour en savoir plus sur les limitations, cliquez ici.

FAQ

La section suivante comprend diverses FAQ sur les événements in-app.

Comment utiliser le paramètre des revenus ?

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.

Comment AppsFlyer attribue les événements ?

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 :

Les événements sont-ils enregistrés si un appareil est hors ligne ?

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.

 Remarque

Le cache du SDK peut stocker jusqu’à 40 événements, ce qui signifie que seuls les 40 premiers événements survenus hors ligne sont enregistrés. Tout ce qui vient après, jusqu'à la prochaine réponse positive, n'est pas retenu.

L'heure de l'événement qui apparaît dans les données brutes est l'heure à laquelle l'événement est envoyé à AppsFlyer après la reconnexion en ligne de l'appareil. Ce n'est pas le moment où l'événement a eu lieu.

Que sont les événements in-app complexes et comment les configurer ?

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"
   }
  ]
}

Attention

Les événements in-app complexes entraînent des problèmes de postback chez Facebook et Criteo. Si vous voulez que l'événement soit entièrement mappé avec Facebook et Criteo, envoyez des événements séparés pour chaque action de l'utilisateur (ex : vous envoyez un événement Ajouter au panier pour chaque article ajouté). Utilisez les données brutes d'événements in-app pour regrouper ces événements.

Puis-je combiner plusieurs éléments en une même transaction ?

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.

 Exemple

Au cours de la même transaction, Mr. Smith achète deux chemises identiques, une paire de chaussures et un chapeau auprès d’un magasin en ligne basé aux États-Unis. La séquence selon laquelle chaque élément est répertorié doit être identique pour chaque paramètre.


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

Plusieurs éléments à la fois sont transmis sous forme de tableau dans les postbacks. À l'heure actuelle, Facebook et Twitter ne peuvent pas analyser correctement les paramètres de ces tableaux. Pour résoudre ce problème, AppsFlyer additionne la quantité d'éléments (af_quantity) au lieu de les envoyer à ces SRN sous forme de tableau. Dans notre exemple, Facebook recevrait af_quantity=4.

 Remarque

Plusieurs articles peuvent être utilisés avec les événements in-app suivants :

af_add_to_cart, af_add_to_wishlist, af_tutorial_completion, af_initiated_checkout, af_purchase, af_rate, af_spent_credits, af_content_view, af_travel_booking, af_update 

Comment AppsFlyer gère-t-il la déduplication des événements ?

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

 Remarque

La déduplication ne fonctionne que pour les événements in-app envoyés à partir du SDK.

Les événements in-app S2S ne sont pas dédupliqués.

Combien de temps AppsFlyer conserve-t-il les données niveau utilisateur et quelles sont les obligations de suppression ?

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.

Dois-je ajouter le paramètre OS (système d'exploitation) à mes événements ?

  • 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.