AI 보조 개발7 분 읽기

앱 열네 개를 진단했고, 전부 틀렸습니다

설치→결제 0.62%가 어디서 죽는지 파고들었습니다. 가설에 맞는 앱 14개를 코드에서 찾아냈는데, 실제 결함은 하나뿐이었습니다.

#analytics#honesty#first-principles#reality-check#monetization
개념 도식: 가설로 지목한 앱 14개 중 실제 결함은 1개뿐이고 나머지는 의도된 설계였음을 보여주는 도식
글 내용을 요약한 개념 도식.

전날 매출 지표를 분석하다 질문 하나가 남았습니다. 노출을 50% 늘렸더니 매출이 23% 줄었던 글에서 던진 질문입니다 — "설치에서 결제까지 0.62%인데, 정확히 어느 단계에서 사람들이 사라지는가."

가설을 세웠습니다. "페이월이 뜨는 시점이 너무 늦어서, 핵심 가치를 경험하기 전에 사라진다." 그 가설에 맞는 패턴을 가진 앱 14개를 코드에서 찾아냈습니다.

결론부터 말하면 그 14개 진단이 전부 틀렸습니다.

당신이 코드 검색으로 찾아낸 "같은 결함"은, 정말 같은 결함입니까?

조건문의 겉모양이 같았을 뿐입니다

"온보딩 완료 여부를 세는 카운터가 없는 앱"을 조건식으로 찾아 14개를 골랐습니다. 그리고 이게 예전에 한 번 고친 적 있는 결함의 재발이라고 적었습니다.

루트 화면 구조를 하나하나 읽어봤습니다.

  • 세 앱은 "온보딩을 마쳐야만 홈 화면이 존재하는" 구조였습니다. 즉 "온보딩 직후에만 한 번"이라는 의도가 정확히 그대로 동작하고 있었습니다.
  • 한 앱은 아예 온보딩 화면이 없었습니다. 첫 화면이 곧 홈이고, 대신 "사용자가 아이템을 하나 이상 만들면" 페이월을 띄우는 조건이 따로 있었습니다 — 시작 시점 하나, 참여 시점 하나로 의도적으로 나눈 두 개의 진입점이었습니다.
  • 실제로 회귀가 있었던 앱은 단 하나였습니다.

페이월을 언제 띄울지는 설계 선택이지 결함이 아닙니다. 조건식만 훑어서 "카운터가 없다"까지는 확인할 수 있어도, 그게 결함이려면 "원래 다른 의도가 있었다는 증거"가 따로 필요합니다. 그 증거는 루트 화면 구조를 실제로 읽어야만 나옵니다.

두 번째 권고도 틀렸습니다

"그럼 페이월을 더 뒤로 미루면 되지 않나." 이것도 데이터로 확인해보니 틀렸습니다.

계측이 실제로 있는 유일한 앱에서:

  • 실제로 뭔가를 담아본 사용자는 전원 이미 페이월을 본 적이 있었습니다. 트리거를 뒤로 옮겨도 이들에겐 변화가 없습니다.
  • 바뀌는 건 아직 아무것도 안 담아본 사용자가 페이월을 못 보게 되는 것뿐이고, 그 표본에서 그 사용자군 중 1명이 실제로 구매까지 갔었습니다.
  • 즉 이 변경을 적용하면 구매가 3건 → 2건으로 줄어듭니다.

당신이라면 "참여한 사람이 전환율이 높다"는 관찰에서 무엇을 처방하겠습니까?

"참여한 사람이 구매 전환이 높다"는 관찰 자체는 참입니다. 하지만 그건 선택 효과입니다 — 원래 관여도가 높은 사람이 결국 사니까 그렇게 보이는 것이지, 페이월 타이밍을 바꿔서 생기는 효과가 아닙니다.

선택 효과를 인과 효과로 착각하면 정반대의 처방을 내립니다.

진짜 남는 숫자

설치 110명 → 페이월 노출 37명(34%) → 결제 시작 5명 → 결제 완료 3명
핵심 행동(아이템 추가) 11명(10%)
 
페이월 본 37명 중 26명은 핵심 행동을 한 번도 안 했다(70%)
핵심 행동을 한 11명은 전원 페이월을 봤다
결제 3명 중 2명이 핵심 행동을 한 쪽 — 표본이 작아 "몇 배 차이"는 근거로 못 씀

병목은 페이월 노출도, 페이월 타이밍도 아니었습니다. **핵심 행동 도달률 자체가 10%**라는 것입니다. 이건 페이월을 어디에 두든 그대로 성립하는 숫자입니다.

자가진단

  • 코드 검색으로 찾은 "같은 패턴"을 같은 결함이라고 쓰기 전에, 각각의 의도를 확인했습니까?
  • 어떤 조건이 결함이려면 원래 다른 의도가 있었다는 증거가 필요합니다. 그 증거가 있습니까?
  • 상관을 처방으로 바꾸기 전에, 그 집단이 원래 그랬을 가능성을 배제했습니까?

솔직한 부분

전날 지표 분석에서 결제까지 계측이 연결된 앱은 46개 중 1개뿐이었습니다. 설치가 가장 많은 상위 5개 앱은 전부 계측이 없습니다.

즉 0.62%라는 숫자 자체가 대부분 근거 없는 어둠 속에 있었습니다. 제가 14개 앱을 진단하는 동안, 진단의 근거가 된 숫자는 한 앱에서만 나온 것이었습니다.

당신이 최근 코드 검색으로 지목한 "결함 N건"을 다시 열어서, 그중 몇 개가 의도된 설계인지 세어보세요.

관련 글