以下是建议的工作流程，用于验证事件和受众群体上传的健康状况，并找出数据问题。
查看每项请求的总体状态。成功的请求具有
Status，其中code等于0（枚举值OK，HTTP 响应200 OK），并返回IngestEventsResponse、IngestAudienceMembersResponse或RemoveAudienceMembersResponse。如果请求不成功，请修改请求以解决错误，然后再次发送请求。
如果请求成功，请捕获响应的
request_id，以便在下一步中使用它来检索诊断信息。等待 30 分钟，然后为每个成功的
request_id发送RetrieveRequestStatus请求。定期为每个
request_id重复此步骤，直到每个目的地的目的地状态达到SUCCESS、PARTIAL_SUCCESS或FAILURE。使用指数退避算法在每个请求之间等待。查看每个
RetrieveRequestStatusResponse，确认上传是否正常运行，并找出数据中的任何问题。更正数据问题。
返回到第 1 步，然后重复执行，直到您已解决上传的所有问题。
发送请求
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 小时最长总时间之前的最后一个请求 |
在退避延迟时间中添加少量随机抖动，以防止出现许多客户端同时重试的“惊群”问题。
查看回答
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 上仅设置了以下字段中的一个：
事件提取状态
如果请求是 IngestEventsRequest，则会填充 events_ingestion_status 字段。
检查 IngestEventStatus 的 record_count，确认收到的记录总数是否符合预期。record_count 包含成功和失败的记录。
受众群体成员提取状态
如果请求是 IngestAudienceMembersRequest，则会填充 audience_members_ingestion_status 字段。以下是每种受众群体数据类型要检查的 IngestAudienceMembersStatus 字段。这些字段中只能设置一个。
composite_data_ingestion_status检查
IngestCompositeDataStatus的record_count，确认收到的记录总数符合您的预期。record_count包含成功和失败的记录。检查
data_type_counts，确认标识符数量符合您的预期。此列表详细列出了DataType接收到的所有标识符（例如邮箱、电话号码、实际地址和 IP 地址）。如果请求包含足够数量的记录，则
upload_match_rate_range会包含请求中记录的匹配率范围。google_user_id_data_ingestion_status检查
IngestGoogleUserIdDataStatus的record_count，确认收到的记录总数符合您的预期。record_count包含成功和失败的记录。检查
google_user_id_count，确认收到的 Google 用户 ID 数量是否符合您的预期。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 数量是否符合您的预期。partner_provided_id_data_ingestion_status检查
IngestPartnerProvidedIdDataStatus的record_count，确认收到的记录总数符合您的预期。record_count包含成功和失败的记录。查看
partner_provided_id_count，确认收到的合作伙伴提供的 ID 数量是否符合您的预期。ppid_data_ingestion_status检查
IngestPpidDataStatus的record_count，确认收到的记录总数符合您的预期。record_count包含成功和失败的记录。检查
ppid_count，确认收到的 PPID 数量是否符合您的预期。user_data_ingestion_status检查
IngestUserDataStatus的record_count，确认收到的记录总数符合您的预期。record_count包含成功和失败的记录。检查
user_identifier_count，确认收到的用户标识符数量是否符合您的预期。如果请求包含足够数量的记录，则
upload_match_rate_range会包含请求中记录的匹配率范围。user_id_data_ingestion_status检查
IngestUserIdDataStatus的record_count，确认收到的记录总数符合您的预期。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_infoWarningInfo对象。其warning_counts字段包含WarningCount对象列表。每个WarningCount都包含一个reason（其中包含警告类型）和一个record_count（用于指示具有该警告类型的记录数）。即使总体目标状态为
SUCCESS，也请检查warning_info。error_infoErrorInfo对象。其error_counts字段包含ErrorCount对象列表。每个ErrorCount都包含一个reason（其中包含错误类型）和一个record_count（指示因该错误类型而失败的记录数）。