この記事でわかること
- ▶ 問い合わせを数えるとき、何を「最後の行動」にするかの決め方
- ▶ キーイベントの値とカウント方法を、画面の初期値・推奨のままにしなかった理由
- ▶ 自分のアクセスとテストを、数字に混ぜない方法
- ▶ 数え始めても0のまま。「誰も押していない」と決める前に、問い合わせの入口を洗う
「サイトから問い合わせ、何件来てる?」と経営者に聞かれて、すぐ答えられるだろうか。GA4 は制作会社が入れてくれた。開けば数字は並んでいる。ただ、どの数字が「問い合わせ」なのかが決まっていない。
このブログも同じだった。記事の最後には、30分の無料相談を予約するページ(Calendly)へのボタンを置いている。10月、初めて28日分のアクセスのレポートを取ったら、Calendly へのクリックは0だった。
そこから相談ボタンのクリックを GA4 で数えられるようにした。設定は管理画面だけで済んだ。手間取ったのは別の所だ。数え始めても0のままで、調べると相談の入口の一部が、数えていない古いフォームを向いていた。この記事は、その順番の失敗も含めた実録だ。先に言うと、数える前に入口を洗うべきだった。
▼「問い合わせ、何件?」に答えられなかった:28日で相談0、そもそも数えていなかった
初回のレポートの数字はこうだった(2026年9月21日〜10月18日の28日)。
| 項目 | 28日の数字 |
|---|---|
| Calendly へのクリック | 0 |
| キーイベント(GA4 で成果として数えるイベント。以前の「コンバージョン」) | 0(1つも設定していなかった) |
| 相談ページ(フォームのあるページ)の閲覧 | 6回、平均7秒 |
この0は、GA4 が自動で取っている外部リンクのクリック(click イベント)を掘って、初めて分かった0だった。相談として数える設定(キーイベント)がないので、レポートの入口には何も出てこない。しかも閲覧の多い古い記事は、ボタンの先が Calendly ではなく相談ページで、そこから先(フォームの送信)は GA4 では見えない。分かったのは「相談が少ない」ではなく、「相談を数える仕組みがない」だった。
規模も小さい。検索から来る読者は月110人ほどで、相談率1%でも月1件だ。ボタンの文言や置き場所を直しても、効果が数字に出るのは数か月先になる。だから改善より先に、前後を比べる土台として数え方を決めた。
▼何を数えるか:サイトで取れる最後の行動を、今ある計測で
数える対象は、自社サイトの上で取れる最後の行動に置く。このブログなら、Calendly へのリンクを押すところまでだ。その先の予約は Calendly のサイトで起きるので、ブログの GA4 には残らない。
候補は4つ。数えるのは Calendly へのクリック
| 候補 | 自社サイトの GA4 で取れるか | 判断 |
|---|---|---|
| 相談ページの閲覧 | 取れる | 見ただけで相談するとは限らない(平均7秒で離れていた)。補助にとどめる |
| Calendly へのクリック | 取れる。外部サイトへのクリック(click イベント)に、リンク先のドメイン(link_domain)が入る | これを数える |
| Calendly の GA4 連携(予約の完了を送る) | Calendly 側の機能。無料プランでは使えない(料金表、2026年10月時点) | 今回は検討していない。予約の完了まで見たくなったときの候補 |
| (自社サイトのフォームの場合)送信完了の画面の表示 | 取れる(完了画面の URL で絞る) | フォームなら、これが「最後の行動」になる |
フォームの場合の補足。GA4 には「フォームの操作」(form_submit)を自動で記録する機能もある。ただ公式ヘルプの説明は「フォームを送信したとき」までで、送信が成功したときに限るとは書かれていない。確実に数えたいなら、送信が終わったときにしか出ない完了画面の表示を使う方が迷わない。ただし、フォームによっては完了画面が別の URL にならず、同じページに「送信しました」と出るだけのものもある。その場合は、どうやって送信の完了を数えるかを制作会社に聞く。
GTM を入れなかった理由
クリックの計測というと、Google タグマネージャー(GTM)を入れる話になりがちだ。入れなかった。理由は2つある。
- ▶ 必要なデータはもう取れていた。GA4 の拡張計測(自動で取る計測)の外部リンクのクリックが動いていて、ほかのサイトへのクリックはリンク先のドメイン付きで記録されていた
- ▶ 道具を増やすと、保守する物が増える。GA4 は WordPress のプラグイン(Site Kit)が入れている。GTM を足すと、同じ計測を二重に送らないかを気にし続けることになる
今ある計測で取れるなら、道具は増やさない。必要になったのは、GA4 の管理画面で既存の click イベントから新しいイベントを作ることだけだった。
既存の click から作る:画面の2択で迷った
GA4 の管理 →「イベント」→「イベントを作成」を開くと、「コードなしで作成」と「コードを使用して作成」の2択が出る。作業を手伝っていた AI(Claude)は「コードなしで作成じゃない方」と案内した。これは間違いだった。既存のイベントを条件にして作る画面は、「コードなしで作成」→「その他のオプションを表示」の奥にあった。
公式ヘルプも、2択から始まるページと、「作成」ボタンだけの古い手順のページが混ざっていた。GA4 の画面は変わる。手順はボタンの名前で覚えず、開いた画面で「既存のイベントを条件にできるか」を確かめる。そこさえ合っていれば、設定はこれだけだ。
| STEP | 設定 |
|---|---|
| 1 | イベント名を calendly_click にする |
| 2 | 条件:event_name が click と等しい、かつ link_domain が calendly.com を含む |
| 3 | 「ソースイベントからパラメータをコピー」をオン(どのページで押されたかを残すため) |
| 4 | キーイベントにする(値とカウント方法は次の節) |
▼初期値のままにしなかった2か所:値とカウント方法
キーイベントにするとき、画面には最初から入っている値と、「推奨」と書かれた選択肢がある。どちらも、自分が知りたいことと一致しているとは限らない。何を知りたいかで決める。
| 項目 | 画面に入っていたもの | 選んだもの | 理由 |
|---|---|---|---|
| キーイベントの値 | 1(米ドル)※自分の画面では | 設定しない | 相談のクリックは売上ではない。金額が付いていると、あとで見た人が売上の数字と読み違える |
| カウント方法 | 「イベントごとに1回(推奨)」 | 「セッションごとに1回」 | 知りたいのは押された回数ではなく、相談しようとした訪問の数 |
カウント方法は、少し正直に書いておく。選んだときの気持ちは「相談しようとした人の数を見たい」だった。1回の訪問で迷って2回押しても、1と数えたい。ただ「セッションごとに1回」が数えるのは、厳密には訪問(セッション)の数で、人の数ではない。同じ人が別の日にまた来て押せば2になる。
人の数で見たいときは、レポートの「エンゲージメント」→「イベント」で calendly_click の行の「合計ユーザー数」を見る。ただし GA4 のユーザーも、ログインのないサイトではブラウザ単位だ。同じ人がスマホと PC で押せば2人になる。どの数え方にもずれはある。どのずれを許すかを決めて、書き残しておく。
なお「セッションごとに1回」は、画面では「従来版」と書かれている。押された回数そのものに意味があるときは、推奨の「イベントごとに1回」が合う。たとえば、同じページの上と下にボタンを置いて、どちらがよく押されるかを比べたいときだ。今のこのブログが知りたいのは置き場所の比較ではなく「相談しようとした訪問があったか」なので、こちらを選んだ。
▼自分のクリックを数えない:除外の設定と、漏れる経路をテストのやり方で埋める
設定した日に、自分で記事のボタンを押して、GA4 のリアルタイムのレポートに click と calendly_click が出ることを確かめた。calendly_click の1件目は、自分のテストだった。月に数件の規模では、この1件で数字の意味が変わる。日時と記事を記録して、集計から外した。
同じ日に、WordPress のプラグイン(Site Kit)の設定で、ログイン中のユーザーを計測から外す項目を「All logged-in users」にした。これで外れるのは、WordPress にログインしているブラウザからのアクセスだけだ。スマホで自分の記事を開いたときや、ログアウトしたブラウザからは計測される。
漏れる経路は、設定ではなく運用で埋めた。
- ▶ 普段の確認は、ログインしたブラウザで。計測から外れる
- ▶ 計測のテストは、シークレットウィンドウで。ログインしていないので計測される。やった日時と記事を記録し、集計から外す
- ▶ 設定より前のデータには、自分のアクセスが混ざっている。過去の数字を読むときの注意として残す(実際、公開前のプレビューの閲覧が数字に入っていた)
会社のサイトでも事情は同じだ。社員や制作会社の確認のアクセスは、問い合わせの少ないサイトほど数字を動かす。オフィスの IP アドレスで外す設定もあるが、在宅勤務や外出先からのアクセスは漏れる。制作会社や担当者には「社内のアクセスとテストを、どう外しているか」を聞いておくとよい。
▼数え始めても0のまま:全87本中26本とヘッダーが古いフォームを向いていた
calendly_click を作ったのは10月21日。同じ日に、閲覧の多い古い記事など6本の相談ボタンを、相談ページ経由から Calendly への直リンクに変えた。
2日後の23日に数字を確かめた。10月20日〜22日の calendly_click は1件。その1件は、21日の自分のテストだ。Calendly への本物のクリックは0のままだった。
この規模なら、3日で0は珍しくない。ただ「誰も押していない」と結論を出す前に、確かめることがあった。calendly_click が数えるのは、calendly.com に飛ぶリンクのクリックだけだ。相談の入口が相談ページを向いていれば、そこでフォームを選んだ人は数えられない。Calendly を押してくれても、どの記事から来たかは分からない。
全記事の相談ボタンのリンク先を、API で調べた
10月23日の時点で、公開中の記事は87本あった。目で全部は見られないので、WordPress の API で全記事の本文を取り出し、末尾の相談ボタンのリンク先を調べた。87本のうち26本が、Calendly ではなく古い相談ページ(フォームのあるページ)にしかリンクしていなかった。直したのは閲覧の多い記事だけで、残りは古いままだった。
記事の外にもあった。ヘッダーメニューの「お仕事のご相談はこちら」も、相談ページのままだった。どの記事を読んでいても目に入る、一番目立つ入口だ。
相談ページにも Calendly へのボタンはある。そこから押されれば calendly_click には入る。ただし記録されるのは「相談ページで押された」までで、どの記事を読んで相談しようと思ったのかは、そのイベントには残らない。フォームから送られた相談は、そもそも GA4 では数えていない。
23日のうちに、26本の相談ボタンを Calendly への直リンクにそろえ、ヘッダーメニューも Calendly に変えた。フッターの「お問い合わせ」はフォームのまま残した。相談以外の連絡の窓口として、フォームも要るからだ。洗い出した入口は、今こうなっている。
| 入口 | 10月23日より前のリンク先 | 今のリンク先 | calendly_click で数えられるか |
|---|---|---|---|
| ヘッダーメニュー「お仕事のご相談はこちら」 | 相談ページ(フォーム) | Calendly | 数えられる(23日から) |
| 記事末尾の相談ボタン(26本) | 相談ページ(フォーム) | Calendly | 数えられる(23日から) |
| 記事末尾の相談ボタン(残り61本) | Calendly(うち6本は21日に相談ページから変更) | Calendly | 数えられる |
| 記事途中の相談ボタン(6本) | Calendly(21日に、閲覧の多い5本に追加。21日公開の1本にも) | Calendly | 数えられる |
| 相談ページの Calendly ボタン | Calendly | Calendly | 数えられる。ただし、どの記事から来たかは残らない |
| フッター「お問い合わせ」 | 相談ページ(フォーム) | そのまま | 数えない(相談以外の連絡の窓口) |
順番は逆がよかった:数える前に入口を洗う
振り返ると、順番を間違えていた。数える仕組みを先に作り、入口には後から気づいた。21日〜23日の間、26本の記事とヘッダーから相談しようとした人は、相談ページを1段はさむ。そこで Calendly を押せば calendly_click には入るが、どの記事を読んで来たかは残らない。フォームを選べば、GA4 には何も出ない。0かどうかは分かっても、どの記事が相談につながったかは比べられない状態だった。ボタンの文言や置き場所を記事ごとに直して効果を比べたいのに、その土台に穴が空いていた。
正しい順番はこうだ。
- ▶ 1. 入口を洗う:ヘッダー、フッター、記事の末尾と途中、固定ページ、サイドバー。問い合わせにつながるリンクを全部書き出す
- ▶ 2. 行き先を1つに決めてそろえる:その先で取れる最後の行動(予約ツールへのクリック、フォームの完了画面)が数える対象になる
- ▶ 3. 設定する:値・カウント方法・自分の除外
入口を洗うのは、GA4 の作業ではない。サイトの作りの棚卸しだ。ページが数十本を超えると、目で見て回るのは無理がある。このブログは API で全記事の本文を取り出して調べたが、会社のサイトなら、制作会社に「問い合わせにつながるリンクの一覧」を出してもらうのが早い。リニューアルやキャンペーンのたびに入口は増えるので、一度で終わる作業でもない。
▼まとめ:自社サイトの問い合わせを数えるときの判断軸
GA4 を自分で触らなくても、下の右の列を制作会社や担当者に渡せば、数え方の抜けは確かめられる。
| 判断のポイント | このブログで選んだこと | 制作会社・担当者に聞く問い |
|---|---|---|
| 何を数えるか | サイトで取れる最後の行動(Calendly へのクリック) | 問い合わせは、どのイベントで数えているか。それは送信の完了か |
| 入口を全部洗ったか | 全87本とヘッダー・フッターを調べ、相談の入口を Calendly にそろえた | 問い合わせにつながるリンクの一覧はあるか。全部、数えている先を向いているか |
| 道具を増やすか | GTM は入れず、拡張計測の click から作った | タグはどこから入れているか。同じ計測が二重になっていないか |
| 値を付けるか | 付けない(売上ではないので) | キーイベントに金額が入っていないか。入っているなら、その金額の根拠は何か |
| カウント方法 | セッションごとに1回(訪問の数。人の数ではない) | その件数は、押された回数か、訪問の数か、人の数か |
| 社内のアクセスとテスト | ログイン中は除外、テストはシークレットウィンドウで記録して外す | 社員や制作会社のアクセスとテストを、どう外しているか |
10月23日の時点で、Calendly への本物のクリックはまだ0だ。数えられるようになっただけで、増えたわけではない。ただ次に相談ボタンの文言や置き場所を変えたとき、前と後を同じ物差しで比べられる。数字が小さいうちに数え方を決めておくのは、そのためだ。
📄 このブログの全記事を API で書き出し、GitHub で履歴管理している話はこちらの記事で書いています。
📅 30分無料相談、受け付けています
「自社サイトやツールの設定を、誰が何を見て決めればいいか分からない」——そういった段階からお気軽にどうぞ。情シスのいない会社で、IT まわりの判断の仕方から一緒に整えます。
📅 30分無料相談を予約する →