## 各種制限

### ヒット

- ヒットは、ユーザーのウェブサイトやアプリ上での行動がGoogleアナリティクスに送信されるデータポイント。
例えば、ページビュー、イベント、トランザクションなどがヒットに該当。
- 「プロパティあたり1か月に最大1,000万ヒット」とは、無料版のGoogleアナリティクスでは、各プロパティが1か月に受け取れるデータポイント（ヒット）の最大数が1,000万に制限されていることを意味。これを超えると、その月の残りの期間において追加のデータは記録されない。

次の制限事項は、ウェブ プロパティ、プロパティ、トラッキング ID に適用されます。

- **プロパティ**あたり 1 か月 1,000 万ヒット

次の制限事項は、gtag.js、analytics.js、Android SDK、iOS SDK、Measurement Protocol に適用されます。

- **ユーザー**あたり 1 日 20 万ヒット
- **セッション** 1 回あたり 500 ヒット

### クォーター

- APIクォータはGoogleアナリティクスのAPIを介して実行できるリクエストの数に適用される制限。
このクォータは、APIリクエストの頻度や数量を管理し、システムの過負荷を防ぐために設定されている。
- データ取得やレポート作成などのためにAPIを通じてGoogleアナリティクスのデータにアクセスする際に使用されるもので、トークンバケットシステムを使用して管理され、各APIリクエストは特定の数のトークンを消費します。

クォータは3つのカテゴリに分かれており、使用する Data API メソッドの種類に応じたカテゴリのトークンが消費される。
1 つのリクエストでコアとリアルタイムの両方の割り当てが消費されることはない。

| 割り当てカテゴリ | API メソッド |
| --- | --- |
| コア | runReport、runPivotReport、batchRunReports、batchRunPivotReports、runAccessReport、getMetadata、checkCompatibility、createAudienceExports |
| リアルタイム | runRealtimeReport |
| ファネル | runFunnelReport |

### アナリティクス プロパティの割り当て

| 割り当て名 | 標準プロパティの上限 | アナリティクス 360 プロパティの上限 |
| --- | --- | --- |
| プロパティあたりの 1 日あたりのコアトークン数 | 200,000 | 2,000,000 |
| プロパティあたりの 1 時間あたりのコアトークン数 | 40,000 | 400,000 |
| 1 プロジェクト、プロパティ、1 時間あたりのコアトークン数 | 14,000 | 140,000 |
| プロパティあたりのコア同時リクエスト数 | 10 | 50 |
| 1 プロジェクト、同一プロパティで 1 時間あたりのコアサーバー エラー数 | 10 | 50 |
| プロパティあたりの 1 日あたりのリアルタイム トークン数 | 200,000 | 2,000,000 |
| プロパティあたりの 1 時間あたりのリアルタイム トークン数 | 40,000 | 400,000 |
| 1 プロジェクト、プロパティ、1 時間あたりのリアルタイム トークン数 | 14,000 | 140,000 |
| プロパティあたりのリアルタイムの同時リクエスト数 | 10 | 50 |
| 1 プロジェクト、プロパティ、1 時間あたりのリアルタイム サーバー エラー数 | 10 | 50 |
| プロパティあたりの 1 日あたりの目標到達プロセスのトークン数 | 200,000 | 2,000,000 |
| プロパティあたりの 1 時間あたりのファネル トークン | 40,000 | 400,000 |
| 1 プロジェクト、プロパティ、1 時間あたりのファネル トークン数 | 14,000 | 140,000 |
| 目標到達プロセスの同時リクエスト数（プロパティあたり） | 10 | 50 |
| 1 プロジェクト、プロパティ、1 時間あたりのサーバーエラー数 | 10 | 50 |

## トークン消費量が増えるパターン

- リクエストするディメンションの数が多い
- クエリ対象の期間が長い
- 基数が大きいディメンションを含む
- クエリ対象のプロパティのイベント数が多い

### 期間ごとのトークン消費量

1. **日単位**:
- 日単位でデータを取得する場合、データ量が比較的少ないため、トークン消費量は比較的低いと予想されます。簡単なリクエストなら10個以下のトークンで済む可能性が高いです。
2. **時間単位**:
- 時間単位でのデータ取得は、より詳細なデータを必要とするため、日単位よりは多くのトークンを消費する可能性がありますが、それでも単純なリクエストでは10個以下のトークンで済むことが多いです。
3. **月単位**:
- 月単位のデータ取得は、期間が長く、データ量が多くなるため、トークン消費量が増加します。複雑なリクエストや多くのディメンションとメトリクスを含む場合は、10個以上のトークンを消費する可能性があります。

## ベストプラクティス

アプリケーションのクォータ消費量を抑える方法は、大きく分けて 2 つある。

- 送信する API リクエストの数を減らす
- 送信する API リクエストの複雑さを軽減する

次の5つが上記を実現する上で考えられる

- **キャッシュ処理:** キャッシュ処理のレイヤーを実装すれば、アプリケーションのユーザビリティとクォータ管理の両面でメリットがあります。Google アナリティクス自体も API リクエストのキャッシュ処理を行っていますが、リクエストを繰り返せばクォータ トークンが消費される点は変わりません。アプリケーション側で API レスポンスをキャッシュすることにより、反復的なリクエストの数を劇的に削減できます。たとえば通常のアナリティクス プロパティの当日データなら、キャッシュの有効期限は 4 時間またはそれ以上に設定可能です。
- **リクエストのマージ:** 複数の API リクエストをひとつにまとめられないか検討しましょう。たとえば、2 日間のデータに対するリクエストを 5 件行った場合のクォータ トークン消費量は、10 日間のデータに対するリクエストを 1 件行った場合の 3 倍になる可能性があります。ディメンションが 1 つ異なるだけでそれ以外は同内容のリクエストが複数あれば、単一のリクエストにまとめることを検討しましょう。
- **リクエスト内容の簡素化:** リクエストの内容は、アプリケーションおよびユーザーが必要とする最小限のデータ量に絞りましょう。多数の行 / 列や複雑なフィルタ条件を指定すれば、クォータ トークンの消費が多くなります。対象期間を長くするとトークン消費も重くなることが一般的です（例: 期間を 28 日間から 365 日間に変更すると、クォータ トークンの消費量は 3 倍になる可能性があります）。可能な限り基数の小さいディメンションを使うことも検討しましょう（例: `dateHourMinute` ではなく `dateHour` をリクエスト）。
- **`limit` の効果的な利用:** API リクエストの `[limit](https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/properties/runReport?hl=ja#body.request_body.FIELDS.limit)` を変更して返される行の数を減らしても、クォータ トークンの節約はあまり期待できません。たとえば、上限（limit）を 1 万行に設定したリクエストを 5 件実行した場合のクォータ トークン消費量は、上限 5 万行のリクエストを 1 件実行した場合の 5 倍になる可能性があります。
- **適切なメソッド カテゴリの使用:** 前述のとおり、クォータの上限は 3 種類のメソッド カテゴリに分けて適用されます。用途に応じて適切なメソッドを使用すれば、他のカテゴリのクォータを節約できます。たとえばファネルを作成する場合、「コア」カテゴリのメソッドで取得したデータを使ってアプリケーション側で独自に作成するよりも、`runFunnelReport` メソッドを使って作成するのがいいでしょう。
- **デフォルト設定の変更:** プラットフォームでレポートの作成やカスタマイズを行うユーザーは、アプリケーションが提示したデフォルト値を変更せず、実行時の設定変更だけで済ませることも想定されます。たとえば、ユーザーが普段参照するのは 28 日間のレポートなのに、アプリケーションのデフォルト期間が 365 日間になっていれば、必要以上のクォータ消費が定期的に発生することになります。デフォルトの期間や選択内容は限定的にしておき、ユーザー自身に用途に応じた設定を選択してもらう運用も検討しましょう。場合によっては、ユーザーが変更できるデフォルト設定の種類を制限することも可能です。
- **リクエストのキュー処理と遅延読み込み:** 「プロパティあたりの同時リクエスト数」トークンの上限を意識しましょう。アプリケーションが同時に送信するリクエストの数を抑える必要があります。アプリケーションに多数の UI 要素があるために API リクエストが嵩んでしまう場合は、UI のページネーション、遅延読み込み、リクエストのキュー処理（再試行は指数関数的バックオフで処理）を検討しましょう。`returnPropertyQuota` メソッドを使ってアプリケーションの「プロパティあたりの同時リクエスト数」トークンの使用状況を積極的にモニタリングすることも重要です。

## 初期データ投入時に引っ掛かるかどうかについて

いくつかドキュメントを読んだり、GPTに聞いてみた感じユーザー数を3000人と仮定して、1年間を一気に取得しようとすると制限に引っかかりそう。
「プロパティあたりの 1 日あたりのコアトークン数」が200,000ということなので、もし1ユーザーにつき1年間取得で100トークン使用すると仮定すると300,000なので超えてしまうかと思われる。

ベストプラクティスにある通りに行えば制限に行く可能性は低いとGPTが言っており、この設計でどの程度抑えられるかでユーザー数をどの程度まで増やせるのか変わってくる。

一旦どのぐらいトークンを使用しているか実際に試してみる必要がある。

## 参考資料

- **[Google アナリティクスのデータ収集上限](https://developers.google.com/analytics/devguides/collection/analyticsjs/limits-quotas?hl=ja)**
- **[割り当て](https://developers.google.com/analytics/devguides/reporting/data/v1/quotas?hl=ja#analytics_property_quotas)**
- **[Google Analytics Data API のクォータの管理](https://developers.google.com/analytics/blog/2023/data-api-quota-management?hl=ja)**