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 riches :

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.

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

Événements recommandés par secteur d'activité

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
InApp_Events_games.png  Événements recommandés pour les apps de gaming
InApp_Events_ecommerce.png Événements recommandés pour les apps de eCommerce
InApp_Events_streaming.png Événements recommandés pour les apps de divertissement
banking.png Événements recommandés pour les apps de gestion financière et bancaire
InApp_Events_lending.png Événements recommandés pour les apps de prêt P2P
education.png Évènements d'app de formation en ligne recommandés
InApp_Events_ride.png Événements recommandés pour les apps de transport
InApp_Events_flight.png Événements recommandés pour les apps de réservation de vols
InApp_Events_hotel.png Événements recommandés pour les apps de réservation d'hôtels
5669_Healthcare_icon_3.png Événements recommandés pour les apps de soins de santé
telecommunications_icon.png Événements recommandés pour les apps de télécommunication
InApp_Events_eWallet.png Événements recommandé pour les apps de portefeuille électronique
soccer_ball.png Événements recommandés pour les paris sportifs

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 d'aperçu du tableau de bord : affiche les performances en temps réel de la LTV d'acquisition d'utilisateurs (AU)
  • Page des événements : affiche les performances des événements in-app LTV sur l'ensemble des sources média
  • 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.

Conseils 

Gardez les points suivants à l'esprit lors de l'ajout de noms et de paramètres d'événements :

  • 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 les points suivants à l'esprit lors de l'ajout de noms et de paramètres d'événements :

  • 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énements ne peuvent pas commencer par les caractères suivants : ", =, +, -.
  • 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.
Cet article vous a-t-il été utile ?