스토어 전환율이 32%에서 21%로 떨어졌다고 해 볼게요. 회의에서 제일 먼저 나오는 말은 대개 "스크린샷 바꾼 지 오래됐죠?"예요. 그런데 소스별로 나눠 보면 Search도 Browse도 전환율이 하나도 안 변한 경우가 있습니다. 소스별 관측 전환율은 유지됐지만 합계가 낮아진 것입니다. 페이지가 최적이라는 뜻은 아닙니다.
이 글은 그 두 경우를 가르는 방법에 대한 겁니다. 처방이 정반대라서, 섞인 채로는 어느 쪽도 못 고칩니다.
전체 전환율은 두 가지가 섞인 숫자입니다
스토어 전환율은 보통 제품 페이지 조회 대비 설치로 봅니다. 그런데 이 하나의 숫자 안에는 성격이 다른 두 움직임이 들어 있어요.
- 효율 — 소스별 전환율 자체가 변했다. 페이지를 본 사람 중 설치하는 비율이 달라진 것.
- 믹스 — 소스별 전환율은 그대로인데 소스별 비중이 변했다. 전환이 낮은 쪽에서 사람이 더 많이 들어온 것.
둘 다 전체 전환율을 똑같이 끌어내립니다. 화면에 뜨는 증상이 같아요. 그런데 효율 변화는 페이지뿐 아니라 소스 안의 유입 의도·기기·측정 변화에서도 나올 수 있습니다. 두 항은 점검할 범위를 좁히는 단서입니다.
숫자로 보면 분명해집니다
연속된 6주 중 앞 3주와 뒤 3주를 비교한다고 해 볼게요. 소스는 둘만 두겠습니다.
| 앞 기간 조회 | 앞 기간 전환율 | 뒤 기간 조회 | 뒤 기간 전환율 | |
|---|---|---|---|---|
| App Store Search | 4,300 | 45% | 2,600 | 45% |
| App Store Browse | 2,400 | 9% | 5,200 | 9% |
소스별 전환율은 45%와 9%로 앞뒤가 완전히 똑같습니다. 한 소스도 나빠지지 않았어요.
그런데 전체를 계산하면 이렇습니다.
- 앞 기간: 설치 (4,300×0.45) + (2,400×0.09) = 1,935 + 216 = 2,151. 조회 6,700. 전환율 32.1%
- 뒤 기간: 설치 (2,600×0.45) + (5,200×0.09) = 1,170 + 468 = 1,638. 조회 7,800. 전환율 21.0%
전환율이 약 11.1%p 떨어졌습니다. 조회는 오히려 1,100건 늘었는데 설치는 513건 줄었고요. 이 분해만으로 스크린샷 변경의 미래 효과까지 알 수는 없습니다. 바뀐 건 전환이 낮은 Browse의 비중이 36%에서 67%로 커진 것뿐이니까요.
소스별 전환율이 모두 올랐는데도 전체가 떨어지는 더 극단적인 경우는 심슨의 역설에서 같은 원리로 다룹니다.
부분에서는 아무것도 안 나빠졌는데 전체만 나빠지는 이 현상은 통계에서 심슨의 역설로 불리는 것과 같은 구조예요. 가중치가 움직이면 평균은 부분과 반대로 갈 수 있습니다.
반대 경우도 똑같이 위험합니다
방향을 뒤집어 볼게요. 비중은 그대로인데 Search 전환율이 45%에서 38%로 떨어졌다면, 이건 진짜 페이지 문제일 가능성이 큽니다. 스크린샷 교체, 평점 급락, 앱 용량 증가, 스토어 정책 변경 같은 것들이 후보예요.
이때 "Browse 유입이 늘어서 그런가 보다"라고 넘기면 실제로 손대야 할 문제를 못 보고 지나갑니다. 두 원인은 서로의 알리바이가 되기 쉬워요.
도구의 분해 단위부터 확인하세요
전환율 변화(%p)와 도구의 분해 항은 단위가 다릅니다. 도구는 기존 PVM 엔진으로 설치당 조회 수(조회 ÷ 설치, 전환율의 역수) 변화를 분해하며, 가중치는 조회 비중이 아닌 설치 비중입니다.
소스별 앞·뒤 기간의 설치당 조회 수를 r₁, r₂, 설치 비중을 s₁, s₂라 하고, 막대 표시는 두 기간의 산술평균이라고 두면:
- 믹스 항 =
(r̄ − 전체 설치당 조회 수의 두 기간 평균) × (s₂ − s₁) - 효율 항 =
s̄ × (r₂ − r₁)
같은 소스 집합과 유효 분모를 사용하면 두 항의 전체 합은 설치당 조회 수 변화와 일치합니다. 화면의 전환율 차이를 이 항과 직접 더하거나 %p로 표기하면 안 됩니다. 신규·종료 소스와 0 설치는 도구의 지원 범위와 보류 사유를 확인하세요.
도구로 나누기
이 계산을 CSV 올려서 바로 보려면 ASO 스토어 전환 분석을 쓰면 됩니다. App Store Connect의 소스 유형 리포트나 Google Play Console의 트래픽 소스 리포트를 그대로 올리면 돼요.
기간을 반으로 갈라 앞뒤를 비교하고, 믹스와 효율 중 어느 쪽이 주도했는지 판정합니다. 소스별 전환율·비중 표와 날짜별 추이 차트도 같이 나오니까, 변화가 특정 날짜에 꺾였는지 서서히 밀렸는지도 볼 수 있어요.
추이 차트에서 읽는 법은 간단해요. 소스별 점선은 나란한데 전체 굵은 선만 내려가면 믹스, 점선들이 같이 내려가면 페이지입니다.
나눈 다음에 할 일
믹스가 원인일 때. 유입 구성이 왜 바뀌었는지부터 봅니다. 광고를 늘려 Browse 노출이 커졌는지, 피처링이 붙었는지, 시즌 요인인지에 따라 대응이 달라요. 이때 전환율은 정상이므로 목표를 전환율이 아니라 설치 수로 다시 잡는 게 맞을 수 있습니다. 저전환 소스라도 설치 절대량이 늘었다면 나쁜 일이 아니거든요.
효율이 원인일 때. 어느 소스에서 떨어졌는지를 먼저 좁힙니다. 전 소스에서 고르게 떨어졌다면 페이지 요소나 평점, 특정 소스에서만 떨어졌다면 그 소스의 유입 의도가 바뀐 겁니다. Search에서만 떨어졌다면 새로 랭크된 키워드가 우리 앱과 안 맞는 경우가 흔해요.
오늘 해볼 것
- 스토어 콘솔에서 최근 6주치를 소스 유형(또는 트래픽 소스)별로 내려받으세요.
- 소스별 전환율을 앞 3주·뒤 3주로 나눠 각각 계산해 보세요. 여기서 소스별 값이 그대로인지 아닌지만 봐도 절반은 답이 나옵니다.
- 믹스가 원인이었다면, 그 기간에 광고비나 노출 구성을 바꾼 게 있는지 캘린더를 확인하세요.
이 방법의 한계
이 분해는 어디를 볼지 좁혀 줄 뿐 원인을 증명하지 않습니다. 도구의 믹스 항은 설치당 조회 수에서 비중 변화로 설명되는 몫이지, 왜 비중이 변했는지까지 알려주지는 않아요. 같은 기간에 광고 증액과 피처링과 시즌이 겹쳤다면 이 표로는 셋을 가를 수 없습니다.
스크린샷이나 아이콘 변경의 효과를 확정하려면 관측 데이터가 아니라 스토어 실험이 필요합니다. 유료 유입이 오가닉을 잠식하는지가 궁금하면 증분 분석 쪽이고요.
그리고 기간을 반으로 가르는 방식 자체가 가정입니다. 변화가 딱 중간에 일어났다는 보장이 없어요. 추이 차트를 먼저 보고 실제로 꺾인 날이 어디인지 확인한 다음, 그 지점 기준으로 다시 나눠 보는 편이 정확합니다.