記事の末尾に問い合わせボタンを置いた。アクセス解析にはクリックが記録されている。それでも、届いた相談とのつながりがわからず、記事を増やすべきか、ボタンを直すべきか迷うことがあります。
最初に分けたいのは、問い合わせ先へ進んだことと、問い合わせが受け付けられたことです。クリックは前者の手がかりであり、それだけで後者を確かめることはできません。記事、フォーム、受付のどこまでを記録しているかをそろえると、次に調べる場所を絞れます。
この記事では、Webフォームへ案内する企業メディアを対象に、少人数でも始められる計測の整理方法を提案します。Google アナリティクス4（GA4）のイベントを例にしますが、使うツールより先に「何が起きたら1件とするか」を決めるのが出発点です。
媒体全体でどの指標を選ぶかは、オウンドメディアのKPI設計で扱っています。ここでは、記事からフォームへの案内と、フォームで受け付けた結果を確かめる範囲に絞ります。カバーは編集部作成の概念イラストです。
「問い合わせ1件」の条件を書き出す
アクセス解析のイベントは、閲覧やクリックなどの行動を記録する単位です。イベント名が「問い合わせ」になっていても、いつ記録する設定なのかによって数字の意味が変わります。
たとえば、記事内のボタンを押した時点で記録しているなら、その数字は案内先へ進もうとした回数です。フォームを入力せず戻った場合も含み得ます。送信ボタンを押した時点なら、入力不備や通信失敗で受付が終わらない場合をどう扱うか、別に確かめる必要があります。
最初の整理では、次のように段階を分けてみてください。
| 見たい段階 | 記録する出来事の例 | その数字だけではわからないこと |
|---|---|---|
| 記事から案内先へ進む | 問い合わせリンクのクリック | フォームが表示されたか、相談が届いたか |
| フォームを使い始める | フォームでの最初の入力操作 | 入力を終えたか、送信できたか |
| 問い合わせを受け付ける | 受付処理の成功を確認した後の記録 | 商談になったか、依頼条件が合うか |
この表は計測設計の例です。すべての段階を一度に実装する必要はありません。まず現在のイベントについて、担当者に「何をきっかけに記録するか」を聞き、未計測の段階を空欄にせず「未計測」と書きます。
特に、送信完了を成果として扱うなら、ボタンの操作だけで完了と数えない設計を検討します。フォーム側で受付に成功した応答を確かめ、その後にイベントを送る、といった条件を実装担当者と決めます。これは編集部の設計提案であり、どのフォームでも同じコードで実現できるという意味ではありません。
GA4の自動計測で拾える範囲を確認する
GA4の拡張計測機能には、別のサイトへ移動するリンクのクリックや、フォームの操作を記録する機能があります。フォームでは form_start と form_submit が用意されています。公式説明での form_start は、セッション内で初めてフォームを操作したときの記録です。同じ人の入力操作の総回数とは区別します。
一方、外部リンクのクリック計測を有効にしただけで、同じドメイン内の問い合わせリンクまで記録されるとは考えないでください。公式説明では、現在のドメインを離れるリンクが対象で、クロスドメイン測定を設定したドメインへのリンクも除かれています。
記事とフォームがどこにあるか、既に独自のイベントを追加していないかを確認してから、必要な計測を補います。似たイベントが二つあるときは、両方を足す前に、それぞれの発生条件を調べます。同じ操作を別名で記録しているだけかもしれません。
Googleは、問い合わせのフォームやリクエストの送信に対する推奨イベントとして generate_lead を挙げています。ただし、推奨イベントは自動送信されるものではありません。名前を採用することと、自社のフォームで期待どおりに記録することは別の作業です。
form_submit などの記録が実際の受付と一致するかも、自社のフォームで試して確かめます。イベントが見えるという理由だけで、受付件数の代わりに使わないようにします。
受付を事業上の重要な行動として扱うなら、適切に記録できるイベントをキーイベントとして指定する方法があります。ただし、指定しただけで発生条件が正しくなるわけではありません。カウント方法も、イベントごとかセッションごとかを確認します。セッションごとに数えて重複を見えにくくすることと、同じ受付を二度送信しない実装は別の作業です。
記事名とボタンの位置を、入力内容と分けて残す
「どの記事の案内が使われたか」を比べるには、記録に記事を識別できる情報が必要です。記事末尾のボタンと本文途中のボタンを分けたいなら、位置の情報も役立ちます。
最小限の案としては、記事の識別名、リンク先の種類、ボタンの位置をそろえます。たとえば「記事A／問い合わせ／記事末尾」です。文章を修正するたびに別の値になると比較しにくいため、見出し全文やボタン文言だけに頼らず、継続して使える短い識別名を決めます。
フォームまで移動した後も記事との関係を調べたい場合は、その情報をどこまで引き継ぐかも設計します。記事内のクリックに記事名が付いていても、送信完了の記録へ自動的に同じ情報が残るとは限りません。別ドメインのフォームや外部サービスを使う場合は、特に実装担当者との照合が必要です。
ここで、問い合わせの氏名やメールアドレス、相談本文まで解析データへ入れる必要はありません。Googleの案内では、個人を特定できる情報をアナリティクスへ送らないよう求めています。入力値だけでなく、それらがURLへ含まれていないかも確認してください。
記事の導線を調べる記録と、相談に返信するための受付情報は、目的と扱う内容を分けます。
実装担当者へ渡す、計測条件の記入例
次の表は、問い合わせフォームへ案内する「記事A」の架空の設計です。イベント名や項目名は自社で決める例であり、設定済みのコードやGoogleの標準項目一覧ではありません。
| 項目 | 記事内のクリック | 受付完了 |
|---|---|---|
| イベント名の例 | article_cta_click（独自名） | generate_lead（推奨名を採用する例） |
| 発生条件 | 対象の問い合わせリンクが操作された | 対象フォームの受付成功を確認した |
| 記事を示す値 | article_id=article-a | 引き継ぎ条件を満たすときだけ同じ値 |
| 場所・行き先 | cta_position=article_end、target_kind=consultation | 対象フォームを示す固定の識別名 |
| 発生させない操作 | 対象外のリンク、単なる表示 | 入力エラー、受付失敗、同じ受付の画面再表示 |
| 照合するもの | 対象記事のリンクと実際の遷移先 | 受付システムの記録と、重複しない1件の定義 |
記事の識別名をフォームへ引き継ぐなら、「直前に案内した記事だけか」「いつまで有効か」「別の記事から来たら更新するか」「値がない場合は不明とするか」を決めます。引き継げなかった記事名を推測して補わないようにします。完了画面の再表示だけでイベントを発生させる場合は、重複や直接アクセスも別途確認します。
記事の識別名やボタンの位置のような独自のイベントパラメータをレポートで使うには、目的に応じてイベントスコープのカスタムディメンションを設定します。値がイベントと一緒に届いたことと、通常のレポートで記事別に集計できることは分けて確認します。
正常な送信と、失敗する操作を試す
計測を設定したら、実際にフォームを操作して確かめます。Googleも、推奨イベントの確認にDebugViewやリアルタイム レポートを案内しています。DebugViewは、デバッグモードを有効にした端末などで、検証中のイベントの流れを確認するための画面です。
テストは、関係者と合意した検証環境やテスト受付を使います。本物の相談に紛れないよう、テストの扱いと後処理も決めておきます。次の表は確認する操作の例です。
| 操作 | 確かめたいこと |
|---|---|
| 記事の問い合わせリンクを1回押す | 対象の記事と位置で、意図したクリック記録が残るか |
| 入力を始め、そのまま戻る | 受付完了として数えられていないか |
| 必須項目が足りない状態で送信を試す | エラー時に完了イベントが出ていないか |
| 正常に送信する | 受付先に届き、完了の記録も意図した回数だけ残るか |
| 完了画面を再読み込みする | 同じ受付が新しい成果として増えていないか |
外部フォームを使っていて完了を確認できない場合は、「クリックまでを計測」と記録に残します。取得できない数字をゼロとして報告すると、反応がなかった場合と区別できなくなります。
解析側の件数と受付側の件数に差が出たときも、すぐに入力欄を減らしたり、記事を書き換えたりする必要はありません。集計期間、計測への同意、ブラウザー側の制限、テスト操作や重複記録など、比較する条件から確認します。
DebugViewに表示されないときは、デバッグモードの対象端末や同意条件も確認します。Googleの案内にも、プライバシー制御やアナリティクスCookieへの同意がない場合など、イベントが表示されない条件が記載されています。実際に受付がない場合と、解析側で観測できない場合を分けて記録してください。
数字の差を、次に調べる場所へつなげる
計測できる範囲がわかったら、記事とフォームを別々に点検できます。
- 記事を読む目的と案内先が合うか
- クリック前に相談内容を想像できるか
- リンクが見える位置にあるか
- 計測と受付の条件がそろっているか
- フォームが正常に表示・送信できるか
- 入力に必要な情報や負担が伝わるか
この図は原因を断定するものではありません。たとえばクリックが少なくても、調べものの疑問を解く記事なら、すぐ問い合わせないこと自体は不自然ではありません。相談を促す目的の記事なのか、理解や比較を助ける記事なのかを、数字の前に確かめます。
案内先へ進んでいるのに受付が少ないときも、記事が悪いと結論づけず、フォームの表示や説明、入力エラーから点検できます。最初に変える箇所を一つに絞り、変更日と狙いを残しておくと、次の確認で何を見たいかが明確になります。
比率を出すなら、期間と対象に加え、分母・分子が「操作の回数」なのか「人の数」なのかをそろえてください。クリック回数と、その記事を経由したか不明な全問い合わせ件数を割っても、記事別の成果率にはなりません。件数が少ないうちは率だけで良し悪しを決めず、実数と確認できた操作も併記します。
たとえば、同じ期間に記事Aの案内クリックが20回、全フォームの受付が4件あったとします。しかし、4件が記事A経由か不明なら「記事Aの問い合わせ率20%」とは言えません。記事Aのクリックと結びつく受付を2件確認できた場合も、2÷20の10%は、その定義での受付件数とクリック回数の比です。クリックした人のうち10%が送信した、とは限りません。同じ人の複数操作や、計測できなかった行動を含む可能性があるためです。これは計算方法を説明する架空の数値で、推奨する目標値ではありません。
また、記事を読んだ人が後日別の経路で相談することも考えられます。計測した導線だけで、記事の影響をすべて説明するのは難しいものです。読む目的や検討の順序を考える際は、カスタマージャーニーの作り方も参考になります。
まずは問い合わせリンクのある記事を一つ選び、「クリック」「入力開始」「受付完了」のどこまで確かめられるかを書き出す。そのうえで、正常な送信と失敗する操作を実際に試してみる。新しい記事を増やす前に、いまある記事の案内がどう使われているかを知る、小さな点検から始められます。
出典・参考
参照情報の確認日：2026年10月15日。キーイベント・カウント方法・独自項目・DebugViewの原典は該当箇所にも示しています。計測項目、テスト表、改善箇所の分類はbalubo magazine編集部の提案です。特定サイトの実測結果や、改善効果の保証を示したものではありません。
