devlog
EN앱소개
카테고리

비즈니스 현실

유통, 정책, 결제 리스크, 만들기와 사업 사이의 간극을 과장 없이 기록.

전체 글

53
왼쪽: 앱 단위 페이지당 수율 표에서 2위 앱이 0.57로 멀쩡해 보인다. 오른쪽: 같은 앱을 URL 모양별로 쪼개면 늘리려던 모양의 페이지 5장이 전부 0이고, 유입은 전혀 다른 두 경로로 들어온다
비즈니스 현실11 분 읽기

수율 2위 앱에 25페이지를 낼 뻔했습니다 — 그 모양의 URL은 0을 받고 있었습니다

앱 27개의 페이지당 수율을 실측해 증설 대상을 골랐습니다. 1등과 2등이 나왔고, 2등에 25페이지를 낼 계획이었습니다. URL 모양으로 한 겹 내려가 보니 그 모양의 기존 페이지 5장이 전부 0이었습니다. 앱 평균이 살아 있다고 그 안의 모양까지 살아 있는 건 아니었습니다.

#measurement#seo#naver#reality-check
왼쪽: 합격선 150은 비교군을 전 소스 세션으로 잡아서 나온 숫자이고, 같은 유형 앱의 검색 세션 실측 최고치는 39다. 오른쪽: 실측 네 개를 페이지당 수율과 함께 늘어놓으면 두 무리로 갈라지고, 새 임계 20이 그 사이에 놓인다
비즈니스 현실13 분 읽기

제가 정한 합격선은 다른 지표에서 가져온 숫자였습니다

새 앱 게이트를 두 번 다시 썼습니다. 첫 판은 함대 최상위 앱도 못 넘는 바였고, 두 번째 판은 비교 대상의 단위가 달랐습니다 — 전 소스 세션으로 잰 숫자를 검색 세션 임계로 쓰고 있었습니다. 관측이 0인 동안 고쳤으니 사후 바 이동은 아닙니다. 다만 두 번 틀렸습니다.

#gates#preregistration#measurement#reality-check
개념 도식: 같은 캡션 트리트먼트가 다섯 앱에서 서로 다른 방향으로 갈린 향상
비즈니스 현실11 분 읽기

같은 캡션이 한 앱에서 +325%, 다른 앱에서 -42%였습니다

스토어 제품 페이지 A/B 5건을 같은 날 읽었습니다. 트리트먼트는 다섯 개 모두 캡션 합성 하나로 같았는데 결과가 -42%에서 +325%로 갈렸습니다. 그리고 며칠 전 검정력 계산은 중복 제거 전 노출을 써서 9배 틀려 있었습니다.

#analytics#measurement#app-store#methodology
두 패널 도식. 왼쪽은 4시간 안에 일어난 일 — 제품 스크래치, 리스트 100건, 발송 111통. 오른쪽은 다음 날 회신 분류 — 하드바운스 3, 자동응답 15, 사람 회신 5(그중 부정 3), 무응답 77, 샘플 요청 0. 아래에 수신자 주소 대부분이 support·contact·info 형태라는 표기.
비즈니스 현실14 분 읽기

콜드메일 111통을 4시간에 보냈습니다 — 다음 날 세어보니 샘플 요청은 0건이었습니다

하루 만에 제품을 만들고, 리스트를 뽑고, 111통을 보냈습니다. 다음 날 회신을 전수 조회하니 하드바운스 3, 자동응답 15, 사람 회신 5, 샘플 요청 0이었습니다. 사전등록한 킬 기준은 100통 후 요청 10건 미만이면 중단이었고, 결과는 FAIL입니다. 그런데 더 불편한 사실은 내가 측정한 게 수요가 아니라 남의 고객지원 큐였다는 것입니다.

#distribution#reality-check#gates#preregistration
같은 데이터를 두 그래프로. 왼쪽은 4,000자 상한 대비라 막대들이 전부 3분의 1쯤 차 있어 다 비어 보이고, 오른쪽은 원문 대비 언어 밀도로 정규화해 대부분이 기준선에 붙어 있고 두 개만 바닥에 붙어 빨간 테두리가 쳐져 있음.
비즈니스 현실8 분 읽기

"51만 자가 비어 있다"고 적어 두고, 기준을 바꾸니 1만 9천 자였습니다

안드로이드 스토어 전체 설명 196개 슬롯이 한도의 34%만 쓰고 있었습니다. 미사용 51만 자를 '가장 큰 유입 면적'이라고 보고서에 적었는데, 그 숫자는 잘못 잰 것이었습니다. 상한 대신 원문 대비로 재니 결손은 1만 9천 자였고 대부분이 소수 슬롯에 몰려 있었습니다.

#metrics#aso#audit#gotchas
왼쪽: 심사 승인이 풀어주는 것 — 비공개 전용 게시가 공개 게시로 바뀐다, 그게 목록 전부. 오른쪽: 풀어주지 않는 것 — 공유 가이드라인이 게시 건별 명시적 동의를 계속 요구하므로 사람이 폼을 열고 미리보기를 보고 공개범위를 골라 게시를 누른다. 승인이 아끼는 사람 클릭 = 0.
비즈니스 현실14 분 읽기

심사 반려 세 번을 맞고 나서야, 승인이 아무것도 안 아껴준다는 걸 계산해봤습니다

숏폼 자동게시 API 심사에 두 번 반려당하고 아이콘과 도메인을 고쳤습니다. 세 번째 반려는 고칠 것이 없는 사유였습니다. 그때서야 계산해보니, 승인을 받아도 제가 아끼는 사람 손은 0회였습니다 — 그 사실은 첫날 가이드라인 원문에 적혀 있었습니다.

#reality-check#first-principles#api#distribution
왼쪽: 건강 선언 폼. 수면·스트레스 관리에 체크되어 있고 앱은 게시된다. 오른쪽: 'Diseases and conditions management'에 체크된 순간 제출 위에 'Organization account required' 도장이 찍힌다.
비즈니스 현실10 분 읽기

체크박스 한 칸을 골랐더니, 개인 계정으로는 그 앱을 낼 수 없다고 했습니다

건강 앱 세 개가 스토어에서 거부됐습니다. 사유는 콘텐츠가 아니라 계정 종류였습니다. 같은 계정의 다른 건강 앱은 통과했고, 갈린 지점은 건강 선언에서 Medical 섹션을 골랐는지 하나였습니다. 선언을 비우고 재제출해도 거부됐습니다 — 남은 길은 조직 계정 하나뿐이었고, 거기엔 되돌릴 수 없는 대가가 붙습니다.

#android#google-play#distribution#reality-check
왼쪽: 제보가 지적한 11개 항목. 오른쪽: 문구 수정으로 닫을 수 있었던 것은 2개, 나머지 9개는 사실과 결정이 필요했다.
비즈니스 현실13 분 읽기

익명의 제보가 제 개인정보처리방침이 거짓이라고 했습니다. 사실이었습니다

이름도 소속도 없는 메일 한 통이 제 앱의 EU 규제 문제 11가지를 조목조목 적어 보냈습니다. 인용문을 전부 실물과 대조했더니 한 글자도 틀리지 않았고, 그중 두 개는 제 정책이 실제로 하고 있던 거짓 진술이었습니다. 하나는 동의 화면 안에 있었습니다.

#privacy#supabase#reality-check#postmortem
개념 도식: 왼쪽은 호출 비용 0, 약관에 API 언급 0건, 그러나 제14조 6항이 제3자 제공을 금지해 기대 상한 월 50~300달러 대비 광고계정 해지 리스크가 큰 상태. 오른쪽은 원천을 이용범위 제한 없는 공공데이터로 바꿔 같은 제품을 하루에 출시한 상태.
비즈니스 현실10 분 읽기

API는 공짜였는데, 약관 한 줄이 제품을 죽였습니다

트렌드 리포트에서 추격할 카테고리 세 개를 실측으로 기각하고, 남은 후보를 짓기 직전에 원천 데이터 약관을 읽었습니다. 호출은 무료였고 수치도 정확했지만, 취득한 정보를 제3자에게 제공하지 말라는 한 줄이 제품 전체를 무효로 만들었습니다.

#reality-check#first-principles#gotchas#distribution
왼쪽 패널은 내가 고객에게 보낸 답변 - 하루 한 건, 설계상 그렇다, 다시 저장하면 교체된다, 이 앱은 맞지 않는다. 오른쪽 패널은 코드가 실제로 한 일 - 폼이 모든 증상을 0으로 초기화하고 하루 유니크 행에 upsert 해서 아침의 hot_flash 3·sleep 4가 저녁에 hot_flash 0·sleep 3으로 바뀌었으며 스트릭은 초록불로 남았다
비즈니스 현실14 분 읽기

제가 고객에게 "설계상 그렇습니다"라고 답했고, 그건 데이터 손실이었습니다

환불 요청에 "하루 한 건이 설계입니다"라고 답했습니다. 코드를 열어보니 설계가 아니라 버그였습니다. 체크인 화면이 항상 빈 상태로 열려서, 저녁에 저장하면 아침에 기록한 값 위에 0을 덮어쓰고 있었습니다. 스트릭은 계속 초록불이었습니다.

#support#data-loss#postgres#reality-check
개념 도식: 왼쪽은 '크롤러가 막혔다'는 편한 가설, 오른쪽은 본문 472자와 조회 29,625 대비 세션 29라는 실측
비즈니스 현실11 분 읽기

광고 거절을 크롤러 탓으로 돌릴 뻔했다

AdSense가 '가치가 별로 없는 콘텐츠'로 사이트를 거절했습니다. 저는 CDN이 크롤러를 막았다고 확신했고, 예전에 실제로 그랬던 적도 있었습니다. 확인해 보니 크롤러는 멀쩡히 들어오고 있었고, 문제는 제 앱 본문이 472자라는 사실이었습니다.

#monetization#adsense#reality-check#first-principles
개념 도식: 왼쪽은 대시보드를 그대로 읽어 내린 결론, 오른쪽은 수집 상한을 올리자 드러난 실제 데이터
비즈니스 현실12 분 읽기

내 리포트가 상위 10개만 담고 있었고, 나는 '수요가 없다'고 결론냈다

검색 유입을 1원칙으로 점검하다 같은 오류를 하루에 두 번 잡았습니다. 롱테일이 없던 게 아니라 수집기가 10개만 담고 있었고, 한 앱이 유입의 73%였던 게 아니라 계측된 앱이 6개뿐이었습니다. 둘 다 데이터를 더 파서가 아니라 수집 상한을 의심해서 뒤집혔습니다.

#reality-check#analytics#first-principles#seo
개념 도식: 왼쪽은 공들인 유튜브가 앱 유입 13%, 오른쪽은 거의 안 밀던 Threads가 63%
비즈니스 현실8 분 읽기

앱 유입의 63%는 내가 안 밀던 채널에서 왔다

여섯 달을 유튜브 쇼츠에 부었습니다. 앱 유입을 소스별로 처음 측정해 보니, 유튜브는 13%였고 거의 손 안 대던 Threads가 63%였습니다. 게다가 그 측정 도구는 이미 존재했는데 제 grep이 조용히 거짓말을 해서 하마터면 똑같은 걸 다시 만들 뻔했습니다.

#first-principles#analytics#reality-check#traffic
개념 도식: +30% 리프트 검출에 필요한 일수. 매출 상위 앱은 299일·280일로 30일 선 밖, 노출 538/일인 매출 0원 앱만 9일로 선 안.
비즈니스 현실9 분 읽기

실험을 설계했더니 통계적으로 불가능했다

매출 상위 앱 3개에 새 크리에이티브 자산을 붙이고 전후를 비교할 계획이었습니다. 실행 전에 검정력을 계산했더니, 이 앱들은 어떤 현실적 기간에도 효과를 검출할 수 없었습니다. 효과를 재는 앱과 효과를 보는 앱을 분리해야 했습니다.

#app-store#statistics#ab-testing#reality-check
개념 도식: 노출 상위 6개 앱이 인벤토리의 53%를 먹지만 매출 0원. 노출 19위 앱 하나가 매출의 81%. 설치의 52%는 팔 물건이 없는 앱으로.
비즈니스 현실8 분 읽기

노출 1위 앱의 매출은 0원이었다

40개 넘는 앱의 ASO를 몇 달 만졌습니다. 노출이 늘면 매출이 는다는 가정 위에서요. 처음으로 돈을 직접 뽑아 대조하니 노출 순위와 매출 순위가 역상관이었습니다. 레버는 트래픽이 아니라 설치당 매출이었습니다.

#app-store#aso#revenue#reality-check