読了時間

ページは閲覧者を引きつけることもあれば、3秒で離脱されることもあります。読了時間はその違いを分ける数値であり、生の数値を見るまで気づけない形で、多くの分析ツールが誤って算出している数値でもあります。

得られるもの#

ドキュメントの各ページには平均読了時間が表示され、「ページ」カードと 「見出し」カードではその時間で順位付けできます。測定値のないページには ダッシュが表示され、0 になることはありません。ゼロでは「誰も滞在しなかった」と 読めてしまいますが、実際には「何も測定されなかった」という意味だからです。

読了時間は訪問ごとではなく、ページごとにカウントされます。読者が3ページを 開いた場合、それぞれに固有の秒数が与えられ、最も忙しいページに合わせて 3ページすべてが忙しく見えることはありません。

このレポートの閲覧によってプロジェクトの残高が消費されることはなく、 すべてのプランで利用できます。

どのように構築されているか#

ストップウォッチではなく、セグメントです。 トラッカーはページが開かれたときに時計を開始し、読者がページを離れたときに読み取ります — pagehide のとき、サイト内ナビゲーションで別のページに移動したとき、そして iOS では visibilitychange → hidden のときです。iOS では pagehide が信頼できないためです。読み取りごとに、その秒数の区間を含む docs.read_time イベントが1つ送信され、時計がリセットされます。そのため、読者がタブを非表示にしてから戻ってきた場合、二重にカウントされた1つの区間ではなく、2つのセグメントが生成されます。

3秒未満のセグメントは決して送信されません。 それ未満の場合、読者は通過しただけです。記録しても読み取り値が増えないままページの平均にノイズを加えるだけだからです。

送信にはビーコンを使用します。 滞在時間、見出しの閲覧、離脱は navigator.sendBeacon を通じて同一オリジンのエンドポイントに送信され、1つのビーコンにつき最大100イベントがまとめられます。通常のログ転送は fetch 上で2秒間デバウンスされ、タブを閉じると保持されないためです。すべてのコレクターはべき等です。つまり、まだ送信されていないイベントだけを返します。そのため、iOS での非表示時のフラッシュ後に実際の離脱が発生しても二重カウントされず、戻る／進むキャッシュから復元されたページでは再度フラッシュできます。

すべてのセグメントは、合計される前に300秒で切り詰められます。 これはレポート全体の基盤となる数値です。デスクトップのタブがバックグラウンドにある間もエミッターはカウントを続けます。11,176件の実際のセッションを7つのワークスペースで調査したキャリブレーションでは、2時間を超えた個別セグメントが40件あり、99パーセンタイルは81,342秒 — 22時間 — でした。また、生のセグメントを合計すると、総読了時間は真の42,160秒から1,268,422秒へと、約30倍に膨れ上がりました。

この上限は、インポートのない1つのモジュールで一度だけ定義され、時間の数値を引用するすべての箇所に再エクスポートされます — ページごとの平均、訪問の概要、チャットテーブルの「サイト滞在時間」列、目標レイヤー、MCP ツールです。最初の定義から1列離れた場所に、より緩い「サイト滞在時間」の定義をもう1つ置くと、同じ読者についての2つの数値が食い違い始めます。

平均値は訪問回数ではなく、セグメント数で割ります。 タブを離れて戻ってきた読者は、1回の訪問に2つのセグメントを加えます。訪問回数で平均すると、その訪問を2回分として扱うことになるためです。

ボットは、ダッシュボードの他の部分で使用しているものと同じ User-Agent フィルターによって除外されます。これにより、ページの読了時間と閲覧数が整合します。動作ベースのクローラーゲート — JavaScript が発行したイベントを1つも持たない訪問は、User-Agent が何を名乗っていてもクローラーです — には完全なセッションの再構築が必要なため、代わりに訪問レイヤーで適用されます。詳しくは測定の仕組みを参照してください。

ページの読了時間が示すこと#

読了時間は判定ではなく比較です。ページの長さや、そのページが果たす役割との関係で意味を持ちます。

見出しの閲覧数と組み合わせて見てください。読了時間は滞在した時間を示し、見出しの閲覧数はどこまで読み進めたかを示します。最初の2つの見出しに集中した長い読了時間は、読者が関心を持っているのではなく、そこで行き詰まっていることを意味します。

これが正しい方法である理由#

最後の行こそ、Docsbook がページビュー間の間隔から時間を推測するのではなく、独自の終了イベントを送出する理由のすべてである。訪問の最後のページ — 読者が立ち止まったページであり、通常は最も評価したいページ — は、間隔ベースの測定ではまさに見ることができないページである。

制限事項と未解決の問題#

• 閲覧時間は可視性によって制御されるのではなく、クリップされます。 デスクトップでは、バックグラウンドのタブは300秒のクリップによって停止されるまで秒数を加算し続けます。そのため、誤差の方向（過大）と上限（セグメントあたり300秒）が明らかであり、利用可能な指標となっています。ただし、これはフォーカスによって制御されるエンゲージメント時間と同じ測定値ではなく、このページもそう主張していません。読者がドキュメントをバックグラウンドのタブに常時置いておく傾向がある場合は、この数値を上限として扱ってください。
• 1回の連続した閲覧が5分を超えても、5分として記録されます。 読者が長いチュートリアルを実際に読み進めた場合、この値は過小評価になります。このクリップ処理は、まれな長時間閲覧での範囲が限定された過小評価と、アイドル状態のタブでの30倍の過大評価を交換するものです。
• 疑問点：「平均閲覧時間」は「平均的な注意」を意味しません。 検証可能なのは、上記の仕組み、つまりセグメント、下限、クリップ、除数です。このデータから検証できないのは、読者が画面を見ていたかどうかです。これを測定できるウェブ分析製品はなく、そうであるかのように示唆すべき製品もありません。
• JavaScriptを無効にしている読者とクローラーは、閲覧時間にまったく寄与しません。 それでもページビューにはカウントされるため、頻繁にクロールされたページでは、閲覧時間のサンプルが少ないのに高い閲覧数が表示されることがあります。
• 履歴全体は30日分です。 長期的な閲覧時間の推移を示すことはできません。

読了時間レポートを開く方法#

1. ドキュメントサイトを開きます。
2. Float Widget → Analytics タブ。
3. ページまたは見出しカードをReading timeで並べ替えます。

Reading timeは、ページと見出しでのみ提供されます。これは、ドキュメント内の場所を示す行には意味がありますが、 国やブラウザーを示す行には意味がないため、ページと見出しで提供され、それ以外では提供されません。

関連#

• 測定の仕組み — クリップ、ビーコンパス、ボットフィルターの詳細
• アナリティクス概要 — このランキングが表示されるPagesカード
• トラッキング対象イベントのリファレンス — 見出しビュー。長いページを読者がどこまで読み進めたかを示します
• 目標とファネル — 訪問が達成したことを測定します。滞在時間だけではありません