Événements d'annulation

Aperçu

Les API d'événements vous transmettront les événements de transaction en temps quasi réel. Dès que nous recevons un enregistrement de conversion réussie de la part de l'annonceur, nous transmettons les données dans le postback. La même procédure s'applique aux annulations. Lorsqu'un client retourne ou annule un achat, l'annonceur nous envoie un enregistrement de cette annulation, que nous envoyons également dans le postback. Le même ensemble de données est transmis pour les annulations, mais avec certaines valeurs modifiées pour indiquer que l'événement est une annulation.

Ce sont les données qui sont susceptibles d’être modifiées dans les postbacks d'annulation. Cliquez sur le signe + pour voir les modifications éventuelles :

<transaction_date>
Modifications : N/A
<sku_number>
Modifications : N/A
<quantity>
Modifications : modifié uniquement si des articles sélectionnés sont annulés dans une transaction qui contenait à l'origine plusieurs instances du même produit. Exemple : si deux jupes identiques ont été achetées lors de l'événement d'origine, la quantité est de deux. Si une seule des jupes est renvoyée par le client, la quantité d'annulation est alors d'une.
<etransaction_id>
Modifications : sera nouveau et unique pour l'enregistrement de l'annulation, c'est-à-dire qu'il ne correspondra pas au numéro d'identification de l'événement d'origine (identifiant_etransaction).
<transaction_type>
Modifications : dépend du type de suivi et de la méthode d'annulation de l'annonceur.
<product_name>
Modifications : N/A
<offer_id>
Modifications : N/A
<advertiser_id>
Modifications : N/A
<sid>
Modifications : N/A
<is_event>
Modifications : N/A (les événements d'annulation seront toujours N)
<commissions>
Changements : la commission sera négative (inverse de l'événement d'origine).
<process_date>
Modifications :Cette date indique la date à laquelle nous avons reçu la demande d'annulation. Format de décodage de l'horodatage :
YYYY-MM-DDTHH:mm:ss.SSS[+|-]Z
<currency>
Modifications : N/A
<u1>
Modifications : N/A
<order_id>
Modifications : N/A
<sale_amount>
Modifications : le montant des ventes sera négatif (inverse de l'événement d'origine).

Nous vous recommandons fortement d'inclure au moins le paramètre de Ventes et/ou Commissions lorsque vous demandez un postback personnalisé. Sans le montant négatif des ventes ou des commissions, il est pratiquement impossible de distinguer les événements d'annulation des nouveaux événements de conversion.

Événements d'optimisation des médias et annonceurs de suivi par lots

Pour les annonceurs qui utilisent le suivi par lots, il faut s'attendre à un temps de latence entre le moment où un enregistrement de conversion arrive dans notre système et le moment où le client a effectivement effectué l'achat. Cette situation est particulièrement fréquente pour les annonceurs de réservations et de voyages, les détaillants qui proposent des précommandes, ainsi que les annonceurs qui ne signalent les conversions qu'au moment de l'expédition d'un achat.

Ces annonceurs utilisent le « Media Optimization Pixel » (MOP, qui capture l'achat en temps réel en tant qu'événement préliminaire) afin de disposer d'un premier enregistrement de la conversion ultérieure. Ces événements MOP seront indiqués comme « is_event=Y » dans le postback. En d'autres termes, veuillez considérer tous les enregistrements Y comme préliminaires.

Lorsque la conversion est ensuite finalisée, le postback est à nouveau déclenché avec « is_event=N ». S'il s'agit d'un retour partiel, le montant des ventes ne fera apparaître que le prix de l'article retourné et non le montant total au point de vente. Tous les autres points de données seront identiques, à l'exception de « etransaction_id » et « process_date ».

Veuillez noter que, pour le tracking pixel en temps réel, les annonceurs avec un événement Y seront déclenchés et suivis presque immédiatement par un événement N correspondant. Veuillez considérer les événements N comme finalisés.

Comme pour les annulations, nous vous recommandons d'inclure l'indicateur « is_event » lorsque vous demandez un postback personnalisé. L'exclusion de ce drapeau rendra pratiquement impossible la distinction entre les événements préliminaires et les événements finalisés.

Pour plus d'informations sur ce sujet, voir Aperçu des API d'événements et Questions fréquentes sur les API d'événements.

Cet article vous a-t-il été utile ?
Utilisateurs qui ont trouvé cela utile : 0 sur 0

Commentaires

0 commentaire

Vous devez vous connecter pour laisser un commentaire.