Lorsque AppsFlyer traite des événements in-app S2S, les champs d'attribution sont remplis en se basant sur l'ID AppsFlyer afin d'identifier l'événement d'installation qui a précédé les événements in-app.

Cela signifie que certaines données qu'AppsFlyer associe à des événements in-app S2S non organiques ne sont pas associées à des événements in-app S2S organiques.

Une démarche en arrière-plan est requise pour obtenir les valeurs permettant de renseigner les paramètres. Vous trouverez ci-dessous comment obtenir l'ID AppsFlyer :

• L'ID AppsFlyer est obligatoire et sert à attribuer les événements.
• Il est généré dès qu'un utilisateur installe une app mobile pour la première fois.
• Pour pouvoir mapper votre CUID à l'ID AppsFlyer, vous devez définir le CUID dans l'app. 

Pour connaître plus facilement l'utilisateur à l'origine de chaque évènement, procédez comme suit :

• Définissez l'ID utilisateur du client lorsque l'utilisateur installe l'app.
• Les rapports de données brutes AppsFlyer contiennent le CUID et l'ID AppsFlyer. Pour l'obtenir, utilisez l'un des outils de livraison de données ou bien l'API Push AppsFlyer.
• Utilisez les rapports de données brutes pour comparer le CUID et l'ID AppsFlyer. 
• L'ID AppsFlyer est disponible dans le SDK intégré à votre app (Android/iOS).
• Mappez l'ID AppsFlyer avec l'ID utilisateur du client dans vos systèmes internes (très important pour les futures utilisations).

Après avoir mappé l'ID AppsFlyer à votre CUID, vous pourrez facilement associer chaque utilisateur avec les événements qu'il a exécutés. Vous pourrez ensuite obtenir d'autres valeurs (valeur d'évènement, devise d'évènement, heure de l'évènement, etc.), puis envoyer l'évènement in-app de serveur à serveur.

appsflyer_id est un paramètre obligatoire dans les messages d’événement de serveur à serveur. AppsFlyer utilise ce paramètre pour attribuer l’événement à l’appareil d’origine et à la source média attribuée. Vous pouvez définir l’ID utilisateur en appliquant l'une des méthodes suivantes :

• Depuis un appareil mobile en appelant l'API SDK AppsFlyer :
  Android iOSUnity

  getAppsFlyerId

  getAppsFlyerId

  getAppsFlyerId

• Depuis la plate-forme AppsFlyer à l'aide de l'un des éléments suivants : API Pull, API Push, Exportation installation des données brutes.

Lorsque les événements S2S arrivent en groupe sur AppsFlyer, ils sont horodatés en fonction des valeurs de la propriété eventTime et de leur heure d'arrivée. La propriété eventTime indique l'heure à laquelle l'événement s'est produit dans l'application.

À leur arrivée, les événements sont horodatés comme suit :

• Si le paramètre eventTime n'est pas inclus dans l'enregistrement de l'événement, l'heure de l'événement correspond à l'heure d'arrivée du message HTTP.
• Les événements qui arrivent avant 02:00 UTC sont datés avec la valeur eventTime. En d'autres termes, pour que les événements soient marqués de eventTime, ils doivent être signalés soit le jour de l'événement, soit le jour suivant jusqu'à 02:00 UTC.
• Les événements qui ont eu lieu la veille ou encore plus tôt, mais qui arrivent après 02:00 UTC, sont datés à l'heure d'arrivée (l'heure de l'appel d'API).
• Les événements qui arrivent avec une heure eventTime future (eventTime est postérieure à l'heure d'arrivée) :
  • Si l'heure de l'événement eventTime et l'heure d'arrivée ont lieu le même jour, l'événement est daté à l'heure de eventTime.
  • Si la date eventTime transmise a lieu le jour suivant, l'événement est daté à l'heure d'arrivée.

Exemple

• Un événement est envoyé avec l'eventTime = Lundi 21h00.

Les événements qui ont une valeur négative de revenus peuvent être envoyés. Par exemple, dans le cas où un achat a été annulé. Le paramètre af_revenue peut avoir des valeurs négatives pour permettre l'enregistrement.

Lorsque vous remplissez af_quantity, vous pouvez avoir besoin de renseigner une valeur négative en fonction du fonctionnement de votre système. AppsFlyer n'utilise pas af_quantity.

• Point de terminaison : vérifiez que le point de terminaison est utilisé proprement.
• Vérifiez que la charge utile contient bien les paramètres obligatoires. Plus d'infos ici.
• Vérifiez que l'ID AppsFlyer que vous utilisez pour amorcer l'événement est un véritable appsflyer_id, et qu'il est bien installé sur l'app concernée. Veuillez à ne pas utiliser un ID factice comme on peut en trouver dans les exemples. Plus d'infos ici.
• Les événements S2S ne prennent pas en charge l'envoi d'événements multiples sur une seule requête S2S. Chaque événement doit obligatoirement être envoyé séparément.
  • Les événements peuvent être envoyés en désynchronisé pour réduire le temps de réponse.
• Dans le tableau de bord général, la plage de dates se rapporte au jour d'installation de l'app (LTV), et non au jour de l'événement.
  • Veillez à sélectionner la bonne période.
  • Assurez-vous que la plage de dates du tableau de bord correspond bien à la date d'installation de l'appareil (appsflyer_id), et non à la date de l'événement.
• Rapports de données brutes d'événements : la plage de dates se rapporte au jour de l'événement et non au jour d'installation.

Si vous envoyez des événements S2S dont les revenus ne sont pas enregistrés : veillez à ce que le JSON que vous envoyez soit converti en chaîne. La section la plus importante est celle du paramètre de valeur d'événement dans le JSON. Elle doit être convertie en chaîne comme stipulé dans l'exemple suivant.

"{\"af_revenue\":\"6\" ,\"af_content_type\":\"wallets\"}"

Dans le cas contraire, la valeur de l'événement ne sera pas traitée correctement et ne pourra pas être enregistrée.

Les valeurs de revenus ne doivent en aucun cas être formatées. Elles peuvent contenir une virgule décimale. N'y ajoutez aucun caractère, code de devise, séparateur ou , (virgule). Les revenus peuvent être précédés d'un - (tiret du milieu)

• Exemples de valeurs valides : 123, -123.45, 123.456 
• Exemples de valeurs invalides : 1,234.56, 1,234

Les champs de données brutes sont renseignés à l'aide de la valeur transmise dans l'appel S2S, tandis que d'autres champs sont remplis à l'aide de l'événement d'installation.  On observe la même chose, à quelques exceptions près, pour les événements in-app signalés à l'aide du SDK AppsFlyer. Il existe quelques différences entre les deux, notamment, les champs suivants ne sont pas renseignés pour les événements S2S :

• wifi
• operator
• langue
• Modèle d'appareil
• Catégorie d'appareil
• Version de l'app : vous pouvez utiliser app_version_name
• Nom de l'app
• Agent utilisateur