サイトの問い合わせ計測を整えたいWeb・営業担当者
問い合わせボタンを押した数と、正常に届いた相談の数は同じではありません。何が起きた数字なのかを分けると、改善すべき場所が見えます。個人情報を解析へ送らない測定の考え方も整理します。
- 01ボタンを押す
- 02フォームを入力
- 03サーバーで受付
- 04社内で商談化
矢印の順に、自社の状況へ置き換えて確認しましょう。
1. 測りたい段階を先に決める
ボタンのクリック、入力開始、正常受付、商談を分けます。送信を押しただけで『問い合わせ完了』と数えると、エラーや営業投稿が混ざります。
送信ボタンのクリックだけで完了を数えると、入力エラーや通信失敗も成果に混ざります。完了画面の再読み込みで重複計測しないかも確認します。サーバー受付とメール通知は別の状態なので、通知失敗を問い合わせ未受付と混同しない記録が必要です。
2. 個人情報をイベントへ入れない
氏名、メール、相談本文をアクセス解析へ送らないようにします。URLに入れた情報も記録される可能性があるため、設定と実際の送信内容を確認します。
解析には、フォームの種類やページの区分など、必要で個人を特定しない項目を使います。受付番号のような識別子も安易に連携せず、利用目的と取り扱いを確認します。実際の導入では同意管理、プライバシー表示、社内運用も合わせて検討します。

3. 営業の質は受付データで判断する
相談が対象業務に合うかは社内の受付記録で確認します。営業投稿と適合する相談を分け、商談へ進んだ理由や止まった理由を整理します。
商談へ進んだか、何の説明が不足したか、依頼条件が合ったかを社内で記録します。解析の数値と受付件数は、同意、広告ブロック、通信環境、重複などで一致しないことがあります。差分の理由を確認し、GA4をすべての受付の正本として扱わないでください。
4. 公開前と変更後にテストする
正常、入力エラー、拒否、通信失敗を試します。解析の数字だけでなく、受付記録と実際のメール到達も確認してください。画面変更後は再テストします。
レポートでは期間と指標の定義を明記します。たとえばCTAの反応が高くても正常受付が少ないなら、フォームやエラーを調べます。適合相談が少ないなら広告・記事の対象者と説明を見直します。
計測は数字を並べるためではなく、次の改善を選ぶために設計します。
判断に使う比較表
| 段階 | 記録する場所 | 意味 |
|---|---|---|
| CTAクリック | サイト解析 | 導線への反応 |
| 正常受付 | サーバーと解析 | 受付が成立した |
| 適合相談 | 社内の受付管理 | 対象課題と依頼意向 |
| 商談 | 社内の営業管理 | 具体的な検討に進んだ |
相談前のチェックリスト
- イベントの定義を文書にした
- 正常受付後だけ完了を計測する
- 個人情報をURL・イベントへ送らない
- 重複と失敗をテストした
- 解析と受付の差分を確認できる
よくある質問
GA4と問い合わせ件数は一致しますか?
必ずしも一致しません。同意や広告ブロック、通信、重複などの影響があります。受付の正本はサーバー側で管理します。
相談文を送れば分析しやすくなりますか?
自由記述には個人情報が含まれるため解析へ送らないでください。必要な分析は権限と保存条件を管理した社内環境で行います。
NEXT STEP / 次の一歩
自社の場合を、
一緒に整理する。
現在のフォームと、どの行動を成果として数えているかを教えてください。正常受付、通知、解析、商談管理を分けて確認します。
