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

• Les paramètres de charge utile sont constitués d'un ou plusieurs identifiants d'appareil (selon le système d'exploitation).
• Que se passe-t-il si je ne parviens pas à envoyer l'identifiant d'un appareil?
  • Vous pouvez être dans l'impossibilité d'envoyer l'identifiant pour une raison qui ne vous appartient pas, par exemple l'utilisateur a activé le suivi limité des publicités (LAT) ou bien il utilise iOS 14 et a refusé l'ATT (pas d'IDFA).
  • Si cela se produit, sachez que si l'envoi d'un ID publicitaire/d'appareil ne se fait pas, l'attribution peut échouer,ce qui signifie qu'AppsFlyer ne pourra pas attribuer l'événement à la source média. Les évènements sont enregistrés et s'affichent bien dans les rapports et les tableaux de bord.

curl --location --request POST 'https://api2.appsflyer.com/inappevent/<app_id_placeholder>' \
--header 'authentication: <dev_key_placeholder>
' \
--header 'Content-Type: application/json' \
--data-raw '{
  "appsflyer_id": "9999999999999-9999999999999999999",
	"advertising_id": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
	"customer_user_id" : "example_customer_id_123",
	"ip": "199.0.2.1",
	"app_version_name" : "example_version_name",
	"eventTime" : "2020-02-25 12:00.000",
	"eventName": "af_purchase",
	"eventCurrency": "ZAR",
	"eventValue": 
	"{
		\"af_revenue\": \"1006\",
		\"af_content_type\": \"wallets\",
		\"af_content_id\": \"15854\",
		\"af_quantity\" :\"1\"
   }"
}
'

Important :

• Pour le test, utilisez l'ID AppsFlyer d'une installation non organique afin que les attributs de l'événement testé soient pris en temps réel. Les événements organiques sont attribués avec un décalage de quelques heures.
• Certains champs d'un événement sont remplis en utilisant l'événement d'attribution d'installation de l'utilisateur. Par exemple, l'heure d'installation et la source média.

Pour attribuer l'appareil de test comme installation non organique :

1. Préparez un lien d'attribution personnalisé pour tester les messages S2S. Définissez le paramètre de source média du lien sur s2s_test. Exemple : &pid=s2s_test 
2. Enregistrer l'appareil de test
3. Désinstallez l'app de l'appareil de test.
4. Envoyez le lien vers l'appareil de test.
5. Cliquez sur le lien.
6. Installez l'application puis lancez-la.
7. Dans le tableau de bord, vérifiez que l'installation est bien attribuée.
8. Extrayez l'ID d'appareil AppsFlyer qui sera utilisé pour vos messages S2S.

Pour envoyer le message de test S2S :

1. Préparez un message S2S avec l'ID AppsFlyer alloué. Consultez les exemples de code ci-dessous.
2. Envoyez le message.
3. Réalisez l'une des opérations suivantes pour voir comment le message est enregistré dans AppsFlyer :
   • Téléchargez le rapport de données brutes des événements in-app. Prévoyez jusqu'à 15 minutes après l'envoi d'un événement pour qu'il s'affiche dans le rapport de données brutes.
   • Lancez l'API Push (pensez également aux outils du genre Postman ou Webhook site.)
4. Vérifiez que :
   • Les valeurs envoyées dans le message S2S apparaissent bien dans le rapport. Portez une attention particulière aux champs Date de l'événement, Devise de l'événement, Revenus de l'événement et Valeur de l'événement.
   • Les sources d'attribution et les heures d'installation sont renseignées par AppsFlyer.
   • Les valeurs fournies par le SDK lui-même, comme la version SDK, ne sont pas complétées.

• L'ID de publicité / l'identifiant d'appareil est obligatoire pour garantir les postbacks envoyés aux SRN comme Facebook et Google Ads. Si vous ne pouvez pas envoyer l'ID, sachez que les postbacks ne pourront pas être envoyés.
• Si vous n'envoyez que l'identifiant AppsFlyer, les événements in-app seront enregistrés et attribués correctement.

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 avec l'ID AppsFlyer, vous devez définir le CUID au sein de 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": "1415211453000-6513894",
	"advertising_id": "38412345-8cf0-aa78-b23e-10b96e40000d",
	"eventName": "af_purchase",
	"eventValue": 
	"{
		\"af_revenue\": \"6\",
		\"af_content_type\": \"wallets\",
		\"af_content_id\": \"15854\",
		\"af_quantity\" :\"1\"
   }",
	"eventCurrency": "USD",
	"ip": "1.2.3.4",
	"eventTime": "2014-05-15 12:17:00.000"
}

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 l'appareil mobile en appelant l'API SDK AppsFlyer : Android, iOS
• Depuis la plate-forme AppsFlyer à l'aide de l'un des éléments suivants : API Pull, API Push, Exportation installation des données brutes.

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.

Exemple contenant des revenus négatifs

{
	"eventName": "cancel_purchase",
	"eventValue": 
	"{
		\"af_revenue\": \"-6\",
		\"af_content_type\": \"wallets\",
		\"af_content_id\": \"15854\",
		\"af_quantity\" :\"1\"
   }",
	"eventCurrency": "USD",
	
}

Si vous souhaitez envoyer des événements sans valeur d'événement, transmettez simplement une chaîne vide à la valeur d'événement : "event_value": ""

AppsFlyer est alors en mesure, selon la configuration de l’annonceur, d’envoyer de tels événements rich in-app aux sources médias aux fins de ciblage avancé, d'optimisation et de création de public.

• 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é un par un. 
• 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 absolument pas être formatées. Elles peuvent contenir une virgule, mais ce n'est pas obligatoire. N'y ajoutez aucun signe, code de devise ou séparateur. Les revenus peuvent être précédés d'un -

• 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
• Type d'appareil
• Catégorie d'appareil
• Version de l'app : vous pouvez utiliser app_version_name
• Nom de l'app