Data API には、次の上限と割り当てが適用されます。
割り当ての適用方法
Google Analytics Data API v1 へのすべてのリクエストには Google Cloud プロジェクトが必要であり、このページで説明する割り当てが適用されます。割り当ては、呼び出し元プロジェクトの識別に使用される方法に関係なく消費されます。たとえば、次のような方法があります。
- OAuth 2.0 認証情報で認証されたリクエスト。
- API キーのみを使用して認証されたリクエスト。
API キーは、割り当てと課金を目的として、リクエストを特定の Google Cloud プロジェクトに関連付けるために使用されます。プロジェクトの認証情報または API キーを使用して行われたすべての API 呼び出しは、プロジェクトと Google アナリティクスのプロパティに適用される割り当てにカウントされます。
割り当てカテゴリ
Data API には、Core、Realtime、Funnel、Chat の 4 つのリクエスト割り当てカテゴリがあります。
Core メソッドへの API リクエストには、Core の割り当てが課金されます。Realtime メソッドへの API リクエストには、Realtime の割り当てが課金されます。ファネル メソッドへの API リクエストは、ファネルの割り当てにカウントされます。Chat メソッドへの API リクエストには、Chat の割り当てが課金されます。各リクエストは 1 種類の割り当てのみを消費します。
| 割り当てカテゴリ | API メソッド |
|---|---|
| コア | runReport、runPivotReport、batchRunReports、batchRunPivotReports、runAccessReport、getMetadata、checkCompatibility、createAudienceExports |
| リアルタイム | runRealtimeReport |
| ファネル | runFunnelReport |
| チャット | properties.chat |
アナリティクス プロパティの割り当て
すべてのリクエストは、プロパティの割り当てを消費します。
| 割り当て名 | 標準プロパティの上限 | アナリティクス 360 プロパティの上限 |
|---|---|---|
| 1 日あたりのプロパティごとのコアトークン数 | 200,000 | 2,000,000 |
| 1 プロパティ、1 時間あたりのコアトークン数 | 40,000 | 400,000 |
| 同一プロジェクト・同一プロパティで 1 時間あたりのコアトークン数 | 14,000 | 140,000 |
| プロパティあたりのコア同時リクエスト数 | 10 | 50 |
| 同一プロジェクト・同一プロパティで 1 時間あたりのコアサーバー エラー数 | 10 | 50 |
| 1 日あたりのプロパティごとのリアルタイム トークン数 | 200,000 | 2,000,000 |
| 1 プロパティ、1 時間あたりのリアルタイム トークン数 | 40,000 | 400,000 |
| 同一プロジェクト・同一プロパティで 1 時間あたりのリアルタイム トークン数 | 14,000 | 140,000 |
| プロパティあたりのリアルタイム同時リクエスト数 | 10 | 50 |
| 同一プロジェクト・同一プロパティで 1 時間あたりのリアルタイム サーバーエラー数 | 10 | 50 |
| 1 プロパティ、1 日あたりのファネル トークン数 | 200,000 | 2,000,000 |
| 同一プロパティで 1 時間あたりのファネル トークン数 | 40,000 | 400,000 |
| 同一プロジェクト・同一プロパティで 1 時間あたりのファネル トークン数 | 14,000 | 140,000 |
| プロパティあたりのファネルの同時リクエスト数 | 10 | 50 |
| 同一プロジェクト・同一プロパティで 1 時間あたりのファネル サーバーエラー数 | 10 | 50 |
| 1 プロパティ、1 日あたりのチャット トークン数 | 3,750,000 | 3,750,000 |
| プロパティごと、1 時間あたりのチャット トークン数 | 500,000 | 500,000 |
- 同時リクエストは、同時に実行されているリクエストの数で測定されます。リクエストの同時実行数を減らすには、前のリクエストが完了するのを待ってから、追加のリクエストを送信します。
- サーバーエラーは 500 コードと 503 コードです。サーバーエラーの割り当ては、リクエストがサーバーエラーになった場合にのみ課金されます。プロジェクトとプロパティのペアでサーバーエラーの割り当てが使い果たされると、プロジェクトからプロパティへのすべてのリクエストがブロックされます。エラー レスポンスの一覧については、エラー レスポンスをご覧ください。
- 各リクエストは、1 時間あたりのプロパティあたりのトークン数と、1 時間あたりのプロジェクトあたりのプロパティあたりのトークン数の両方の割り当てを消費します。つまり、「1 プロパティ、1 時間あたりのトークン数」の割り当てが「1 プロジェクト、1 プロパティ、1 時間あたりのトークン数」の割り当てよりも先に使い切られるには、1 つのプロパティに 3 つ以上のプロジェクトからアクセスされる必要があります。
プロパティでは、1 時間あたり 120 件の、割り当ての上限に達する可能性のあるリクエストが許可されます。ディメンション userAgeBracket、userGender、brandingInterest、audienceId、audienceName には、しきい値が適用される可能性があります。個々のユーザーのユーザー属性またはインタレスト カテゴリが、レポートを表示するユーザーに推測されないようにする手段として、しきい値が適用されます。
プロパティ トークンの割り当て
トークンは、Google Analytics Data API v1 へのリクエストごとに消費されます。課金されるトークンの数は、リクエストの複雑さによって異なります。ほとんどのリクエストでは 10 個以下のトークンが課金されますが、より複雑なリクエスト（Ask Advisor chat クエリなど）ではより多くのトークンが消費されます。
トークン消費に影響する要因
リクエストの正確なトークン費用は実行時に決定されるため、正確な事前計算は困難です。費用は、リクエスト自体に関連する要因と、Google アナリティクスのプロパティの基盤となるデータに関連する要因の組み合わせによって影響を受けます。たとえば、次のような要因により費用が増加する可能性があります。
- 行数: リクエストする行数が多い。
- ディメンションと指標の数: ディメンションと指標の数を増やす。
- フィルタの複雑さ: 複雑なフィルタ式を使用している。
- 期間の長さ: 長い期間にわたってクエリを実行している。
- データのカーディナリティ: カーディナリティが高いディメンション（
pagePath、カスタム ディメンションなど、一意の値が多いディメンション）は、トークン費用を大幅に増加させる可能性があります。 - プロパティのイベント数: イベント数が多いプロパティに対するクエリは、データが少ないプロパティに対する同じクエリよりも多くのトークンを消費する可能性があります。
トークン使用量のモニタリング
特定の API 呼び出しのトークン費用を判断する最も効果的な方法は、リクエスト本文にパラメータ "returnPropertyQuota": true を含めることです（runReport、batchRunReports、runPivotReport、batchRunPivotReports、runRealtimeReport、runFunnelReport でサポートされています）。API レスポンスには PropertyQuota オブジェクトが含まれます。このオブジェクトには、その特定のリクエストで消費されたトークンと残りの割り当て残高の詳細が記載されています。
returnPropertyQuota を使用したリクエストの例
POST https://analyticsdata.googleapis.com/v1beta/properties/GA_PROPERTY_ID:runReport
{
"dateRanges": [
{ "startDate": "7daysAgo", "endDate": "yesterday" }
],
"dimensions": [
{ "name": "country" }
],
"metrics": [
{ "name": "activeUsers" }
],
"returnPropertyQuota": true
}
propertyQuota レスポンス ペイロードの例
"returnPropertyQuota": true が設定されている場合、レスポンスには propertyQuota オブジェクトが含まれます。各フィールドには、consumed 整数と remaining 整数を含む QuotaStatus が含まれます。
{
"dimensionHeaders": [
{ "name": "country" }
],
"metricHeaders": [
{ "name": "activeUsers", "type": "TYPE_INTEGER" }
],
"rows": [
{
"dimensionValues": [{ "value": "United States" }],
"metricValues": [{ "value": "4820" }]
}
],
"propertyQuota": {
"tokensPerDay": {
"consumed": 1,
"remaining": 199999
},
"tokensPerHour": {
"consumed": 1,
"remaining": 39999
},
"concurrentRequests": {
"consumed": 0,
"remaining": 10
},
"serverErrorsPerProjectPerHour": {
"consumed": 0,
"remaining": 10
},
"potentiallyThresholdedRequestsPerHour": {
"consumed": 0,
"remaining": 120
},
"tokensPerProjectPerHour": {
"consumed": 1,
"remaining": 13999
}
}
}
propertyQuota の各フィールドは、アナリティクス プロパティの割り当ての割り当てに対応しています。1 つの API リクエストのトークン料金は、tokensPerDay、tokensPerHour、tokensPerProjectPerHour から同時に差し引かれます。いずれかの割り当てバケットの残量が 0 に達すると、そのプロパティに対する後続のリクエストは 429 RESOURCE_EXHAUSTED エラーを返します。
429 RESOURCE_EXHAUSTED エラーを回避するためのベスト プラクティス
remainingの残高を動的にモニタリングする: レスポンスのpropertyQuota.tokensPerProjectPerHour.remainingとpropertyQuota.tokensPerHour.remainingを検査し、残りのトークンが安全しきい値を下回った場合は、緊急性の低いバックグラウンド ジョブをスロットリングまたは一時停止します。- バッチ関連のクエリ:
batchRunReportsまたはbatchRunPivotReportsを使用して、1 回の HTTP 呼び出しで最大 5 つのレポートをグループ化し、HTTP ラウンドトリップのオーバーヘッドを削減します（バッチ内の各レポートは、トークンとconcurrentRequestsの割り当てに対して個別にカウントされます）。 - クエリの複雑さとカーディナリティを減らす: 必要なディメンションと指標のみにリクエストを制限し、可能な場合は
dateRangesを短縮します。また、頻繁にポーリングするクエリで複数の高基数ディメンション（pagePathやfullPageUrlなど）を組み合わせないようにします。 - リクエストの同時実行を制御する: リクエストをキューに入れるか、ワーカープールのサイズを制限して、処理中のリクエストが
concurrentRequestsの上限（標準の場合は 10、アナリティクス 360 の場合は 50）を下回るようにします。 - 再試行制限付きの指数バックオフを実装する: リクエストが
429 RESOURCE_EXHAUSTED、500 INTERNAL、503 UNAVAILABLEで失敗した場合は、エラー レスポンスで説明されているように、切り捨て型指数バックオフを使用して再試行します。
チャットのトークン消費量とモニタリング
Ask Advisor chat リクエストの場合、トークンはモデルの計算、推論、基盤となるデータの取得費用を表します。チャットのトークン消費量は、次の要因に影響されます。
- クエリと分析の範囲: リクエストされた分析の複雑さと範囲。
- モデルの入力トークンと出力トークン: 処理されたコンテキスト データの量と、生成されたレスポンスのナラティブ。
- 思考トークン: 検出結果を統合するために必要なモデルの推論ステップ。
- 実行レイテンシ: マルチステップのデータ探索に必要な処理時間。
チャット トークンの使用状況をモニタリングするには、ChatRequest で "returnPropertyQuota": true を設定します。レスポンスには、使用済み残高と残高を含む tokensPerDay フィールドと tokensPerHour フィールドを含む PropertyChatQuota オブジェクトが含まれます。