Chẩn đoán

Định kỳ gửi RetrieveRequestStatusRequest bằng thuật toán thời gian đợi tăng theo cấp luỹ thừa cho đến khi request_status đạt đến SUCCESS, FAILURE hoặc PARTIAL_SUCCESS cho mọi đích trong yêu cầu ban đầu. Quá trình này có thể mất đến 24 giờ, mặc dù Data Manager API có thể hoàn tất quá trình xử lý một số yêu cầu chỉ trong 30 phút.

Dưới đây là ví dụ về thời gian đợi ban đầu hợp lý và cấu hình thử lại giúp cân bằng mức độ hoạt động và mức sử dụng hạn mức:

Dưới đây là trình tự các yêu cầu và thời gian đã trôi qua với cấu hình này:

Thêm một lượng nhỏ biên độ ngẫu nhiên vào độ trễ thời gian đợi để ngăn vấn đề "đàn bò rống" khi nhiều ứng dụng đồng thời thử lại.

Xem lại câu trả lời

The request_status_per_destination trong a RetrieveRequestStatusResponse chứa một mục riêng cho từng đích trong yêu cầu nhập tương ứng.

Ví dụ: nếu IngestAudienceMembersRequest của bạn chứa 3 mục trong danh sách destinations để gửi dữ liệu đến 3 đối tượng khác nhau, thì phản hồi trạng thái sẽ chứa 3 mục trong request_status_per_destination (mỗi mục cho một đối tượng).

Kiểm tra trạng thái tổng thể của đích

Bước đầu tiên là kiểm tra trường request_status để xác định xem API Trình quản lý dữ liệu đã hoàn tất quá trình xử lý dữ liệu cho destination của RequestStatusPerDestination hay chưa.

Sau đây là các giá trị có thể có của request_status:

• PROCESSING: Dữ liệu cho đích vẫn đang được xử lý. Các cảnh báo và lỗi không được điền sẵn cho đích ở giai đoạn này.

• SUCCESS: Quá trình xử lý yêu cầu cho đích đã hoàn tất mà không có lỗi nào. Kiểm tra các cảnh báo được gắn cờ trong quá trình xử lý.

• FAILURE: Tất cả hồ sơ cho đích đều không thành công do lỗi. Kiểm tra các cảnh báo và lỗi để xác định lý do tất cả hồ sơ không thành công. Ngoài ra, hãy kiểm tra các cảnh báo được gắn cờ trong quá trình xử lý.

• PARTIAL_SUCCESS: Một số hồ sơ cho đích đã thành công, nhưng những hồ sơ khác không thành công do lỗi. Kiểm tra các lỗi để xác định lý do một số hồ sơ không thành công. Ngoài ra, hãy kiểm tra các cảnh báo được gắn cờ trong quá trình xử lý.

Kiểm tra trạng thái sự kiện hoặc đối tượng theo đích

Kiểm tra trường trạng thái tương ứng với loại yêu cầu nhập. Chỉ một trong các trường sau được đặt trên mỗi RequestStatusPerDestination:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

Trạng thái nhập sự kiện

Trường events_ingestion_status được điền sẵn nếu yêu cầu là IngestEventsRequest.

Kiểm tra record_count của IngestEventStatus để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Trạng thái nhập thành viên đối tượng

Trường audience_members_ingestion_status được điền sẵn nếu yêu cầu là IngestAudienceMembersRequest. Sau đây là trường IngestAudienceMembersStatus để kiểm tra từng loại dữ liệu đối tượng. Chỉ một trong các trường này được đặt.

user_data_ingestion_status

Kiểm tra record_count của IngestUserDataStatus để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Kiểm tra user_identifier_count để xác nhận rằng số lượng giá trị nhận dạng người dùng nhận được khớp với kỳ vọng của bạn.

Nếu yêu cầu có đủ số lượng hồ sơ, thì upload_match_rate_range sẽ chứa phạm vi tỷ lệ khớp cho các hồ sơ trong yêu cầu.

mobile_data_ingestion_status

Kiểm tra record_count của IngestMobileDataStatus để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Kiểm tra mobile_id_count để xác nhận rằng số lượng mã di động nhận được khớp với kỳ vọng của bạn.

pair_data_ingestion_status

Kiểm tra record_count của IngestPairDataStatus để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Kiểm tra pair_id_count để xác nhận rằng số lượng mã PAIR nhận được khớp với kỳ vọng của bạn.

ppid_data_ingestion_status

Kiểm tra record_count của IngestPpidDataStatus để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Kiểm tra ppid_count để xác nhận rằng số lượng PPID nhận được khớp với kỳ vọng của bạn.

user_id_data_ingestion_status

Kiểm tra record_count của IngestUserIdDataStatus để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Kiểm tra user_id_count để xác nhận rằng số lượng mã người dùng nhận được khớp với kỳ vọng của bạn.

composite_data_ingestion_status

Kiểm tra record_count của IngestCompositeDataStatus để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Kiểm tra data_type_counts để xác nhận rằng số lượng giá trị nhận dạng khớp với kỳ vọng của bạn. Danh sách này cung cấp bảng chi tiết về tất cả giá trị nhận dạng nhận được (chẳng hạn như địa chỉ email, số điện thoại, địa chỉ thực tế và địa chỉ IP) theo DataType.

Nếu yêu cầu có đủ số lượng hồ sơ, thì upload_match_rate_range sẽ chứa phạm vi tỷ lệ khớp cho các hồ sơ trong yêu cầu.

Trạng thái xoá thành viên đối tượng

Trường audience_members_removal_status được điền sẵn nếu yêu cầu là RemoveAudienceMembersRequest. Sau đây là trường RemoveAudienceMembersStatus để kiểm tra từng loại dữ liệu đối tượng. Chỉ một trong các trường này được đặt.

user_data_removal_status

Trạng thái xoá đối với dữ liệu người dùng.

mobile_data_removal_status

Trạng thái xoá đối với dữ liệu di động.

pair_data_removal_status

Trạng thái xoá đối với dữ liệu PAIR.

ppid_data_removal_status

Trạng thái xoá đối với dữ liệu PPID.

user_id_data_removal_status

Trạng thái xoá đối với dữ liệu Mã người dùng

composite_data_removal_status

Trạng thái xoá đối với dữ liệu Tổng hợp

Kiểm tra record_count để xác nhận rằng tổng số hồ sơ nhận được khớp với kỳ vọng của bạn. record_count bao gồm cả hồ sơ thành công và không thành công.

Ngoài ra, hãy kiểm tra user_identifier_count, mobile_id_count, pair_id_count, ppid_count hoặc user_id_count để xác nhận tổng số giá trị nhận dạng nhận được.

Đối với dữ liệu tổng hợp, hãy kiểm tra data_type_counts để xác nhận rằng số lượng giá trị nhận dạng khớp với kỳ vọng của bạn. Danh sách này cung cấp thông tin phân tích về tất cả giá trị nhận dạng nhận được (chẳng hạn như địa chỉ email, số điện thoại, địa chỉ thực tế và địa chỉ IP) theo DataType.

Kiểm tra cảnh báo và lỗi

Ngoài các trường trạng thái cho đích và loại yêu cầu, RetrieveRequestStatusResponse còn chứa bảng chi tiết về các cảnh báo và lỗi cho yêu cầu.

• Lỗi cho biết rằng API đã hoàn toàn từ chối hồ sơ.
• Cảnh báo cho biết rằng API không từ chối hồ sơ, nhưng phải bỏ qua một số phần dữ liệu của hồ sơ.

Ví dụ: nếu Event chứa dữ liệu được mã hoá UserIdentifier và AdIdentifiers như gclid, đồng thời không thể giải mã dữ liệu UserIdentifier, thì Data Manager API vẫn xử lý hồ sơ bằng AdIdentifiers nhưng trả về cảnh báo PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

Tuy nhiên, nếu Event không chứa AdIdentifiers và không thể giải mã dữ liệu UserIdentifier, thì Data Manager API sẽ từ chối toàn bộ hồ sơ và báo cáo lỗi PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR vì Event hợp lệ phải có ít nhất một trong các giá trị ad_identifiers hoặc user_data.

Sau đây là các trường phản hồi chứa thông tin cảnh báo và lỗi. Các trường này được điền sẵn khi trạng thái tổng thể của đích đạt đến SUCCESS, PARTIAL_SUCCESS, hoặc FAILURE.

warning_info

Danh sách các đối tượng WarningCount. Mỗi WarningCount chứa một reason với loại cảnh báo và một record_count cho biết số lượng hồ sơ có loại cảnh báo đó.

Kiểm tra warning_info ngay cả khi trạng thái tổng thể của đích là SUCCESS.

error_info

Danh sách các đối tượng ErrorCount. Mỗi ErrorCount chứa một reason với loại lỗi và một record_count cho biết số lượng hồ sơ không thành công do loại lỗi đó.