このガイドでは、アプリの効率とパフォーマンスを最適化するために実装できるベスト プラクティスについて説明します。
アプリをメンテナンスする
アプリが中断されることなく実行されるようにするには、次の操作を行います。
Google Cloud プロジェクトのオーナーと編集者のリストが最新であることを確認します。Google は、緊急事態が発生した場合や、API 利用規約の遵守に関連するトピックがある場合に、これらのユーザーに連絡します。API の利用規約の遵守に関して Google からお客様に連絡できない場合、API へのアクセス権が引き下げられるか、取り消される可能性があります。
プロダクトの変更、メンテナンスによるダウンタイム、サポート終了日などの問題に関する情報を入手するには、API ブログとプロダクト ブログに登録してください。
アプリが Google Ads API の利用規約に準拠していることを確認します。必要に応じて、API コンプライアンス チームが、API アクセス権を持つ Google Cloud プロジェクトのオーナーと編集者に連絡します。利用規約についてご質問やご不明な点がある場合は、API アクセス申請の審査時にコンプライアンス チームから送信されたメールに返信して、コンプライアンス チームにお問い合わせください。
最適化
バッチ オペレーションを実行し、必要に応じてスパース オブジェクトを送信することで、アプリを最適化できます。
バッチ オペレーション
API にリクエストを行うと、ラウンドトリップ ネットワーク レイテンシ、シリアル化とシリアル化解除の処理、バックエンド システムの呼び出しなど、多くの固定費用が発生します。こうした固定費の影響を軽減し、全体的なパフォーマンスを向上させるため、API のほとんどの mutate メソッドは、オペレーションの配列を受け入れるように設計されています。複数のオペレーションを各リクエストにバッチ処理することで、リクエストの数と関連する固定費用を削減できます。可能であれば、1 つのオペレーションのみを含むリクエストは行わないでください。
たとえば、複数の広告グループに渡ってキャンペーンに 50,000 個のキーワードを追加する場合は、1 つのキーワードを含むリクエストを 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 を使用した開発をすぐに開始できます。