유저 속성

행동 기록만 쌓아 두면 답할 수 있는 질문의 종류가 좁습니다. 이벤트는 언제 누가 무엇을 했는지 남긴 한 줄인데, 이것만으로는 그 일이 몇 번 일어났는지까지만 셀 수 있습니다. 문서 공유가 지난달에 4만 2천 건 일어났다는 사실은 나오지만, 그중 얼마가 돈을 내는 팀에서 나왔는지는 나오지 않습니다.

그래서 회의가 이런 모양으로 막혔습니다. "유료 팀이 공유 기능을 더 쓰나요" 라는 질문에 분석 담당자가 "지금 화면에서는 안 나옵니다" 라고 답하고, 결제 정보가 있는 데이터베이스에서 계정 목록을 따로 뽑아 와 행동 기록과 손으로 맞춰 붙입니다. 한 번 하는 데 이틀이 걸리고, 다음 주에 같은 질문이 오면 다시 이틀입니다.

빠져 있던 것은 사람에게 붙는 값이었습니다. 행동은 순간에 일어나지만 요금제나 팀 인원은 그 사람에게 계속 붙어 있는 성질입니다. 유저 속성은 이 값을 행동 기록과 같은 곳에 두어, 질문을 받은 자리에서 바로 나눠 볼 수 있게 만든 장치입니다.

값이 이벤트가 아니라 사용자에게 붙고, 상태가 바뀌면 마지막 값만 남으며, 붙는 대상은 사용자 식별자가 정합니다.

1. 붙는 자리가 다릅니다. 이벤트는 한 줄씩 계속 쌓이지만 유저 속성은 사용자 한 명당 한 벌만 존재합니다. 사용자 A의 요금제 칸은 하나이고, 그 칸에 적힌 값이 A가 남긴 모든 행동 기록에 함께 읽힙니다.
2. 값은 덮어씌워집니다. 무료에서 유료로 옮긴 계정의 요금제 칸은 유료로 바뀌고, 무료였던 기록은 남지 않습니다. 이 성질이 가장 자주 사고를 냅니다. 지난 6개월 데이터를 요금제로 나눠 보면 지금 유료인 계정의 과거 행동까지 유료 쪽으로 세어집니다.
3. 그래서 순간의 값은 이벤트 속성으로 실습니다. 이벤트에 딸려 저장되는 부가 정보인데, 그 순간에 일어난 일의 내용이라 나중에 바뀌지 않습니다. 결제 당시의 요금제가 필요하면 결제 이벤트에 요금제를 함께 담아야 합니다.
4. 심는 시점은 두 군데입니다. 사용자가 로그인하거나 가입할 때 한 벌을 보내고, 상태가 바뀔 때 바뀐 칸만 다시 보냅니다. 갱신을 잊으면 값은 사라지지 않고 옛 값으로 남아 있어서, 틀렸다는 사실이 드러나지 않습니다.
5. 무엇에 붙일지는 사용자 식별자가 정합니다. 같은 사람의 기록을 이어 보려고 쓰는 고유한 값이고, 이 값이 흔들리면 속성도 엉뚱한 사람에게 붙습니다.

담는 값은 대개 다섯 종류 안에서 정해집니다. 요금제 같은 계약 상태, 가입일처럼 시작 시점을 알려 주는 날짜, 팀 인원이나 업종 같은 조직 정보, 어느 광고나 검색으로 들어왔는지 같은 유입 경로, 그리고 관리자인지 일반 구성원인지 같은 역할입니다.

가장 자주 쓰이는 자리는 분석 화면에서 숫자를 나누는 일입니다. 같은 기능 사용률을 요금제별로, 팀 인원별로, 유입 경로별로 갈라 봅니다. 전체 사용률 18퍼센트라는 숫자보다 유료 팀 34퍼센트와 무료 팀 9퍼센트라는 두 숫자가 다음에 할 일을 정해 줍니다.

같은 조건으로 묶은 사용자 무리를 만들 때도 씁니다. 3월에 가입한 팀, 인원 스무 명이 넘는 팀처럼 조건으로 무리를 정해 두고 몇 달에 걸쳐 남아 있는 비율을 따라갑니다. 3월에 가입한 팀 스물두 곳 중 넉 달 뒤에도 쓰는 곳이 몇인지를 이렇게 셉니다.

제품 안에서 보내는 안내 메시지와 메일도 이 값으로 대상을 고릅니다. 무료 팀에게만 요금제 안내를 띄우고, 가입 7일이 안 된 계정에게만 설정 안내를 보내는 식입니다. 값이 낡아 있으면 어제 유료로 전환한 팀에게 요금제 안내가 한 번 더 갑니다.

실험을 돌릴 때는 대상을 좁히는 데 씁니다. 기업 고객에게만 영향을 주는 변경이라면 그 조건에 맞는 사용자만 실험에 넣습니다. 그리고 고객 성공 담당자는 갱신이 가까운 계정을 이 값으로 찾아냅니다.

"요금제별로 나눠 보고 싶은데 유저 속성에 플랜이 안 들어와 있어요."

지금 도구로는 그 질문에 답할 수 없다는 뜻입니다.

"그건 유저 속성이 아니라 이벤트 속성으로 실어야 합니다. 그 순간의 값이 필요해요."

나중에 덮어씌워지면 안 되는 값이라는 지적입니다.

"속성 갱신이 하루 늦게 들어와서 어제 전환한 계정이 아직 무료로 잡힙니다."

값이 틀린 것이 아니라 갱신 시점이 문제라는 보고입니다.

지현이 유료 팀과 무료 팀의 공유 기능 사용률을 비교하려다 막힌 적이 있습니다. 태오가 그 주에 요금제, 팀 인원, 가입일, 유입 경로 네 가지를 유저 속성으로 심었고, 그다음부터 같은 질문은 화면에서 30초 만에 답이 나왔습니다.

다만 과거 데이터에서 한 번 더 걸렸습니다. 요금제 칸은 현재 값이라서, 지난 반년 기록을 요금제로 나누면 지금 유료인 계정의 무료 시절 행동까지 유료로 세어졌습니다. 태오는 요금제가 바뀌는 순간을 별도 이벤트로 남기게 고쳤고, 그 뒤로는 전환 전후를 갈라 볼 수 있게 됐습니다.

속성 값이 바뀔 때마다 기록으로 쌓인다고 생각하는 경우가 가장 많습니다. 다른 것이 다 한 줄씩 쌓이는 구조이니 이것도 그럴 것 같아 보입니다. 하지만 유저 속성은 현재 상태를 담는 칸이라 마지막 값만 남습니다. 이 오해가 남으면 반년 전 분석을 다시 돌렸을 때 결과가 달라지고, 그 이유를 찾는 데 며칠이 듭니다. 상태가 바뀐 시점 자체가 분석에 필요하다면 바뀌는 순간을 이벤트로 함께 남겨 두어야 합니다. 이 성질을 알고 나면 어느 값을 어느 쪽에 둘지가 설계 단계의 질문이 됩니다.

많이 심어 둘수록 좋다고 보는 오해도 흔합니다. 나중에 쓸지 모르니 일단 넣어 두자는 판단은 자연스럽습니다. 그런데 속성이 마흔 개로 늘어나면 어느 것이 지금도 갱신되고 있는지 아는 사람이 없어집니다. 갱신이 끊긴 칸은 비는 것이 아니라 옛 값으로 남아 있어서, 화면에서 필터로 고르면 아무 경고 없이 틀린 답을 내놓습니다. 쓰는 것만 남기고 쓰지 않는 것은 지우는 편이 안전합니다.