GA4の仕組み｜イベントとセッション

GA4を「見方が難しいツール」だと思っていると、いつまでも使えません。難しいのは見方ではなく、データの持ち方が以前の解析ツールと違うことです。 GA4が持っているのは、イベント（何が起きたか）と、そこに付いたパラメータ（どんな条件で起きたか）だけです。ページも、購入も、問い合わせも、全部イベントです。 この章は、その仕組みと、名前の付け方、セッションが切れる場面、数字が合わなくなる理由を押さえるための章です。設定を足す前に、ここを読んでください。

この章で分かること

• GA4が持っているのはイベントとパラメータだけ、という構造と、イベントの4つの層
• 名前の付け方の決めごと（あとから変えられない前提で決める）
• セッションが切れる場面・参照元が書き換わる場面と、そこで数字が合わなくなる理由

なお、Search Console と GA4 の役割分担、入れた直後に必ず変える設定の合格ラインは、SEOの教科書3章が扱っています。同じ表を2冊に書きません。 この章は、その先にある「GA4というツールの考え方」に絞ります。

GA4が持っているのは、イベントとパラメータだけ

以前の解析ツールは、「ページが見られた」を中心に組み立てられていました。GA4は違います。起きたことをすべて同じ形（イベント）で記録します。

この違いを飛ばして操作を覚えようとすると、必ず行き詰まります。画面の操作は、うまくいっている間は覚えられますが、思ったとおりの数字が出ないときに、どこを疑えばよいか分からないからです。仕組みを知っていれば、疑う場所は3つに絞れます。イベントが送られていないのか、パラメータが付いていないのか、レポートで使う登録をしていないのか。この3択に落とせるだけで、調べる時間が大幅に減ります。

そしてもうひとつ、仕組みを知っておくべき実務上の理由があります。画面は変わるが、仕組みは変わらないことです。メニューの位置や名称は、この数年でも何度も変わりました。そのたびに手順書を作り直していては追いつきません。イベントとパラメータという構造を理解していれば、画面がどう変わっても、探すべきものの名前が分かります。この本が画面の手順を書かず、探す言葉だけを添えているのは、この理由によります。

起きたこと	GA4での扱い
ページが表示された	イベント（どのページか、はパラメータ）
ファイルがダウンロードされた	イベント（どのファイルか、はパラメータ）
フォームが送信された	イベント（どのフォームか、はパラメータ）
商品が購入された	イベント（金額・商品、はパラメータ）

つまり「イベント＝動詞、パラメータ＝その説明」です。この形が分かると、設定でやることは2つに減ります。

1. どの動詞を記録するか（イベントを決める）
2. その動詞に、どんな説明を付けるか（パラメータを決める）

4章のコンバージョン設計も、5章のGTM設計も、この2つを決める作業でしかありません。

イベントは4つの層に分かれる

自分で全部を作る必要はありません。GA4には、放っておいても集まるものがあります。

層	どこから来るか	自分で決めること	注意
1 自動で集まる	タグを入れただけで記録される（ページの表示、初回訪問など）	無し	止められないものが多い
2 設定で増やせる	設定を有効にすると、追加で記録される（スクロール、外部リンクのクリック、ファイルのダウンロード、サイト内検索など）	有効にするかどうか	有効・無効の切り替えで、ある日から数字が変わる
3 名前が決まっているもの	用途ごとに名前と形が用意されている（購入、カート投入、ログインなど）	使うかどうか	決められた名前を使うと、既存のレポートに載る
4 自分で作るもの	自分で名前を決めて送る（問い合わせ完了、電話リンクのクリックなど）	名前・パラメータ・送る条件	この本の主戦場

この表は、自分の作業範囲を見極めるために使ってください。読む順番は、4の層から上に向かってです。まず自社が数えたいもの（1章の設計シートの出口と中間行動）を書き出し、それが3の層に用意された名前で足りるか、2の層を有効にするだけで済むか、と上へたどります。上から順に読むと、1と2の層の細かい挙動に時間を使ってしまい、肝心の4の層に着く前に力尽きます。

1の層に手を出す必要はまずありません。止められないものが多く、止める理由もないからです。中小企業が設計として悩むべきなのは、実質的に2の層を有効にするかどうかと、4の層で何を作るかの2点だけです。

2の層（設定で増やせるもの）は、事故の原因になりやすい場所です。 あとから有効にすると、その日を境にイベント数が増えます。増えたのは実態ではなく設定です。有効・無効を変えた日を必ず記録してください（12章）。

3の層は、決められた名前を使うかどうかが判断点です。ECのように用意された形がある領域では、決められた名前を使うと標準のレポートがそのまま使えます。一方、問い合わせのように自社固有のものは、4の層で自分で作ります。

層の名称と、どのイベントがどの層にあるかは変わることがあります。最新は公式ヘルプで確認してください（探す言葉：「GA4 自動収集イベント 拡張計測機能 推奨イベント」）。

パラメータは「登録しないとレポートに出ない」

ここが最初の落とし穴です。イベントにパラメータを付けて送っても、それだけではレポートの中で分けて見られません。 レポートで使うには、別途「このパラメータを項目として使う」という登録が要ります。

性質	内容	実務上の意味
登録が要る	送っただけでは、レポートの分類軸にならない	「送っているのに見られない」の原因の大半
上限がある	登録できる数に上限がある	思いつきで増やすと、後で本当に必要なものが登録できない
さかのぼらない	登録した日以降のデータにしか適用されない	気づいた日に登録する。過去は戻らない

上限があることが、設計が要る理由です。 「とりあえず全部パラメータにする」と、半年後に枠が足りなくなります。1章の設計シートに書いた出口と中間の行動で必要な分だけを登録してください。

登録の場所と上限の数は変わります（探す言葉：「GA4 カスタムディメンション 登録 上限」）。

名前の付け方（あとから変えられない前提で決める）

イベント名は、後から一括で変えられません。 名前を変えると、過去のデータと新しいデータが別物として並びます。だから最初に決めます。

決めごと	内容	理由
小文字のみ	contact_submit（Contact_Submit にしない）	大文字と小文字は区別されます。 表記揺れが別イベントになる
単語は _ でつなぐ	tel_click	読みやすさと、ツール間の互換
日本語を使わない	shiryo_download	書き出し・連携で壊れることがある
動詞で終える	form_submit・tel_click	「何が起きたか」が名前で分かる
数字・日付を名前に入れない	contact_submit_202604 にしない	月が変わるたびに新しいイベントが増える
区別はパラメータで行う	form_submit ＋ パラメータ form_id=contact	イベント名を増やさずに分けられる

最後の行が最も重要です。イベント名を増やすのではなく、パラメータで分けます。

悪い例	何が起きるか	良い例
contact_submit / saiyo_submit / shiryo_submit / lp_a_submit	イベントが増え続け、合計を出すたびに足し算が要る	form_submit ＋ form_id（contact / saiyo / shiryo / lp_a）
tel_click_header / tel_click_footer	設置場所が増えるたびにイベントが増える	tel_click ＋ location（header / footer / floating）

「合計を見たいのか、分けて見たいのか」ではなく、「両方見たい」が普通です。 パラメータで分ければ、合計も内訳も出せます。イベント名で分けると、合計が出しにくくなります。

イベント名を増やすかパラメータで分けるかで迷ったら、迷った時点でパラメータです。判断の基準は単純で、「これは同じ種類の行動か」を自問してください。問い合わせフォームの送信も、採用応募フォームの送信も、資料請求フォームの送信も、読者の立場から見れば同じ「フォームを送った」という行動です。同じ行動なら、1つのイベント名にして、違いはパラメータで持たせます。

この判断を誤ると、被害は時間とともに大きくなります。たとえば、キャンペーンごとにイベント名を分けていくと、キャンペーンを打つたびにイベントが1つ増え、2年もすれば30を超えます。問い合わせの合計を出すには、その都度30個を選んで足し算します。毎月それをやるのは現実的ではないので、結局、誰も合計を見なくなります。出口の件数という、いちばん大事な数字が出せない状態です。

さらに厄介なのは、後から直せないことです。イベント名は一括で変えられないので、名前を統一した日から新旧が分断されます。過去2年分をさかのぼって直すことはできません。この章を設定の前に置いているのは、名前の決めごとだけは、やり直しが効かないからです。

セッションはどこで切れるか

GA4の「セッション（訪問の回）」は、一定時間操作が無いと終了します。 既定値は変更できますが、初期値のまま使っている会社がほとんどです。細かい挙動（日付をまたいだときの扱いなど）は仕様が変わりうるので、最新は公式ヘルプで確認してください（探す言葉：「GA4 セッション タイムアウト 定義」）。

実務で問題になるのは、切れてほしくないところで切れる場面です。

場面	何が起きるか	結果
外部の決済・予約サービスに移動して戻ってくる	別のサイトへの移動として扱われる	成果の参照元が、その外部サービスになる
問い合わせフォームだけ別ドメインのサービスを使っている	同上	広告から来た問い合わせが、広告の成果に見えなくなる
LINEやSNSのアプリ内ブラウザから開く	通常のブラウザと別の入れ物になる	同じ人が別人に見える
入力に時間がかかるフォーム	操作が無い時間が長いと切れる	送信が「直接訪問」として記録される

2行目が、中小企業のサイトで最も多い事故です。 外部のフォームサービスを使っていて、その設定をしていないと、問い合わせの参照元がすべて「そのフォームサービス」になります。 広告もSEOも、成果が0件に見えます。

参照元が書き換わる（自己参照とドメインまたぎ）

症状と対処を表にします。設定の名称は変わりますが、やることは2つだけです。

症状	原因	やること（探す言葉）
参照元に自社のドメインが並んでいる	自分のサイトから来たことになっている	参照元から自社ドメインを除外する（「参照元除外リスト」）
参照元に決済・予約・フォームのサービス名が並ぶ	別ドメインへの移動で切れている	そのドメインを除外し、ドメインをまたぐ計測を設定する（「クロスドメイン測定 設定」）
広告から来たのに「直接」が多い	途中で参照元が失われている	上の2つを両方確認する
同じ人が別人に見える	アプリ内ブラウザ、端末またぎ	仕組み上避けられない部分がある。台帳で補う（6章）

この表の使い方は、左端の症状から引くことです。原因や設定の名称を覚える必要はありません。参照元の一覧を開いて、そこに何が並んでいるかを見て、当てはまる行の右端の言葉で検索する——それだけです。設定の名称は変わりますが、症状は変わりません。だから左端から引ける形にしてあります。

4行目だけは性質が違います。上の3行は設定で直りますが、4行目は仕組み上そうなるもので、設定では直りません。直らないものを直そうとして時間を使わないために、あえて同じ表に入れてあります。直らないと確定させて、台帳で補う側に回してください。

「直接／ノーリファラー」が不自然に多いサイトは、まずここを疑ってください。 ブックマークや直接入力だけでこの比率にはなりません。

数字が合わないとき、GA4側にある理由

計測が正しく入っていても、画面に出る数字がぴったり合わないことがあります。壊れているとは限りません。 主な理由を並べます。

理由	何が起きているか	どう扱うか
表示のしきい値	個人が特定されうる場合に、一部のデータが表示されないことがある	少数の内訳が消えることがある。合計との差として扱う
値の種類が多すぎる	値の種類が上限を超えると、まとめて「その他」に寄せられることがある	パラメータに一意の値（URL全文・IDなど）を入れない
値が取得できなかった	「未設定」として記録される	どの条件で取れていないかを調べる
保持期間を過ぎた	詳細な分析に使えるデータが残っていない	保持期間を最長にする（2章・工程8）
集計のタイミング	当日の数字は後から確定する	当日の数字で判断しない

最後の行は覚えておいてください。 当日や前日の数字は、後から増えることがあります。判断は週単位・月単位で行います（10章）。

そして、GA4の数字と広告媒体の数字が合わない理由は、GA4側ではなく媒体側の数え方にあることが大半です。これは7章で扱います。

GA4でやらなくてよいこと

設定は、足すほど壊れやすくなります。次のものは、多くの中小企業では要りません。

やらなくてよいこと	理由
ページごとの細かいスクロール計測	判断が変わらない。件数が動かない
全てのボタンのクリック計測	上限を食う。見る人がいない
1つの会社で複数のプロパティを並行運用	数字が分かれ、どちらが正か決まらない
見る予定のないパラメータの登録	上限があるため、本当に必要なときに登録できなくなる

判断が変わらない数字は、取らない。 これが設計の原則です。1章の設計シートに無いものは、原則として取りません。

よくある間違いを5つ

「イベント名を、キャンペーンやページごとに分けて作った」 ——イベントが増え続け、合計を出すたびに足し算が要ります。上限にも近づきます。直し方：イベント名は行動の種類だけにし、区別はパラメータ（form_id・location）で行う。

「パラメータを送っているのに、レポートで分けられない」 ——送ることと、レポートの項目として使えることは別です。直し方：項目としての登録を行う。登録した日以降のデータにしか効かないので、気づいた日にやる。

「参照元に自社のドメインや決済サービスが並んでいるが、そういうものだと思っていた」 ——参照元が書き換わっています。この状態では、広告もSEOも成果0件に見えます。 直し方：参照元の除外と、ドメインをまたぐ計測の設定を行い、設定後に自分で1件送って確かめる。

「昨日の数字が今日見たら変わっていたので、壊れていると思った」 ——当日・前日の数字は後から確定します。直し方：判断は週単位・月単位で行う。日次は監視（0件になっていないか）にだけ使う。

「拡張の計測を全部オンにして、取れるものは全部取った」 ——上限を食い、見る人のいないイベントが並びます。しかも、オンにした日から数字が変わるので、過去との比較ができなくなります。直し方：1章の設計シートにあるものだけをオンにする。変更した日を記録する。

この章の出口

手元に残っているべきものは3つです。

1. 命名規則を書いた1枚（イベント名の付け方・パラメータで分ける方針）
2. 登録したパラメータの一覧（何を、いつ登録したか）
3. 参照元の設定を確認した記録（自社ドメインの除外・ドメインまたぎ・実測の日付）

土台が分かったので、次は「何を成果として印を付けるか」です。ここを間違えると、数字は増えますが判断は悪くなります。

次の章へ：4章 GA4のコンバージョン設定｜キーイベントと重複