診断

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

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

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

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

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

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

    各宛先の宛先 ステータスがSUCCESS、 PARTIAL_SUCCESS、またはFAILUREになるまで、request_idごとにこの手順を定期的に繰り返します。各リクエストの間隔を空けるには、指数バックオフ アルゴリズムを使用します。

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

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

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

リクエストの送信

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

承認

RetrieveRequestStatusRequest は、宛先 アカウントまたはリクエスト ヘッダーを受け付けません。代わりに、Data Manager API は、 元の取り込みリクエストから宛先を特定し、 request_id に関連付けられた呼び出し元が各 Destination の operating_account にアクセスできることを確認します。

リクエストのステータスを確認するには、a RetrieveRequestStatusRequest で使用される認証情報が、元の 取り込みリクエストの各宛先の operating_account に関して次の 要件を満たしている必要があります。

  • 同一のアクセスパス: 認証情報には、元の取り込みリクエストで指定されたまったく同じアクセスパスを使用して、各 operating_accountにアクセスできる必要があります。

    たとえば、Google 広告の operating_account の取り込みリクエストで、親のクライアント センター（MCC）アカウントが login_account として指定されている場合、認証情報にはその MCC アカウントを介して operating_account にアクセスできる必要があります。認証情報に関連付けられた Google アカウントが子 operating_account に直接アクセスできる場合でも、取り込み時に指定された login_account MCC アカウントを介してそのアカウントにアクセスできない場合、リクエストは PERMISSION_DENIED エラーで失敗します。

  • 十分なアクセスレベル: 認証情報に関連付けられた Google アカウントには、データを取り込む 権限を持つアクセスレベルまたはロールが必要です。operating_account

    たとえば、Google 広告では、Google アカウントに 管理者 または 標準 アクセスレベルが必要です。 読み取り専用 のアクセスレベルのアカウントの認証情報を使用したリクエストは、PERMISSION_DENIED エラーで失敗します。

ポーリング戦略

元のリクエストのすべての宛先で 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 つのエントリが含まれていて、destinations3 つの異なる オーディエンスにデータを送信する場合、ステータス レスポンスの request_status_per_destination には 3 つのエントリ（オーディエンスごとに 1 つのエントリ）が含まれます。

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

まず、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 つだけが設定されます。

composite_data_ingestion_status

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

data_type_counts を確認して、識別子の数が想定どおりであることを確認します。このリストには、受信したすべての 識別子（メールアドレス、電話番号、住所、IP アドレスなど）がDataTypeごとに分類されています。

リクエストに十分な数のレコードが含まれている場合、 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 の数が想定どおりであることを確認します。

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

audience_members_removal_status フィールドは、リクエストが RemoveAudienceMembersRequestの場合に入力されます。オーディエンス データのタイプごとに確認する 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 を確認して、識別子の数が想定どおりであることを確認します。このリストには、受信したすべての 識別子（メールアドレス、電話番号、住所、 IP アドレスなど）が DataTypeごとに分類されています。

警告とエラーを確認する

宛先とリクエストのタイプのステータス フィールドに加えて、 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

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

宛先の全体的な ステータスが SUCCESS であっても、warning_info を確認してください。

error_info

An ErrorInfo オブジェクト。その error_counts フィールドには、ErrorCount オブジェクトのリスト が含まれています。各 ErrorCount には、エラーのタイプを示す reason と、そのタイプのエラーが原因で失敗したレコードの数を示す record_count が含まれています。