「レポートは見れる。
でも、なぜ悪いのかが分からない。」
GA4を触り始めて、ほぼ全員がここで止まります。
流入元やLPは見た。数字の増減も追える。なのに改善になると、結局は感覚で直す（CTAを増やす、文章を足す、見出しを変える…）。これだと、当たったのか外したのかも分からず、時間だけ溶けます。
そこで必要になるのが 探索レポート（Explorations） です。
探索は一言でいうと、「原因特定のための精密検査」。標準レポートが健康診断なら、探索は検査で原因を絞る場所。「どの流入が」「どのページで」「どのデバイスで」崩れているかを、切り分けて言えるようになります。
ただし探索は自由度が高いぶん、初心者ほど迷子になります。
「何を置けばいい？」「どこを見ればいい？」「作ったけど次の一手が出ない…」となりがち。なのでこの記事では、難しい理屈より先に 探索の型（最小ルート）を固めます。まずは自由形式で最小構成1枚を作り、そこから1つずつ足して原因を切り分け、最後に探索結果を 「事実→仮説→次の一手」 に変換するところまでやります。
結論（3行）
- 探索は「自由に分析する場所」ではなく、原因を特定する場所として使う
- まずは 最小構成1枚→そこから1個ずつ拡張が最短
- レポートで異常検知→探索で切り分け→1施策で検証 が勝ち筋
📌 前提記事
なぜ今「探索」なのか（標準レポートとの違いを1分で）
標準レポート＝異常に気づくためのダッシュボード
標準レポートは、毎日・毎週のチェックに向いています。
たとえば「セッションが減った」「コンバージョン率が落ちた」「特定の流入元だけ悪い」など、変化を見つけるのが得意です。
ただし、標準レポートは基本的に「用意された見方」なので、ここで止まりやすいです。
- どのページが原因かまで絞れない
- どのデバイスだけ悪いのか切り分けづらい
- “流入元 × LP × 行動”みたいな掛け算ができない
結果として「なんとなくLPを直す」「CTAを増やす」になりがちで、改善が運ゲー化します。
探索＝原因を特定するための精密検査
探索（Explorations）は、標準レポートで見つけた異常に対して、原因を切り分けて言い切るための場所です。
たとえば「セッションが減った」という同じ事実でも、探索ならこう分解できます。
- 減っているのは Organicだけ？それとも Socialだけ？
- 影響が大きいのは mobileだけ？PCも同じ？
- 落ちているのは 特定のLPだけ？それとも全体？
- さらに、そのLPで どの行動（スクロール/クリック/フォーム到達）が弱い？
つまり探索は、
「誰が（セグメント）×どこで（ページ）×どんな状況で（デバイス/流入）×何が起きたか（指標）」
を組み合わせて、原因を狭める道具です。
Day16の位置づけ：改善系記事を回すための土台
このシリーズでは、流入元・LP・離脱・ファネルなど「改善の打ち手」回が増えていきます。
でも、その前提として必要なのが 迷子にならない探索の型です。
- レポートで異常を見つける（健康診断）
- 探索で原因を切り分ける（精密検査）
- 1施策だけ打って、また数字で検証する（治療→再検査）
この順番が固定できると、改善が「思いつき」ではなく再現性のある手順になります。次のH2では、探索でまず覚える要素を最小限だけ押さえて、すぐ1枚作ります。
探索レポートでまず覚える5要素（ここだけ押さえれば迷子にならない）
探索は自由度が高い分、「画面の情報量」に圧倒されがちです。
でも実は、探索は 5つの部品 さえ理解すれば動かせます。逆に言うと、最初にここを押さえないと、どれだけ触っても「なんとなく操作」から抜けられません。
このセクションでは、細かい機能説明は捨てて、最小限で“使える理解に絞ります。
① 変数：材料（ディメンション / 指標 / セグメント）
探索は料理に似ています。
変数 = 材料。材料がないと、何も作れません。
- ディメンション：切り口（例：参照元/メディア、ページパス、デバイスカテゴリ）
→「どこで分けて見るか」 - 指標：数値（例：セッション、ユーザー、キーイベント数、セッションのキーイベント率）
→「何を良し悪しの判断に使うか」 - セグメント：比較グループ（例：Organicだけ、mobileだけ、新規ユーザーだけ）
→「AとBを比べるための“枠”」
ここでのコツは1つ。
最初は ディメンション1個＋指標1個で十分です。材料を盛るほど、原因がぼやけます。
② タブの設定：盛り付け（行・列・値・フィルタ）
次に「材料をどう並べて見せるか」です。
探索の結果を決めるのは、ほぼここです。
- 行：縦に並べる切り口（例：参照元/メディア）
- 列：横に並べる切り口（例：デバイスカテゴリ）
- 値：表示したい数値（例：セッション、キーイベント数）
- フィルタ：条件で絞る（例：page_path に「/ga4/」を含む＝記事だけ）
迷子にならないための鉄則は、これです。
行 → 値 →（必要なら）列 → 最後にフィルタ
いきなり列やフィルタから入ると、構造が崩れて原因が見えなくなります。
③ 可視化：まずは表だけでOK
探索にはグラフや複雑な可視化もありますが、今回では捨ててOKです。
初心者が最初にやるべきは 「表で原因を特定する」 こと。
なぜなら、改善の現場で必要なのは「映えるグラフ」ではなく、
- どの流入が悪いか
- どのページが悪いか
- どのデバイスだけ悪いか
を、言い切れる表だからです。
まずは 自由形式（表） で、原因特定の筋肉をつけましょう。
④ 期間：比較できる固定期間が基本
探索で地味に多い事故が「期間ミス」です。
期間がブレると、同じ探索でも数字が変わってしまい、判断できません。
基本はこれだけ守ればOKです。
- まずは直近28日（データ量が足りない場合は直近90日）
- 改善前後を見るなら 比較（前の期間） を使う
- 週末・祝日でブレるサイトは 週単位で揃える（例：月〜日で固定）
探索は「原因特定」なので、期間が揺れると原因が“外部要因”と混ざります。
期間は固定してから、切り口を変える。これが順番です。
⑤ 数字が合わないときの考え方（まず疑う3点だけ）
「標準レポートと探索で数字が違うんですが…」は、初心者のあるあるです。
ここで詰まると手が止まるので、Day16では 疑うポイントを3つだけ覚えておきます。
- 期間：日付が同じか（比較も含めて揃ってるか）
- 定義：見ている指標が同じか（ユーザー/セッション/イベントを混同してないか）
- 絞り込み：フィルタやセグメントで“自分で狭めていないか”
まずはこの3つを確認して、合っていれば「多少の差」は深追いしなくてOKです。
今日のゴールは完璧に一致させることではなく、改善に使える原因特定ができることです。
ここまでのまとめ：探索は「材料×並べ方×比較」だけ
探索を難しく見せているのは、画面ではなく“順番”です。
やることはシンプルで、
- 変数（材料）を用意して
- タブの設定（並べ方）で表を作り
- 期間を固定して
- 必要ならセグメント（比較）で原因を絞る
これだけ。
次のセクションでは、この5要素を使って 「最小構成の探索テンプレ（まず1枚）」 を実際に作ります。ここを作れれば、探索はもう怖くありません。
最小構成（テンプレ1）自由形式で「まず1枚作る」
探索で一番大事なのは、機能を覚えることではなく 1枚作れる状態”になることです。
ここでは、迷子にならないために 最小構成テンプレ を固定します。
ゴール：探索で「参照元ごとの現状」を1枚で説明できる表を作る
（この1枚が、後でLP/離脱/ファネルにつながる土台になります）
テンプレ1：参照元/メディア × セッション（自由形式）
まずは入口の整理から。
流入元別の改善をする前に、どこが強くてどこが弱いかを1枚にします。
1) 作るもの（完成イメージ）
- 行：参照元/メディア
- 値：セッション
- （余裕があれば）値：セッションのキーイベント率 or キーイベント数
→「量（来ているか）」と「成果（働いているか）」を同じ表で見れる状態
手順
- GA4 → 探索
- 自由形式 →「空白」で開始
- 左の「変数」で追加
- ディメンション：参照元/メディア
- 指標：セッション（＋余裕があれば キーイベント数 / セッションのキーイベント率）
- 「タブの設定」で配置
- 行：参照元/メディア
- 値：セッション（＋必要なら成果系指標）
- 期間：直近28日（迷ったらこれ）
ここまでで、探索の最低限は完成です。
読み方（この1枚で言えること）
この表からは、最低でも次の2つが言えます。
- どの流入が量を運んでいるか（セッションが多い参照元）
- どの流入が成果に近いか（キーイベント率やキーイベント数が強い参照元）
よくあるのはこのパターンです。
- SNS：セッションはあるが、成果が弱い
- Organic：セッションは少ないが、成果が強い
- Referral：特定の参照元だけ極端に強い/弱い
この時点では、まだ「改善案」は出さなくてOKです。
今回の目的は、問題を言い切れる形にすること。改善は次のセクションで「切り分け」してからで十分です。
つまずきポイント（出ない/変になる時の原因3つ）
「何も出ない」「変な表になった」は、ほぼこの3つです。
- 行にディメンションを入れていない
→ 参照元/メディアは「変数に追加」しただけだと表示されません。必ず「行」へ。 - 値に指標が入っていない
→ セッションを「値」に入れてないと数字が出ません。 - 期間が短すぎる/違う
→ 直近7日は少なすぎてブレます。まず28日で固定。
次にやること（この1枚を改善に繋げる準備）
このテンプレが作れたら、次のステップは簡単です。
- 「弱い流入」を見つけたら → LP（着地ページ） まで落として原因を見る
- 「成果が弱い」と分かったら → 離脱やファネル で“どこで止まったか”を探す
つまりこの1枚は、シリーズ全体の“分岐点”になります。
次のセクションでは、このテンプレに 列（デバイス） や フィルタ（記事/LPだけ） を足して、原因を一段ずつ絞っていきます。
拡張の順番（迷子防止）「1個ずつ足す」ルール
探索で失敗する一番の原因は、最初から盛りすぎることです。
ディメンションも指標もセグメントも一気に入れると、確かにそれっぽい表はできます。でも、何が原因で数字が動いたのか分からず、改善に繋がりません。
ここからは、前セクションで作った最小テンプレに対して、拡張は必ず1個ずつ。
順番はこの4つだけでOKです。
①列（比較軸）→ ②フィルタ（対象を絞る）→ ③行の追加（ページに落とす）→ ④成果指標を足す
※セグメントは次のH2でまとめて扱います
拡張①：列に「デバイスカテゴリ」を追加（mobileだけ悪い？を一発で見る）
最初に足すべきは、列＝比較軸です。
理由はシンプルで、改善の現場で一番多い原因が「デバイス差」だから。
やること
- 列：デバイスカテゴリ（mobile / desktop / tablet）
- 行：参照元/メディア（そのまま）
- 値：セッション（そのまま）
これで分かること
- OrganicはPCで強いが、mobileで弱い
- SNSはmobileに偏っていて、desktopはほぼ来ない
- 特定流入だけmobileで極端に悪い
ここで初めて「直すべき場所」が具体になります。
たとえば SNS×mobileだけ弱い なら、改善対象は「SNS投稿」ではなく、mobileの着地体験（LP/ファーストビュー/表示速度）の可能性が高い、というように仮説が立てやすくなります。
拡張②：フィルタで対象を絞る（記事だけ / LPだけ）
次にやるのは フィルタです。
全ページ混ぜると、ブログ記事と問い合わせページが同居して判断が崩れます。
例：記事ページだけに絞る
- フィルタ：ページパス（page_path） に「ga4」を含む
（あなたのサイト運用ルールに合わせてOK）
例：特定のLPだけに絞る
- フィルタ：ページパス ＝
/lp/xxxxx/のように完全一致（または含む）
対象を絞ってから比較すると、数字の解像度が一気に上がります。
逆に、対象を絞らずに比較すると「結局どのページの話？」が残って、改善が止まります。
拡張③：行に「ページ」を足して、原因をページ単位に落とす
探索は最終的に、ページ（または導線）まで落とさないと改善案に変換できません。
なので、次は行にページ系ディメンションを追加します。
おすすめはこの順番です。
- まず：ページパス（URLで確実に判定できる）
- 次に：ページタイトル（読者向けに分かりやすい）
例：参照元/メディア → ページパス まで落とす
- 行：参照元/メディア →（第2階層として）ページパス
- 値：セッション
これで「どの流入が」「どのページに着地して」「弱いのか」が言えます。
改善が作業ではなく診断になります。
拡張④：成果指標を足す（見るべきは量より質）
最後に、成果系の指標を追加します。
探索で最も価値が出るのは、「来ているか」より 働いているかを見たときです。
最低限おすすめはこのどちらか。
- キーイベント数（成果の絶対数を見る）
- セッションのキーイベント率（効率を見る）
ここまでくると、同じ流入でも意味が変わります。
- セッションは多いが、キーイベント率が低い → 集客の質が低い（訴求ズレ/導線ズレ）
- セッションは少ないが、キーイベント率が高い → 伸ばす価値が高い（SEO強化/導線強化）
多い＝良いから抜けられるのが探索の強さです。
NG例：一気に盛って「原因が分からない探索」になる
最後に注意点。これをやると、探索が一気に死にます。
- ディメンションを3つ以上同時に入れる
- 指標を5つ以上並べる
- セグメントもフィルタも同時に入れる
- 期間を頻繁に変える
探索は「当てる」ではなく「絞る」ための道具です。
だから、拡張は必ず1個ずつ。何を足したら何が変わったかが追える状態にしましょう。
次のセクションでは、ここまでの表に セグメント比較を入れて、原因特定をもう一段深くします。
セグメント比較が原因特定を一気に進める（探索の本領）
前セクションまでで「表は作れる」状態になりました。
でも、ここで止まると探索はただの見やすいレポートで終わります。
探索が本当に強いのは、セグメント比較で原因を切り分けられるところです。
同じ「数字が悪い」でも、誰の数字が悪いのかが分かれば、打ち手は一気に絞れます。
セグメントとは？（一言で）
セグメント＝比較用の“グループ分けです。
「全体」では見えない差を、A/Bで比べて浮かび上がらせます。
- 例）mobile と desktop を比べる
- 例）Organic と Social を比べる
- 例）新規ユーザー と リピーター を比べる
ポイントは、セグメントは「細かく作るほど良い」ではなく、
原因が変わりやすい軸から切ることです。
まず切るべき優先順位（この順でやれば迷わない）
初心者が最短で結果を出すなら、セグメントはこの順番です。
- デバイス（mobile / desktop）
- 流入（Organic / Social / Referral など）
- 新規 / リピーター
理由はシンプルで、改善の現場で原因になりやすい順だからです。
（デバイス差はUI/速度/CTA配置に直結、流入差は訴求ズレに直結、新規/リピは設計思想が変わる）
具体例：mobile vs desktop でどこが悪いかを言い切る
H2-3のテンプレ（参照元/メディア×セッション）を土台に、セグメントを2つ作ります。
1) 作るセグメント（例）
- セグメントA：デバイスカテゴリ＝mobile
- セグメントB：デバイスカテゴリ＝desktop
2) 見るべきは「差が出る場所」
たとえば、こういう結論が出ます。
- SNS流入だけ、mobileで成果が弱い
→ 投稿文の問題ではなく、mobileのLP体験が原因候補 - Organicはdesktopは強いが、mobileで落ちる
→ 表示速度 / ファーストビュー / 文字サイズ / CTA位置が原因候補
重要なのは「悪い」で止めないことです。
探索の価値は、悪いのはどれかを特定できることにあります。
具体例：Organic vs Social で訴求ズレを見つける
次に流入で切ります。ここでの狙いは、入口の期待値がズレていないかを見ること。
セグメント例
- セグメントA：デフォルトチャネルグループ＝Organic Search
- セグメントB：デフォルトチャネルグループ＝Organic Social（または Social）
これで見えること
- Socialだけ キーイベント率が低い
→ SNSの投稿内容と、LPの内容がズレている（期待値不一致） - Organicだけ 特定記事で極端に弱い
→ 検索意図と記事の答えがズレている（SEOの中身の問題）
ここまで言えると、「CTAを増やす」みたいな雑な改善から卒業できます。
直すべきは 投稿なのか LPなのか 記事本文なのか、優先順位が自然に決まります。
セグメント比較でやりがちな失敗（これだけ避けて）
セグメントは強い反面、やり方を間違えると判断がブレます。初心者はこの3つだけ避けてください。
- セグメントを増やしすぎる（3つ以上）
→ まずは2つで十分。差が出たら深掘り。 - 期間をコロコロ変える
→ 期間固定が前提。変えると差の理由が分からなくなる。 - “差がある＝原因確定”と断定する
→ セグメントは「原因候補を絞る道具」。確定は次の検証で行う。
まとめ：探索の勝ち筋は「比較→差→原因候補」
探索で結果を出す人は、いつも同じ手順です。
- 2つに分けて比べる（セグメント）
- 差が出る場所を特定する（ページ/流入/デバイス）
- 原因候補を1つに絞る（仮説）
次のセクションでは、この結果をそのまま使って、探索を 「事実→仮説→次の一手」 に変換します。ここまでできれば、探索は作って終わりになりません。
探索でありがちな落とし穴はこれです。
- 表は作れた
- 差も見えた
- でも、何をすればいいか決められない
原因はシンプルで、探索結果を「改善の言葉」に翻訳できていないからです。
ここでは、探索を見た瞬間に次の一手まで落とすテンプレを渡します。
✅ ゴール：探索の結果を、誰が見ても伝わる「改善メモ」にする
（これができると、月次レポートにもそのまま転記できます）
改善テンプレ（コピペ用）
以下をそのまま埋めるだけでOKです。
①事実（どこが悪いか）
- どの流入が：＿＿＿＿
- どのページで：＿＿＿＿
- どの条件で：＿＿＿＿（例：mobile / 新規 / 特定期間）
- 何が悪い：＿＿＿＿（例：キーイベント率が低い / 離脱が高い）
②仮説（なぜ悪いか：原因候補は1つ）
- 原因候補：＿＿＿＿（例：期待値ズレ / CTAが見えてない / 読む前に離脱）
③次の一手（1個だけ）
- 施策：＿＿＿＿（例：FVに結論を前出し / CTA位置を1箇所だけ変更）
- 検証：＿＿＿＿（例：1週間後に同じ探索でキーイベント率を比較）
ポイントは2つです。
- 仮説は1つに絞る（複数にすると検証できない）
- 施策も1個に絞る（複数にすると何が効いたか分からない）
例：探索結果を改善メモに変換してみる
（あくまで型の例です。あなたの実データで置き換えてください）
①事実
- どの流入が：Social（X / Instagram）
- どのページで：GA4初心者向けの入口記事（/ga4/〜）
- どの条件で：mobile
- 何が悪い：セッションはあるが、セッションのキーイベント率が低い
②仮説（原因候補1つ）
- SNS投稿の期待値と、LP冒頭の内容がズレていて
「知りたい答え」が最初に出ていない（＝読む前に離脱）
③次の一手（1個だけ）
- 施策：ファーストビューに「この記事で分かること3つ」を追加（結論を前出し）
- 検証：1週間後に、同じ探索で Social×mobile のキーイベント率を比較
これが“探索→改善”の最短形です。
立派な施策を考える必要はありません。小さく直して、数字で確認できれば勝ちです。
施策アイデアは「ズレ」「摩擦」「導線」の3カテゴリで出す
仮説が出ない人は、原因候補の引き出しが少ないだけです。
探索から出やすい原因は、だいたいこの3つに収まります。
- ズレ（期待値不一致）
- 流入（広告/SNS/検索）で見た内容と、LP冒頭が違う
- タイトルは強いが、本文が答えていない
- 摩擦（読む/動くの邪魔）
- mobileで見づらい、読みづらい、表示が遅い
- CTAが小さい/遠い/分かりにくい
- 導線（次が分からない）
- 関連記事が弱い、内部リンクがない
- CTAがどこにあるか分からない（または多すぎて迷う）
探索で「どの条件だけ悪いか」が分かれば、上のどれかに当てはめるだけで仮説が出ます。
検証のコツ：同じ探索を保存して繰り返す
改善が続かない最大の理由は、検証が面倒だからです。
探索は作り捨てにせず、テンプレとして保存してください。
- 今回作った探索を保存（例：
Day16_流入×デバイス×成果） - 施策を1つ打つ
- 1週間後、同じ探索を開いて比較
これで、改善が「気合」ではなく「運用」になります。
月次レポートにも、そのまま「事実→仮説→次の一手」として転記できます。
探索は「原因特定の型」を持てば、改善が再現できる
探索レポートは、自由に分析できる“便利機能”ではありません。
標準レポートで見つけた異常に対して、原因を切り分けて言い切るための道具です。
この記事で押さえたポイントは、結局この3つでした。
- 最小構成1枚（自由形式）をまず作る
→「参照元/メディア × セッション（＋成果）」で入口の現状を言語化する - 拡張は 1個ずつ足す
→ 列（デバイス）→ フィルタ（対象を絞る）→ 行（ページに落とす）→ 成果指標 - 仕上げは セグメント比較
→ 「誰の数字が悪いか」を特定して、改善対象を狭める
そして、探索が作って終わりにならないように、最後は必ずこの形に変換します。
事実（どこが悪い）→ 仮説（なぜ悪い：1つ）→ 次の一手（施策も1つ）→ 検証（同じ探索で比較）
この型さえ持てば、改善は思いつきではなく、手順になります。
逆に言うと、探索で上達する人は「機能を覚えた人」ではなく、同じ型で何回も検証した人です。
今日やること（5分でOK）
- 探索（自由形式）で 参照元/メディア × セッション の表を1枚作る
- 列に デバイスカテゴリ を足して、差が出る流入を見つける
- 弱いところを1つ選び、改善メモを1行で書く
- 事実：＿＿＿が＿＿＿で弱い
- 仮説：原因は＿＿＿かも
- 次：＿＿＿を1つだけ変えて検証
次のステップ（内部リンク：ここから改善回に繋げる）
探索で「弱い場所」が見つかったら、次はテーマ別に深掘りです。
- 入口（どこから来たか）を改善したい
→ 【GA4実践】流入元別の改善施策｜参照元ごとのKPI設定と次の打ち手 - 着地（どのLPに降りたか）を改善したい
→ 【GA4実践】ランディングページの改善施策｜流入元別のLP最適化と次の打ち手 - 終点（どこで止まったか）を改善したい
→ 【GA4実践】離脱ページの分析と改善｜「止まってる場所」を特定して次の一手まで落とす - 途中（どこで落ちたか）を改善したい
→ 【GA4実践】コンバージョンファネル分析｜落ちる場所を特定して改善案まで落とす（探索テンプレ付き）
今回の記事は、シリーズ全体でいうと「改善回を回すための基礎体力」です。
まずはテンプレ1枚を保存して、来週も同じ探索で比較してください。
それだけで、GA4が見るだけから使って改善するに変わります。
