Chẩn đoán

Sau đây là quy trình đề xuất để xác minh tình trạng của tệp tải lên chứa dữ liệu sự kiện và đối tượng, cũng như xác định vấn đề về dữ liệu.

  1. Gửi yêu cầu để gửi sự kiện hoặc gửi hay xoá thành viên trong phân khúc đố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 để có thể sử dụng thông tin này nhằm truy xuất thông tin chẩn đoán trong 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 mỗi request_id cho đến khi trạng thái đích đến của mỗi đích đến đạt SUCCESS, PARTIAL_SUCCESS hoặc FAILURE. Sử dụng thuật toán đợi luỹ thừa để chờ giữa mỗi yêu cầu.

  4. Xem lại từng RetrieveRequestStatusResponse để xác nhận rằng dữ liệu bạn tải lê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 mỗi mã yêu cầu mà bạn thu thập được từ một yêu cầu nhập thành công.

Ủy quyền

RetrieveRequestStatusRequest không chấp nhận tài khoản đích hoặc tiêu đề của yêu cầu. Thay vào đó, Data Manager API xác định các đích đến từ yêu cầu nhập ban đầu liên kết với request_id và xác minh rằng phương thức gọi có quyền truy cập vào operating_account trên mỗi Destination.

Để kiểm tra trạng thái của một yêu cầu, thông tin đăng nhập được dùng trong RetrieveRequestStatusRequest phải đáp ứng các yêu cầu sau đây đối với operating_account của từng đích đến trong yêu cầu nhập ban đầu:

  • Đường dẫn truy cập giống hệt nhau: Thông tin đăng nhập phải có quyền truy cập vào từng operating_account bằng đường dẫn truy cập giống hệt được chỉ định trong yêu cầu nhập ban đầu.

    Ví dụ: nếu yêu cầu nhập dữ liệu cho một operating_account Google Ads chỉ định một tài khoản người quản lý cấp cao là login_account, thì thông tin đăng nhập cũng phải có quyền truy cập vào operating_account thông qua chính tài khoản người quản lý đó. Ngay cả khi Tài khoản Google được liên kết với thông tin xác thực có quyền truy cập trực tiếp vào operating_account con, thì yêu cầu vẫn không thành công và trả về lỗi PERMISSION_DENIED nếu tài khoản đó không có quyền truy cập thông qua tài khoản người quản lý login_account được chỉ định trong quá trình nhập.

  • Cấp truy cập phù hợp: Tài khoản Google được liên kết với thông tin xác thực phải có cấp truy cập hoặc vai trò có quyền nhập dữ liệu vào operating_account.

    Ví dụ: trong Google Ads, Tài khoản Google phải có cấp truy cập Quản trị hoặc Tiêu chuẩn. Yêu cầu có thông tin đăng nhập của một tài khoản có cấp truy cập Chỉ có thể đọc sẽ không thành công và trả về lỗi PERMISSION_DENIED.

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

Định kỳ gửi RetrieveRequestStatusRequest bằng thuật toán thời gian đợi 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ù API Trình quản lý dữ liệu có thể hoàn tất việc xử lý một số yêu cầu chỉ trong 30 phút.

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

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

Sau đâ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:

Biểu đồ

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

Dữ liệu

Lần thử Thời gian kể từ khi có yêu cầu nhập (hh:mm) Thời gian trì hoãn trước khi thử lại Ghi chú
1 00:30 30 phút Trước tiên, hãy kiểm tra xem có trạng thái hay không
2 01:09 39 phút
3 01:59 50,7 phút
4 02:59 60 phút Thời gian trễ hiện được giới hạn ở mức 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 thuật toán thời gian đợi luỹ thừa để ngăn chặn vấn đề "thundering herd" (bầy đàn sấm sét) khi nhiều ứng dụng khách thử lại cùng một lúc.

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

request_status_per_destination trong RetrieveRequestStatusResponse chứa một mục riêng biệt cho mỗi đích đến 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 đến

Bước đầu tiên là kiểm tra trường request_status để xác định xem Data Manager API đã xử lý xong 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: Quá trình xử lý yêu cầu cho đích đến đã 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ả 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 một số 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 của 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 nhập. Chỉ có một trong số 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 được điền sẵ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ố bản ghi 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.

Trạng thái nhập thành viên trong phân khúc đối tượng

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

composite_data_ingestion_status

Kiểm tra record_count của IngestCompositeDataStatus để xác nhận rằng tổng số bản ghi 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 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 chi tiết về tất cả giá trị nhận dạng đã nhận (chẳng hạn như địa chỉ email, số điện thoại, địa chỉ thực tế và địa chỉ IP) của DataType.

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ệ khớp cho các bản ghi trong yêu cầu.

google_user_id_data_ingestion_status

Kiểm tra record_count của IngestGoogleUserIdDataStatus để xác nhận rằng tổng số bản ghi 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 google_user_id_count để xác nhận số lượng mã nhận dạng người dùng Google nhận được có khớp với kỳ vọng của bạn hay không.

mobile_data_ingestion_status

Kiểm tra record_count của IngestMobileDataStatus để xác nhận rằng tổng số bản ghi 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 Mobile ID nhận được có khớp với mong đợi 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ố bản ghi 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 pair_id_count để xác nhận số lượng mã nhận dạng PAIR nhận được có khớp với số lượng bạn mong đợi hay không.

partner_provided_id_data_ingestion_status

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

Kiểm tra partner_provided_id_count để xác nhận số lượng mã nhận dạng do đối tác cung cấp mà bạn nhận được có khớp với số lượng 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ố bản ghi 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 ppid_count để xác nhận số lượng PPID nhận được khớp với kỳ vọng của bạn.

user_data_ingestion_status

Kiểm tra record_count của IngestUserDataStatus để xác nhận rằng tổng số bản ghi 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 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ệ khớp cho các bản ghi trong yêu cầu.

user_id_data_ingestion_status

Kiểm tra record_count của IngestUserIdDataStatus để xác nhận rằng tổng số bản ghi 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 user_id_count để xác nhận số lượng mã 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.

Trạng thái xoá thành viên trong phân khúc đối tượng

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

composite_data_removal_status
Trạng thái gỡ bỏ Dữ liệu tổng hợp
google_user_id_data_removal_status
Trạng thái xoá dữ liệu mã nhận dạng người dùng của Google
mobile_data_removal_status
Trạng thái xoá dữ liệu di động.
pair_data_removal_status
Trạng thái xoá dữ liệu PAIR.
partner_provided_id_data_removal_status
Trạng thái xoá đối với Dữ liệu giấy tờ tuỳ thân do đối tác cung cấp
ppid_data_removal_status
Trạng thái xoá cho dữ liệu PPID.
user_data_removal_status
Trạng thái xoá dữ liệu người dùng.
user_id_data_removal_status
Trạng thái xoá 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 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.

Ngoài ra, hãy kiểm tra user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count hoặc partner_provided_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 số lượng bạn mong đợi. Danh sách này cung cấp thông tin chi tiết về tất cả giá trị nhận dạng đã nhận (chẳng hạn như địa chỉ email, số điện thoại, địa chỉ thực tế và địa chỉ IP) của DataType.

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 thông tin chi tiết về các cảnh báo và lỗi cho yêu cầu.

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

Ví dụ: nếu một Event chứa dữ liệu UserIdentifier đã mã hoá và AdIdentifiers 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 hợp lệ phải có ít nhất một trong hai giá trị ad_identifiers hoặc user_data.

Dưới đâ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 đến đạt đến SUCCESS, PARTIAL_SUCCESS hoặc FAILURE.

warning_info

Đối tượng WarningInfo. Trường warning_counts của đối tượng này chứa 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 tổng thể của đích đến là SUCCESS.

error_info

Một đối tượng ErrorInfo. Trường error_counts của đối tượng này chứa danh sách các đối tượng ErrorCount. Mỗi ErrorCount chứa một reason có 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 đó.