API d'événements de serveur à serveur

L'API d'événements de serveur à serveur permet d'envoyer des événements qui ne sont pas envoyés à l'aide du SDK AppsFlyer. Par exemple, si vous avez à la fois une interface web et une interface mobile, dans AppsFlyer vous pouvez enregistrer les événements issus de ces deux interfaces à l'aide de l'API d'événements de serveur à serveur. 

Les événements de serveur à serveur doivent être préparés comme indiqué ci-dessous :

  • Type de contenu : défini comme application / json.
  • Point de terminaison d'URL :
    https://api2.appsflyer.com/inappevent/{app_id}
    • Exemple Android :
      https://api2.appsflyer.com/inappevent/com.appsflyer.myapp
    • Exemple iOS :
      https://api2.appsflyer.com/inappevent/id123456789
      Remarque : l'ID app est l'ID iTunes de l'application. Assurez-vous que l'ID app sous iOS contient un id d'appel avant l'ID. Si ça n'est pas le cas, le code retour 200 OK est bien valide, mais l'événement n'est pas enregistré.
    • Exemple Windows :
      https://api2.appsflyer.com/inappevent/a1b2c3d4e5f6
      Remarque : l'ID app est l'ID de l'application dans l'app store Microsoft.
  • Taille maximale de la charge utile JSON : 1K
  • La charge utile JSON doit être transmise sous forme de chaîne et la valeur de l'événement doit être convertie en chaîne.
  • La charge utile JSON doit inclure le paramètre : "af_events_api" : "true"
    Ce paramètre garantit que l'événement est structuré comme un événement riche, et ce afin de permettre le mappage automatique des valeurs d'événement vers différents partenaires.

Voir les exemples ci-dessous.

Méthode : POST

En-tête - "authentication"= {dev-key}

La clé dev se trouve dans Tableau de bord > Paramètres d'app > Clé dev

iOSAndroid et Windows
{
  "appsflyer_id": {AppsFlyer Device ID }, // e.g. 1415211453000-6513894
  "idfa":{idfa},
  "customer_user_id": {customer_user_id}, // Customer User ID optional parameter
  "eventName": {The event name}, // e.g. "af_purchase"
  "eventValue": {A JSON containing a rich in-app event value - must be stringfied},
  "{

    \"af_revenue\":\"6\",
    \"af_content_type\":\"wallets\",
    \"af_content_id\":\"15854\"

  }",
  "eventCurrency": {Event currency}, // e.g "USD"
  "ip": {device IP},
  "eventTime": {Event timestamp in UTC +0}, // e.g "2014-05-15 12:17:00.000"
  "af_events_api" :"true"
}

 Remarque

Tous les caractères réservés (https://tools.ietf.org/html/rfc3986#section-2.1) doivent être encodés en pourcentage avant la formation de l’URI.

Paramètres

Nom du paramètre Type Description
appsflyer_id Obligatoire Attribue l'événement à une source média et à une campagne.
eventName Obligatoire Indique le nom de l'événement.
Valeur de l'événement Recommandé Exception : le paramètre est obligatoire pour calculer le revenu.
af_events_api Obligatoire La valeur doit être "true".
idfa Recommandé Exception : le paramètre est obligatoire pour envoyer des postbacks d'événements in-app à des partenaires externes.

advertising_id

Recommandé

Exception : le paramètre est obligatoire pour envoyer des postbacks d'événements in-app à des partenaires externes.

ip Recommandé
  • L'adresse IP (ip) est l'adresse IP de l'appareil mobile (lors d'une occurrence d'événement).
  • L'adresse IP détermine le pays de l'événement. Si aucune adresse IP n'est spécifiée, le champ du pays indique N/A dans les données brutes.
customer_user_id OPTIONNELLE L'ID utilisateur du client est utilisé pour associer les événements in-app aux utilisateurs dans les systèmes BI.

 

Préparation des données pour les paramètres

Une approche d'arrière-plan est nécessaire afin d'obtenir certaines valeurs correspondant aux paramètres précédemment mentionnés. Vous trouverez ci-dessous la procédure conseillée permettant d'obtenir ces valeurs :

Mappage de l'ID AppsFlyer avec l'ID utilisateur du client

L'ID AppsFlyer est un paramètre obligatoire lors de l'envoi des évènements in-app serveur à serveur. Pour connaître plus facilement l'utilisateur à l'origine de chaque évènement, procédez comme suit :

  1. Définissez l'ID utilisateur du client lorsque l'utilisateur installe l'app.
  2. Téléchargez le rapport de données brutes pour les installations via Exporter des données ou l'API Pull
  3. Obtenez l'ID AppsFlyer en comparant l'ID utilisateur du client figurant dans vos systèmes internes à l'ID utilisateur du client du rapport de données brutes.
    Remarque : vous pouvez obtenir l'ID AppsFlyer de vos utilisateurs depuis le SDK AppsFlyer intégré à vos applications (Android/iOS).
  4. Mappez l'ID AppsFlyer à l'ID utilisateur du client de votre système interne (important pour les utilisations ultérieures)

Après avoir mappé l'ID AppsFlyer à votre ID utilisateur du client interne, vous pouvez déterminer facilement l'utilisateur à l'origine de chaque évènement. Vous pouvez ensuite obtenir l'ID AppsFlyer et d'autres valeurs (valeurs d'évènement, devise d'évènement, heure d'évènement, etc.), puis envoyer l'évènement in-app serveur à serveur.

Synchronisation des événements

Les évènements de serveur à serveur peuvent être envoyés en temps réel ou avec un horodatage d'évènement.

Vous pouvez utiliser le paramètre eventTime facultatif pour spécifier l’heure d’occurrence de l’événement (fuseau horaire UTC +0). Si le paramètre n’est pas inclus dans le message, AppsFlyer utilise l’horodatage du message HTTPS reçu. 

eventTime utilise le format suivant : « aaaa-MM-jj HH:mm:ss.SSS » (par exemple "2014-05-15 12:17:00.000")

Lorsque vous envoyez des évènements avec des horodatages, ceux-ci doivent tous être envoyés à AppsFlyer avant 02h00 (UTC +0) le jour suivant pour que ces évènements soient enregistrés avec leur horodatage réel (lorsqu'ils ont lieu).


Les événements avec des horodatages passés, qui n'ont pas été envoyés avant 2h00, sont enregistrés à l'heure à laquelle ils ont été envoyés.

Évènement avec horodatage envoyé avant 02h00 UTC +0

Déclenchement de l'événement : 2 mai @ 22h00

Envoi de l'événement aux serveurs d'AppsFlyer : 3 mai @ 01h00

L'événement est enregistré dans la plate-forme à l'heure à laquelle l’événement s’est réellement produit (2 mai @ 22:00).

Évènement avec horodatage envoyé après 02h00 UTC +0

Déclenchement de l'événement : 2 mai @ 22h00

Envoi de l'événement aux serveurs d'AppsFlyer : 4 mai @ 09h00

L'événement est enregistré dans la plateforme à l’heure à laquelle il a été envoyé au serveur AppsFlyer, et non à l'heure à laquelle l’événement s’est produit (4 mai @ 09:00).

Évènement avec horodatage futur

Les évènements envoyés avec un horodatage futur sont toujours enregistrés dans AppsFlyer à l'heure où ils sont envoyés à AppsFlyer, et non selon l'horodatage de l'évènement dans la charge utile.

Évènements chronologiques : chronologie visuelle

Server-to-Server-Events.PNG

 Remarque

Le nombre maximal de requêtes S2S est 60K par minute ou 1K par seconde. Contactez votre responsable de réussite client si vos exigences sont différentes.

Codes de retour de service

200
OK lorsque la demande a été traitée par le système Appsflyer.
401
non autorisé lorsque la clé indiquée dans l’en-tête d’authentification n’est pas la DevKey pour cette application.
400
Demande incorrecte lorsqu'au moins un des critères de validation a échoué pour la demande
500
Erreur interne du serveur indique une erreur de serveur

Si vos serveurs sont protégés par un pare-feu, vous devrez mettre sur liste blanche les réponses entrantes provenant des plages d’adresse IP AWS pour recevoir les messages de retour.

Exemple du corps de la demande

{
  "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",
	"af_events_api" :"true"
}


Dans ce cas, AppsFlyer reçoit un événement in-app S2S qui représente un événement d'achat avec revenu, ainsi que des propriétés supplémentaires telles que le type de contenu, etc.

Cas particuliers

Envoi de revenus négatifs

Si vous souhaitez envoyer un événement avec un revenu négatif (pour des événements tels qu'un achat annulé ou un remboursement), vous pouvez spécifier une valeur négative dans le paramètre de revenu. Par exemple :

{
  "appsflyer_id": "1415211453000-6513894",
	"advertising_id": "38412345-8cf0-aa78-b23e-10b96e40000d",
	"eventName": "cancel_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",
	"af_events_api" :"true"
}

Envoi d'événements sans valeur d'événement

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.

Extraction de l’ID d'appareil 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.  L'ID peut être obtenu comme suit :

 Astuce

Pendant le test des messages S2S, si vous utilisez des Raw Data ou des API Push ou Pull, recherchez l'enregistrement doté de la source média « s2s_test ». Il s’agit de votre appareil de test et son ID d'appareil AppsFlyer est l’ID dont vous avez besoin.

Différence entre organique et non organique

Lorsque vous envoyez des événements in-app S2S, AppsFlyer associe automatiquement des données supplémentaires aux événements. Les données supplémentaires proviennent de l'événement d'installation qui précède 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 contiennent des données sur la source multimédia, la campagne, le type de touch attribué et le temps de touch attribué.

D'autre part, les événements in-app organiques suivent une installation organique. Les installations organiques ne disposent pas de données relatives à la campagne, aux sources média ou au type et au temps de touch attribués. 

Cet article vous a-t-il été utile ?