Chẩn đoán

Sau đây là quy trình công việc được đề xuất để xác minh tình trạng tải lên sự kiện và đối tượng, đồng thời xác định các vấn đề về dữ liệu.

  1. Đưa ra yêu cầu gửi sự kiện hoặc gửi hoặc xoá thành viên đối tượng.

  2. Kiểm tra trạng thái tổng thể của từng yêu cầu. Yêu cầu thành công có Status với code bằng 0 (giá trị enum OK, phản hồi HTTP 200 OK) và trả về IngestEventsResponse, IngestAudienceMembersResponse hoặc RemoveAudienceMembersResponse.

    Nếu yêu cầu không thành công, hãy sửa đổi yêu cầu để giải quyết lỗi và gửi lại yêu cầu.

    Nếu yêu cầu thành công, hãy ghi lại request_id của phản hồi để bạn có thể dùng mã này truy xuất thông tin chẩn đoán ở bước tiếp theo.

  3. Chờ 30 phút, sau đó gửi yêu cầu RetrieveRequestStatus cho mỗi request_id thành công.

    Định kỳ lặp lại bước này cho từng request_id cho đến khi destination status (trạng thái đích đến) của từng đích đến đạt đến SUCCESS, PARTIAL_SUCCESS hoặc FAILURE. Sử dụng thuật toán thời gian đợi tăng theo cấp luỹ thừa để đợi giữa mỗi yêu cầu.

  4. Xem xét từng RetrieveRequestStatusResponse để xác nhận rằng các lượt tải lên của bạn đang hoạt động đúng cách và xác định mọi vấn đề về dữ liệu.

  5. Khắc phục vấn đề về dữ liệu.

  6. Quay lại bước 1 và lặp lại cho đến khi bạn giải quyết xong tất cả vấn đề về tệp tải lên.

Gửi yêu cầu

RetrieveRequestStatusRequest yêu cầu một giá trị request_id duy nhất. Gửi một yêu cầu riêng về trạng thái cho từng mã yêu cầu mà bạn đã ghi nhận từ một yêu cầu tiếp nhận thành công.

Định kỳ gửi RetrieveRequestStatusRequest bằng cách sử dụ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 đến 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 việc xử lý một số yêu cầu chỉ trong 30 phút.

Sau đây là ví dụ về thời gian chờ 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:

Cài đặt Giá trị
Thời gian chờ trước yêu cầu chẩn đoán đầu tiên (phút) 30
Hệ số nhân thời gian đợi 1.3
Thời gian tối đa để tạm ngưng (phút) 60 (1 giờ)
Tổng thời gian tối đa (phút) 1440 (24 giờ)

Sau đây là một chuỗi các yêu cầu và thời gian đã trôi qua với cấu hình này:

Biểu đồ

Chiến lược thăm dò ý kiến

Dữ liệu

Số lần thực hiện Thời gian kể từ khi có yêu cầu truyền dẫn (hh:mm) Độ trễ trước khi thử Ghi chú
1 00:30 30 phút Trước tiên, hãy kiểm tra xem trạng thái có sẵn hay không
2 01:09 39 phút
3 01:59 50,7 phút
4 02:59 60 phút Giờ đây, thời gian trễ tối đa là 1 giờ
5 03:59 60 phút
6 04:59 60 phút
7 05:59 60 phút
8 06:59 60 phút
9 07:59 60 phút
10 08:59 60 phút
11 09:59 60 phút
12 10:59 60 phút
13 11:59 60 phút Mốc 12 giờ
14 12:59 60 phút
15 13:59 60 phút
16 14:59 60 phút
17 15:59 60 phút
18 16:59 60 phút
19 17:59 60 phút
20 18:59 60 phút
21 19:59 60 phút
22 20:59 60 phút
23 21:59 60 phút
24 22:59 60 phút
25 23:59 60 phút Yêu cầu cuối cùng trước khi đạt đến tổng thời gian tối đa là 24 giờ

Thêm một lượng nhỏ biên độ ngẫu nhiên vào độ trễ của cơ chế dự phòng để ngăn chặn vấn đề "đàn gia súc" khi nhiều ứng dụng đồng thời thử lại.

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

request_status_per_destination trong RetrieveRequestStatusResponse chứa một mục riêng cho từng đích đến trong yêu cầu tiếp nhận 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 đối tượng một mục).

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

Bước đầu tiên, hãy kiểm tra trường request_status để xác định xem Data Manager API đã hoàn tất việc 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 đến vẫn đang được xử lý. Cảnh báo và lỗi không được điền sẵn cho đích đến ở giai đoạn này.

  • SUCCESS: Đã hoàn tất quá trình xử lý yêu cầu cho đích đến mà không gặp 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ả bản ghi cho đích đến đều không thành công do lỗi. Kiểm tra cảnh báo và lỗi để xác định lý do khiến tất cả bản ghi đều 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ố bản ghi cho đích đến đã thành công, nhưng những bản ghi khác không thành công do lỗi. Kiểm tra lỗi để xác định lý do khiến một số bản ghi 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 từng đích đến

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

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

Trường events_ingestion_status sẽ được điền nếu yêu cầu là một 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 số hồ sơ bạn mong đợi. record_count bao gồm cả bản ghi 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 sẽ được điền nếu yêu cầu là một IngestAudienceMembersRequest. Dưới đây là trường IngestAudienceMembersStatus để kiểm tra từng loại dữ liệu đối tượng. Chỉ có một trong số 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 mong đợi của bạn. record_count bao gồm cả bản ghi thành công và không thành công.

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

Nếu yêu cầu có đủ số lượng bản ghi, thì upload_match_rate_range sẽ chứa phạm vi tỷ lệ trùng khớp cho các bản ghi 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 số lượng bạn mong đợi. record_count bao gồm cả bản ghi thành công và không thành công.

Kiểm tra mobile_id_count để xác nhận số lượng mã nhận dạng thiết bị di động nhận được có khớp với kỳ vọng của bạn hay không.

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 mong đợi của bạn. record_count bao gồm cả bản ghi thành công và không thành công.

Kiểm tra pair_id_count để xác nhận số lượng mã nhận dạng PAIR nhận được có đúng như bạn mong đợi hay không.

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 mong đợi của bạn. record_count bao gồm cả bản ghi thành công và không thành công.

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

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 mong đợi của bạn. record_count bao gồm cả bản ghi thành công và không thành công.

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

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

Trường audience_members_removal_status sẽ được điền sẵn nếu yêu cầu là RemoveAudienceMembersRequest. Sau đây là trường RemoveAudienceMembersStatus cần kiểm tra cho từng loại dữ liệu đối tượng. Chỉ có một trong số 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á 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ã nhận dạng người dùng

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

Ngoài ra, hãy kiểm tra user_identifier_count, mobile_id_count hoặc pair_id_count để xác nhận tổng số giá trị nhận dạng người dùng, mã nhận dạng thiết bị di động hoặc mã PAIR đã nhận được.

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

Ngoài các trường trạng thái cho đích đến 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 API đã hoàn toàn từ chối bản ghi.
  • Cảnh báo cho biết API không từ chối bản ghi, nhưng API phải bỏ qua một phần dữ liệu của bản ghi.

Ví dụ: nếu một Event cho lượt chuyển đổi ngoại tuyến trên Google Ads chứa dữ liệu UserIdentifier đã mã hoá và AdIdentifiers chẳng hạn như gclid, đồng thời dữ liệu UserIdentifier không thể giải mã, thì Data Manager API vẫn xử lý bản ghi 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ộ bản ghi và báo cáo lỗi PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR vì Event lượt chuyển đổi ngoại tuyến hợp lệ trên Google Ads 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 chung của đích đến đạ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 có loại cảnh báo và một record_count cho biết số lượng bản ghi có loại cảnh báo đó.

Kiểm tra warning_info ngay cả khi trạng thái chung của đích đến 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 bản ghi không thành công do loại lỗi đó.