このガイドでは、アプリの効率とパフォーマンスを最適化するために実装できるベスト プラクティスについて説明します。
アプリのメンテナンス
アプリが中断なく実行されるようにするには、次のことを行います。
Google Cloud プロジェクトのオーナーと編集者のリストが最新の状態であることを確認します。緊急時や API 利用規約の遵守に関するトピックについては、これらのユーザーに連絡します。API 利用規約の遵守についてお客様にご連絡できない場合、API アクセスが制限または取り消される可能性があります。
プロダクトの変更、メンテナンスによるダウンタイム、および 非推奨の日付などの問題について通知を受け取るには、API ブログと プロダクト ブログを購読してください。
アプリが Google Ads API 利用規約（ T&C）に準拠していることを確認します。必要に応じて、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 を使用して開発を開始できます。