GA4イベント：分類を選び、測定を確認する

公開 11/05/2026 · 更新 01/11/2026 · データと成果測定 · 7 分で読めます · 執筆 Cyber Intelligence Embassy

要点

GA4は自動収集、拡張計測、推奨、カスタムの各イベントを区別します。実装方法は異なり、イベント名だけでは業務上の行為の成功を証明しません。

白紙のカードを並べた2台の机、真ちゅうのランプ、えんじ色の資料がある架空の無人分析室

この記事の内容

観測できる行為を定義する

新規作成前に既存や推奨イベントを探します。発火条件、パラメータ、計数単位、限界を文書化します。フォームのクリックは依頼の受領とは違います。名前、URL、送信パラメータに個人情報を含めません。

収集と業務上の重要性を分ける

GA4ではイベントをキーイベントに指定できます。これは選んだ分析上の重要性であり、販売や収益性の証明ではありません。レポートを読む前に重複、値、収集範囲を確認します。拡張計測と自動収集は別分類です。

GA4イベントの四つの分類
分類	例	条件
自動収集	first_visit, session_start	基本設定で予定される収集
拡張計測	scroll, file_download	機能が有効で対象操作をサポート
推奨	add_to_cart, purchase	文書化された名前とパラメータを実装
カスタム	製品固有の行為	他の分類で対応できない場合に定義

出典と確認

2026年11月1日確認

カスタムイベントはビジネス上の事実を記述する必要があります。

カスタムGA4イベントは、観測可能なアクションを表し、意思決定を支援する必要があります。明確な名前では、不正確なトリガーを修正することはできません。フォームを送信しただけでは、サーバーがリクエストを受け入れたという証拠にはなりません。

イベント辞書で、トリガー、パラメータ、型、および除外ケースのバージョン管理を行います。
DebugViewまたは同等のツールで、成功、エラー、戻るナビゲーション、および再読み込みをテストします。
受信したイベントを既知の操作と照合し、不一致を割り当てます。

一次資料：Google Analytics — Set up events. 関連する方法：実践ガイドを読む.

データ結合の整合性

結合による行の増加が合計値を歪める場合があります。

注文テーブルの1行は注文、明細の1行は注文内の商品を表します。結合前に重複キーとNULLキーを確認します。
明細を注文キーごとに集約します。その結果と結合すれば、商品ごとに注文金額が繰り返されません。元の注文テーブルの合計と照合します。
LEFT JOINは明細のない注文を残しますが、右側テーブルへのWHERE条件はその注文を除外する場合があります。対応する行がないことと金額ゼロは別です。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る

{
    "orders": [
        {
            "id": 1,
            "total": 100
        },
        {
            "id": 2,
            "total": 200
        }
    ],
    "line_order_ids": [
        1,
        1,
        2
    ],
    "sum_before": 300,
    "sum_after_raw_join": 400
}

期待される判断

400は注文を二重計上しています。注文ごとに明細を集約し、合計300に戻します。追加で、各100の架空の注文を2件試します。合計は200です。SUM(DISTINCT total)では100となり、正しい値が消えます。金額の重複排除ではなく、識別子と結合の対応件数を確認します。

再現できるSQLクエリ

架空例：金額100と200の注文2件と、注文1、1、2に対応する明細3件。クエリはVALUESだけを使います。テスト環境で実行してください。

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
  SELECT order_id, COUNT(*) AS line_count
  FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;

直接結合すると3行で合計400になります。先に集約すれば2件の注文と合計300を得られます。

WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
       SUM(DISTINCT total) AS distinct_total
FROM orders;

金額が100と100の場合、正しい合計は200ですがSUM(DISTINCT total)は100です。

検証手順

注文と明細の粒度を定めます。
2明細の注文を結合します。
キー、件数、照合済み合計を残します。

PostgreSQL — Table expressions and joins

SUM(DISTINCT total)だけで直せますか？

いいえ。100の注文が2件あれば合計は200ですが、SUM(DISTINCT total)は100になります。金額の重複排除ではなく、キーの関係を修正します。

一次資料：PostgreSQL — Table expressions and joins. 関連する方法：実践ガイドを読む.

結合の多重度、NULL、集計

この言語版の詳しい参照メモは英語で提供しています。

Read the cardinality behind a published number

When a result combines sources, ask what one row represents and how keys were matched. An apparently correct sum can conceal two offsetting errors. Pair counts and identifier coverage provide additional evidence.

Document population before and after joining.
Do not infer causation from the total alone.
Connect the metric definition to actual retained rows.

Inspect pairs and aggregates in the workshop →

PostgreSQL 18 · Table expressions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Aggregate functions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Comparison functions · PostgreSQL 18 · documentation reviewed 2026-10-23