記事を最後まで見たか調べるには？本文末尾とページ全体の90％を分ける

90％の記録と、本文の終わりは何が違う？

ページ全体の下部には、本文以外の関連記事やフッターも含まれます。記事を最後まで表示したかを知りたいなら、まず「本文の終わり」を決め、ページの高さで決まる位置と分けます。

GA4の拡張計測による標準のscrollは、そのページの縦方向90％の位置が初めて表示されたときの記録です。本文の最後の文を選んで記録する仕組みではありません。利用中のサイトで拡張計測がどう設定されているかも、実際の担当に確認してください。Google公式の自動収集イベントで定義を確認できます。

本文の下に長い関連記事欄があれば、本文を表示した後も、ページ全体の90％位置には届かない場合があります。逆に短いページでは、対象の深さが読み込み直後から画面内にある場合もあります。GTMのスクロール距離トリガーの説明も、初期表示範囲にある指定位置は実際にスクロールしなくても発火し得るとしています。

画面内に入ったこと、文章を実際に読んだこと、内容を理解したこと、相談したことは、それぞれ別です。「読了率」という名前で報告するときも、何を数えた数字なのかを一緒に書かないと、文章が理解された割合のように受け取られます。

同じ記事を開き、まとめと関連記事の境界を確かめる

調べたい記事を一つ選び、スマホとPCで、本文の最後の文、その下の関連記事、フッターの順に確認します。目印はページ最下部ではなく、読ませたい本文の終わりに合わせます。

最初に記事のURLと版を記録し、どこまでを本文とするかを編集側で決めます。たとえば、まとめの後にある相談案内までが読者へ伝えたい本文なら、その案内も含めた最後を確認します。関連記事の一覧を読んだかまで知りたい場合は、本文末尾の記録と混ぜず、別の問いとして扱います。

そのまま画面を下へ進め、本文後の部品を確かめてください。端末が変わると折返しや部品の並びが変わるため、同じ記事でも本文末尾とページ全体の下部との距離は同じとは限りません。遅れて表示される画像や、後から増える関連記事があるかも、実表示を見ながら担当に伝えます。これは確認する条件の説明であり、この架空例で実際の表示や発火を測定した結果ではありません。

図で考える問い：数えたいのは、まとめを含む本文の終わりが画面に入ったことですか。それとも、関連記事やフッターを含むページ全体の下部ですか。

原寸画像を開く

図は長い記事の配置案です。本文末尾の下に関連記事と長いフッターがあるため、90％位置が本文末尾より下になる可能性を示します。正確な位置、本文末尾の表示、標準記録、独自記録は、いずれも未確認です。図の配置だけで「本文を読んだ人が何人いる」とは判断できません。

次に行うことは、実記事の本文末尾を一箇所指して、計測担当と同じ範囲を見ているか確かめることです。下の短いPC記事は別の記事案・別の版で、スマホ記事を直した後の結果でも、端末の違いだけを比較した実験でもありません。

計測担当には、本文末尾のどの要素を数えるか伝える

依頼では、対象の記事と本文末尾の要素、表示とみなす条件、同じページで数える回数を具体的にします。「読了を計測して」だけでは、ページ90％を数えるのか、本文末尾を数えるのかが決まりません。

GTMの要素の表示トリガーは、IDやCSSセレクターで選んだ要素の表示を条件にできます。本文全体の大きな枠を選ぶのと、最後の段落を選ぶのとでは、表示されたと判定する対象が違います。「まとめの最後の段落を対象とし、関連記事と共通フッターは含めない」のように、編集上の意味を先に伝えてから、実際のHTMLで一意に選べるかを担当に確認します。

たとえば、同じ記事の本文末尾が表示された記録をページの表示ごとに一度数えたい場合は、選択する要素、何割見えたら対象とするか、表示時間を条件にするか、そのページで一度だけ発火するかを決めます。これらは実サイトの条件に合わせて決める項目で、すべての記事に共通する読解の基準ではありません。ページを読み込み直せば発火条件もリセットされ得るため、一度の発火を一人の読者と同一視しないでください。

計測担当には「この記事の、この版の、まとめ最後の段落を数えたい。関連記事より下の90％位置とは別に報告したい。対象を一意に選べるか、同じ表示で重複して数えないかをプレビューで確認してほしい」と伝えると、確認する作業が具体的になります。これは依頼文の例です。実際の対象要素、イベント名、設定、発火結果は決まっていません。

この作業には、組織で権限を持つ計測担当の確認が必要です。GoogleのGA4イベントの設定説明では、GA4プロパティ・ウェブストリーム・GTMなどの準備とアクセスを前提に、イベントタグと発火条件を分けています。編集担当が権限設定や本番タグを直接変更するための案内ではありません。

プレビューで、初期表示・戻り・再読込を分けて確かめる

本番へ反映する前に、権限のある担当がプレビューで、狙った記事と末尾だけが対象になるか、想定した回数で記録されるかを確かめます。タグ側の発火と、解析側に届いた記録も分けて確認します。

1. 記事を開いた直後を見る。本文末尾が最初から画面内にある短いページも含め、操作前に対象が表示される条件を確認します。発火したから下までスクロールした、と後から説明しないためです。

2. 本文末尾まで進み、前後へ戻る。選んだ末尾要素が表示されたときに、意図したタグが動くかを見ます。ページごとに一度という設計なら、同じページで上へ戻って再び末尾へ進んだとき、余計な発火がないかを確認します。実際の結果はその場の記録で判定します。

3. 読み込み直しと対象外の記事を見る。再読込後の扱い、別の記事や関連記事を開いたときの対象範囲を確認します。対象の記事ではない場所の記録を混ぜないよう、URLと版も残します。

4. 解析側に届いた名前と条件を読む。設定したイベントと対象の記事が対応しているかを確認します。Google公式は、プレビューと、Analyticsのリアルタイム・DebugViewなどでの確認を案内しています。プレビューの画面だけを公開後の集計結果に置き換えないでください。

確認する端末と表示条件もそろえます。動的に部品が増えるページでは、ページの高さと末尾要素の選び方を担当へ戻して確認します。実装・確認・公開の各記録を分け、組織の手順に沿って担当が反映した後に、公開版でも対象の対応を確かめます。ここでは実GTM・GA4への接続、イベント送信、設定や公開の変更は行っていません。

割合を比べる前に、版・期間・端末・分母をそろえる

報告には「どの本文末尾を、どの条件で数えたか」と、対象の記事版・期間・端末・分母を付けます。末尾表示のイベント件数だけから、読んだ人の割合を作らないでください。

同じ人が読み込み直す場合もあり、イベント件数・ページの表示回数・利用者数は同じ数ではありません。分母を何にするかは、知りたい問いと計測仕様に合わせて担当と決めます。条件が違う数字を前後の改善率としてつなぐのではなく、違いがあることを明記します。

たとえば、次の二つは配置を考えるための架空例です。長い記事のスマホ案と、短い記事のPC案は別の版で、表示結果も発火結果もありません。実読・理解・問い合わせの結果も、未確認のままです。

末尾の記録がないときも、「読まれていない」と即断せず、対象範囲と計測条件を確認します。Googleが説明するエンゲージメント時間はページへのフォーカスなどを扱う時間で、それだけで文章の理解を示すものではありません。理解を知りたい場合は、記事を使って情報を探し、自分の言葉で説明してもらう確認を別に設計します。

LPの最後のページの記録を調べる仕事は、ページ移動と画面内の操作を分ける説明へ、色や到達の集計を読む仕事はヒートマップの見方へ分けられます。本稿の判断は、記事本文の終わりをどこに定め、どの表示を記録するかです。

まとめ：本文の最後を選び、何を数えたかを一緒に伝える

記事が最後まで表示されたかを知りたいときは、本文末尾と、関連記事・フッターを含むページ全体の90％位置を分けます。標準のscrollが答える範囲を確認し、足りなければ実際の末尾要素の表示をどう記録するか、計測担当と決めます。

プレビューでは対象の記事・要素・回数・初期表示・再読込を確認し、解析側の記録と公開版も分けて確かめます。結果を比べるときは版・期間・端末・分母をそろえ、到達を実読・理解・成果へ言い換えないでください。

記事の終わりや計測の依頼範囲を整理したい場合は、対象記事、記事の版、知りたいこと、いま未確認の条件をDREEXYへお知らせください。支援範囲・費用・条件は個別に確認します。記事の表示と計測の整理を相談する