以下是验证事件和受众群体上传的健康状况并找出数据问题的推荐工作流。
检查每个请求的总体状态。成功的请求具有
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 不接受目标
账号或请求标头。相反，Data Manager API 会从与
request_id 关联的原始注入请求中识别
目标位置，并验证调用方是否有权访问每个 Destination 上的 operating_account
。
如需检查请求的状态，
RetrieveRequestStatusRequest 中使用的凭据必须满足原始
注入请求中每个目标位置的 operating_account 的以下
要求：
相同的访问路径：凭据必须使用
operating_account中指定的完全相同的访问路径访问每个 原始注入请求。例如，如果 Google Ads
operating_account的注入请求将父级经理账号指定为login_account，则凭据还必须通过该经理账号访问operating_account。即使与凭据关联的 Google 账号可以直接访问子级operating_account，如果该账号缺少通过注入期间指定的login_account经理账号进行的访问权限，请求也会失败并显示PERMISSION_DENIED错误。足够的访问权限级别：与 凭据关联的 Google 账号必须具有可将数据注入
operating_account的访问权限级别或角色。例如，在 Google Ads 中，Google 账号必须具有 管理员或标准 访问权限级别。 如果账号的凭据具有只读 访问权限级别，请求会失败并显示
PERMISSION_DENIED错误。
轮询策略
使用 指数退避算法 定期发送 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 是否已完成对 RequestStatusPerDestination 的 destination 的数据处理。
request_status 的可能值如下：
PROCESSING：目标位置的数据仍在处理中。在此阶段，系统不会为目标位置填充 警告和错误 。SUCCESS：目标位置的请求处理已完成，没有任何错误。检查警告处理期间标记的。FAILURE：目标位置的所有记录均因错误而失败。 检查警告和错误，以确定所有记录 失败的原因。另请检查处理期间标记的警告。PARTIAL_SUCCESS：目标位置的部分记录成功，但其他记录因错误而失败。检查错误以 确定部分记录失败的原因。另请检查处理期间标记的警告。
按目标位置检查事件或受众群体状态
检查与注入请求类型对应的状态字段。在每个 RequestStatusPerDestination 上，系统只会设置以下字段中的 一个 ：
事件注入状态
如果请求是
IngestEventsRequest，系统会填充 events_ingestion_status 字段。
检查 record_count 的 IngestEventStatus
，以确认收到的记录总数符合您的
预期。record_count 包括成功和失败的记录。
受众群体成员注入状态
如果请求是
IngestAudienceMembersRequest，系统会填充 audience_members_ingestion_status 字段。以下是针对
IngestAudienceMembersStatus字段检查的
每种类型的受众群体数据。系统只会设置这些字段中的 一个 。
composite_data_ingestion_status检查
record_count的IngestCompositeDataStatus，以确认收到的 记录总数符合您的预期。record_count包括成功和失败的记录。检查
data_type_counts，以确认标识符的数量符合您的预期。此列表按DataType细分了收到的所有 标识符（例如电子邮件地址、电话号码、实际生活中的 地址和 IP 地址）。如果请求包含足够多的记录，
upload_match_rate_range会包含 匹配率 范围 请求中记录的。google_user_id_data_ingestion_status检查
record_count的IngestGoogleUserIdDataStatus，以确认 收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
google_user_id_count，以确认收到的 Google 用户 ID 数量符合您的预期。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 数量符合您的预期。partner_provided_id_data_ingestion_status检查
record_count的IngestPartnerProvidedIdDataStatus，以 确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
partner_provided_id_count，以确认收到的合作伙伴提供的 ID 数量符合您的预期。ppid_data_ingestion_status检查
record_count的IngestPpidDataStatus，以确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
ppid_count，以确认收到的 PPID 数量符合您的预期。user_data_ingestion_status检查
record_count的IngestUserDataStatus，以确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
user_identifier_count，以确认收到的 用户标识符数量符合您的 预期。如果请求包含足够多的记录，
upload_match_rate_range会包含 匹配率 范围 请求中记录的。user_id_data_ingestion_status检查
record_count的IngestUserIdDataStatus，以确认收到的记录总数符合您的预期。record_count包括成功和失败的记录。检查
user_id_count，以确认收到的用户 ID 数量符合您的预期。
受众群体成员移除状态
如果请求是
RemoveAudienceMembersRequest，系统会填充 audience_members_removal_status 字段。以下是针对每种
类型的受众群体数据检查的
RemoveAudienceMembersStatus 字段。系统只会设置这些字段中的 一个 。
composite_data_removal_status- 复合数据的移除状态
google_user_id_data_removal_status- Google 用户 ID 数据 的移除状态
mobile_data_removal_status- 移动数据的移除状态。
pair_data_removal_status- PAIR 数据的移除状态。
partner_provided_id_data_removal_status- 合作伙伴提供的 ID 数据的移除状态
ppid_data_removal_status- PPID 数据的移除状态。
user_data_removal_status- 用户数据的移除状态。
user_id_data_removal_status- 用户 ID 数据的移除状态
检查 record_count，以确认收到的记录总数符合您的预期。record_count 包括成功和失败的记录。
此外，检查 user_identifier_count、mobile_id_count、
pair_id_count、ppid_count、user_id_count、google_user_id_count 或
partner_provided_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一个
WarningInfo对象。其warning_counts字段包含WarningCount对象列表。每个WarningCount都包含一个reason（包含警告类型）和一个record_count（表示具有该类型警告的记录数）。即使 总体目标 状态 为
SUCCESS，也要检查warning_info。error_info一个
ErrorInfo对象。其error_counts字段包含ErrorCount对象列表。每个ErrorCount都包含一个reason（包含错误类型）和一个record_count（表示因该类型错误而失败的记录数）。