以下是建議的工作流程，可驗證事件和目標對象上傳資料的狀態，並找出資料問題。
- 發出要求來傳送活動，或是傳送/移除目標對象成員。
- 從每個
IngestEventsResponse、IngestAudienceMembersResponse或RemoveAudienceMembersResponse擷取request_id。 - 為每個
request_id傳送RetrieveRequestStatus要求。 - 請檢查每個
RetrieveRequestStatusResponse，確認上傳作業正常運作，並找出資料問題。 - 修正資料問題。
- 返回步驟 1 並重複操作，直到解決所有上傳問題為止。
建構要求
RetrieveRequestStatusRequest 具有單一 request_id 欄位。針對您在傳送擷取要求時擷取的每個要求 ID，傳送一項要求。
查看回覆
RetrieveRequestStatusResponse 中的 request_status_per_destination 包含對應擷取要求中每個目的地的個別項目。
舉例來說，如果 IngestAudienceMembersRequest 的 destinations 清單包含 3 個項目，可將資料傳送至 3 個不同的目標對象，則狀態回應的 request_status_per_destination 會包含 3 個項目 (每個目標對象各 1 個項目)。
查看整體目的地狀態
首先，請檢查 request_status 欄位，判斷 Data Manager API 是否已完成 RequestStatusPerDestination 的 destination 資料處理作業。request_status 可能的值如下：
PROCESSING：系統仍在處理目的地資料。SUCCESS：目的地要求處理作業已完成，未發生任何錯誤。FAILURE：目的地所有記錄都因錯誤而失敗。PARTIAL_SUCCESS：部分目的地記錄成功，但其他記錄因發生錯誤而失敗。
依目的地查看事件或目標對象狀態
檢查與擷取要求類型對應的狀態欄位。每個 RequestStatusPerDestination 只能設定下列其中一個欄位：
事件擷取狀態
如果要求是 IngestEventsRequest，系統就會填入 events_ingestion_status 欄位。
檢查 IngestEventStatus 的 record_count，確認收到的記錄總數符合預期。record_count包含成功和失敗的記錄。
目標對象成員擷取狀態
如果要求是 IngestAudienceMembersRequest，系統會填入 audience_members_ingestion_status 欄位。以下是每種目標對象資料的IngestAudienceMembersStatus 欄位，可供您檢查。這些欄位只會設定一個。
user_data_ingestion_status檢查
IngestUserDataStatus的record_count，確認收到的記錄總數符合預期。record_count包含成功和失敗的記錄。檢查
user_identifier_count，確認收到的使用者 ID 數量符合預期。如果要求包含足夠的記錄，
upload_match_rate_range會包含要求中記錄的比對率範圍。mobile_data_ingestion_status檢查
IngestMobileDataStatus的record_count，確認收到的記錄總數符合預期。record_count包含成功和失敗的記錄。檢查
mobile_id_count，確認收到的行動 ID 數量符合預期。pair_data_ingestion_status檢查
IngestPairDataStatus的record_count，確認收到的記錄總數符合預期。record_count包含成功和失敗的記錄。檢查
pair_id_count，確認收到的 PAIR ID 數量符合預期。
移除目標對象成員的狀態
如果要求是RemoveAudienceMembersRequest，系統就會填入 audience_members_removal_status 欄位。以下列出各類目標對象資料的 RemoveAudienceMembersStatus 欄位，供您檢查。這些欄位只會設定一個。
user_data_removal_status- 使用者資料的移除狀態。
mobile_data_removal_status- 「行動數據」的移除狀態。
pair_data_removal_status- PAIR 資料的移除狀態。
查看 record_count，確認收到的記錄總數符合預期。record_count包含成功和失敗的記錄。
此外，請查看 user_identifier_count、mobile_id_count 或 pair_id_count，確認收到的使用者 ID、行動 ID 或 PAIR ID 總數。
檢查警告和錯誤
除了目的地和要求類型的狀態欄位外，RetrieveRequestStatusResponse 還包含要求的警告和錯誤明細。
- 如果出現錯誤，表示 API 完全拒絕記錄。
- 警告表示 API 並未拒絕記錄，但必須忽略記錄的部分資料。
舉例來說，如果 Event 包含加密的 UserIdentifier 資料和 AdIdentifiers (例如 gclid)，且 UserIdentifier 資料無法解密，Data Manager API 仍會使用 AdIdentifiers 處理記錄，但會傳回警告 PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR。
不過，如果 Event 不含 AdIdentifiers，且 UserIdentifier 資料無法解密，Data Manager API 會拒絕整個記錄並回報 PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR 錯誤，因為有效的 Event 必須至少包含 ad_identifiers 或 user_data。
以下是包含警告和錯誤資訊的回覆欄位。
warning_infoWarningCount物件的清單。每個WarningCount都包含reason(警告類型) 和record_count(指出該類型警告的記錄數)。error_infoErrorCount物件的清單。每個ErrorCount都包含錯誤類型reason，以及指出因該類型錯誤而失敗的記錄數量的record_count。