今回の計測（1回ぶん・毎回揺れる）
累計で「最下位」に選ばれた回数
計測ボタンを押すと、1回ぶんの通過率が表示されます。
1回きりの計測だと最下位の段階が回ごとに入れ替わり、弱点を名指しできない。何度も繰り返して均していくと、「詳細閲覧→登録」だけが判で押したように最下位へ沈む。1回の数字ではなく、繰り返し現れる段階を離脱ポイントと見なす。これがファネル分析の出発点になる。
GA4/GTMのイベント設計とタグ構成
GA4は「ページビュー」よりも「イベント」を軸に設計するのが基本思想で、ボタンクリック・スクロール到達・フォーム送信といった行動それぞれをイベントとして送信する。GTM（Googleタグマネージャー）を挟むと、コード修正なしにイベント発火の条件（トリガー）を管理画面から追加・変更できるようになり、計測の追加が実装のボトルネックになりにくくなる。
計測対象のページ（触ってみる）
プランA
月額980円・広告なし
25 / 50 / 75 / 100% の到達時に一度だけ scroll_depth が発火する
送信されたイベント（新しい順）
まだイベントがありません。左のページを操作してみてください。
ボタン1つ、スクロール1回が、その場で「イベント名＋パラメータ」に変換されてログへ流れていく。どの行動を、どんな名前と粒度で送るのか——その対応表を引くのがイベント設計の実務だ。
ミニページ（要素をクリック）
タグ発火ログ（新しい順）
条件を選んで、左の要素をクリックしてみてください。
同じクリックでも、トリガーの条件しだいで発火したりスルーされたりする。「何を送るか」の前に「どんな時に送るか」を切り出しておく。この判定をコードの外に置けるからこそ、計測の追加が実装待ちにならずに済む。
ファネル分析・離脱ポイントの特定
「訪問→一覧を見る→詳細を見る→申込」のような一連の流れをファネルとして定義し、各段階での通過率を見る。数値が急落する段階が離脱ポイントであり、そこにボトルネックがある可能性が高い。ファネル自体を正しく設計するには、各段階に対応するイベントが漏れなく送信されている必要がある。
いま +5pt の改善が最も効くのは「詳細閲覧 → 登録」（+18人）。改善の優先順位は感覚ではなく、この掛け算から決められる。
最終CVは各段階の通過率の掛け算だから、いちばん低い段階を少し持ち上げるのが最も効く。冒頭のデモが弱点を「見つける」体験なら、こちらは見つけた後に「どこへ手を入れるか」を決める体験。
訪問が少ないと信頼区間が広く、9.5%が5%にも14%にも見えてしまう。冒頭のデモで数字が毎回揺れたのはこれ——サンプルが増えるほど帯は狭まり、初めてファネルの差を信じられる。
段階が落ちていると判断する前に、その数字が信頼に足るだけの訪問を集めているかを確かめたい。訪問が少ないうちは通過率が大きくブレるので、わずかなデータで離脱ポイントを断じると、ただのノイズを犯人に仕立ててしまう。
ヒートマップ・セッション録画ツールの使い分け
ヒートマップは「どこがクリックされているか・どこまでスクロールされているか」を面で俯瞰するのに向き、セッション録画は「なぜこの人は離脱したのか」を個別の行動から読み解くのに向く。数値（GA）で異常を見つけ、録画で理由の仮説を立てる、という組み合わせが実務では機能しやすい。
1クリックずつは点でしかないが、何度も同じ辺りを押すと色が濃く溜まる。ヒートマップは個別の理由ではなく「面としてどこに注目が集まるか」を俯瞰する道具。
1クリックは点にすぎないが、何百と積もれば面になり、注目の偏りが色の濃さとして立ち上がる。個人の理由ではなく集団の傾向を俯瞰する——ヒートマップが得意なのはそちらだ。
軌跡は申込ボタンの手前で止まり、輪をかいて迷ったあと引き返す。録画は「なぜ押さなかったのか」という個別の理由の仮説を、数値のあとに与えてくれる。
ヒートマップが集団を面で捉えるのに対し、録画はたった1人の軌跡を時間軸で追う。申込ボタンの手前で輪をかいて迷い、押さずに引き返す。面では見えない「なぜ」の手がかりは、こうした1本の録画から立ち上がってくる。
計測とプライバシー配慮の両立
個人を特定できる情報（氏名・メールアドレス・入力値そのもの）をイベントパラメータに含めないことが大前提になる。Cookieを使わない計測（サーバーサイド集計・軽量なself-host解析）を選ぶことで、同意管理の複雑さを避けつつ、PV・イベントの集計だけで多くの改善判断は可能になる。
分析基盤に送られるペイロード
{
"event": "sign_up",
"user_id": "(計算中)",
"message_length": 10
}氏名は送らず、メールは同一人物の識別だけができる不可逆なハッシュに。中身は復元できない。
生のまま送れば、氏名もメールも分析基盤にそのまま積み上がってしまう。氏名は送らず、メールは復元できないハッシュに変える。すると「同じ人か」の識別だけを残して、中身は誰にも読めなくなる。何を送らないかを決める設計が、そのままプライバシー配慮になっている。
Cookieは同意した人しか数えられず真値に届かない。一方Cookielessは全員拾えるが、 個人を識別しないぶん同じ人の再訪を重複して数え、今度は行き過ぎる。どちらも真値は外すが、 外し方の向きが逆——「誰か」を捨てて母数を取るか、母数を諦めて一意性を守るかの選択になる。
Cookie計測は同意した人しか数えられず、真の訪問数に届かない。Cookielessなら全員を拾えるが、個人を識別しないぶん同じ人の再訪を重複して数え、今度は行き過ぎる。どちらも真値は外すのに、外れる向きは正反対だ。「誰か」を捨てて母数を取るか、母数を諦めて一意性を守るか。どちらの誤差と付き合うかを選ぶことになる。
訪問経路はまったく同じなのに、モデルを変えるだけで「手柄」が別のチャネルへ移る。どのチャネルに投資すべきかの結論は、計測値そのものより「どう割り振ると決めたか」に左右される。
訪問経路はまったく同じなのに、割り当てモデルを変えるだけで各チャネルの「手柄」は移ろう。計測値そのものは客観的でも、そこから導く投資判断はモデルの選び方という主観に委ねられている。数字を扱う仕事の最後には、どうしても人の判断が残る。