Data API には、次の上限と割り当てが適用されます。
割り当ての適用方法
Google アナリティクス Data API v1 へのリクエストにはすべて Google Cloud プロジェクトが必要であり、このページに記載されている割り当てが適用されます。割り当ては、呼び出し元プロジェクトの識別に使用される方法に関係なく消費されます。たとえば、次のような場合です。
- OAuth 2.0 認証情報で認証されたリクエスト。
- API キーのみを使用して認証されたリクエスト。
API キーは、割り当てと課金の目的で、リクエストを特定の Google Cloud プロジェクトに関連付けるために使用されます。プロジェクトの認証情報または API キーを使用して行われたすべての API 呼び出しは、プロジェクトと Google アナリティクス プロパティに適用される割り当てに対してカウントされます。
割り当てカテゴリ
Data API には、コア、リアルタイム、ファネル、チャットの 4 つのリクエスト割り当てカテゴリがあります。
コアメソッドへの API リクエストには、コア割り当てが適用されます。リアルタイム メソッドへの API リクエストには、リアルタイム割り当てが適用されます。ファネル メソッドへの API リクエストには、ファネル割り当てが適用されます。チャット メソッドへの API リクエストには、チャット割り当てが適用されます。各リクエストは 1 種類の割り当てのみを消費します。
| 割り当てカテゴリ | API メソッド |
|---|---|
| コア | runReport、runPivotReport、batchRunReports、batchRunPivotReports、runAccessReport、getMetadata、checkCompatibility、createAudienceExports |
| リアルタイム | runRealtimeReport |
| ファネル | runFunnelReport |
| チャット | properties.chat |
アナリティクス プロパティの割り当て
すべてのリクエストでプロパティの割り当てが消費されます。
| 割り当て名 | 標準プロパティの上限 | アナリティクス 360 プロパティの上限 |
|---|---|---|
| プロパティあたりの 1 日のコアトークン数 | 200,000 | 2,000,000 |
| プロパティあたりの 1 時間のコアトークン数 | 40,000 | 400,000 |
| プロジェクト、プロパティあたりの 1 時間のコアトークン数 | 14,000 | 140,000 |
| プロパティあたりの同時コアリクエスト数 | 10 | 50 |
| プロジェクト、プロパティあたりの 1 時間のコアサーバーエラー数 | 10 | 50 |
| プロパティあたりの 1 日のリアルタイム トークン数 | 200,000 | 2,000,000 |
| プロパティあたりの 1 時間のリアルタイム トークン数 | 40,000 | 400,000 |
| プロジェクト、プロパティあたりの 1 時間のリアルタイム トークン数 | 14,000 | 140,000 |
| プロパティあたりの同時リアルタイム リクエスト数 | 10 | 50 |
| プロジェクト、プロパティあたりの 1 時間のリアルタイム サーバーエラー数 | 10 | 50 |
| プロパティあたりの 1 日のファネル トークン数 | 200,000 | 2,000,000 |
| プロパティあたりの 1 時間のファネル トークン数 | 40,000 | 400,000 |
| プロジェクト、プロパティあたりの 1 時間のファネル トークン数 | 14,000 | 140,000 |
| プロパティあたりの同時ファネル リクエスト数 | 10 | 50 |
| プロジェクト、プロパティあたりの 1 時間のファネル サーバーエラー数 | 10 | 50 |
| プロパティあたりの 1 日のチャット トークン数 | 3,750,000 | 3,750,000 |
| プロパティあたりの 1 時間のチャット トークン数 | 500,000 | 500,000 |
- 同時リクエストは、同時に実行されるリクエストの数で測定されます。リクエストの同時実行数を減らすには、前のリクエストが完了してから追加のリクエストを送信します。
- サーバーエラーは 500 と 503 のコードです。サーバーエラーの割り当ては、リクエストがサーバーエラーになった場合にのみ課金されます。プロジェクトとプロパティのペアでサーバーエラーの割り当てが上限に達すると、プロジェクトからプロパティへのすべてのリクエストがブロックされます。エラー レスポンスの完全なリストについては、Error Responsesをご覧ください。
- 各リクエストは、プロパティあたりの 1 時間のトークン数とプロジェクト、プロパティあたりの 1 時間のトークン数の両方の割り当てを消費します。つまり、プロジェクト、プロパティあたりの 1 時間のトークン数の割り当てよりも先に、プロパティあたりの 1 時間のトークン数の割り当てが上限に達するには、1 つのプロパティに 3 つ以上のプロジェクトからアクセスする必要があります。
プロパティでは、1 時間あたり 120 件のしきい値が設定される可能性のあるリクエストが許可されます。ディメンション userAgeBracket、userGender、brandingInterest、audienceId、audienceName には、しきい値が設定される可能性があります。個々のユーザーのユーザー属性またはインタレスト カテゴリが、レポートを表示するユーザーに推測されないようにする手段として、しきい値が適用されます。
プロパティ トークンの割り当て
トークンは、Google アナリティクス 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 オブジェクトが含まれます。各フィールド
には、QuotaStatus と
consumed および remaining の整数が含まれます。
{
"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を使用して、最大 5 つのレポートを 1 回の HTTP 呼び出しにグループ化し、HTTP 往復のオーバーヘッドを削減します（バッチ内の各レポートは、トークンとconcurrentRequestsの割り当てに対して個別にカウントされます）。 - クエリの複雑さとカーディナリティを減らす: リクエストを必要なディメンションと指標のみに制限し、可能な限り
dateRangesを短縮します。また、頻繁なポーリング クエリで複数の高カーディナリティ ディメンション（pagePathやfullPageUrlなど）を組み合わせないようにします。 - リクエストの同時実行数を制御する: リクエストをキューに入れるか、ワーカープールのサイズを制限して、処理中のリクエストが
concurrentRequestsの上限（スタンダードの場合は 10、アナリティクス 360 の場合は 50）を超えないようにします。 - 再試行上限付きの指数バックオフを実装する: リクエストが
429 RESOURCE_EXHAUSTED、500 INTERNAL、または503 UNAVAILABLEで失敗した場合は、 切り捨てられた指数バックオフを使用してエラー レスポンスの説明に従って再試行します。
チャット トークンの消費とモニタリング
Ask Advisor chat
リクエストの場合、トークンはモデルの計算、推論、基盤となるデータ
の取得費用を表します。チャット トークンの消費は、次の要因によって影響を受けます。
- クエリと分析の範囲: リクエストされた分析の複雑さと範囲。
- モデルの入力トークンと出力トークン: 処理されたコンテキスト データと生成されたレスポンスの量。
- 思考トークン: 調査結果を合成するために必要なモデルの推論ステップ。
- 実行レイテンシ: 複数ステップのデータ探索に必要な処理時間。
チャット トークンの使用状況をモニタリングするには、"returnPropertyQuota": true
で
ChatRequestを設定します。レスポンスには、
PropertyChatQuota
オブジェクトが含まれます。このオブジェクトには、
tokensPerDay
フィールドと
tokensPerHour
フィールドが含まれます。これらのフィールドには、消費された残高と残りの残高が含まれます。