このガイドでは、アプリの効率とパフォーマンスを最適化するために実装できるベスト プラクティスをいくつか紹介します。
アプリをメンテナンスする
アプリが中断なく実行されるようにするには、次の操作を行います。
Google Cloud プロジェクトのオーナーと編集者のリストが最新であることを確認します。緊急時や API の利用規約の遵守に関するトピックがある場合は、これらのユーザーに連絡します。API 利用規約の遵守についてご連絡できない場合、API アクセスが制限または取り消されることがあります。
プロダクトの変更、メンテナンスのダウンタイム、サポート終了日などの問題について通知を受け取るには、API ブログとプロダクト ブログを購読してください。
アプリケーションは Google Ads API の利用規約に準拠している必要があります。必要に応じて、API コンプライアンス チームから、API アクセス権を持つ Google Cloud プロジェクトのオーナーと編集者に連絡します。利用規約についてご不明な点やご懸念がある場合は、API アクセス申請の審査時にコンプライアンス チームから送信されたメールに返信して、コンプライアンス チームにお問い合わせください。
最適化
バッチ オペレーションを実行し、必要に応じてスパース オブジェクトを送信することで、アプリを最適化できます。
バッチ オペレーション
API にリクエストを行うには、ネットワーク ラウンド トリップ レイテンシ、シリアル化とシリアル化解除の処理、バックエンド システムの呼び出しなど、多くの固定費用が発生します。これらの固定費の影響を軽減し、全体的なパフォーマンスを向上させるため、API のほとんどの mutate メソッドは、オペレーションの配列を受け入れるように設計されています。複数のオペレーションを各リクエストにバッチ処理することで、リクエストの数と関連する固定費を削減できます。可能であれば、1 つのオペレーションのみを含むリクエストは避けてください。
たとえば、複数の広告グループに渡ってキャンペーンに 50,000 個のキーワードを追加する場合は、キーワードごとにリクエストを 50,000 回行うのではなく、キーワードを 500 個ずつに分けて 100 回のリクエストを、またはキーワードを 5,000 個ずつに分けて 10 回のリクエストを行います。リクエストで許可されるオペレーションの数には上限があるため、最適なパフォーマンスを実現するにはバッチサイズを調整する必要がある場合があります。
スパース オブジェクトを送信する
オブジェクトが API に送信されると、フィールドは逆シリアル化、検証され、データベースに保存されます。いくつかのフィールドのみを更新する場合にオブジェクト全体を渡すと、処理時間が長くなり、パフォーマンスが低下する可能性があります。この問題を軽減するため、Google Ads API はスパース更新をサポートしています。これにより、変更する必要があるオブジェクトのフィールドまたは必須のフィールドのみを入力できます。スパース アップデートは処理が速く、エラーが発生しにくいです。update_mask（FieldMask）にないフィールドは変更されません。
たとえば、キーワード単位で入札単価を更新するアプリケーションでは、値を入れる必要のあるフィールドが広告グループ ID、条件 ID、入札単価に限られるため、スパース アップデートが役に立ちます。
エラー処理と管理
開発にはエラーがつきものです。このセクションでは、アプリにエラー管理を組み込む際の考慮事項と戦略について説明します。エラーの管理について詳しくは、トラブルシューティング ガイドもご覧ください。
リクエスト ソースを区別する
一部のアプリは主にインタラクティブで、UI でユーザーが開始したアクションに応じて API 呼び出しを直接発行します。他のユーザーは主にオフラインで作業し、定期的なバックエンド プロセスの一部として API 呼び出しを発行します。この 2 つを組み合わせたアプリも多くあります。エラー管理を考えるうえで、これらのさまざまなタイプのリクエストを区別すると便利です。
ユーザーが開始するリクエストの場合、ユーザーの利便性を最優先にする必要があります。発生した特定のエラーを使用して、UI でユーザーにできるだけ多くのコンテキストを提供します。エラーを解決するためにユーザーが実行できる明確な手順を提示します（以下の提案を参照）。
バックエンドで開始されたリクエストについては、アプリで発生する可能性のあるさまざまなタイプのエラーのハンドラを実装します。あまり発生しないエラーや過去に例のないエラーを処理するためのデフォルト ハンドラを必ず用意してください。デフォルト ハンドラでは、オペレーターが確認して適切な解決策を判断できるよう、失敗したオペレーションや発生したエラーをキューに追加すると便利です。
エラータイプを区別する
堅牢なエラー処理を構築するうえで、Google Ads API のエラータイプ間の違いを把握することは非常に重要です。最も一般的なエラー メッセージは次のとおりです。
バックエンドを同期する
アプリケーションのユーザーが Google 広告アカウントに直接アクセスできる場合、ユーザーが行った変更をアプリケーションで認識できず、ローカル データベースの同期が失われる場合があります。エラータイプに記載されているとおり、同期関連のエラーの発生後に対処することはできますが、事前に防ぐのもよいでしょう。事前対応策の 1 つとして、定期的な同期ジョブを実行して、ローカル データベースとアカウントの Google 広告オブジェクトを調整します。大規模なアカウント階層の場合は、毎晩すべてのアカウントのすべてのオブジェクトをプルして 1 日の割り当てを使い切らないようにします。代わりに、ChangeStatus をクエリするか、最近変更されたエンティティをフィルタして、変更を増分的に同期します。
ログのエラー
デバッグと確認を容易にするため、エラーはすべてログに記録しておく必要があります。少なくとも、リクエスト ID、エラーの原因となったオペレーション、エラー自体をログに記録します。ログに記録するその他の情報には、顧客 ID、API サービス、リクエストの往復レイテンシ、再試行回数、サニタイズされた未加工のリクエストとレスポンス（OAuth トークン、デベロッパー トークンなどの機密性の高い認証情報が以前のリクエスト ヘッダーに含まれている場合は、必ず削除してください。また、PII も削除してください）などがあります。
傾向を確認する
API エラーの傾向をモニタリングして、アプリの問題を検出して対処できるようにしてください。独自のソリューションを構築するか、ログを使用してインタラクティブなダッシュボードを作成し、自動アラートを送信できる市販のツールを多数利用することを検討してください。
開発
開発中はテスト アカウントを使用します。
テスト アカウントを使用する
テスト アカウントは、実際に広告を配信しない Google 広告アカウントです。テスト アカウントを使用すると、Google Ads API を試して、アプリの接続、キャンペーン管理ロジック、その他の処理が想定どおりに動作していることをテストできます。テスト アカウントで使用するには、Google Cloud プロジェクトにテスト アクセス権のみが必要です。そのため、Google がより高い API アクセスレベルのアプリケーションを審査している間、すぐに Google Ads API を使った開発を開始できます。