诊断信息

以下是建议的工作流程，可用于验证活动和受众群体上传的健康状况，并发现数据存在的问题。

1. 发出请求以发送事件或发送/移除目标受众群体成员。

2. 查看每项请求的总体状态。如果请求成功，则会返回 code 等于 0（枚举值 OK，HTTP 响应 200 OK）的 Status，并返回 IngestEventsResponse、IngestAudienceMembersResponse 或 RemoveAudienceMembersResponse。

   如果请求不成功，请修改请求以解决错误，然后再次发送请求。

   如果请求成功，请捕获响应的 request_id，以便在下一步中使用它来检索诊断信息。

3. 等待 30 分钟，然后针对每个成功的 request_id 发送 RetrieveRequestStatus 请求。

   针对每个 request_id 定期重复执行此步骤，直到每个目的地的目的地状态达到 SUCCESS、PARTIAL_SUCCESS 或 FAILURE。使用指数退避算法在每个请求之间等待。

4. 查看每个 RetrieveRequestStatusResponse，确认上传功能是否正常运行，并找出数据中的任何问题。

5. 更正数据问题。

6. 返回第 1 步并重复执行，直到解决上传的所有问题。

发送请求

RetrieveRequestStatusRequest 需要单个 request_id 值。针对您从成功的提取请求中捕获的每个请求 ID，单独发送一个状态请求。

使用指数退避算法定期发送 RetrieveRequestStatusRequest，直到原始请求中的每个目的地都达到 request_status 的 SUCCESS、FAILURE 或 PARTIAL_SUCCESS。此过程可能需要长达 24 小时，不过 Data Manager API 可能只需 30 分钟即可完成某些请求的处理。

以下是一个合理的初始等待时间和重试配置示例，可平衡活跃度和配额使用情况：

设置	值
首次诊断请求之前的等待时间（分钟）	30
退避系数	1.3
最长退避时间（分钟）	60（1 小时）
最长总时间（分钟）	1440（24 小时）

以下是采用此配置的一系列请求和经过的时间：

在退避延迟中添加少量随机抖动，以防止出现“惊群”问题，即许多客户端同时重试。

查看回答

RetrieveRequestStatusResponse 中的 request_status_per_destination 包含相应提取请求中每个目的地的单独条目。

例如，如果您的 IngestAudienceMembersRequest 的 destinations 列表中包含 3 个条目，用于将数据发送给 3 个不同的受众群体，则状态响应的 request_status_per_destination 中将包含 3 个条目（每个受众群体对应一个条目）。

查看整体目标状态

首先，检查 request_status 字段，以确定 Data Manager API 是否已完成对 RequestStatusPerDestination 的 destination 的数据处理。

request_status 的可能值如下：

• PROCESSING：目标的数据仍在处理中。在此阶段，系统不会为目标填充警告和错误。

• SUCCESS：目标请求处理完成，未出现任何错误。检查处理过程中标记的警告。

• FAILURE：由于错误，目标的所有记录均失败。 检查是否存在警告和错误，以确定所有记录失败的原因。另请检查处理过程中标记的警告。

• PARTIAL_SUCCESS：部分目标记录成功，但其他记录因错误而失败。检查错误，以确定部分记录失败的原因。还要检查处理过程中标记的警告。

按目标平台查看事件或受众群体状态

检查与提取请求类型对应的状态字段。每个 RequestStatusPerDestination 仅设置以下字段中的一个：

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

事件提取状态

如果请求是 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，确认收到的用户标识符数量是否符合您的预期。

如果请求包含足够数量的记录，则 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 数量是否符合您的预期。

ppid_data_ingestion_status

检查 IngestPpidDataStatus 的 record_count，确认收到的记录总数是否符合您的预期。record_count 包含成功记录和失败记录。

检查 ppid_count，确认收到的 PPID 数量是否符合您的预期。

user_id_data_ingestion_status

检查 IngestUserIdDataStatus 的 record_count，确认收到的记录总数是否符合您的预期。record_count 包含成功记录和失败记录。

检查 user_id_count，确认收到的用户 ID 数量是否符合您的预期。

composite_data_ingestion_status

检查 IngestCompositeDataStatus 的 record_count，确认收到的记录总数是否符合您的预期。record_count 包括成功和失败的记录。

检查 data_type_counts 以确认标识符的数量是否符合您的预期。此列表详细列出了 DataType 收到的所有标识符（例如电子邮件地址、电话号码、实际地址和 IP 地址）。

如果请求包含足够数量的记录，则 upload_match_rate_range 包含请求中记录的匹配率范围。

受众群体成员移除状态

如果请求是 RemoveAudienceMembersRequest，则会填充 audience_members_removal_status 字段。下表列出了每种受众群体数据需要检查的 RemoveAudienceMembersStatus 字段。只会设置这些字段中的一个。

user_data_removal_status

用户数据的移除状态。

mobile_data_removal_status

移动数据的移除状态。

pair_data_removal_status

PAIR 数据的移除状态。

ppid_data_removal_status

PPID 数据的移除状态。

user_id_data_removal_status

用户 ID 数据的移除状态

composite_data_removal_status

复合数据的移除状态

检查 record_count，确认收到的记录总数是否符合您的预期。record_count 包含成功和失败的记录。

此外，请检查 user_identifier_count、mobile_id_count、pair_id_count、ppid_count 或 user_id_count，以确认收到的标识符总数。

对于复合数据，请检查 data_type_counts 以确认标识符的数量是否符合您的预期。此列表详细列出了 DataType 收到的所有标识符（例如电子邮件地址、电话号码、实际地址和 IP 地址）。

查看警告和错误

除了目标和请求类型的状态字段之外，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 中的至少一个。

以下是包含警告和错误信息的响应字段。当整体目的地状态达到 SUCCESS、PARTIAL_SUCCESS 或 FAILURE 时，系统会填充这些字段。

warning_info

WarningCount 对象的列表。每个 WarningCount 都包含一个 reason（包含警告类型）和一个 record_count（指示出现相应类型警告的记录数）。

即使整体目的地状态为 SUCCESS，也要检查 warning_info。

error_info

ErrorCount 对象的列表。每个 ErrorCount 都包含一个 reason（包含错误类型）和一个 record_count（用于指明因相应类型的错误而失败的记录数）。