以下是验证事件和受众群体上传的健康状况并找出数据问题的推荐工作流程。
查看每个请求的总体状态。成功的请求具有
Status，其code等于0（枚举值OK，HTTP 响应200 OK），并返回IngestEventsResponse、IngestAudienceMembersResponse或RemoveAudienceMembersResponse。如果请求不成功，请修改请求以解决错误，然后再次发送请求。
如果请求成功，请捕获响应的
request_id，以便在下一步中检索诊断信息时使用。等待 30 分钟，然后针对每个成功的
request_id发送RetrieveRequestStatus请求。针对每个
request_id定期重复此步骤，直到每个目标位置的 目标 状态 达到SUCCESS、PARTIAL_SUCCESS或FAILURE为止。使用 指数退避 算法 在每个请求之间等待。查看每个
RetrieveRequestStatusResponse，以确认 上传正常运行并找出数据中的任何问题。更正数据问题。
返回到第 1 步并重复，直到解决上传的所有问题为止。
发送请求
A RetrieveRequestStatusRequest 需要单个
request_id 值。针对从成功的提取请求中捕获的每个请求 ID 发送单独的状态请求。
使用 指数退避算法 定期发送 RetrieveRequestStatusRequest，直到原始请求中每个目标位置的 request_status 达到SUCCESS、FAILURE 或 PARTIAL_SUCCESS 为止。这可能需要长达 24 小时，不过 Data Manager API 可能只需 30 分钟即可完成某些请求的处理。
以下是合理的初始等待时间和重试配置示例，可平衡活跃度和配额使用情况：
| 设置 | 值 |
|---|---|
| 首次诊断请求之前的等待时间（分钟） | 30 |
| 退避调节系数 | 1.3 |
| 最长退避时间（分钟） | 60（1 小时） |
| 最长总时间（分钟） | 1440（24 小时） |
以下是使用此配置的请求序列和经过的时间：
图表
数据
| 尝试 | 自提取请求以来的时间 (hh:mm) | 尝试前的延迟时间 | 备注 |
|---|---|---|---|
| 1 | 00:30 | 30.0 分钟 | 首次检查状态可用性 |
| 2 | 01:09 | 39.0 分钟 | |
| 3 | 01:59 | 50.7 分钟 | |
| 4 | 02:59 | 60.0 分钟 | 延迟时间现在上限为 1 小时 |
| 5 | 03:59 | 60.0 分钟 | |
| 6 | 04:59 | 60.0 分钟 | |
| 7 | 05:59 | 60.0 分钟 | |
| 8 | 06:59 | 60.0 分钟 | |
| 9 | 07:59 | 60.0 分钟 | |
| 10 | 08:59 | 60.0 分钟 | |
| 11 | 09:59 | 60.0 分钟 | |
| 12 | 10:59 | 60.0 分钟 | |
| 13 | 11:59 | 60.0 分钟 | 12 小时标记 |
| 14 | 12:59 | 60.0 分钟 | |
| 15 | 13:59 | 60.0 分钟 | |
| 16 | 14:59 | 60.0 分钟 | |
| 17 | 15:59 | 60.0 分钟 | |
| 18 | 16:59 | 60.0 分钟 | |
| 19 | 17:59 | 60.0 分钟 | |
| 20 | 18:59 | 60.0 分钟 | |
| 21 | 19:59 | 60.0 分钟 | |
| 22 | 20:59 | 60.0 分钟 | |
| 23 | 21:59 | 60.0 分钟 | |
| 24 | 22:59 | 60.0 分钟 | |
| 25 | 23:59 | 60.0 分钟 | 最长总时间 24 小时之前的最后一个请求 |
向退避 延迟时间添加少量随机 抖动，以防止出现“惊群”问题，即许多客户端 同时重试。
查看回答
request_status_per_destination 在
RetrieveRequestStatusResponse 中包含相应提取请求中每个目标位置的单独条目。
例如，如果您的 IngestAudienceMembersRequest
包含 3 个条目在 destinations 列表中，用于向 3 个不同的
受众群体发送数据，则状态响应将在
request_status_per_destination 中包含 3 个条目（每个受众群体一个条目）。
查看总体目标位置状态
第一步，检查 request_status 字段，以确定
Data Manager API 是否已完成 destination 的
RequestStatusPerDestination 的数据处理。
request_status 的可能值如下：
PROCESSING：目标位置的数据仍在处理中。在此阶段，系统不会为目标位置填充 警告和错误 。SUCCESS：目标位置的请求处理已完成，没有任何错误。检查警告处理期间标记的。FAILURE：由于错误，目标位置的所有记录均失败。 检查警告和错误，以确定所有记录 失败的原因。另请检查处理期间标记的警告。PARTIAL_SUCCESS：目标位置的部分记录成功，但其他记录因错误而失败。检查错误以 确定部分记录失败的原因。另请检查处理期间标记的警告。
按目标位置查看事件或受众群体状态
检查与提取请求类型对应的状态字段。在每个 RequestStatusPerDestination 上，系统仅会设置以下字段之一：
事件提取状态
如果请求是
IngestEventsRequest，系统会填充 events_ingestion_status 字段。
检查 record_count 的 IngestEventStatus
，以确认收到的记录总数符合您的
预期。record_count 包括成功和失败的记录。
受众群体成员提取状态
如果请求是
IngestAudienceMembersRequest，系统会填充 audience_members_ingestion_status 字段。以下是针对
IngestAudienceMembersStatus字段检查的
每种类型的受众群体数据。系统仅会设置这些字段之一。
user_data_ingestion_status检查
record_count的IngestUserDataStatus，以确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
user_identifier_count，以确认收到的 用户标识符数量符合您的 预期。如果请求包含足够数量的记录，则
upload_match_rate_range包含请求中记录的匹配率 范围。mobile_data_ingestion_status检查
record_count的IngestMobileDataStatus，以确认 收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
mobile_id_count，以确认收到的移动设备 ID 数量符合您的预期。pair_data_ingestion_status检查
record_count的IngestPairDataStatus，以确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
pair_id_count，以确认收到的 PAIR ID 数量符合您的预期。ppid_data_ingestion_status检查
record_count的IngestPpidDataStatus，以确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
ppid_count，以确认收到的 PPID 数量符合您的预期。user_id_data_ingestion_status检查
record_count的IngestUserIdDataStatus，以确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
user_id_count，以确认收到的用户 ID 数量符合您的预期。
受众群体成员移除状态
如果请求是
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 数据的移除状态
检查 record_count，以确认收到的记录总数符合您的预期。record_count 包括成功和失败的记录。
此外，检查 user_identifier_count、mobile_id_count 或 pair_id_count，以确认收到的用户标识符、移动设备 ID 或 PAIR ID 的总数。
检查警告和错误
除了目标位置和请求类型的状态字段之外，
RetrieveRequestStatusResponse 还包含请求的
警告和错误细分。
- 错误表示 API 完全拒绝了该记录。
- 警告表示 API 未拒绝该记录，但必须忽略该记录的部分数据。
例如，如果 Google Ads 线下转化的 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，因为有效的 Google Ads 线下转化 Event 必须至少包含 ad_identifiers 或 user_data 之一。
以下是包含警告和错误信息的响应字段。当总体目标位置状态达到 SUCCESS、PARTIAL_SUCCESS 或 FAILURE 时，系统会填充这些
字段
。
warning_infoWarningCount对象列表。每个WarningCount都包含一个reason（包含警告类型）和一个record_count（表示出现该类型警告的记录数）。即使 总体目标 状态 为
SUCCESS，也要检查warning_info。error_infoErrorCount对象列表。每个ErrorCount都包含一个reason（包含错误类型）和一个record_count（表示因该类型错误而失败的记录数）。