API d'événements de serveur à serveur pour mobile (S2S mobile)

En bref : envoyez les événements de vos serveurs à AppsFlyer pour mesurer les événements mobiles qui se produisent en dehors de l'app.

S2S_us-en.png

API pour mobile d'événements de serveur à serveur

Pour les apps iOS, à partir d'iOS 14 vous devez envoyer le paramètre de système d'exploitation (OS). 

La plateforme AppsFlyer attribue et enregistre les événements d'apps mobile qui sont envoyés par le SDK AppsFlyer et par les API. Utilisez l'API S2S pour signaler les événements qui ont lieu hors de l'app, par exemple pour un utilisateur qui renouvellerait son abonnement en utilisant votre interface web. Une fois enregistrés, les événements S2S sont disponibles sur toute la plateforme, y compris les tableaux de bord, les données brutes et les analyses. Pour les événements web de PBA, consultez Le S2S mobile pour la PBA.

AppsFlyer remplit les événements S2S en se basant sur :

  • Les valeurs envoyées dans le message S2S
  • Certaines AppsFlyer valeurs d'attribution d'installation AppsFlyer, comme l'heure ou la source du média.

Pour envoyer des événements via l'API, dites à votre développeur de suivre les instructions sur l'API pour les événements de serveur à serveur.

Paramètres de remplissage

Différence entre organique et non organique

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.

 Exemple

Par exemple, si vous comparez les rapports de données brutes d'événements in-app S2S non organiques et organiques, les événements non organiques contiennent des données que les événements in-app organiques ne contiennent pas.

Les événements in-app non organiques incluent les données concernant la source média, la campagne, le type de touch attribué et l'heure du touch attribué.

Les événements in-app organiques quant à eux suivent une installation organique. Les installations organiques ne disposent pas de données relatives à la campagne ou source média, ni au type ou à l'heure de touch attribué.

Mappage de l'ID AppsFlyer avec l'ID utilisateur du client (CUID)

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.

Récupérer l'ID AppsFlyer

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 :

 Astuce

Lorsque vous testez les messages S2S, si vous utilisez des données brutes recherchez l'enregistrement dont la source média est signalée par « s2s_test ». Il s’agit de votre appareil de test et son ID d'appareil AppsFlyer est l’identifiant dont vous avez besoin.

Horodatage des Événements S2S

diagramme de logique d'horodatage

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.
  • Les événements dont la valeur eventTime n'est pas valide sont marqués par l'heure d'arrivée du message HTTP.

Exemple

  • Un événement est envoyé avec l'eventTime = Lundi 21h00.
Arrivée sur AppsFlyer Horodatage AppsFlyer Remarque
Mardi 01h00 Lundi 21h00 Arrivée avant l'heure de fermeture. L'heure est fixée d'après la valeur eventTime.
Mercredi 09h00 Mercredi 09h00 Arrivée après l'heure de fermeture. L'heure est définie sur l'heure d'arrivée. 

Envoi de revenus négatifs

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.

Dépannage

Les événements ne s'affichent pas dans le tableau de bord

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

Les événements ne contiennent pas de revenu

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.45123.456 
  • Exemples de valeurs invalides : 1,234.561,234

Dans les événements S2S, tous les champs ne sont pas remplis

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