Google Analytics 360

解決する課題

• アクセス解析でレポートにサンプリングがかかり、大規模サイトで数値の精度が落ちるのを避けたい
• 標準版の**処理上限（イベント数・ヒアリング容量など）**を超える大量トラフィックを、欠損なく計測したい
• 管理画面の定型レポートだけでなく、イベント単位のローデータを取り出して自社のデータ基盤で自由に分析したい
• 広告・CRM・オフライン購買などの外部データと結合して、ユーザー行動を横断的に把握したい
• エンタープライズ運用に必要なSLA とサポート、組織管理機能を確保したい

主要概念と用語

• Google アナリティクス 360: Google マーケティング プラットフォームに含まれる、Google アナリティクスの有償エンタープライズ版。標準版（無償）と同じ計測基盤の上に、高い上限・SLA・追加管理機能を提供する
• GA4（Google アナリティクス 4）: 現行のアナリティクスの計測モデル。ページビュー中心ではなくイベント単位で計測し、ウェブとアプリを横断して扱える。360 はこの GA4 の上位プランにあたる
• イベント / パラメータ: 計測の最小単位。ページ表示・クリック・購入などをイベントとして記録し、付随情報をパラメータで持たせる
• プロパティ / データストリーム: 計測対象をまとめる単位がプロパティ、ウェブやアプリなど収集元ごとの入口がデータストリーム
• サンプリング: レポート集計時に一部データだけを使って近似する処理。360 は標準版より高いサンプリングしきい値を持ち、大規模でも精度を保ちやすい
• BigQuery Export（エクスポート）: アナリティクスのイベントデータを BigQuery のテーブルへ書き出す連携機能。ローデータを SQL で直接分析できる
• Google マーケティング プラットフォーム: アナリティクス 360 を含む、広告・計測・最適化のエンタープライズ製品群の総称

仕様・制限・クォータ

• 標準版に比べ、イベント数・カスタムディメンション・サンプリングしきい値・データ更新頻度などの上限が引き上げられている。これにより大規模トラフィックでも欠損やサンプリングの影響を抑えやすい
• BigQuery Export は標準の GA4 でも利用できるが、360 ではエクスポートの容量や更新の面で上位の扱いになる。実際の取り込みは BigQuery 側の料金・クォータに従う
• 課金・契約は通常のセルフサービスではなく、販売パートナー経由の年間契約が中心。具体的な上限値・価格・SLA は契約とプランで変動するため、断定せず公式情報と契約条件で確認する
• 計測モデルは GA4 に統一されており、過去のユニバーサルアナリティクス（旧版）とはデータ構造が異なる点に注意する

内部の仕組み

アナリティクスの計測は、サイトやアプリに設置したタグ（Google タグや SDK）がイベントを収集サーバーへ送信するところから始まります。送られたイベントはプロパティ単位で集約・処理され、管理画面のレポートとして可視化されます。360 ではこの処理パスにおける上限としきい値が引き上げられ、大量のイベントでもサンプリングや遅延の影響を受けにくくなります。

分析の自由度を生むのが BigQuery Export です。イベントはほぼ素のままの粒度で BigQuery のテーブルへ書き出され、利用者は SQL でローデータに直接アクセスできます。管理画面の定型集計に縛られず、ファネル分析・コホート分析・LTV 計算などを自由に組み立てられ、広告や CRM のテーブルと結合してユーザー行動を横断的に追えます。

レポート集計では、対象データが一定規模を超えるとサンプリング（一部抽出による近似）が働きます。360 はこのしきい値が高いため、大規模でも全量に近い精度を保ちやすく、これが標準版との実務的な差として現れます。

設計パターン / ベストプラクティス

• 早い段階で BigQuery Export を有効化し、イベントのローデータを継続的に蓄積する。後から過去分はさかのぼれないため、計測開始時の設定が重要
• イベントとパラメータの命名規則を最初に統一する。BigQuery で SQL を書く段になって命名がバラつくと、集計が著しく煩雑になる
• 広告・CRM・オフラインデータは BigQuery 側で結合する前提にし、ユーザー識別子の設計（同意取得と整合性）を最初に決める
• 管理画面のレポートは速報・モニタリング用、精密な分析は BigQuery 側、と役割を分担させる
• 同意管理（コンセントモード）と計測タグの整合を取り、プライバシー要件を満たした計測を設計する

運用・監視

• データストリームの計測が止まっていないか、イベント数の急減を定期的に監視する。タグの破損やデプロイ事故は計測欠損に直結する
• BigQuery Export の日次テーブルが欠けていないかを確認し、欠損があれば取り込みパイプライン側の異常を疑う
• カスタムイベントやパラメータの仕様変更は、BigQuery 側の集計クエリに影響するため、スキーマ変更として管理する
• 同意状態の変化やプライバシー設定の更新が、計測量の変動として現れることを理解しておく

コスト

セキュリティ

• アクセス制御はアナリティクス側のユーザー権限とロールで行い、誰がどのプロパティを閲覧・編集できるかを最小権限で割り当てる
• BigQuery へ出したデータは BigQuery の IAM で保護され、列レベル・行レベルのアクセス制御や VPC Service Controls などの境界制御を適用できる
• 個人を特定しうる情報の扱いは**プライバシー規制（同意取得・保持期間）**に従い、不要な識別子をローデータに残さない設計にする
• 計測タグの改ざんや不正なイベント送信に備え、タグ管理と公開フローを統制する

関連サービス・比較

最も関係が深いのは連携先の BigQuery で、360 のローデータ分析はこの上で行います。可視化では Looker Studio や Looker と組み合わせるのが一般的です。標準版との違いは上限・SLA・サポート面に集約されます。

ハンズオン / CLI例

# アナリティクス 360 自体の設定は管理画面（Google マーケティング プラットフォーム）で行い、
# 日常操作に gcloud は使いません。ここでは連携先となる BigQuery 側の準備例を示します。

# 1) エクスポート先のデータセットを用意する（アナリティクスの BigQuery Export 連携先）
bq --location=asia-northeast1 mk --dataset MY_PROJECT:analytics_360

# 2) 連携データを読むサービスアカウントを作成する
gcloud iam service-accounts create ga-export-reader \
  --display-name="GA360 BigQuery export reader"

# 3) BigQuery の読み取り・ジョブ実行権限を最小権限で付与する
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:ga-export-reader@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataViewer"

gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:ga-export-reader@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/bigquery.jobUser"

# 4) 取り込まれた日次イベントテーブルを確認する（events_ は日付サフィックス付き）
bq ls MY_PROJECT:analytics_360

# 5) 直近のイベント件数をローデータから集計する例
bq query --use_legacy_sql=false \
  'SELECT event_name, COUNT(*) AS cnt
   FROM `MY_PROJECT.analytics_360.events_*`
   WHERE _TABLE_SUFFIX = FORMAT_DATE("%Y%m%d", DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
   GROUP BY event_name
   ORDER BY cnt DESC
   LIMIT 20'