動画: 2019 年のワークショップのベスト プラクティスに関する講演をご覧ください
この実践ガイドでは、アプリケーションの効率とパフォーマンスを最適化する方法をご紹介します。
継続的なメンテナンス
アプリケーションが中断なく実行されるようにするには:
API センターに登録されているデベロッパーの連絡先メールアドレスを最新の状態に保ちましょう。このメールアドレスは、API センターから連絡を取るために使用されます。API 利用規約の遵守に関して連絡が取れない場合、事前の通知なしに API へのアクセスを無効にさせていただく場合があります。個人のアカウントや普段チェックしていないアカウントに結び付けられた個人用メールアドレスの使用は避けてください。API センターを表示するには、MCC アカウントにログインする必要があります。
サービスの変更、メンテナンスによるダウンタイム、サポート終了日などの情報を受け取るため、次のコンテンツにご登録ください。
フォーラムは、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 エラーの傾向を確認するようにしましょう。独自のソリューションの構築、またはログを使用したインタラクティブなダッシュボードの作成やアラートの自動送信を可能にする市販ツールの導入を検討してください。
開発
開発中はテスト アカウントを使用します。
テスト アカウントを使用する
テスト アカウントは、実際には広告を配信しない Google 広告アカウントです。テスト アカウントを使用すると、Google Ads API をテストしたり、アプリケーションの接続、キャンペーン管理ロジック、その他の処理が期待どおりに動作するかどうかをテストしたりすることができます。テスト アカウントでは開発者トークンの承認は不要なため、開発者トークンをリクエストした後、アプリケーションがまだ審査されていなくても、すぐに Google Ads API を使った開発を開始できます。