Data Manager API を使用する際は、次のベスト プラクティスを念頭に置いてください。
すべてのユーザー識別子を送信する
UserData を使用してオーディエンス メンバーまたはイベントを送信する場合は、同じタイプの複数の識別子を送信するなど、できるだけ多くの user_identifiers を含めます。
たとえば、ユーザーに複数のメールアドレスがある場合は、メールアドレスごとに個別の UserIdentifier を含めます。同様に、ユーザーに異なるタイプの識別子（メールアドレス、電話番号、住所など）がある場合は、識別子ごとに個別の UserIdentifier を追加します。追加できる識別子の数は、最大識別子数までです。
リクエストを最適化する
1 日あたりのリクエスト数の上限を超える可能性を減らすには、各リクエストでできるだけ多くのアイテムをバッチ処理します（リクエストごとの上限まで）。
たとえば、10,000 人のオーディエンス メンバーをオーディエンスに追加する場合は、1 つの IngestAudienceMembersRequest の audience_members リストに 10,000 人のメンバーをすべて追加します。10,000 人のメンバーを 1 つのリクエストにまとめてバッチ処理する方が、各オーディエンス メンバーを追加するリクエストを個別に送信するよりも効率的です。
同時リクエストを送信する
データの取り込みに必要な全体的な時間を短縮するには、IngestionService に同時リクエストを送信します。1 分あたりのリクエスト数の上限を超えないように、同時に送信するリクエストは 10 件までにすることをおすすめします。
リクエストに同じ destinations が含まれている場合でも、同時リクエストを送信できます。
validateOnly を使用して、ファストフェイル エラーを確認する
validateOnly を true に設定してリクエストを送信し、ファストフェイル エラーをキャッチします。Data Manager API は、通常のリクエストと同じ検証チェックを実行しますが、データの取り込みや削除は行いません。
検証のみのリクエストが成功しても、処理中にエラーが発生しないとは限りません。通常のリクエストを送信した後も、診断の確認を続けてください。
診断結果を確認
各 IngestAudienceMembersResponse または IngestEventsResponse から request_id をキャプチャして収集し、リクエスト ID を使用して診断を確認します。
割り当てのモニタリングとアラート
予期しないリクエストの拒否を回避するには、Google Cloud コンソールで割り当てアラートとモニタリングを設定します。割り当て使用量をモニタリングすると、アプリケーションが1 日あたりの上限または 1 分あたりの上限に達する前に、消費パターンを追跡してリクエストのバッチ処理を最適化できます。
本番環境にデプロイする
ローカルテストから本番環境のワークロードに移行する場合は、サービス アカウントまたは Workload Identity 連携が関連付けられたアプリケーションのデフォルト認証情報を使用して、非対話型で安全に認証します。
さまざまな本番環境の認証を構成する方法については、本番環境にデプロイするをご覧ください。