概覽
事件 API 將近乎實時地將交易事件傳遞給您。一旦我們收到廣告主的成功轉換記錄，我們就會在回傳中傳遞數據。相同的工作流程適用於取消。當客戶退貨或取消購買時，廣告主會向我們發送此次取消的記錄，我們也會在回傳中觸發該取消。相同數據組會被傳遞以進行取消，僅更改某些值以指示該事件為取消。
這是您可以預期在取消回傳中看到變更的數據。單擊 + 號以查看更改（如果有）：
<transaction_date>
更改：不適用
<sku_number>
更改：不適用
<quantity>
更改：僅當在最初包含同一商品的多個實例的交易中取消選擇物品時才會更改。示例：如果在原始事件中購買了兩條相同的裙子，那麼數量就是兩條。如果客戶只退回其中一條裙子，則取消數量為一件。
<etransaction_id>
更改：對於取消記錄將是新的和唯一的，即與原始事件 etransaction_id 不匹配。
<transaction_type>
更改：取決於廣告主的追蹤類型和取消方法。
<product_name>
更改：不適用
<offer_id>
更改：不適用
<advertiser_id>
更改：不適用
<sid>
更改：不適用
<is_event>
更改：不適用（取消事件將始終為 N）
<佣金>
更改：佣金將為負數（與原始事件相反）。
<process_date>
更改：該日期將指示我們收到取消記錄的時間。時間戳解碼格式：
YYYY-MM-DDTHH:mm:ss.SSS[+|-]Z
<currency>
更改：不適用
<u1>
更改：不適用
<order_id>
更改：不適用
<sale_amount>
更改：銷售額將為負數（與原始事件相反）。
我們強烈建議您在請求自訂回傳時至少包含銷售額和/或佣金參數。如果沒有負銷售額或佣金金額，幾乎不可能區分取消事件和新轉換事件。
媒體優化事件和批量追蹤的廣告主
對於使用批量追蹤的廣告主，在轉換記錄到達我們的系統和客戶實際進行購買之間預計會有延遲。這對於預訂和旅遊廣告主、提供預購的零售商以及僅在購買發貨時報告轉換的廣告主來說尤其常見。
這些廣告主採用「媒體優化像素」（MOP，可捕捉實時購買作為初步事件）以便對後續轉換進行初始記錄。這些 MOP 事件將在回傳中指示為「is_event=Y」。換句話說，請將所有 Y 記錄視為初步記錄。
當轉換隨後完成時，回傳將再次以「is_event=N」觸發。如果是部分退貨，銷售額將僅反映已退貨商品的價格，而不是在銷售點所列出的全部金額。除了「etransaction_id」和「process_date」之外，所有其他數據點都是相同的。
請注意，對於實時像素追蹤，具有 Y 事件的廣告主將被觸發，並且幾乎立即緊隨其後的是相應的 N 事件。請將 N 個事件視為已完成。
與取消一樣，我們建議在請求自訂回傳時包含「is_event」標誌。排除這個標識將使它幾乎不可能區分初步事件和最終事件。
評論
請登入寫評論。