ベスト プラクティス
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このページでは、Google Ad Manager API を使ったアプリケーションを開発する際に考慮すべきさまざまなおすすめの方法について説明します。
実行中にサービス クライアント/スタブを再利用する
新しいサービス クライアント/スタブの作成には、WSDL の取得とリソースの割り当てに関連する限界コストがかかります。可能であれば、実行の開始時にサービス クライアント/スタブを 1 回作成し、必要に応じてクラスと関数で使用できるようにします。
オブジェクトの取得時にページングを使用する
すべてのサービスは get*ByStatement() メソッドをサポートしています。これにより、PQL 構文を使用して結果をフィルタリングできます。LIMIT 句と OFFSET 句を使用すると、サイズの大きい結果セットをページに分割できます。これにより、タイムアウトを防ぎ、レスポンスのページサイズを適度に保つことができます。推奨されるページサイズは 200 ～ 500 で、オブジェクトの複雑さによって異なります。
バッチ アップデート リクエスト
同じタイプの複数のオブジェクトを変更する場合は、同じ update*() リクエストですべてのオブジェクトを送信することで、パフォーマンスを向上させることができます。リクエストごとにクライアントとサーバーでわずかなオーバーヘッドがあるため、バッチ処理はリクエスト数を減らす効果的な手段です。たとえば、updateOrders を使用して、呼び出しごとに 1 つの注文ではなく、注文のバッチを更新します。
PQL でバインド パラメータを使用する
バインド パラメータは、PQL クエリ ステートメントに変数を入れる方法です。PQL では、コロンで始まるスペースを含まない名前でバインド変数を参照します。例::name。コード例については、PQL 構文のページをご覧ください。
バインド変数を使用することをおすすめします。バインド変数を使用すると、文字列と変数をクエリ ステートメントに連結する必要がないため、コードが読みやすくなります。また、バインド パラメータ値を置換することで新しいクエリを作成できるため、PQL ステートメントの再利用が容易になります。
ユーザー権限は慎重に付与する
UserService を使用してユーザーロールを作成または更新するときは、不要な権限をユーザーに付与しないように注意してください。ユーザーに管理者ロールを割り当てるのではなく、ロールの組み合わせで API の多くの機能にアクセスできます。ユーザーに割り当てるロールを決定する際は、権限に関するドキュメントをご覧ください。また、サードパーティ アプリケーション デベロッパーは、ネットワークにユーザーの作成を依頼する際に、アプリケーションに必要なアクセスレベルを決定しておく必要があります。管理者よりも権限の少ない役割で十分な場合もあります。
割り当て上限を超えないようにする
Ad Manager API では、堅牢性を確保するためにいくつかの割り当て上限が適用されます。アプリケーションをこれらの上限内に収め、API が返す割り当てエラーへの対処方法を理解しておくことが重要です。
API 割り当て
API リクエストに適用される最初の割り当ては、ネットワーク レベルの割り当てです。リクエスト数の上限は、アド マネージャー 360 アカウントの場合は 1 秒あたり 8 件、アド マネージャー アカウントの場合は 1 秒あたり 2 件です。この上限を超えると、
QuotaError.EXCEEDED_QUOTA エラーが発生します。ネットワーク上で行われたすべての API リクエストは、この割り当てに適用されます。これには、ユーザーまたは社内の他のユーザーがネットワークへの API アクセスを許可したサードパーティ アプリケーションも含まれます。
システム固有の割り当て
アド マネージャー内でリソースを大量に消費するシステムを適切に保護するには、API の割り当てだけでは不十分です。レポート作成システムと予測システムでは、API エラーを引き起こす可能性がある独自の割り当て（それぞれ
QuotaError.REPORT_JOB_LIMIT と
ForecastError.EXCEEDED_QUOTA）が定義されています。
割り当てエラーの処理
アプリケーションで上記の割り当てエラーが発生した場合は、API リクエストを再試行してください。最初は少なくとも 5 秒間待機し、エラーが続く場合は
指数バックオフを使用して再試行間隔を長くすることをおすすめします。再試行が成功しない場合は、API アプリケーションの監査を実行して、ネットワーク上のユーザーが割り当てを消耗していないかどうかを確認します。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-21 UTC。
[null,null,["最終更新日 2025-08-21 UTC。"],[[["\u003cp\u003eThis page provides best practices for developing applications using the Google Ad Manager API to enhance performance and efficiency.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers should reuse service clients, use paging for large data sets, and batch update requests to optimize interactions with the API.\u003c/p\u003e\n"],["\u003cp\u003ePQL bind parameters are recommended for improved code readability and reusability, while user privileges should be granted judiciously.\u003c/p\u003e\n"],["\u003cp\u003eAd Manager API enforces quota limits; developers should implement strategies to handle quota errors and stay within allowed usage.\u003c/p\u003e\n"]]],["Optimize Google Ad Manager API usage by reusing service clients, creating them once per execution. When retrieving objects, use paging with `LIMIT` and `OFFSET` clauses, aiming for 200-500 items per page. For updates, batch multiple objects in a single request. Employ bind parameters in PQL for readability and reusability. Grant user privileges sparingly, avoiding unnecessary administrative roles. Respect quota limits, implementing retry strategies with exponential backoff, particularly for reporting and forecast requests.\n"],null,["# Best Practices\n\nThis page covers various best practices that should be considered when\ndeveloping applications against the Google Ad Manager API.\n\n- [Reuse service clients/stubs during the course of an execution](#ReuseServices)\n- [Use paging when fetching objects](#UsePaging)\n- [Batch update requests](#BatchUpdate)\n- [Store the Ad Manager API client object when appropriate](#StoreDfpUser)\n- [Use bind parameters in PQL](#UseBindParameter)\n- [Grant user privileges sparingly](#GrantUserPrivilegesSparingly)\n\n### Reuse service clients/stubs during the course of an\nexecution\n\nCreating a new service client/stub has a marginal cost associated with\nfetching the WSDL and allocating resources. If possible, create the service\nclient/stub once at the beginning of an execution and make it available to\nclasses and functions as needed.\n\n### Use paging when fetching objects\n\nAll of the services support a `get*ByStatement()` method, which\nallows for the filtering of results using [PQL](/ad-manager/api/pqlreference)\nsyntax. The `LIMIT` and `OFFSET` clauses can be used to\nsplit large result sets into pages, preventing time outs and keeping the\nresponse page sizes reasonable. The suggested page size is 200-500, depending\non the complexity of your objects.\n\n### Batch update requests\n\nWhen changing multiple objects of the same type, you can get better\nperformance by sending all of the objects in the same `update*()`\nrequest. There is a marginal overhead on the client and the server for each\nrequest, and batching can be an effective means of reducing the number of\nrequests. For example, use [`updateOrders`](/ad-manager/api/reference/latest/OrderService#updateOrders)\nto update a batch of [Orders](/ad-manager/api/reference/latest/OrderService.Order)\nrather than a single order in each call.\n\n### Use bind parameters in PQL\n\nBind parameters are a way to put variables into a PQL query statement. PQL\nrefers to a bind variable by a name without spaces starting with a colon,\ne.g., `:name`. A code example is provided in the [PQL syntax](/ad-manager/api/pqlreference#syntax) page.\n\nWe recommend using bind variables because they improve code readability by\nremoving the need to concatenate strings and variables into a query statement.\nThey also make it easy to reuse PQL statements, since new queries can be made\nby substituting the bind parameter values.\n\n### Grant user privileges sparingly\n\nWhen using [UserService](/ad-manager/api/reference/latest/UserService) to\ncreate/update user roles, be careful not to grant users privileges they do not\nneed. Many features of the API can be accessed with a combination of roles\nrather than assigning the user an administrator role. Please refer to the [permissions\ndocumentation](//support.google.com/admanager/answer/177403) when deciding which roles to assign a user. Also, as a [third party](/ad-manager/api/third-parties) application developer, make sure to\ndetermine what level of access your application needs when asking a network to\ncreate a user for you; a role with fewer privileges than administrator may be\nenough.\n\n### Stay under quota limits\n\nThe Ad Manager API enforces several quota limits for robustness. It's\nimportant to keep your applications under these limits and that you know how to\nrespond to any of the quota errors the API can return.\n\n#### API quota\n\nThe first quota applied to API requests is a network-level quota. For Ad Manager\n360 accounts, the limit is 8 requests per second, and for Ad Manager accounts,\nthe limit is 2 requests per second. Going beyond this limit results in a\n[`\nQuotaError.EXCEEDED_QUOTA`](/ad-manager/api/reference/latest/LineItemService.QuotaError#reason) error. All API requests made on your\nnetwork apply to this quota, including third-party applications that you or\nsomeone at your company has granted API access to your network.\n\n#### System-specific quotas\n\nThe API quota alone is not enough to adequately protect certain\nresource-intensive systems within Ad Manager. The reporting and forecast systems\ndefine their own quotas that can result in API errors:\n[`\nQuotaError.REPORT_JOB_LIMIT`](/ad-manager/api/reference/latest/ReportService.QuotaError#reason) and [`\nForecastError.EXCEEDED_QUOTA`](/ad-manager/api/reference/latest/ForecastService.ForecastError#reason), respectively.\n\n#### Handling quota errors\n\nIf your application encounters any of the above quota errors, carry out a\nstrategy for retrying the API request. We recommend waiting at least 5 seconds\nfirst, and if you continue to get the error, use [exponential backoff](//cloud.google.com/storage/docs/exponential-backoff#example_algorithm) to increase the time between retries. If retrying\ndoesn't succeed, perform an audit of your API applications to see if any users\non your network are draining your quota."]]
