診断

イベントとオーディエンスのアップロードの健全性を確認し、データに関する問題を特定するためのおすすめのワークフローは次のとおりです。

1. イベントの送信、オーディエンス メンバーの追加または削除のリクエストを発行します。

2. 各リクエストの全体的なステータスを確認します。リクエストが成功すると、code が 0（列挙値 OK、HTTP レスポンス 200 OK）に等しい Status が返され、IngestEventsResponse、IngestAudienceMembersResponse、または RemoveAudienceMembersResponse が返されます。

   リクエストが成功しなかった場合は、エラーに対処するようにリクエストを変更して、リクエストを再度送信します。

   リクエストが成功した場合は、レスポンスの request_id をキャプチャして、次のステップで診断情報を取得できるようにします。

3. 30 分待ってから、成功した request_id ごとに RetrieveRequestStatus リクエストを送信します。

   各宛先の宛先ステータスが SUCCESS、PARTIAL_SUCCESS、または FAILURE に達するまで、各 request_id に対してこの手順を定期的に繰り返します。指数バックオフ アルゴリズムを使用して、各リクエスト間の待機時間を設定します。

4. 各 RetrieveRequestStatusResponse を確認して、アップロードが正しく機能していることを確認し、データに関する問題を特定します。

5. データの問題を修正します。

6. ステップ 1 に戻り、アップロードに関するすべての問題に対処するまで繰り返します。

リクエストの送信

RetrieveRequestStatusRequest には 1 つの request_id 値が必要です。取り込みリクエストが成功したときに取得したリクエスト ID ごとに、個別のステータス リクエストを送信します。

元のリクエストのすべての宛先で request_status が SUCCESS、FAILURE、または PARTIAL_SUCCESS に達するまで、指数バックオフ アルゴリズムを使用して RetrieveRequestStatusRequest を定期的に送信します。24 時間ほどかかることがあります。ただし、Data Manager API では、リクエストの処理が 30 分ほどで完了することもあります。

以下に、ライブネスと割り当て使用量のバランスを取る適切な初期待機時間と再試行構成の例を示します。

設定	値
最初の診断リクエストまでの待機時間（分）	30
バックオフ乗数	1.3
バックオフの最大値（分）	60（1 時間）
最大合計時間（分）	1440（24 時間）

この構成でのリクエストと経過時間のシーケンスは次のとおりです。

バックオフ遅延にランダムなジッターを少し追加して、多くのクライアントが同時に再試行する「サンダリング ハード」の問題を防ぎます。

回答を確認する

RetrieveRequestStatusResponse の request_status_per_destination には、対応する取り込みリクエストの宛先ごとに個別のエントリが含まれています。

たとえば、IngestAudienceMembersRequest に 3 つの異なるオーディエンスにデータを送信する destinations リストのエントリが 3 つ含まれている場合、ステータス レスポンスの request_status_per_destination には 3 つのエントリ（オーディエンスごとに 1 つのエントリ）が含まれます。

宛先の全体的なステータスを確認する

まず、request_status フィールドを調べて、Data Manager API が RequestStatusPerDestination の destination のデータを処理し終えたかどうかを確認します。

request_status に指定できる値は次のとおりです。

• PROCESSING: 宛先のデータがまだ処理中です。このステージでは、宛先の警告とエラーは入力されません。

• SUCCESS: 宛先の処理がエラーなしで完了しました。処理中にフラグが設定された警告を確認します。

• FAILURE: エラーのため、宛先のすべてのレコードが失敗しました。警告とエラーを確認して、すべてのレコードが失敗した理由を特定します。処理中にフラグが設定された警告も確認します。

• PARTIAL_SUCCESS: 一部のレコードは成功しましたが、エラーにより失敗したレコードもあります。[エラーを確認] をクリックして、一部のレコードが失敗した理由を確認します。処理中にフラグが付けられた警告も確認します。

宛先ごとにイベントまたはオーディエンスのステータスを確認する

取り込みリクエストのタイプに対応するステータス フィールドを調べます。各 RequestStatusPerDestination に設定されるのは、次のフィールドのうち 1 つのみです。

• 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 フィールドは次のとおりです。これらのフィールドのうち 1 つのみが設定されます。

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 を確認して、受け取ったペア 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 を確認して、受け取ったユーザー ID の数が想定どおりであることを確認します。

リクエストに十分な数のレコードが含まれている場合、upload_match_rate_range にはリクエスト内のレコードの一致率の範囲が含まれます。

user_id_data_ingestion_status

IngestUserIdDataStatus の record_count を確認して、受け取ったレコードの合計数が想定どおりであることを確認します。record_count には、成功したレコードと失敗したレコードの両方が含まれます。

user_id_count を確認して、受け取ったユーザー ID の数が想定どおりであることを確認します。

オーディエンス メンバーの削除ステータス

リクエストが RemoveAudienceMembersRequest の場合、audience_members_removal_status フィールドが入力されます。各タイプのオーディエンス データで確認する RemoveAudienceMembersStatus フィールドは次のとおりです。これらのフィールドのうち 1 つのみが設定されます。

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 データを復号できない場合、有効な Event には ad_identifiers または user_data のいずれかが少なくとも 1 つ含まれている必要があるため、Data Manager API はレコード全体を拒否し、エラー PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR を報告します。

警告とエラーの情報を含むレスポンス フィールドは次のとおりです。これらのフィールドには、宛先の全体的なステータスが SUCCESS、PARTIAL_SUCCESS、または FAILURE に達したときにデータが入力されます。

warning_info

WarningCount オブジェクトのリスト。各 WarningCount には、警告のタイプを示す reason と、そのタイプの警告があったレコードの数を示す record_count が含まれています。

コピー先全体のステータスが SUCCESS であっても、warning_info を確認します。

error_info

ErrorCount オブジェクトのリスト。各 ErrorCount には、エラーの種類を示す reason と、その種類のエラーが原因で失敗したレコードの数を示す record_count が含まれています。