スクロール計測はページ上の到達位置を記録します。読了、理解、注意を証明するものではありません。しきい値、測定範囲、分母を明確にします。
自動計測と独自のしきい値を分ける
GA4の拡張計測は、垂直方向90%の深度が初めて見えるとscrollを送信します。25%、50%、75%の段階は自動では得られません。独自のしきい値には別の計測と重複排除が必要です。高さの変化、遅延読み込み、動的な画面遷移も記録します。
課題に照らして解釈する
高速スクロールやアンカーリンクで、継続的に読まずに末尾へ到達できます。答えが上部にある場合もあります。似た構造を比較し、課題達成、エラー、意見と組み合わせます。イベント数、ページビュー数、利用者数は異なる単位です。
収集範囲を定める
フランスのCNILは一部の閲覧者計測トラッカーについて厳格な条件下で同意免除を示しています。告知や集計だけでは免除を証明できません。目的、アクセス、保存期間を記録し、未計測の訪問を否定的な観測と扱わないようにします。
架空の例：測定範囲内だけの割合
| 項目 | 値 | 解釈 |
|---|---|---|
| 測定したページビュー | 100 | 計測対象として適格な範囲のみ。 |
| 90%に達したページビュー | 60 | ページビューごとに重複を排除。 |
| この範囲内の割合 | 60 / 100 = 60% | ユニーク利用者数でも読了率でもありません。 |
出典
- Google Analytics · Enhanced measurement events
- Google Analytics · Sessions and user engagement
- CNIL · Cookies et autres traceurs · FAQ
編集確認日：2026年11月1日。
スクロール深度は、理解度ではなく、露出度を示す指標です
ページ深度に到達したからといって、注意や理解度を示すものではありません。コンテンツの長さ、利用可能な時間、そしてその後の行動と関連付けることで、より有用な指標となります。
- しきい値が文書全体に適用されるのか、それとも表示されているセクションに適用されるのかを定義する。
- 短いページ、読み込みの遅延、モバイル端末、再訪問をテストする。
- シグナルは読了完了の証明ではなく、閲覧経路の指標として提示する。
一次資料：Google Analytics — Set up events. 関連する方法：実践ガイドを読む.
データ結合の整合性
結合による行の増加が合計値を歪める場合があります。
- 注文テーブルの1行は注文、明細の1行は注文内の商品を表します。結合前に重複キーとNULLキーを確認します。
- 明細を注文キーごとに集約します。その結果と結合すれば、商品ごとに注文金額が繰り返されません。元の注文テーブルの合計と照合します。
- LEFT JOINは明細のない注文を残しますが、右側テーブルへのWHERE条件はその注文を除外する場合があります。対応する行がないことと金額ゼロは別です。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"orders": [
{
"id": 1,
"total": 100
},
{
"id": 2,
"total": 200
}
],
"line_order_ids": [
1,
1,
2
],
"sum_before": 300,
"sum_after_raw_join": 400
}期待される判断
400は注文を二重計上しています。注文ごとに明細を集約し、合計300に戻します。 追加で、各100の架空の注文を2件試します。合計は200です。SUM(DISTINCT total)では100となり、正しい値が消えます。金額の重複排除ではなく、識別子と結合の対応件数を確認します。
再現できるSQLクエリ
架空例：金額100と200の注文2件と、注文1、1、2に対応する明細3件。クエリはVALUESだけを使います。テスト環境で実行してください。
WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
SELECT order_id, COUNT(*) AS line_count
FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;直接結合すると3行で合計400になります。先に集約すれば2件の注文と合計300を得られます。
WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
SUM(DISTINCT total) AS distinct_total
FROM orders;金額が100と100の場合、正しい合計は200ですがSUM(DISTINCT total)は100です。
検証手順
- 注文と明細の粒度を定めます。
- 2明細の注文を結合します。
- キー、件数、照合済み合計を残します。
SUM(DISTINCT total)だけで直せますか？
いいえ。100の注文が2件あれば合計は200ですが、SUM(DISTINCT total)は100になります。金額の重複排除ではなく、キーの関係を修正します。
一次資料：PostgreSQL — Table expressions and joins. 関連する方法：実践ガイドを読む.
アクセシブルなデータ表
小さな画面でもセルの関係を理解できる必要があります。
- captionで表を識別し、thで見出しを示します。単純な表ではscope="row"とscope="col"で方向を示し、単位と期間を値の文脈に残します。
- 横スクロール領域はキーボードから到達可能にし、すべての列を読めるようにします。カードに変換するならラベルと単位を繰り返し、比較に必要な情報を消しません。
- キーボードとスクリーンリーダーでセル、行、列、単位を探す課題を試します。並べ替えや絞り込み後も繰り返します。見た目だけで読み上げの対応は確認できません。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"column_headers": [
"2025",
"2026"
],
"row_headers": [
"A",
"B"
],
"cell": {
"row": "B",
"column": "2026",
"value": 42
},
"layout": "mobile"
}期待される判断
モバイル表示でも値42とB、2026の関連が分かる必要があります。
検証手順
- 行見出し、列見出し、単位を特定します。
- キーボードと支援技術でセルを読みます。
- モバイル化と拡大後も関係を保ちます。 重要なセルではスクロール後も行、列、単位を確認します。見出しがないと、読める値でも意味を取り違える可能性があります。
一次資料：W3C WAI — Tables tutorial. 関連する方法：実践ガイドを読む.