이탈률에는 추적기가 아니라 비트 하나가 필요합니다
이 글의 내용
8월 28일까지 이 사이트는 이탈률을 보여 주지 않았고, 소개 페이지는 그것이 의도라고 적었습니다. 여러 페이지 조회에 걸쳐 따라가는 세션이 필요할 텐데 그러려면 동의 배너가 필요하다고 말입니다.
앞 절반은 참이었습니다. 뒤 절반은 우리가 이탈 페이지를 기록하기 시작한 순간 참이기를 그쳤고, 아무도 그 문장을 고치지 않았습니다.
왜 그냥 계산할 수 없었는가
페이지에서 페이지로의 전이 표가 있습니다. 이탈률에 필요한 모든 것을 담은 것처럼 보입니다. 한 페이지에서 다른 페이지로 가는 방문은 이탈이 아니니, 전이가 없는 방문을 세면 됩니다.
그것은 되지 않고, 까닭은 기록 코드 세 줄에 있습니다. 두 페이지가 같을 때, 둘 사이에 30분이 넘게 지났을 때, 그리고 한 카운터에서 하루에 새 쌍 삼백 개를 넘긴 뒤에 전이가 버려집니다. 규칙 하나하나가 그 표의 목적 — 어느 페이지가 어느 페이지로 이어지는지 보여 주는 것 — 에는 옳고, 하나하나가 진짜 두 번째 페이지를 보이지 않게 만듭니다.
한편 방문은, 하나를 세는 목적으로는 한 시간 지속됩니다. 살아 있는 표의 줄이 그만큼 남기 때문입니다. 그러니 분자는 방문의 한 정의를 쓰고 분모는 다른 정의를 썼을 것입니다. 숫자가 조금 틀린 것이 아니라 아무 데도 매여 있지 않았을 것입니다.
데이터가 실제로 말한 것
8월 27일과 28일에 방문 8,669건과 전이 2,817건이 있었으니 평균 방문당 1.32페이지입니다. 카운터 572개 가운데 99개가 전이를 하나라도 기록했습니다.
스위치가 꺼져 있어서가 아닙니다 — 경로 기록은 기본이 켜짐이고 166,453개 카운터 모두 켜져 있습니다. 그 사이트들은 정말로 한 페이지짜리입니다. 프로필 페이지, 한 페이지 사이트, 남의 플랫폼에 놓인 사진 갤러리 말입니다. 그 대부분의 이탈률은 백 퍼센트 가까이 나올 것이고, 그것이 옳을 것입니다.
비트 하나, 새 수집은 없음
방문에는 이미 한 시간짜리 줄이 있습니다. 이제 하나를 더 지닙니다. 이 방문이 두 번째의, 다른 페이지를 본 적이 있는지 말입니다. 값은 어차피 도는 문 안에서, 추가 조회 없이 설정됩니다:
ON DUPLICATE KEY UPDATE mehr = mehr | (url <> VALUES(url)),
last_seen = UNIX_TIMESTAMP(), url = VALUES(url)그 대입의 순서가 요령 전부입니다. 데이터베이스가 왼쪽에서 오른쪽으로 처리하므로, 비교가 돌 때 url는 아직 이전 주소를 담고 있습니다. url를 앞에 두면 줄이 새 주소를 자기 자신과 견주고, 비트는 영원히 0으로 남고, 이탈률은 모두에게 백 퍼센트로 읽힙니다. 그럴듯한 결과와 똑같아 보이는 실패이고, 그래서 믿기 전에 버릴 줄 하나에서 증명해 볼 값어치가 있었습니다.
한 시간이 지나면 야간 정리가 만료되는 줄을 셉니다. 방문이 몇이고 그 가운데 여러 페이지를 본 것이 몇인지 세고, 카운터와 날짜마다 한 줄을 쓰고, 줄을 지웁니다. 비트는 한 시간을 삽니다. 쿠키도 없고, 그것보다 오래 사는 것도 없습니다.
무엇이 일반화되는가
흥미로운 물음은 세션을 어떻게 따라갈까가 결코 아니었습니다. 우리가 이미 적어 두는 것 가운데 무엇이 마침 그 물음에 답하는가, 그리고 그것이 주는 답이 물음과 같은 정의에 매여 있는가였습니다.
둘 다 방문을 재는 것처럼 보이는 두 출처가, 하나는 30분 규칙이고 다른 하나는 60분 규칙이라면, 숫자이기는 하되 아무 뜻도 없는 비율을 내놓습니다. 이미 있는 줄에 비트 하나를 더하는 편이, 나중에 그 비율이 왜 그런지 설명하는 것보다 쉽습니다.