イベントとオーディエンスのアップロードの健全性を確認し、データに関する問題を特定するためのおすすめのワークフローは次のとおりです。
- イベントの送信、オーディエンス メンバーの送信または削除のリクエストを発行します。
- 各
IngestEventsResponse、IngestAudienceMembersResponse、またはRemoveAudienceMembersResponseからrequest_idをキャプチャします。 - 各
request_idに対してRetrieveRequestStatusリクエストを送信します。 - 各
RetrieveRequestStatusResponseを確認して、アップロードが正しく機能していることを確認し、データに関する問題を特定します。 - データの問題を修正します。
- 手順 1 に戻り、アップロードに関するすべての問題に対処するまで繰り返します。
リクエストを作成する
RetrieveRequestStatusRequest には 1 つの request_id フィールドがあります。取り込みリクエストの送信時にキャプチャしたリクエスト ID ごとに 1 つのリクエストを送信します。
回答を確認する
RetrieveRequestStatusResponse の request_status_per_destination には、対応する取り込みリクエストの各宛先のエントリが個別に含まれています。
たとえば、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 には、成功したレコードと失敗したレコードの両方が含まれます。
オーディエンス メンバーの取り込みステータス
リクエストが IngestAudienceMembersRequest の場合、audience_members_ingestion_status フィールドに値が入力されます。各タイプのオーディエンス データを確認する IngestAudienceMembersStatus フィールドは次のとおりです。これらのフィールドの 1 つのみが設定されます。
user_data_ingestion_statusIngestUserDataStatusのrecord_countを確認して、受信したレコードの合計数が想定どおりであることを確認します。record_countには、成功したレコードと失敗したレコードの両方が含まれます。user_identifier_countを確認して、受け取ったユーザー ID の数が想定どおりであることを確認します。リクエストに十分な数のレコードが含まれている場合、
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 の数が想定どおりであることを確認します。
オーディエンス メンバーの削除ステータス
リクエストが RemoveAudienceMembersRequest の場合、audience_members_removal_status フィールドに値が入力されます。各タイプのオーディエンス データを確認する RemoveAudienceMembersStatus フィールドは次のとおりです。これらのフィールドの 1 つのみが設定されます。
user_data_removal_status- ユーザーデータの削除ステータス。
mobile_data_removal_status- モバイルデータの削除ステータス。
pair_data_removal_status- PAIR データの削除ステータス。
record_count を確認して、受信したレコードの合計数が想定どおりであることを確認します。record_count には、成功したレコードと失敗したレコードの両方が含まれます。
また、user_identifier_count、mobile_id_count、pair_id_count を確認して、受信したユーザー識別子、モバイル ID、PAIR ID の合計数を確認します。
警告とエラーを確認する
宛先とリクエスト タイプのステータス フィールドに加えて、RetrieveRequestStatusResponse にはリクエストの警告とエラーの内訳が含まれています。
- エラーは、API がレコードを完全に拒否したことを示します。
- 警告は、API がレコードを拒否しなかったものの、レコードのデータの一部を無視する必要があったことを示します。
たとえば、Event に暗号化された UserIdentifier データと AdIdentifiers（gclid など）が含まれており、UserIdentifier データを復号できない場合でも、データマネージャー API は AdIdentifiers を使用してレコードを処理しますが、警告 PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR を返します。
ただし、Event に AdIdentifiers が含まれておらず、UserIdentifier データを復号できない場合、有効な Event には ad_identifiers または user_data のいずれかが含まれている必要があるため、Data Manager API はレコード全体を拒否し、エラー PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR を報告します。
警告とエラーの情報を含むレスポンス フィールドは次のとおりです。
warning_infoWarningCountオブジェクトのリスト。各WarningCountには、警告のタイプを含むreasonと、そのタイプの警告が発生したレコードの数を示すrecord_countが含まれます。error_infoErrorCountオブジェクトのリスト。各ErrorCountには、エラーのタイプを示すreasonと、そのタイプのエラーが原因で失敗したレコードの数を示すrecord_countが含まれます。