Google Ads API では、単一の変更リクエストで送信できるオペレーションの数など、API オペレーションに上限が適用されます。次の表に、注意が必要な重要な上限と割り当ての一部をまとめます。
| リクエスト タイプ、制限、エラーコード | ||
|---|---|---|
| テスト アクセスレベルでのオペレーション | テスト アカウントに対して 1 日あたり 15,000 件の API オペレーション |
RESOURCE_EXHAUSTED
|
| エクスプローラのアクセスレベルでのオペレーション |
本番環境アカウントに対して 1 日あたり 2,880 件の API オペレーション テスト アカウントに対して 1 日あたり 15,000 件の API オペレーション |
RESOURCE_EXHAUSTED
|
| ベーシック アクセスレベルのオペレーション | テスト アカウントと本番環境アカウントの両方で 1 日あたり 15,000 件の API オペレーション |
RESOURCE_EXHAUSTED
|
| 標準アクセスレベルでのオペレーション | テスト アカウントと本番環境アカウントの両方で、1 日あたりの API オペレーション数が無制限 | 該当なし |
| 変更リクエスト | 1 リクエストあたり 10,000 件の変更オペレーション |
TOO_MANY_MUTATE_OPERATIONS
|
| Planning Service のリクエスト | 1 QPS |
RESOURCE_EXHAUSTED
|
| コンバージョン アップロード サービスの依頼 | 2,000 コンバージョン/リクエスト |
TOO_MANY_CONVERSIONS_IN_REQUEST
|
| Billing and Account Budget Service のリクエスト | 変更リクエストごとに 1 つのオペレーション |
TOO_MANY_MUTATE_OPERATIONS
|
1 日あたりの API オペレーション制限
1 日あたりの API 使用量の上限は、Google Cloud プロジェクトで行われた API オペレーションの数に基づいています。API オペレーションは、Search リクエストと SearchStream リクエスト、個々の mutate オペレーション、その他のサービス リクエストの合計です。1 日あたりの API オペレーション数の上限は、Google Cloud プロジェクトの API アクセスレベルによって異なります。アクセスレベルと許容される使用に関するガイドには、各アクセスレベルの特定の API オペレーションの上限が記載されています。
これらの上限に違反するリクエストは、エラー RESOURCE_EXHAUSTED で拒否されます。
gRPC の制限
Google Ads API のすべてのクライアント ライブラリは、リクエストとレスポンスの生成に gRPC を使用します。デフォルトでは、gRPC のメッセージ サイズは 4 MB ですが、クライアント ライブラリでは効率を高めるために最大メッセージ サイズが 64 MB に設定されています。
レスポンスはこの上限を超えてはなりません。たとえば、多くのフィールドを含む検索リクエストでは、サイズが 64 MB を超えるレスポンスが生成されることがあります。この上限を回避するには、選択するフィールドの数を減らすか、ストリーミングを使用します。変更の場合は、リクエストあたりのオペレーション数を減らします。
この制限に違反するリクエストでは、GoogleAdsError は生成されませんが、RESOURCE_EXHAUSTED(gRPC コード 8 / HTTP 429)エラーが生成されます。gRPC のエラーコードとメッセージの一覧をご覧ください。
変更リクエスト
ユーザーの 1 日あたりのオペレーション割り当てにカウントされるだけでなく、1 件のリクエストに含めることができる変更オペレーションの数は 10,000 件までです。この制限に違反するリクエストは、エラー TOO_MANY_MUTATE_OPERATIONS で拒否されます。
特定のサービスとリクエスト タイプに関する追加の上限と考慮事項については、以下をご覧ください。
リクエストを検索
Search リクエストまたは SearchStream リクエストは、ユーザーの 1 日あたりのオペレーション割り当てに対して 1 つのオペレーションとしてカウントされます。1 つの SearchStream リクエストは、バッチ数に関係なく 1 つの API オペレーションとしてカウントされます。
ページ分けリクエスト
ページ分けされたリクエスト(有効な next_page_token を含むリクエストなど)は、ユーザーの 1 日のオペレーション割り当てにカウントされません。ただし、期限切れまたは無効なページトークンを含むページネーション リクエストは例外を生成し、1 日のオペレーション割り当てにカウントされます。
ページ分けの詳細については、結果のページ分けをご覧ください。
その他の種類のリクエスト
Mutate、Search、SearchStream リクエストではないリクエストは、ユーザーの 1 日のオペレーション割り当てに対して 1 つのオペレーションとしてカウントされます。
このようなリクエストの例をいくつか示します。
BatchJobService.ListBatchJobResultsConversionUploadService.UploadCallConversionsConversionUploadService.UploadClickConversionsOfflineUserDataJobService.AddOfflineUserDataJobOperationsOfflineUserDataJobService.CreateOfflineUserDataJobUserDataService.UploadUserData
API 例外を返すリクエスト
GoogleAdsFailure で拒否されたリクエストも、ユーザーの 1 日あたりのオペレーション割り当ての対象となります。
失敗しても GoogleAdsFailure を返さないリクエスト(ネットワーク レベルのエラーなど)は、サービスに到達しないため、ユーザーの 1 日のオペレーション割り当てにカウントされません。この例としては、ネットワーク接続障害があります。
キーワード プランニング サービス
費用と複雑さのため、次のキーワード プランニング サービス メソッドには、他のタイプのリクエストとは異なる上限が適用されます。
CID あたり 1 秒あたり 1 件のリクエストに制限されます。
KeywordPlanIdeaService.GenerateKeywordIdeasKeywordPlanIdeaService.GenerateKeywordHistoricalMetricsKeywordPlanIdeaService.GenerateKeywordForecastMetrics
これらの制限に違反するリクエストは、エラー
RESOURCE_EXHAUSTEDで拒否されます。1 QPS は、60 秒あたり 60 件のリクエストとして計算されます。
CID ごとに 1 秒あたり 2 件のリクエストに制限されます。
キーワード プランを作成する際は、これらの上限に注意してください。
| キーワード プラン オブジェクト | 最大数 |
|---|---|
KeywordPlan 個のアカウント |
10,000 |
KeywordPlanAdGroup/KeywordPlan |
200 |
KeywordPlan あたり KeywordPlanAdGroupKeyword |
10,000 |
KeywordPlan あたりのKeywordPlanCampaignKeyword(除外キーワード) |
1,000 |
KeywordPlanCampaign/KeywordPlan |
1 |
オーディエンス分析サービス
AudienceInsightsService 内の次のメソッドには、特定の割り当て上限が適用されます。
- CID ごとに 1 日あたり約 200 件のリクエストに制限されています。
- Google Cloud プロジェクトごとに 1 秒あたり 2 リクエストに制限されます。
コンバージョン アップロード サービス
リクエストあたりの通話コンバージョンまたはクリック コンバージョンは 2,000 件まで:
これらの上限に違反するリクエストは、エラー
TOO_MANY_CONVERSIONS_IN_REQUESTで拒否されます。
コンバージョン調整アップロード サービス
リクエストあたりのコンバージョン調整は 2,000 件までに制限されています。
これらの上限に違反するリクエストは、エラー
TOO_MANY_ADJUSTMENTS_IN_REQUESTで拒否されます。
コンバージョン値のルール
アカウントごとに設定できるコンバージョン値のルールは 100,000 個までです。
この上限に違反するリクエストは、エラー
ResourceCountLimitExceededError.ACCOUNT_LIMITで拒否されます。
アカウントに attachment_type が CUSTOMER の ConversionValueRuleSet がすでに存在する場合は、新しいコンバージョン値のルールをそのセットに追加して有効にする必要があります。このようなコンバージョン値のルールセットが存在しない場合は、ルールセットを作成するの説明に沿ってルールセットを作成し、コンバージョン値のルールを追加する必要があります。
お支払いとアカウント予算サービス
mutate リクエストは、毎月の請求書発行が設定されたアカウントに対してのみ行うことができます。
この制限に違反するリクエストは、エラー
MUTATE_NOT_ALLOWEDで拒否されます。変更リクエストで許可されるオペレーションは 1 つのみです。
この制限に違反するリクエストは、エラー
TOO_MANY_MUTATE_OPERATIONSで拒否されます。同じアカウントのアカウントの予算(
AccountBudgetまたはAccountBudgetProposal)を変更する場合は、少なくとも 12 時間待つ必要があります。12 時間が経過する前に変更を加えると、Google 広告のアカウント担当者しか解決できない回復不能なエラーが発生する可能性があります。
顧客アカウントへの招待
CustomerUserAccessInvitationService を使用して、既存のクライアント アカウントに新しいユーザーを招待できます。この機能は他のユーザーに招待メールを送信するため、不正使用される可能性があります。そのため、その動作には制限があります。
ユーザーは、同じクライアント アカウントに対して複数の保留中の招待状を受け取ることはできません。保留中の招待がすでにあるユーザーに招待を送信するリクエストが後で行われると、
EMAIL_ADDRESS_ALREADY_HAS_PENDING_INVITATIONというエラーが返されます。クライアント アカウントで保留できる招待状は、一度に 70 件までです。この値を超えるリクエストが送信されると、エラー
PENDING_INVITATIONS_LIMIT_EXCEEDEDが返されます。
ユーザーデータ
ユーザーデータは、UserDataService と OfflineUserDataJobService で管理されます。
create オペレーションまたは remove オペレーションの各 UserData オブジェクトは、1 人のエンドユーザーに関連しています。1 つの UserData オブジェクト内の user_identifiers フィールドは、最大 20 個の識別子に制限されています。1 つの UserData オブジェクトでこの上限を超えると、OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS エラーまたは UserDataError.TOO_MANY_USER_IDENTIFIERS エラーが発生します。
20 個を超える識別子を持つユーザーを処理する
1 人のエンドユーザーがアップロードする必要のある識別子を 20 個以上所有している場合は、これらの識別子を複数の UserData オブジェクトに分散する必要があります。Google がこれらすべての識別子を同じエンドユーザーに関連付けられるようにするには、そのユーザーの各 UserData オブジェクトに、同じ hashed_email、hashed_phone_number、third_party_user_id など、少なくとも 1 つの共通の user_identifier を含める必要があります。Google は、これらの共有識別子を使用して、個別の UserData オペレーションの情報を正しいエンドユーザー プロファイルにリンクして統合します。
ハッシュ化されたメールアドレスや電話番号などの個人情報を使用する場合は、リンクエラーを防ぐため、Google Ads API の要件(SHA-256、小文字、スペースなし)に沿って正規化およびハッシュ化されていることを確認してください。
たとえば、ユーザーが 30 個のメールアドレスを持っている場合、共通の third_party_user_id を共有する 2 つの UserData オブジェクトを送信できます(最初のオブジェクトに thirdPartyUserId とメール 1 ~ 19 を含めて 20 個の識別子の制限内に収め、2 番目のオブジェクトに thirdPartyUserId とメール 20 ~ 30 を含めます)。
{
"userIdentifiers": [
{ "thirdPartyUserId": "user123" },
{ "hashedEmail": "SHA256_OF_EMAIL_1" },
// Hashed emails 2 through 18 are omitted here.
{ "hashedEmail": "SHA256_OF_EMAIL_19" }
]
}
{
"userIdentifiers": [
{ "thirdPartyUserId": "user123" },
{ "hashedEmail": "SHA256_OF_EMAIL_20" },
// Hashed emails 21 through 29 are omitted here.
{ "hashedEmail": "SHA256_OF_EMAIL_30" }
]
}
1 つの AddOfflineUserDataJobOperationsRequest 内のすべてのオペレーションにおける user_identifiers の合計上限は 100,000 です(OfflineUserDataJob は複数の AddOfflineUserDataJobOperationsRequest 呼び出しを受け入れることができます。ジョブあたりの推奨される最大オペレーション数は 1,000,000 です)。UploadUserDataRequest(UserDataService.UploadUserData)を使用した同期アップロードの場合、各リクエストは最大 10 オペレーションとリクエスト全体で 100 user_identifiers に制限されます。
その他の種類の制限
リクエスト内のアイテムが多すぎるオペレーションのリストなどの繰り返しフィールドでは、REQUEST_SIZE_LIMIT_EXCEEDED エラーが発生する可能性があります。このエラー メッセージは、他の問題が原因で表示されることもあります。
この制限に達し、繰り返しフィールドを使用するリクエストを行っている場合は、オペレーションのリストを複数の変更リクエストに分割して、繰り返しフィールドのアイテム数を減らしてみてください。
GAQL クエリを作成する場合、IN 句内のアイテムの最大数は 20,000 です。この上限を超えると、FILTER_HAS_TOO_MANY_VALUES エラーが返されます。