SaaSのアクティベーション・ファネルをGA4で測る — 登録から初回成果までのイベント設計ガイド

登録数のグラフは毎週ちゃんと右肩上がり。なのに「で、そのうち何人が使い始めたの？」と聞かれると答えに詰まる。SaaSにGA4を入れただけだと、追えるのはたいてい登録完了までだ（GA4は玄関の人数を数えるのは得意だが、奥の部屋まではついてこない）。

筆者らはシフト作成サービス Shift Bud で、登録から最初のシフト表を確定するまでを6段のイベントで測っている。その設計を、自分のプロダクトに置き換えられる形でまとめる。サイトの問い合わせフォームの離脱を測る話はGA4のコンバージョンファネル計測の記事に書いたので、今回はプロダクトの中の話だ。

ゴールから逆算して6段に切る

最初に決めるのは、いちばん奥の部屋、つまりユーザーが「これは使える」と感じる初回成果だ。シフト作成なら、自動で作った表を保存して確定したとき。登録はまだ玄関にすぎない。間の段は、初回成果までに欠かせない操作を手前から並べる。

段	イベント	送るとき	他のSaaSなら
1	signup_start	登録フォームに最初に入力した	同じ
2	sign_up	登録が成功した	同じ
3	email_verified	メール認証が成功した	同じ
4	staff_invited	メンバーの招待が成功した	取引先の登録、メンバー招待
5	shift_generated	自動作成の結果が画面に出た	下書きができた
6	shift_confirmed	結果を保存した	確定した、送った

肝は5段目と6段目を分けることだ。結果は見たのに保存せず閉じた人が、ここで初めて見える。2段目の sign_up はGoogleの推奨イベントの名前だ。筆者らは独自の名前で送っているが、これから決めるなら推奨イベントの一覧に同じ意味のものがないかを先に見ておきたい。

数字を盛らないための4つのルール

段を決めても、送るタイミングがゆるいとファネルの率はもっともらしい嘘をつく。

1. 成功してから送る: ボタンを押した瞬間に送ると、失敗した登録まで数えて率が良く見える。1段目だけは、画面を開いたときではなく最初の入力で送る。開いただけのボットを数えないためだ
2. 作った段と確定した段を分ける: 上の5段目と6段目
3. 1人1回の段は二重に数えない
4. デモの訪問者を入れない: 未登録で試せるデモがあるなら、そこからは送らない

3つ目は、筆者らの実装でもレビューで引っかかった。メール認証のAPIは、認証済みの人が同じリンクを開き直しても成功を返す作りだった。そのため、開くたびに email_verified が届く実装になっていた（同じ人を毎回律儀に数えてくれる）。ファネルデータ探索はユーザー単位で数えるので率への影響は小さいが、キーイベントの件数は膨らむ。

直し方は、サーバーが「初回の認証か」を返して初回だけ送るか、サーバーから送るかだ。後者はGA4の Measurement Protocol を使う。登録した画面の client_id をサーバーに保存しておき、それを付けて送る。保存した値ではなく別の client_id で送ると、画面側のイベントとは別の人として数えられる。公式も、Measurement Protocol をタグによる収集を補うものと位置づけている。

画面側で sessionStorage に送信済みの印を付ければ済みそうに見える。実際は、これはタブごとの保存領域だ。メールのリンクはたいてい新しいタブで開くので、認証の重複は止まらない。止まるのは、同じタブでの再読み込みや、開発時に React の Strict Mode が effect を余分に走らせる分までだ。

もう1つ決めておくことがある。件数そのものはDBで数え、GA4は段の間の率を見る道具にする。広告ブロッカーなどで届かないイベントがある前提だ。

GA4の画面でやること

以下の上限は、無料の標準プロパティの値だ。

• キーイベント: 管理画面の「データの表示」→「イベント」で星を付ける。まだ届いていないイベントは、「+ イベントを作成」で名前を入れ、「キーイベントとしてマークを付ける」をオンにすれば先に登録できる。上限は30個なので、登録・認証・招待・確定のような節目に絞る。付ける前のデータは変わらない
• ファネルデータ探索: 「探索」から作る。ステップ（この記事の段）は最大10個。最初の段を通った人だけを数えるクローズド型にする。オープン型だと、招待で参加したメンバーのように途中の段から入った人も数えられる
• 内訳の注意: ユーザーはファネルに入った時点の値で、全段に振り分けられる。5段目から付く scope（月単位か日単位か）は、6段のままだと入口の時点では空なので、月単位と日単位に分かれない。比べたいなら、5段目と6段目だけの2段のファネルを別に作る（scope は下のカスタムディメンションに登録してから使う）
• DebugView: 公開前に、段ごとのイベントが1回ずつ届くかを見る。映るのは debug mode を有効にした端末だけだ。gtag.js なら config に debug_mode: true を足すか、Tag Assistant で有効にする。debug_mode は公開前に行ごと外す（false にしても止まらない）。2回届いたら、認証リンクと同じ穴を疑う

送るパラメータは、値の種類が少ないものだけにする。1イベント25個、値は100文字まで。イベント名は40文字までで、大文字と小文字は区別される（Sign_up と sign_up は別のイベントになる）。IDやタイムスタンプのように値が多いものは「(other)」の行にまとめられやすくなる（細かく送ったつもりが、まとめて「その他」で返ってくる）。メールアドレスや氏名は規約で送れない。自作のパラメータはカスタムディメンションに登録すると、24〜48時間後から使える。登録の手順はAIアシスタント経由の流入を測る記事に書いた。

AIエージェントに任せるときの指示

送信のコードはエージェントに頼めばすぐ出てくる。外しやすいのは「いつ送るか」のほうだ。

指示すること	言わないと起きること
段ごとの名前・送る瞬間・パラメータを表で先に出させ、人が確認してから実装させる	ボタンのクリックで送る実装になる
失敗・デモ・2回目のように送らない場合もテストさせ、送った中身をパラメータまで厳密に照合させる	IDがパラメータに紛れても気付かない
サーバーが同じ操作の2回目に何を返すかを読ませる	認証リンクの開き直しで件数が膨らむ
星・カスタムディメンション・探索の画面作業を、PR本文に手順として残させる	コードはマージ済み、キーイベントも探索も空のまま（誰も星を付けていない）

筆者らも、テストまで揃えて万全のはずが、3行目だけが抜けていた。見つけたのはレビューだ。

まとめ

初回成果を1つ決めて、そこから逆算して段を切る。成功してから送り、下書きと確定を分け、二重カウントとデモを除く。件数はDBで、率はGA4で見る。

まずは自分のプロダクトの初回成果を、1つの操作で言えるか試してほしい。言えたら、そこまでの段を上の表の形に書き出してエージェントに渡せば、実装はすぐ出てくる。Shift Bud も、この6段に沿ってイベントを送っている。