만든 앱을 실제로 쓰는 사람 세어 보기

사업이 끝나고 결과보고서를 쓸 때 제일 먼저 채우는 칸이 참여 인원입니다. 저는 제가 만든 앱에서 그 칸을 못 채웠습니다. 몇 명이 가입했는지, 그중 실제로 써 본 사람이 몇 명인지 물었더니 답할 방법이 없었습니다.

세는 방법을 만들었더니 처음에는 0명이 나왔습니다. 계정은 분명히 있는데요. 회원 명부가 두 군데 있었고 제가 빈 쪽을 세고 있었습니다.

이 글은 그 숫자 넉 줄을 만든 기록입니다. 나온 결과는 좋지 않았습니다.

---

앱을 만들어 놓고 왜 세어 보게 됐나요

쓰는 사람이 몇인지 모르는 채로 요금부터 붙이면 순서가 거꾸로 됩니다. 저는 앱에 유료 이용권을 달아 둔 참이었습니다. 무료로 초안을 다섯 번까지 만들고, 더 쓰려면 결제하는 구조입니다.

그러고 나니 답해야 할 물음이 생겼습니다. 이 요금을 계속 둘 것인가, 접을 것인가. 감으로는 못 정합니다. 사업을 이어갈지 접을지 볼 때 참여 인원과 재참여 인원을 먼저 세는 것과 같습니다.

그래서 판정에 쓸 숫자를 넉 줄로 정했습니다. 이번 주에 가입한 사람, 지금까지 가입한 사람, 초안을 한 번이라도 만든 계정, 무료 다섯 번을 다 쓴 계정.

넷째 줄은 무료 한도에 가까이 간 사람이 있는지 보는 지표입니다. 한도에 도달한 사람이 0명이라고 결제도 0명인 것은 아닙니다. 한도를 쓰기 전에 결제할 수도 있고, 초안을 한두 번만 만든 사람도 있을 수 있습니다. 사용 경험은 초안 생성 기록으로, 결제는 결제 완료 기록으로 따로 확인합니다.

계정이 열 개인데 왜 0명이 나왔나요

제가 세라고 시킨 표에 원래 아무것도 없었기 때문입니다. 앱의 회원 정보는 데이터베이스라는 곳에 표 모양으로 쌓입니다. 엑셀 시트가 여러 장 있는 파일이라고 보시면 됩니다.

제가 쓰는 데이터베이스에는 회원가입 기능이 기본으로 딸려 있습니다. 그 기능을 쓰면 정해진 회원 표에 사람이 쌓입니다. 저는 그걸 안 쓰고 회원 표를 직접 만들어 썼습니다. 만들 때 제 손으로 그렇게 정해 놓고, 세러 갈 때는 기본으로 딸려 오는 쪽을 셌습니다.

그 표는 비어 있으니 0이 나옵니다. 오류도 안 납니다. 명령은 정상이고 답도 정상입니다. 다만 물어본 곳이 틀렸습니다.

이걸 알아챈 건 다른 숫자 덕분입니다. 같은 결과에서 최근 30일에 무언가 한 계정이 2명으로 나왔거든요. 가입자가 0명인데 활동한 사람이 2명일 수는 없습니다. 두 숫자가 서로 어긋나서 잡혔습니다.

무엇을 세기로 했나요

세는 대상을 문장으로 먼저 적었습니다. 코드보다 이게 먼저입니다.

• 가입: 회원 표에 줄이 생긴 사람. 이번 주와 누적을 따로 셉니다.
• 초안 생성: 앱에서 문서 초안을 실제로 만든 사람. 가입만 하고 나간 사람과 구분합니다.
• 한도 소진: 이번 달 무료 다섯 번을 다 쓴 계정. 무료 이용 자격과 생성 횟수를 함께 확인해야 하며, 결제 여부와는 별개입니다.
• 활동: 최근 30일에 앱에서 뭐라도 한 계정. 전환율을 낼 때 분모가 됩니다.

기록은 이미 쌓이고 있었습니다. 앱은 사람이 버튼을 누를 때마다 기록 표에 한 줄씩 남깁니다. 문서 내용이나 이름 같은 건 안 담고, 어떤 기능을 썼는지만 짧게 적습니다. 세기 위해 새로 만든 표는 없습니다.

숫자를 뽑는 명령문은 이렇게 생겼습니다

파일 하나에 명령문 한 벌을 적어 두고, 볼 때마다 통째로 붙여넣어 돌립니다. 핵심은 이 대목입니다.

-- 초안을 한 번이라도 만든 계정
select count(distinct user_id)
from public.events
where event_name = 'feature_use'
  and props->>'feature' = 'doc_generate'
  and (props->>'quota_state' is null or props->>'quota_state' = 'committed');

-- 이번 달 초안 생성 기록이 다섯 건 이상인 계정
-- 이 예제만으로는 유료 계정이 제외되지 않는다
select count(*)
from (
  select user_id, count(*) as n
  from public.events
  where event_name = 'feature_use'
    and props->>'feature' = 'doc_generate'
    and (props->>'quota_state' is null or props->>'quota_state' = 'committed')
    and created_at >= date_trunc('month', now())
  group by user_id
) t
where n >= 5;

events 가 아까 말한 기록 표이고, feature_use 는 기능을 실제로 실행했다는 표시입니다. doc_generate 는 그중 초안 만들기입니다.

생성 성공은 예약 상태가 없는 기존 성공 또는 확정된 기록만 셉니다. 예약 중·해제된 기록은 성공에 넣지 않습니다. 두 번째 예제는 생성 기록이 다섯 건 이상인 계정만 셉니다. 유료 계정을 거르는 조건이 없으므로, 이 결과를 그대로 무료 한도 소진 인원이라고 쓰면 안 됩니다. 무료 한도 소진을 집계하려면 해당 시점의 이용 자격과 실제 한도 적용 기록을 함께 확인해야 합니다. 위 코드는 집계 원리를 보여주는 발췌이며 운영 집계의 완성본은 아닙니다.

여기서 지킨 선이 하나 있습니다. 표를 새로 만들지 않았습니다. 세기 위해 표를 늘리면 앱이 무거워지고, 그 표가 맞는지 다시 확인해야 합니다. 이미 쌓이는 기록을 세는 것으로 충분했습니다.

한 가지 더. 무료 한도를 다섯 번으로 정한 건 앱 코드이고, 다섯 번을 세는 건 이 명령문입니다. 두 군데에 같은 숫자가 적혀 있습니다. 나중에 한도를 바꾸면 여기도 같이 고쳐야 한다고 파일 맨 위에 적어 뒀습니다. 안 적어 두면 반년 뒤의 제가 모릅니다.

세어 보니 나온 숫자

9월 8일에 기록해 둔 결과입니다. 아래 값은 당시 기록이며 이번 설명 교정에서 운영 데이터나 결제 내역을 다시 조회하지 않았습니다. 결제 0명을 무료 한도 0명에서 추론하면 안 되며, 위 발췌 코드만으로 아래 표의 모든 항목을 재현할 수는 없습니다.

가입은 열 명인데 초안을 만들어 본 계정은 없습니다. 제 계정으로 시험한 것은 다른 경로라 여기 안 잡힙니다.

이 표를 보고 요금을 손대지 않기로 했습니다. 아무도 안 만들어 봤는데 가격을 내리면 결과가 안 바뀝니다. 손댈 곳은 요금이 아니라 앱에 도착한 사람이 첫 초안까지 가는 길입니다.

복지관 실적으로 옮기면

명부가 두 군데인 상황은 현장에도 흔합니다. 출석부에 적은 인원과 회원관리 시스템에 등록된 인원이 다르고, 담당자가 따로 만든 엑셀에는 또 다른 숫자가 있습니다. 실적을 낼 때마다 어느 쪽을 셌는지가 갈립니다.

제가 이번에 한 것은 세 가지였습니다.

먼저 무엇을 셀지 문장으로 적었습니다. 「참여 인원」이 아니라 「한 번이라도 출석한 사람」처럼, 세는 조건이 문장 안에 들어가 있어야 합니다. 다음으로 어느 명부에서 세는지를 그 문장 옆에 적었습니다. 마지막으로 서로 어긋나면 알아채도록 관련된 숫자를 같이 뽑았습니다. 가입 0명과 활동 2명이 나란히 있었기 때문에 틀린 걸 알았습니다.

숫자 하나만 뽑아 보면 그게 틀려도 모릅니다. 옆에 다른 숫자가 있어야 어긋난 게 보입니다.

이 숫자로 아직 못 하는 것

전환율은 아직 볼 수 없습니다. 최근 30일 활동 계정이 2명이라 분모가 너무 작습니다. 여기서 한 명이 결제하면 50퍼센트, 안 하면 0퍼센트입니다. 어느 쪽도 요금을 접을지 말지에 답해 주지 않습니다.

그래서 판정 시계를 아직 안 켰습니다. 활동 계정이 30명이 되는 달부터 8주를 세기로 정했습니다. 30명이면 한 명이 결제했을 때 3퍼센트쯤 되니, 그때부터 숫자가 뜻을 갖습니다.

이탈한 사람 수는 대략치입니다. 구독이 켜지고 꺼진 이력을 따로 안 쌓아서, 지금 꺼져 있고 최근에 바뀐 줄을 셉니다. 한 사람이 한 달에 여러 번 오갔으면 한 번으로 셉니다.

그리고 이 표는 왜 안 쓰는지를 말해 주지 않습니다. 가입까지 왔다가 초안을 안 만든 열 명이 어디서 멈췄는지는 숫자로 안 나옵니다. 그건 사람한테 물어야 합니다. 다음에 할 일이 그것입니다.