
Webサイトのコンバージョン計測は、「数字が表示されていれば、ひとまず正常に動いている」と判断されがちです。GA4を開けば、新規ユーザー数もセッション数も、それらしい数字が並んでいます。パッと見た限り、何も問題はなさそうに見えます。 しかし「カートに追加」や「会員登録」といった、成果に直結する行動のGA4コンバージョンが計測されないというケースは、実は珍しくありません。数字が出ているからといって、正しく・漏れなく計測できているとは限らないのです。本記事では、その落とし穴と、どう見直せばよいのかを整理します。
GA4やGoogle広告に、「カートに追加された」「会員登録が完了した」といった行動データを送るためには、Googleタグマネージャー(GTM)という管理ツールの中で、「いつ、その行動が起きたとみなすか」という条件をあらかじめ設定しておく必要があります。この条件のことを「トリガー」と呼びます。
トリガーは、「何を条件にするか」によっていくつかの種類に分かれます。代表的なものとしては、次のようなものがあります。
表示テキスト:ボタンなどに表示されている文字が押されたかを条件にする(例:「カートに追加」という文字のボタンが押されたか)
URL:表示されているページのアドレスを条件にする(例:特定のページに来たかどうか)
HTML属性(ID・クラス名):ボタンがクリックされたかどうかを、見た目の文字ではなくHTMLに書かれた名前(id="cart-btn"のようなもの)で判定する
データレイヤーの値:サイトを作った人があらかじめ仕込んでおいた「合図」を条件にする。例えば、購入が完了した瞬間だけ、サイト側から purchase_complete という合図(データ)が送られるように仕込んでおき、GTMはその合図が届いたかどうかで判定する
要素の表示:ボタンのクリックではなく、「特定の文字や画像が画面に映ったかどうか」を条件にする(例:「ご購入ありがとうございました」というメッセージが表示されたか)
スクロール位置・経過時間:閲覧の深さや滞在時間を条件にする
これらは単独で使うだけでなく、複数を組み合わせて判定する(AND条件・OR条件)ことも可能です。今回取り上げるのは、この中でも特に見落とされやすい「表示テキスト」と「条件に何を選ぶか」の2つです。
組み方によって、「取りこぼし」が発生するリスクは大きく異なります。
よくある例として、「カートに追加」ボタンの計測を、次のような条件でトリガーに組んでいるケースがあります。
クリックされた要素の表示テキストに
「カートに追加」という文言を含む一見、正しく組まれているように見えます。しかし、ブラウザの自動翻訳機能を使ったり、ユーザーの言語設定によって表示テキストが変わったりすると、この条件は途端に崩れます。
実際には、次のようなことが起こります。
元の言語表示のままボタンを押す → 記録される
ブラウザの翻訳機能で表示言語を変えてから、同じボタンを押す → 記録されない
サイトの中身もユーザーの行動も変わっていません。「表示されている文字」を条件にしている限り、閲覧環境ひとつで計測が崩れるリスクを常に抱えている、ということです。多言語対応をしていないサイトであっても、閲覧者が翻訳ツールを使えば同じことが起こりうる点は見落とされがちです。
同様の問題は、会員登録を検知する設定にもよく見られます。例えば、次のような条件でトリガーが組まれているケースです。
クリックされた要素の表示テキストに「登録する」という文言を含む
かつ
ページURLに、会員登録ページ自体のパス(例:`/signup`)を含む一見、テキストとURLを組み合わせているので厳密に判定できそうに見えますが、組み合わせている条件が、どちらも「完了する前から成立してしまうもの」であれば、絞り込みとして機能しません。
URL条件:「登録が完了したときだけ表示されるページ」ではなく、「登録フォームが表示されているページ自体」を指している場合があります。例えば/signupのような、フォーム入力画面そのもののURLです。まだ何も入力していない状態でこのページを開いた時点で、この条件はすでに満たされてしまいます。
テキスト条件:「登録する」という文言も、ボタンのラベルなのか、登録完了後の通知メッセージなのか、設定画面だけでは判別できません。もしボタンのラベルだった場合、フォームが表示された時点で、まだ何も送信していないのにこちらの条件も満たされてしまいます。
条件を2つ組み合わせていても、両方とも「入力前から成立してしまう」もの同士であれば、絞り込みの効果はほとんど発揮されません。本来であれば、URL条件は/signupではなく、登録が完了した後にだけ表示される/signup/completeのようなページを対象にすべきです。これなら、フォームを開いただけの段階では条件が満たされず、実際に登録が完了した瞬間だけ計測できます。
さらに、この条件は特定の登録ページのURLしか見ていないため、そのURLを経由しない別の登録ルート(SNS連携登録、別画面からのポップアップ登録など)があれば、そちらは計測からまるごと漏れるという問題も、あわせて抱えています。
もっとも注意すべきなのは、この点です。GTMの設定画面を見る限り、トリガーは「一応、存在している」。動いていないわけではありません。 だからこそ、こうした状態は誰にも疑われずに運用されがちです。「ゼロではない」「一応数字は動いている」ことは、正しく計測できている証明にはなりません。 むしろ、部分的に取りこぼしながらも数字が出続けているからこそ、違和感に気づきにくい、という状態です。
条件の種類 | 具体例 | 主なリスク |
|---|---|---|
表示テキスト | ボタンの文言が一致するか | 翻訳・言語設定・文言変更で簡単に崩れる |
クリックの検知 | ボタン押下の瞬間を検知 | クリックと同時にページ遷移が始まるため、タグの送信が完了する前にページが切り替わり、取りこぼすことがある |
URL(単独) | 特定のURLが表示されたか | 条件が緩すぎると、類似する別ページにも誤反応する |
条件の組み合わせ方 | 完了後にしか成立しない材料を選べているか | 材料そのものが完了前から成立してしまうものだと、複数組み合わせても絞り込みの意味がない |
比較的崩れにくいのは、URLやHTML構造上のID・クラス名といった、表示言語や文言変更の影響を受けない情報を条件にする方法です。例えば、カート追加の条件を「ボタンの表示テキスト」から「完了後のページURLを含むかどうか」に変更すると、表示言語に関係なく安定して記録されるようになります。ただしURL条件も、「含む」の指定が緩すぎると別の完了ページに誤反応するケースがあるため、条件の粒度は個別に確認する必要があります。
ただし、こうした条件も永久に安全というわけではありません。サイトのHTML構造自体は、数年後のリニューアルや改修で書き換えられることがあります。 ボタンのIDやクラス名、ページのURL構造が変更されれば、当時は正しく組まれていた条件でも、その瞬間から静かに計測が止まります。「一度堅牢な条件で組んだから、もう見直さなくていい」ものではなく、サイトに大きな改修が入るタイミングでは、既存のトリガー条件が今も有効かをあわせて確認する運用が必要です。
条件に使っている材料(テキスト・URL・完了メッセージなど)を洗い出し、完了後にしか成立しない状態になっているか確認する
対象の行動に、条件で拾えていない別の導線がないか確認する
GTMのプレビュー機能(実際にサイト上で操作しながら、どのトリガーが発火したかを画面上で確認できる機能)を使い、表示言語や導線の違いなど複数パターンで実際に発火するかテストする
計測設定は、一度組んでしまうと「動いているから大丈夫」と思い込みがちです。しかし、動いているように見えることと、正しく・漏れなく計測できていることは別の話です。
コンバージョンの数字が「ゼロではないから大丈夫」に見えているなら、一度その条件が何を根拠に発火しているのかを確認し、サイトの改修が入るタイミングでも定期的に見直す習慣をつけておきたいところです。
この商品について質問がありますか?コミュニティや専門家に質問してください。