사용자 식별자

행동 기록은 사건 단위로 쌓입니다. 누군가 버튼을 눌렀다는 줄, 문서를 저장했다는 줄이 시간 순서대로 붙습니다. 줄마다 언제 무엇이 일어났는지는 적혀 있지만 누구인지가 없으면 그 줄들을 합칠 수 없습니다. 같은 사람이 가입하고 문서를 만들고 3주 뒤 해지했다는 이야기가 세 줄로 흩어진 채 남습니다.

초기에는 브라우저에 저장한 값 하나로 이 자리를 채웠습니다. 문제는 한 사람이 여러 기기를 쓴다는 점입니다. 회사 컴퓨터, 집 노트북, 휴대폰으로 각각 들어오면 값이 셋이 되고 표에서는 세 사람이 됩니다.

페이지덱에서 이 차이가 드러났습니다. 현우가 지난달 신규 사용자 340명을 보고했는데 수아가 계약 쪽 숫자와 맞지 않는다고 했습니다. 새로 만들어진 계정은 210개였고 차이는 기기 수였습니다. 같은 사람이 회사 컴퓨터로 가입한 뒤 집에서 다시 들어오면 새 사람으로 세어지고 있었습니다. 무엇을 사람 하나로 볼지 정하고 그 값을 모든 기록에 함께 싣자는 것이 이 개념입니다.

식별자는 두 종류를 함께 씁니다.

익명 식별자는 계정이 없을 때 쓰는 값입니다. 브라우저나 앱이 처음 실행될 때 만들어져 그 기기에 저장됩니다. 광고를 눌러 들어온 사람이 가격 페이지를 세 번 본 뒤 가입했다는 흐름은 이 값 덕분에 남습니다.

계정 식별자는 로그인한 뒤 쓰는 값입니다. 서버가 그 사람의 계정을 만들 때 발급한 번호이고 기기가 바뀌어도 같습니다.

기록을 남길 때는 둘을 같이 싣습니다. 로그인 전에는 익명 값만 실리고, 로그인한 순간부터 계정 값이 함께 붙습니다. 그리고 그 순간에 이전까지 익명 값으로 쌓아 둔 기록을 계정 쪽으로 이어 붙이는 처리를 합니다. 이 처리를 아이덴티티 병합이라고 부릅니다.

계정 식별자로 무엇을 쓸지가 자주 틀리는 자리입니다. 조건이 셋입니다.

1. 변하지 않아야 합니다. 사용자가 바꿀 수 있는 값을 쓰면 바꾼 시점에 기록이 둘로 갈립니다.
2. 겹치지 않아야 합니다. 두 사람이 같은 값을 갖는 순간 두 사람의 행동이 한 줄로 합쳐집니다.
3. 사람을 특정하지 못해야 합니다. 이름이나 연락처는 개인 식별 정보여서 분석 도구로 흘러가면 관리 대상이 늘어납니다.

세 조건을 모두 만족하는 것은 내부에서 발급한 계정 번호입니다. 이메일은 앞의 두 조건은 맞지만 세 번째에서 걸리고, 사용자가 주소를 바꾸면 첫 조건도 깨집니다.

여럿이 함께 쓰는 제품이라면 조직 식별자를 하나 더 싣습니다. 계약과 요금은 개인이 아니라 팀에 붙기 때문입니다. 사용자 식별자만 있으면 한 팀에서 아홉 명이 쓰기 시작한 변화와 새 팀 아홉 곳이 들어온 변화가 같은 모양으로 보입니다.

끊기는 자리도 알아 둡니다. 쿠키를 지우거나 앱을 다시 설치하거나 시크릿 모드로 들어오면 익명 값이 새로 만들어집니다. 그래서 가입 전 기록은 언제나 실제보다 사람 수가 많게 잡히고, 이 오차는 없앨 수 없어서 감안하고 읽습니다.

같은 사람을 시간축으로 따라가는 모든 분석이 이 값에 얹혀 있습니다. 단계별로 얼마나 빠져나가는지 보는 퍼널 분석도, 몇 주째 돌아오는지 보는 리텐션 분석도 사람을 이어 붙이지 못하면 계산이 서지 않습니다. 한 번 들어와 나갈 때까지를 묶는 세션도 같은 식별자로 이어진 사건을 시간 간격으로 잘라 만듭니다.

실험에서도 필수입니다. 두 안을 나눠 보여 줄 때 같은 사람에게는 같은 안이 계속 보여야 합니다. 식별자 없이 방문마다 다시 나누면 한 사람이 두 안을 번갈아 보게 되고, 그 실험의 결과는 읽을 수 없습니다.

개인정보 처리에서도 쓰입니다. 사용자가 자기 기록을 지워 달라고 요청하면 이 값으로 찾아 지웁니다. 어디에 무엇이 있는지 정리돼 있지 않으면 삭제 요청에 답할 수 없습니다.

그래서 어떤 값을 식별자로 쓰고 어느 기록에 싣는지는 트래킹 플랜, 즉 어떤 이벤트를 어떤 이름과 속성으로 심을지 적어 둔 문서에 함께 명시합니다. 이 문서 없이 각 화면에서 알아서 심으면 어떤 화면은 계정 번호를, 어떤 화면은 이메일을 실어 보내는 상태가 됩니다.

"신규 340명이 아니라 210명입니다. 기기별로 따로 세어져 있었어요."

익명 식별자를 사람 수로 그대로 읽은 오류를 짚는 말입니다.

"식별자를 이메일로 심어 두면 주소 바꾸는 사용자에게서 기록이 끊깁니다."

변하는 값을 식별자로 쓸 수 없다는 지적입니다.

"팀 단위 지표를 보려면 조직 식별자도 같이 실어야 합니다."

개인 식별자만으로는 계약 단위를 셀 수 없다는 뜻입니다.

페이지덱은 340과 210의 차이를 확인한 뒤 세 가지를 고쳤습니다. 계정 번호를 계정 식별자로 정하고, 로그인 시점에 익명 기록을 이어 붙이는 처리를 넣고, 모든 이벤트에 조직 번호를 함께 싣게 했습니다.

한 달 뒤 신규 사용자 수는 가입 계정 수와 2퍼센트 안쪽으로 맞았습니다. 다만 과거 기록은 되돌릴 수 없었습니다. 어느 익명 값이 어느 계정의 것이었는지 알 방법이 없었기 때문입니다. 그래서 지난 분기 숫자는 새 기준과 비교하지 않고, 기준이 바뀐 시점을 표에 표시해 두었습니다.

식별자 개수를 사용자 수로 읽는 경우가 가장 많습니다. 분석 도구가 고유 값의 개수를 세어 보여 주니 그렇게 보입니다. 하지만 그 값은 사람 수가 아니라 기기와 브라우저의 수에 가깝습니다. 한 사람이 셋으로 세어지고, 쿠키를 지운 사람은 넷이 됩니다. 이 오해를 그대로 두면 유입 수가 실제보다 크게 잡히고 그 숫자로 나눈 전환율은 실제보다 낮게 나옵니다. 그 상태로 채널별 예산을 정하면 기기를 여러 개 쓰는 사용자가 많은 채널이 계속 불리하게 평가됩니다.

이메일을 식별자로 쓰면 편하다고 보는 것도 오해입니다. 사람이 읽을 수 있어 디버깅이 쉽고 도구마다 같은 값을 쓰기 좋아 보입니다. 하지만 개인 식별 정보가 분석 도구와 로그에 흩어지는 순간 그것을 지우고 관리할 의무가 함께 따라붙습니다. 사용자가 주소를 바꾸면 그 사람의 기록이 두 사람으로 갈리는 문제도 남습니다. 내부 번호를 식별자로 두고 이메일은 필요한 곳에만 따로 저장하는 편이 뒤에 붙는 일이 적습니다.