LPやサイトでスクロール深度を計測しているが、アンカーリンクのせいで数値が信用できない——そんな状況に心当たりがある方に向けて書く記事です。実験LP第2弾は、自分がこれから新しく立ち上げるサービス「外部Web担当」の集客用LPで、実績はまだこれからの段階です。このLPで、A/Bテストと計測の設計をどう決めたかを記録しました。今回は「問題を解決した」だけでなく、その解決策が生んだトレードオフまで書いています。同じ迷いを抱えている方に、測り方を選ぶときの考え方のひとつとして読んでもらえたら。
LP第2弾のA/Bテスト、差分はFVのキャッチコピーだけに絞った
このLPは、自分がこれから実際に提供していくサービス「外部Web担当（あなたの会社のWeb担当）」の集客用に作ったものだ。A面・B面の2パターンを用意し、LP一覧ページのJSでランダムに振り分けている。
- A面：「止まったホームページを、動かします。」（痛み起点）
- B面：「社外で持てる、専任Web担当という選択肢。」（欲求起点）
差分はこのFVのキャッチコピー（H1）だけで、§2以降——困りごとの確認・進め方・料金・FAQ・フォームは完全に共通にしている。
差分を1点に絞ったのは、変化の原因をはっきりさせたかったからだ。CTA到達率やセクションごとの読了に差が出たとき、それが「痛み起点か欲求起点か」によるものだと言い切れる設計にしたかった。複数箇所を同時に変えると、差が出ても何が効いたのか切り分けられなくなる。
LP第1弾の時点で分かっていた、スクロール率の限界
このLPのCTAボタンは、すべてhref="#contact"のアンカーリンクだ。クリックすると、ブラウザがページ最下部のフォームまで自動でスクロールする。
このとき困るのが、GA4のスクロールイベントだ。実験LP第1弾（架空のオンラインスクールLP）を設計した段階で、この問題はすでに想定していた。当時のGA4設計メモにはこう書いている。
スクロールイベントはCTAクリックによるジャンプで意図せず発火する場合がある → 限界を記事に明示した上で参考値として記録する方針
つまり、アンカーリンクのCTAがあるページでは、クリック時の自動スクロールが25%・50%・75%の到達イベントを一瞬で同時発火させてしまう。これは今回新しく見つけた問題ではなく、LP第1弾の設計時点で「そういうものだ」と受け入れて、参考値として記録する方針にとどめていた話だ。
今回は測り方自体を切り替えた
「参考値のまま」で終わらせなかった理由
LP第1弾はダミー題材だったこともあり、「参考値として記録する」で十分だった。ただ今回は、実際に問い合わせにつなげたいサービスのLPだ。数字が汚れたまま記録するだけでは、次の改善判断に使えない。
そこで、スクロール率のイベント（25/50/75%）自体を廃止することにした。
切り替えた先：セクション単位の表示計測
代わりに採用したのが、セクション単位の表示を計測する方式だ。IntersectionObserver（要素が画面内に入ったかどうかをブラウザ側で検知できる仕組み）を使い、各セクションが画面内に20%入った時点でlp_section_viewイベントを1回だけ発火させる。
対象のセクションは8つ。困りごとの確認・サービスの選択肢・進め方・相談内容・プロフィール・料金・FAQ・フォームに、それぞれIDを割り当てている。
この方式を選ぶ前に、他の方法も検討した。
| 検討した方法 | 内容 | 判断 |
|---|---|---|
scrollイベントの自前判定 | スクロール位置から各セクションの表示を自前で計算する | そもそも今回問題になったscrollイベントの上に判定ロジックを足すだけで、根本的な解決にならない → 見送り |
| GTMの「要素の表示」トリガー | Googleタグマネージャー（GTM）を使えばコード不要で同様の検知ができる | このサイトはSEO SIMPLE PACKが直接gtag.jsを読み込む構成でGTMを挟んでおらず、導入するとタグ管理の仕組みごと変えることになる → 見送り |
| IntersectionObserver | ブラウザ標準の機能で要素の表示を検知する | 追加コストが低く、今回の規模に見合っている → 採用 |
この方式なら、ユーザーがスクロールで読み進めたのか、CTAクリックで一気に飛んだのかに関係なく、「そのセクションが画面に映ったかどうか」だけを見られる。アンカージャンプの影響を受けない計測に変えた、という設計判断だ。
振り返り：アンカーリンクをなくす選択肢もあった
ここまでは「うまく対応できた話」として書いてきたが、ひとつ反省がある。
もしLP第1弾との比較を優先するなら、別の選択肢もあった。CTAのアンカージャンプ自体をやめて、通常のスクロールで正しいスクロール深度を取得できる構造にし、ページ内移動が必要ならCTAとは別に追従ナビを用意する、というやり方だ。この方法なら、LP第1弾と同じ「スクロール率」という指標のまま、精度だけを上げられたと考えている。
今回選んだのは、指標そのものを「スクロール率」から「セクション表示」に変える方法だった。おかげでLP第2弾単体では読まれている場所がクリーンに分かるようになった一方で、LP第1弾のスクロール率データとはもう直接比較ができなくなっている。「今回のLPで何を知りたいか」だけを見て決めた設計で、「サイト全体でデータをどう積み上げていくか」までは考えが及んでいなかった、という反省だ。
まとめ
- A/B差分をFVのキャッチコピー1点だけに絞ったことで、差が出たときに原因を言い切れる設計にした
- スクロール率の限界はLP第1弾の時点で分かっていたが、「参考値として記録する」で終わらせず、今回はセクション表示計測に測り方を切り替えた
- ただし指標を変えたことで、LP第1弾のデータとの直接比較はできなくなった。個別LPの計測設計と、サイト全体でのデータの積み上げ方は、別々に考える必要があると分かった
このLPでは、A面（痛み起点）/ B面（欲求起点）のCTA到達率とセクション表示の差を、これから観察していく。データが溜まった段階で、計測→改善フェーズとして続きを書く予定だ。
LP自体はこちらで公開している。→ 外部Web担当LP（あなたの会社のWeb担当）
実験LP第1弾の計測設計はこちらに記録している。→ LPに入れるGA4イベント、どう決めた？
更新はXで告知している。→ @AO_weblab