스크롤 추적은 페이지에서 도달한 위치를 기록합니다. 읽기, 이해, 주의를 입증하지 않습니다. 임계값, 측정 범위, 분모를 정해야 합니다.
자동 측정과 맞춤 임계값 구분
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일.
스크롤 깊이는 노출 정도이지 이해도를 나타내는 것이 아닙니다.
특정 페이지 깊이까지 스크롤했다고 해서 관심을 가졌거나 이해했다고 볼 수는 없습니다. 스크롤 깊이는 콘텐츠 길이, 가용 시간, 그리고 후속 조치와 연관시킬 때 더 유용합니다.
- 임계값이 전체 문서에 적용되는지 아니면 특정 부분에 적용되는지 명확히 정의하세요.
- 짧은 페이지, 로딩 지연, 모바일 및 재방문 테스트를 진행합니다.
- 읽기 완료 증명이 아닌 여정 표시기로 신호를 제시합니다.
1차 자료: Google Analytics — Set up events. 관련 방법: 실무 가이드 읽기.
데이터 조인 무결성
조인은 행을 늘려 합계를 왜곡할 수 있습니다.
- 주문 테이블의 한 행은 주문을, 항목 테이블의 한 행은 주문 내 상품을 나타냅니다. 결합 전에 반복 키와 NULL 키를 확인합니다.
- 주문 키별로 항목을 집계합니다. 그 결과를 주문과 결합하면 상품마다 주문 금액이 반복되지 않습니다. 원래 주문 테이블의 합계와 비교합니다.
- LEFT JOIN은 항목이 없는 주문도 남기지만, 오른쪽 테이블에 적용한 WHERE 조건이 이를 제거할 수 있습니다. 대응 없음과 금액 0은 다릅니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"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인 가상 주문 두 건도 시험합니다. 합계는 200입니다. SUM(DISTINCT total)은 100을 반환하여 유효한 값을 제거합니다. 금액 중복 제거 대신 식별자와 조인 관계의 수를 확인합니다.
재현 가능한 SQL 쿼리
가상 예: 주문 금액 100과 200, 주문 1, 1, 2에 연결된 항목 세 개입니다. 쿼리는 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;직접 결합하면 세 행과 합계 400이 나옵니다. 먼저 집계하면 주문 두 건과 합계 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입니다.
검증 절차
- 주문과 항목의 세분성을 정의합니다.
- 두 항목을 가진 주문을 결합합니다.
- 키, 행 수 및 대조한 합계를 보존합니다.
SUM(DISTINCT total)이면 충분한가요?
아닙니다. 금액 100인 주문 두 건의 합계는 200이지만 SUM(DISTINCT total)은 100을 반환합니다. 금액 중복 제거 대신 키 관계를 수정하세요.
1차 자료: 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과 연결되어야 합니다.
검증 절차
- 행 머리글, 열 머리글 및 단위를 확인합니다.
- 키보드와 보조 기술로 셀을 읽습니다.
- 모바일 적응과 확대 후 관계를 보존합니다. 중요한 셀은 스크롤 후에도 행, 열, 단위를 확인하세요. 머리글 없는 읽기 쉬운 값도 다른 의미로 해석될 수 있습니다.
1차 자료: W3C WAI — Tables tutorial. 관련 방법: 실무 가이드 읽기.