イベントとオーディエンスのアップロードの状態を確認し、データに関する問題を特定するためのおすすめのワークフローは次のとおりです。
各リクエストの全体的なステータスを確認します。リクエストが成功した場合、
Statusのcodeは0（列挙値OK、HTTP レスポンス200 OK）になり、IngestEventsResponse、IngestAudienceMembersResponse、またはRemoveAudienceMembersResponseが返されます。リクエストが成功しなかった場合は、エラーに対処するようにリクエストを変更して、再度送信します。
リクエストが成功した場合は、レスポンスの
request_idを取得します。この ID は、次のステップで診断情報を取得するために使用します。true30 分待ってから、成功した
request_idごとにRetrieveRequestStatusリクエストを送信します。各宛先の宛先 ステータスが
SUCCESS、PARTIAL_SUCCESS、またはFAILUREになるまで、request_idごとにこの手順を定期的に繰り返します。各リクエストの間には、指数バックオフ アルゴリズムを使用して待機します。各
RetrieveRequestStatusResponseを確認して、 アップロードが正常に機能していることを確認し、データに関する問題を特定します。データの問題を修正します。
ステップ 1 に戻り、アップロードに関するすべての問題に対処するまで繰り返します。
リクエストの送信
A RetrieveRequestStatusRequest には、1 つの
request_id 値が必要です。取り込みリクエストが成功したときに取得したリクエスト ID ごとに、個別のステータス リクエストを送信します。
元のリクエストのすべての宛先で request_status が
SUCCESS、FAILURE、または PARTIAL_SUCCESS になるまで、指数バックオフ アルゴリズムを使用して RetrieveRequestStatusRequest
を定期的に送信します。Data Manager API は、リクエストの処理を最短 30 分で完了できますが、最大 24 時間かかる場合があります。
以下に、有効性と割り当て使用量のバランスを取る、適切な初期待機時間と再試行構成の例を示します。
| 設定 | 値 |
|---|---|
| 最初の診断リクエストまでの待機時間（分） | 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 時間前の最後のリクエスト |
バックオフ遅延に小さなランダム ジッターを追加して、多くのクライアントが同時に再試行する「Thundering Herd」の問題を防ぎます。
回答を確認する
request_status_per_destination には、対応する取り込みリクエストの宛先ごとに個別のエントリが含まれています。RetrieveRequestStatusResponse
たとえば、IngestAudienceMembersRequest
に 3 つのエントリが含まれていて、3 つの異なる
オーディエンスにデータを送信する場合、ステータス レスポンスの
request_status_per_destination には 3 つのエントリ（オーディエンスごとに 1 つのエントリ）が含まれます。destinations
宛先の全体的なステータスを確認する
まず、request_status フィールドを確認して、
Data Manager API が RequestStatusPerDestination の destination のデータの処理を完了したかどうかを判断します。
request_status の値は次のいずれかになります。
PROCESSING: 宛先のデータはまだ処理中です。この段階では、宛先に対して 警告とエラーは入力されません 。SUCCESS: 宛先のリクエスト処理がエラーなしで完了しました。処理中にフラグが設定された警告を確認します。FAILURE: エラーのため、宛先のすべてのレコードが失敗しました。 警告とエラーを確認して、すべてのレコード が失敗した理由を特定します。処理中にフラグが設定された警告も確認します。PARTIAL_SUCCESS: 宛先のレコードの一部は成功しましたが、エラーのため一部は失敗しました。エラーを確認して、一部のレコードが失敗した理由を 特定します。処理中にフラグが設定された警告も確認します。
宛先ごとのイベントまたはオーディエンスのステータスを確認する
取り込みリクエストのタイプに対応するステータス フィールドを調べます。各 RequestStatusPerDestination に設定されるフィールドは、次のうちの 1 つ のみです。
イベントの取り込みステータス
リクエストが
IngestEventsRequestの場合、events_ingestion_status フィールドが入力されます。
IngestEventStatus
の record_count を確認して、受信したレコードの合計数が想定どおりであることを確認します。record_count には、成功したレコードと失敗したレコードの両方が含まれます。
オーディエンス メンバーの取り込みステータス
audience_members_ingestion_status フィールドは、リクエストが
IngestAudienceMembersRequestの場合に入力されます。オーディエンス データのタイプごとに確認する
IngestAudienceMembersStatus フィールドは次のとおりです。これらのフィールドのうち 1 つ のみが設定されます。
user_data_ingestion_statusIngestUserDataStatusのrecord_countを確認して、受信したレコードの合計 数が想定どおりであることを確認します。record_countには、成功したレコードと失敗したレコードの両方が含まれます。user_identifier_countを確認して、受信した ユーザー識別子の数が想定どおりであることを確認します。リクエストに十分な数のレコードが含まれている場合、
upload_match_rate_rangeにはリクエスト内のレコードの 一致率 範囲 が含まれます。mobile_data_ingestion_statusIngestMobileDataStatusのrecord_countを確認して、 受信したレコードの合計数が想定どおりであることを確認します。record_countには、成功したレコードと失敗したレコードの両方が含まれます。mobile_id_countを確認して、受信したモバイル ID の数が想定どおりであることを確認します。pair_data_ingestion_statusIngestPairDataStatusのrecord_countを確認して、受信したレコードの合計 数が想定どおりであることを確認します。record_countには、成功したレコードと失敗したレコードの両方が含まれます。pair_id_countを確認して、受信した PAIR ID の数が想定どおりであることを確認します。ppid_data_ingestion_statusIngestPpidDataStatusのrecord_countを確認して、受信したレコードの合計 数が想定どおりであることを確認します。record_countには、成功したレコードと失敗したレコードの両方が含まれます。ppid_countを確認して、受信した PPID の数が想定どおりであることを確認します。user_id_data_ingestion_statusIngestUserIdDataStatusのrecord_countを確認して、受信したレコードの合計 数が想定どおりであることを確認します。record_countには、成功したレコードと失敗したレコードの両方が含まれます。user_id_countを確認して、受信したユーザー ID の数が想定どおりであることを確認します。composite_data_ingestion_statusIngestCompositeDataStatusのrecord_countを確認して、 受信したレコードの合計数が想定どおりであることを確認します。record_countには、成功したレコードと失敗したレコードの両方が含まれます。data_type_countsを確認して、識別子の数が想定どおりであることを確認します。このリストには、DataTypeが受信したすべての識別子（メールアドレス、電話番号、住所、IP アドレスなど）の内訳が記載されています。リクエストに十分な数のレコードが含まれている場合、
upload_match_rate_rangeにはリクエスト内のレコードの 一致率 範囲 が含まれます。
オーディエンス メンバーの削除ステータス
audience_members_removal_status フィールドは、リクエストが
RemoveAudienceMembersRequestの場合に入力されます。オーディエンス データのタイプごとに確認する
RemoveAudienceMembersStatus フィールドは次のとおりです。これらのフィールドのうち 1 つ のみが設定されます。
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 データを復号化できない場合、有効な Event には ad_identifiers または user_data のいずれかが少なくとも 1 つ必要であるため、Data Manager API はレコード全体を拒否し、エラー PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR を報告します。
警告とエラーの情報を含むレスポンス フィールドは次のとおりです。これらの
フィールドは、宛先の全体的なステータス
が SUCCESS、PARTIAL_SUCCESS、または FAILURE になると入力されます。
warning_infoWarningCountオブジェクトのリスト。各WarningCountには、警告のタイプを示すreasonと、そのタイプの警告があったレコードの数を示すrecord_countが含まれています。error_infoErrorCountオブジェクトのリスト。各ErrorCountには、エラーのタイプを示すreasonと、そのタイプのエラーが原因で失敗したレコードの数を示すrecord_countが含まれています。