動画: 2019 年のワークショップでのベスト プラクティスの紹介
この実践ガイドでは、アプリケーションの効率とパフォーマンスを最適化する方法をご紹介します。
継続的なメンテナンス
アプリケーションが中断なく実行されるようにするには:
API センターでデベロッパーの連絡先メールアドレスを最新の状態に保ちます。Google からの連絡にはこのエイリアスを使用します。API 利用規約の遵守に関して連絡が取れない場合、事前の通知なしに API へのアクセスを無効にさせていただく場合があります。個人のアカウントや普段チェックしていないアカウントに結び付けられた個人用メールアドレスの使用は避けてください。
サービスの変更、メンテナンスによるダウンタイム、サポート終了日などの情報を受け取るため、次のコンテンツにご登録ください。
フォーラムは、API に関する質問を投稿するには最適な場所です。Google Ads API チームが定期的に確認します。
- アプリが Google Ads API の利用規約に準拠するようにしてください。必要に応じて、トークン審査およびコンプライアンス チームから連絡先メールアドレスにご連絡します。利用規約についてご質問やご不明な点がある場合は、開発者トークン アプリケーションの承認審査の際に送信されたメールに返信して審査チームにお問い合わせください。
最適化
オペレーションをバッチ処理する
API へのリクエストには、往復ネットワーク遅延、シリアライゼーション処理、デシリアライゼーション処理、バックエンド システムの呼び出しなどの多くの固定費用が発生します。このような固定費用の発生を減らし、全体的なパフォーマンスを向上するため、API の mutate メソッドの大部分が、オペレーションの配列を受け取るよう設計されています。複数のオペレーションを 1 つのリクエストにまとめてバッチ処理すると、リクエストの数を減らして関連する固定費用を下げることができます。可能であれば、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 広告アカウントに直接アクセスできる場合、ユーザーが行った変更をアプリケーションで認識できず、ローカル データベースの同期が失われる場合があります。エラータイプに記載されているとおり、同期関連のエラーの発生後に対処することはできますが、事前に防ぐのもよいでしょう。たとえば、毎晩、すべてのアカウントで同期ジョブを実行し、アカウントの Google 広告オブジェクトを取得してローカル データベースと比較します。
エラーをログに記録する
デバッグと確認を容易にするため、エラーはすべてログに記録しておく必要があります。少なくとも、リクエスト ID、エラーが発生したオペレーション、エラー自体は記録し、それ以外にも、お客様 ID、API サービス、往復リクエスト遅延、試行回数、未処理のリクエストとレスポンスなどの情報を記録します。
傾向を確認する
アプリの問題を検出して対処できるように、API エラーの傾向を必ずモニタリングしてください。独自のソリューションを構築するか、ログを使用してインタラクティブなダッシュボードを作成し、自動アラートを送信できる多くの市販ツールの 1 つを採用することを検討してください。
開発環境
テスト アカウントを使用する
テスト アカウントは、実際には広告を配信しない Google 広告アカウントです。テスト アカウントを使用すると、Google Ads API をテストしたり、アプリケーションの接続、キャンペーン管理ロジック、その他の処理が期待どおりに動作するかどうかをテストしたりすることができます。テスト アカウントでは開発者トークンの承認は不要なため、開発者トークンをリクエストした後、アプリケーションがまだ審査されていなくても、すぐに Google Ads API を使った開発を開始できます。