API d'événements de serveur à serveur

Introduction

Cette API vous permet d'envoyer les évènements qui se produisent en dehors de l’application ou dans l'application, mais ne sont pas envoyés via le SDK d'AppsFlyer. Par exemple, si vous avez à la fois une interface web et une interface mobile, vous pouvez enregistrer tous les évènements provenant de ces deux médias dans AppsFlyer.

 Remarque

Le Type de contenu doit être défini comme application/json.

URL :https://api2.appsflyer.com/inappevent/{app_id}

Exemple Android :https://api2.appsflyer.com/inappevent/com.appsflyer.myapp

Example iOS : https://api2.appsflyer.com/inappevent/id123456789

Il est important de vérifier que l’ID App sur iOS contient l'« id » principal avant l’ID ; dans le cas contraire, la demande se termine par HTTPS 200 OK, mais l’événement n’est pas enregistré.

 Important !

La taille maximale de la charge utile JSON ne doit pas dépasser 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.

Assurez-vous que la charge utile JSON inclut le paramètre "af_events_api" :"true"
Ce paramètre garantit que l'événement est structuré comme un événement riche pour permettre le mappage automatique des valeurs d'événement sur différents partenaires.

Consultez les exemples ci-dessous.

Méthode : POST

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

La DevKey se trouve dans Tableau de bord >> Paramètres d'application  >> DevKey

iOSAndroid
{
  "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

  1. Paramètres obligatoires : appsflyer_id (ID d' appareil AppsFlyer), eventName, eventValue et af_events_api
  2. Paramètres fortement recommandés :idfa pour iOS et advertising_id pour Android.
    Si vous souhaitez mapper vos évènements in-app d'utilisateurs organiques avec des partenaires externes, ces paramètres sont OBLIGATOIRES. En outre, certaines fonctions telles qu'Audiences s'appuient sur l'ID d'appareil pour segmenter vos utilisateurs et mettre à jour les réseaux.
  3. Optionnel - eventValue peut être avec une valeur vide, par exemple, "eventValue":"", (aucun espace n’est nécessaire)
  4. Optionnel - L'adresse IP (ip) doit être l’adresse IP de l'appareil mobile (pendant l’occurrence de l’événement)
  5. Optionnel - Le champ d’ID utilisateur client (customer_user_id) est un paramètre d’identifiant utilisateur, mappé avec le champ ID utilisateur-client dans les rapports de données. L'API SDK de l'ID utilisateur-client associe automatiquement cette valeur à tous les événements in-app provenant du SDK. Veillez à inclure ce champ avec TOUS vos événements S2S pour profiter de la même fonctionnalité.

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 d'AppsFlyer sous l'heure réelle à laquelle l’événement s’est produit (2 mai @ 22h00).

É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é sur la plateforme d'AppsFlyer à l’heure à laquelle il a été envoyé au serveur AppsFlyer et non à l'heure à laquelle l’événement s’est produit (4 mai @ 09h00).

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

Il existe plusieurs façons d’obtenir cet ID.

  1. À partir de l’appareil mobile en utilisant l'API SDK d'AppsFlyer (Android / iOS)
  2. Via l'API Pull ou Push (cliquez sur le lien pour plus d’informations sur l’ API Push ou l' API Pull)
  3. Exportez le rapport d'installation Raw Data

 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 ?
Utilisateurs qui ont trouvé cela utile : 4 sur 12