기능 채택률

기능을 하나 내고 나면 잘된 건지 묻게 되는데, 답할 근거가 마땅치 않습니다. 제품 전체를 보는 숫자는 기능 하나의 몫을 따로 보여 주지 않습니다.

페이지덱에서 댓글 기능을 내고 한 달 뒤 회고를 열었을 때가 그랬습니다. 지현이 "이거 잘 쓰이고 있나요" 라고 묻자 아무도 답하지 못했습니다. 그때 팀이 보던 숫자는 주간 활성 사용자, 그러니까 한 주 동안 제품에 들어온 사람의 수 하나였는데, 그 값은 댓글을 내기 전 주와 거의 같았습니다.

이 숫자가 그대로인 데는 두 가지 설명이 다 가능합니다. 댓글을 쓰는 사람이 아무도 없어서일 수도 있고, 이미 들어오던 사람들이 댓글까지 쓰게 됐지만 사람 수 자체는 안 늘어서일 수도 있습니다. 둘은 다음에 할 일이 완전히 다른데 제품 전체 숫자로는 구분되지 않습니다. 그래서 기능 하나를 놓고 "이 기능을 써 본 사람이 몇 퍼센트인가" 만 따로 재기로 한 것이 기능 채택률입니다. 기능마다 값이 따로 나오니, 두 달을 쓴 기능이 아무에게도 닿지 않았다는 사실이 출시 2주 만에 드러납니다.

정해 둔 기간 안에 그 기능을 한 번이라도 쓴 사용자 수를 기준이 되는 사용자 수로 나눕니다. 나눗셈 자체는 간단하고, 값을 정하는 것은 세 가지 결정입니다.

1. 무엇을 "썼다" 로 볼지 — 댓글 화면을 연 것과 댓글을 실제로 남긴 것은 다른 사건입니다. 페이지덱은 남긴 것만 셉니다. 연 것까지 세면 우연히 눌러 본 사람이 전부 들어와 값이 두 배 가까이 뜹니다.
2. 무엇으로 나눌지 — 여기가 값을 가장 크게 흔듭니다. 댓글을 남긴 사람이 320명이라고 할 때, 전체 가입자 8,000명으로 나누면 4퍼센트, 그 주에 제품을 쓴 2,400명으로 나누면 13퍼센트, 댓글 버튼이 있는 문서 화면까지 들어온 900명으로 나누면 36퍼센트입니다. 같은 기능을 두고 4퍼센트와 36퍼센트가 다 사실입니다.
3. 언제까지 셀지 — 출시 이후 계속 누적할지, 최근 4주만 볼지를 정합니다. 누적한 값은 시간이 가면 저절로 올라가서 나빠지는 일이 없습니다. 지금 쓰이고 있는지를 보려면 기간을 끊어야 합니다.

분모 셋은 각자 다른 질문에 답합니다. 전체 가입자로 나눈 값은 회사 전체에서의 몫을, 활성 사용자로 나눈 값은 지금 쓰는 사람들 사이에서의 몫을 말합니다. 기능 화면까지 온 사람으로 나눈 값은 기능 자체가 매력적이었는지를 말합니다. 앞의 둘이 낮은데 마지막 값이 높으면 기능은 괜찮은데 거기까지 가는 길이 막혀 있다는 뜻입니다. 그래서 분모를 하나만 정해 두지 않고 셋을 나란히 두고 어디서 떨어지는지 봅니다.

기능마다 정상 구간이 다릅니다. 문서를 저장하는 기능은 95퍼센트가 나와야 정상이고, 분기마다 한 번 쓰는 권한 일괄 변경 기능은 3퍼센트여도 정상입니다. 그래서 다른 기능의 값과 나란히 놓고 높다 낮다를 말하면 대개 틀립니다. 판정에 쓸 기준은 셋입니다.

첫째는 출시 전에 적어 둔 기대치입니다. 이 기능을 만들자고 할 때 어떤 사용자가 얼마나 쓸 것이라고 말했는지가 있을 것입니다. 2주 안에 문서 화면에 오는 사람의 30퍼센트가 쓸 것이라고 했는데 8퍼센트가 나왔다면, 숫자 자체보다 예측이 어디서 틀렸는지가 다음 회의의 주제가 됩니다.

둘째는 비슷한 기능의 과거 값입니다. 페이지덱에서 지난 1년간 낸 기능 여덟 개의 출시 4주차 값을 적어 두면 그 자체가 기준선이 됩니다.

셋째는 도달 대비 비율입니다. 기능 화면까지 온 사람 중 실제로 쓴 비율은 노출과 무관하게 기능 자체를 평가합니다.

값이 낮게 나왔을 때 원인은 둘 중 하나입니다. 있는 줄 모르거나, 알고도 안 쓰거나. 이 둘은 분모를 바꿔 보면 갈립니다. 도달 대비 비율이 40퍼센트인데 전체 대비가 4퍼센트라면 아는 사람은 잘 쓰고 있으니 온보딩이나 안내를 손볼 일이고, 도달 대비도 5퍼센트라면 기능 자체를 다시 봐야 합니다.

한 번 써 봤다는 사실만으로는 부족합니다. 채택률이 40퍼센트인데 두 번 이상 쓴 사람이 3퍼센트라면 그 기능은 호기심에 한 번 눌러 본 것입니다. 그래서 채택률 옆에는 반복 사용 비율을 같이 둡니다. 두 값이 함께 높으면 그 기능은 파워 유저, 즉 평균보다 훨씬 깊고 자주 쓰는 사용자를 만들어 내고 있는 것입니다.

"출시 4주차인데 채택률이 6퍼센트예요. 분모를 문서 화면 방문자로 바꿔 볼까요?"

값이 낮은 이유가 기능 때문인지 노출 때문인지 가려 보자는 제안입니다.

"채택률은 올랐는데 두 번째 사용이 안 붙어요."

한 번 써 보게는 만들었지만 계속 쓸 이유는 못 줬다는 뜻입니다.

"이 기능은 채택률로 보지 맙시다. 원래 소수만 쓰라고 만든 거예요."

모두가 쓸 기능이 아니므로 다른 지표로 판정하자는 말입니다.

페이지덱은 기능을 낼 때마다 피처 플래그로 일부 계정에만 먼저 켭니다. 코드를 배포한 채 기능만 켜고 끄는 스위치입니다. 2주 뒤 지현이 켠 집단의 채택률을 보고 전체 공개 여부를 정합니다. 지난번 댓글 기능은 첫 2주 도달 대비 11퍼센트에서 멈췄는데, 몇 명에게 물어보니 댓글 버튼이 문서를 끝까지 내려야 보이는 자리에 있었습니다. 버튼을 위로 올리고 다시 켰더니 같은 집단에서 34퍼센트가 나왔습니다.

값이 낮으면 기능이 실패한 것이라고 읽기 쉽습니다. 숫자가 그렇게 보이니 자연스럽습니다. 하지만 이 값은 기능의 품질과 노출의 정도를 한데 섞어 놓은 숫자입니다. 좋은 기능이 안 보이는 자리에 있으면 나쁜 기능과 같은 값이 나옵니다. 그대로 두면 팀은 멀쩡한 기능을 걷어내고 같은 자리에 다른 기능을 만들어 또 같은 값을 받습니다. 값이 낮을 때 먼저 할 일은 기능을 고치는 것이 아니라 분모를 바꿔 어디서 끊기는지 보는 것입니다.

이 숫자를 올리는 것 자체를 목표로 삼는 것도 흔합니다. 목표가 분명해 보여서 그렇습니다. 문제는 올리는 방법이 너무 쉽다는 데 있습니다. 처음 들어온 사람에게 팝업을 띄워 그 기능을 누르게 만들면 채택률은 한 주 만에 두 배가 됩니다. 실제로 그 기능이 필요한 사람은 그대로인데 숫자만 올라가고, 대신 팝업을 닫느라 짜증 난 사람이 늘어 다른 지표가 내려갑니다. 봐야 할 것은 이 기능이 그 사람의 일을 실제로 덜어 줬는지이고, 채택률은 그 질문으로 가는 첫 계단입니다.