Cancellation Events

  1. New Publisher Help Center (beta)
  2. Technical Documents and Guidelines
  3. Developer Portal APIs

Articles in this section

See more

Cancellation Events

Avatar
Brian - Technical Writer
Last edited:

Overview

The Events API will pass transaction events to you in near real-time. As soon as we receive a record of successful conversion from the advertiser, we pass the data in the postback. The same workflow applies to cancellations. When a customer returns or cancels a purchase, the advertiser will send us a record of this cancellation, which we also fire in the postback. The same data set is passed for cancellations, only with some values changed to indicate that the event is a cancellation.

This is the data you can expect to see changed in cancellation postbacks. Click the + sign to see the changes, if any:

<transaction_date>
Changes: N/A
<sku_number>
Changes: N/A
<quantity>
Changes: Changed only if select items are cancelled in a transaction that originally contained multiple instances of the same product. Example: if two of the same skirt were purchased in the original event, then the quantity would have been two. If only one of the skirts is returned by the customer, then the cancellation quantity would be one.
<etransaction_id>
Changes: Will be new and unique to the cancellation record, i.e. will not match the original event etransaction_id.
<transaction_type>
Changes: Dependant on the advertiser's tracking type and cancellation method.
<product_name>
Changes: N/A
<offer_id>
Changes: N/A
<advertiser_id>
Changes: N/A
<sid>
Changes: N/A
<is_event>
Changes: N/A (cancellation events will always be N)
<commissions>
Changes: The commission will be negative (inverse of the original event).
<process_date>
Changes: This date will indicate when the cancellation record was received by us. Timestamp decoded format: 
YYYY-MM-DDTHH:mm:ss.SSS[+|-]Z
<currency>
Changes: N/A
<u1>
Changes: N/A
<order_id>
Changes: N/A
<sale_amount>
Changes: Sales amount will be negative (inverse of the original event).

We highly recommend that you include at least the Sales and/or Commissions parameter when requesting a custom postback. Without the negative sales or commissions amount, it is virtually impossible to distinguish cancellation events from new conversion events.

Media Optimization Events and Batch-Tracking Advertisers

For advertisers utilizing batch-tracking, latency can be expected between when a conversion record hits our system and when the customer actually made the purchase. This is especially common for booking and travel advertisers, retailers who offer pre-orders, as well as advertisers who only report conversions when a purchase ships.

These advertisers employ the "Media Optimization Pixel" (MOP, which captures the real-time purchase as a preliminary event) so as to have an initial record of the subsequent conversion. These MOP events will be indicated as "is_event=Y" in the postback. In other words, please treat all Y records as preliminary.

When the conversion is subsequently finalized, then the postback will fire again with "is_event=N". If it's a partial return, the sales amount will only reflect the price of the returned item and not the full amount at the point of sale. All other data points will be the same, except for "etransaction_id" and "process_date".

Please note that, for real-time pixel tracking, advertisers with a Y event will be fired and followed almost immediately by a corresponding N event. Please treat the N events as finalized.

As with cancellations, we recommend including the "is_event" flag when requesting a custom postback. Excluding this flag will make it virtually impossible to distinguish preliminary events from finalized events.

For more information on this topic, see Events API Overview and Events API Common Questions.

Was this article helpful?
0 out of 0 found this helpful

Related articles

Comments

0 comments

Please sign in to leave a comment.