「読み終えた」をどう数えるか
「この記事は最後まで読まれたのか」を数えたい。
GA4には最初からスクロール距離の計測がありますが、今回はそれを使いませんでした。使わなかった理由と、代わりに何を測ることにしたか。そして確認の途中で、自分の測り方のほうが間違っていたという話です。
スクロール率で読了を測ることの問題、サイト側にすでにある読了状態を使うという判断、「未読から読了に変わった瞬間」だけを送る実装。最後に、計測は必ず一部を取りこぼすという前提について。
スクロール率では「読んだ」と言えない
GA4の拡張計測には scroll というイベントがあり、1回の表示の中で画面が90%まで下がると発火します。設定を1つ入れるだけで使えます。
それでも使わなかったのは、測っているものが違うからです。
| 場面 | scrollは発火するか | 実際に読んだか |
|---|---|---|
| 最後まで読み進めた | する | 読んだ |
| 目次から最後の見出しへ飛んだ | する | 読んでいない |
| 末尾までスクロールだけした | する | 読んでいない |
| 同じ記事を3回開いた | 3回する | 読了は1回 |
下3行が問題です。スクロール率が測っているのは「画面が下まで移動したか」であって、「その人が読み終えたか」ではありません。近い場面が多いので代用できているように見えますが、別のものです。
特に最後の行は効きます。気に入った記事ほど開き直されるので、読まれている記事ほど水増しされるという、いちばん困る方向に歪みます。
すでに答えを持っていた
このサイトには、以前から読了状態を保存する仕組みがあります。記事を最後まで読むと、そのことをブラウザ（localStorage）に記録し、一覧に「読了済み」のバッジを出す機能です。
つまり「この人がこの記事を読み終えたか」は、すでにサイトが知っていました。計測のために新しく測り直す必要はなく、その状態が変わった瞬間を送ればいい。
同じことを2か所で測ると、必ずどこかでずれます。ずれたとき、どちらが正しいかを毎回考えることになります。すでに持っている情報を使うほうが、増やす手間も、あとで悩む回数も少なくて済みます。
「変わった瞬間」を返させる
読了を記録する関数は、もともと何も返していませんでした。
export function markAsRead(slug: string): void {
const current = getReadSlugs();
if (current.includes(slug)) return; // すでに読了なら何もしない
// 保存する
}ここで注目したいのは、この関数はすでに「読了済みかどうか」を知っているということです。3行目で判定しています。知っているのに、その情報を捨てていました。
そこで、戻り値を持たせました。
export function markAsRead(slug: string): boolean {
try {
const current = getReadSlugs();
if (current.includes(slug)) return false; // 再訪
window.localStorage.setItem(KEY, JSON.stringify([...current, slug]));
return true; // 新しく読了になった
} catch {
// 保存できない環境（プライベートモード等）では判定材料が無い。
// 呼び出し側がページ内で1回に制限しているので、そこで歯止めがかかる。
return true;
}
}呼び出し側は、これが true のときだけ計測へ送ります。
const isNewlyRead = markAsRead(slug);
if (!isNewlyRead) return;
window.dataLayer.push({
event: "article_read",
article_slug: slug,
article_title: title,
});結果として、1つの記事から送られる読了は、そのブラウザにつき1回だけになります。再訪しても増えません。読了数が再訪回数に化けることがなくなりました。
「読了済みかどうか」を呼び出し側でもう一度調べることもできました。しかしそうすると、同じ判定が2か所に存在します。片方の条件を変えたときに、もう片方を直し忘れます。すでに判定している場所に、判定結果を返させるほうが素直でした。
タグマネージャー側の設定
サイトから送られた article_read を、GTMで受け取ってGA4へ流します。作ったのは変数2つ、トリガー1つ、タグ1つです。
変数 DLV - article_slug データレイヤー変数 article_slug
変数 DLV - article_title データレイヤー変数 article_title
トリガー CE - article_read カスタムイベント article_read
タグ GA4 - article_read GA4イベント / イベント名 article_read
パラメータに上の2変数を付与スラッグとタイトルを両方送っているのは、レポートでどの記事が読み切られたかを記事単位で見るためです。スラッグだけだと一覧が英数字の羅列になり、読めません。
動かないときは、測り方を疑う
実装が終わり、本番で確認しました。記事を最後までスクロールさせても、読了に切り替わりません。進捗表示は「あと100%」のままでした。
コードを疑って何度か読み返しましたが、間違いは見つかりませんでした。そこで、確認に使っていたスクリプトのほうを調べました。
document.documentElement.scrollTop = 一番下;スクロール位置は確かに変わっていました。しかし進捗を計算している処理は、スクロールイベントを受け取って動きます。この方法では、そのイベントが期待どおりに発生していませんでした。
イベントを明示的に発生させたところ、即座に読了になり、計測も送られました。
「動かない」と思ったとき、疑う先はまず対象のコードになります。しかし今回、間違っていたのは確認する側でした。手で操作していれば一度で分かったはずのことに、時間を使いました。以前にも正規表現の数え方を間違えて、コードのせいだと思い込んだことがあります。同じ形の失敗です。
数字が1件も届かない
読了イベントがブラウザ内で発火することは確認できました。ところが、GA4の管理画面には「受信したデータはまだありません」と出たままでした。
サイトからGTMへの受け渡しは、この目で確認しています。止まっているとすれば、その先です。ネットワークの記録を見ました。
chrome-extension://（拡張機能のID）/
rule_resources/redirects/google-analytics_analytics.js広告ブロッカーが、Googleの計測スクリプトを無害化した別のファイルに差し替えていました。gtm.js の取得自体は成功（200）しているのに、コンテナは動いていない。読み込まれてはいるが、実行されていない状態です。
別の端末で同じ記事を読んだところ、そちらは正しく届きました。
計測は必ず一部を取りこぼす
この経験には、設定の話より大きな中身がありました。
閲覧者の一定割合は広告ブロッカーを使っています。つまりアクセス解析の数字は、はじめから実数より少なく出ます。これは不具合ではなく、仕様として受け入れるしかない前提です。
知らないと、2つの困ったことが起きます。ひとつは、正常なのに「壊れている」と考えて原因を探し続けること。実際、私はしばらくそう考えていました。もうひとつは、数字を実数だと思って判断してしまうことです。
取りこぼしがあっても、記事どうしの比較は成立します。どの記事がよく読まれたか、読了率が高いのはどれか。取りこぼす割合はどの記事でも似た程度なので、比べる分には使えます。「何人が読んだか」ではなく「どちらがよく読まれたか」を見る道具だと考えるのが実態に合っています。
今回の学び
まず、近い場面で発火するものは、同じものではないということ。スクロール率は読了と多くの場面で一致しますが、目次から飛んだときも、読まずに流したときも発火します。名前が似ているだけで代用すると、あとで数字の意味を説明できなくなります。
次に、すでに知っている情報を捨てないこと。読了を記録する関数は、すでに「読了済みかどうか」を判定していました。その結果を返させるだけで、呼び出し側の二重判定がなくなりました。新しく調べるより、判定している場所に返させるほうが素直です。
そして、動かないときは対象より先に測り方を疑うこと。今回いちばん時間を無駄にしたのがここでした。数が合わないときは、だいたい数え方のほうが間違っています。
最後に、計測は完全ではないと知ったうえで使うこと。0件を見て慌てるか、「そういうものだ」と分かって傾向を読むか。前提を持っているかどうかで、同じ数字から引き出せるものが変わります。