매출과 구독
Paywall → Purchase → Success 구독 퍼널 설계
업데이트 2026-09-143 분 분량
짧은 답
페이월 노출(표시될 때마다 한 번, 노출 위치와 함께), 구매 시작(스토어 결제 시트를 요청할 때), 구매 확정(검증을 마친 뒤 거래당 한 번), 그리고 성공하지 못한 결말(취소·실패·보류)을 기록하세요. 이 이벤트들을 사용자 기준의 닫힌 퍼널로 보고 노출 위치별로 나눈 뒤, 확정된 구매 수를 스토어 데이터와 대조하세요.
많은 구독 앱이 페이월 노출과 구매만 기록하고 하나를 다른 하나로 나눕니다. 그렇게 나온 숫자로는 아무것도 할 수 없습니다. 사람들이 가격을 보고 나갔는지, 스토어 결제 시트를 열었다가 취소했는지, 결제했는데 오류가 났는지 알 수 없기 때문입니다. 셋은 각각 다른 해결책이 필요하고, 각각 자기 이벤트가 필요합니다.
기록할 이벤트
| 이벤트 | 기록 시점 | 추가할 만한 매개변수 |
|---|---|---|
| paywall_view | 페이월이 실제로 화면에 표시될 때 — 표시될 때마다 한 번 | placement(온보딩, 설정, 기능 잠금 등 노출 위치), paywall_id 또는 variant |
| purchase_start | 사용자가 상품을 누르고 스토어 결제 시트를 요청할 때 | product_id, placement |
| purchase_success | 거래 검증을 마치고 이용 권한을 부여할 때 — 거래당 한 번 | product_id, placement, is_trial |
| purchase_cancel | 스토어가 사용자 취소를 알려줄 때 | product_id, placement |
| purchase_fail | 스토어나 자체 검증에서 오류가 반환될 때 | product_id, error_code |
| purchase_pending | 보호자 승인 요청(Ask to Buy)이나 Google Play 결제 대기처럼 승인을 기다릴 때 | product_id |
참고: Firebase는 App Store와 Google Play 구매에 대해 in_app_purchase도 수집하며, StoreKit 2에서는 Analytics.logTransaction()으로 기록합니다. 직접 만드는 이벤트 이름은 purchase가 아닌 purchase_success 같은 이름으로 정하세요. 그래야 GA4 구매 수익에서 같은 판매가 두 번 집계되지 않습니다.
이벤트별로 자주 틀리는 지점
- paywall_view를 렌더링할 때마다, 또는 화면이 다시 나타날 때마다 기록하면 노출이 부풀고 전환율이 줄어듭니다
- 이미 구독 중인 사람에게도 paywall_view를 기록하면 구매할 수 없는 화면을 재는 셈입니다
- purchase_start를 탭이 아니라 페이월이 열릴 때 기록하면 첫 단계가 노출 이벤트의 복사본이 됩니다
- 앱이 활성 구독을 발견할 때마다 — 실행할 때마다, 또는 복원 후에 — purchase_success를 기록하면 기존 구독자가 신규 판매로 잡힙니다
- 취소를 오류로 처리하면 정상적인 망설임이 실제 실패 사이에 섞여 보이지 않게 됩니다
퍼널 읽기
GA4에서 paywall_view → purchase_start → purchase_success 순서의 닫힌 유입경로 탐색 분석을 사용자 기준으로 만들고 placement별로 나눠 보세요. 단계마다 답하는 질문이 다릅니다.
| 단계 | 낮다면 확인할 것 |
|---|---|
| paywall_view → purchase_start | 가격, 무료 체험 제안, 요금제 배치, 사용자가 가치를 경험하기 전에 페이월이 뜨는지 여부 |
| purchase_start → purchase_success | 결제 시트에서의 취소, 결제 실패, 승인 대기, 검증 오류 |
| placement별 purchase_success | 앱의 어떤 순간에 사람들이 결제할 준비가 되는지 |
온보딩 기능 잠금 paywall_view (사용자) 5,000 800 purchase_start 400 120 purchase_success 300 60 노출 → 성공 6.0% 7.5% 시작 → 성공 75% 50%
기능 잠금 위치가 전체 전환율은 더 높지만, 그곳에서 구매를 시도한 사람의 절반이 끝내지 못합니다. 그 경로의 결제 문제입니다. 해당 placement의 purchase_cancel과 purchase_fail을 확인하세요. 페이월 가격을 아무리 테스트해도 이 문제는 드러나지 않았을 것입니다.
스토어 데이터와 대조하기
퍼널의 확정 구매는 스토어 자체 기록과 같은 흐름을 보여야 합니다. 같은 날짜 기준으로 iOS 스트림의 purchase_success 사용자 수는 App Store Connect의 신규 구독과, Android는 Play Console과 비교하세요. 차이가 꾸준하다면 이벤트가 빠졌거나 중복된 것이고, 갑자기 생긴 차이라면 대개 릴리스에서 기록 위치가 바뀐 것입니다.
주의: 무료 체험은 며칠 뒤, 대개 앱이 닫혀 있을 때 유료 구독으로 전환됩니다. 퍼널이 재는 것은 체험 시작이며, 유료 전환은 App Store Connect와 Play Console, 또는 Firebase가 수집하는 경우 app_store_subscription_convert에서 확인합니다.
배포 전에 확인할 것
- placement, product_id, paywall_id를 맞춤 측정기준으로 등록하세요. 등록하기 전에는 이벤트 매개변수가 보고서와 탐색 분석에 나타나지 않고, 등록해도 이전 데이터는 채워지지 않습니다
- purchase_success를 주요 이벤트로 표시하세요
- DebugView에서 기기 하나로 노출, 시작, 취소, 실패, 성공을 모두 거치며 각 이벤트가 정확히 한 번씩 도착하는지 확인하세요
- 확인할 때는 iOS 샌드박스 계정과 Google Play 라이선스 테스터를 쓰세요. GA4는 in_app_purchase에서 샌드박스 구매를 제외하므로 테스트가 매출을 오염시키지 않습니다
Appnaly에서는 어떻게 보이나요
Appnaly에서는 시작 이벤트와 완료 이벤트를 앱의 핵심 흐름으로 지정할 수 있으며, purchase_start와 purchase_success가 잘 맞습니다. 그러면 Appnaly는 GA4 유입경로 보고서에 두 이벤트를 순서대로 모두 한 사람 수를 요청하고, 그 비율을 직전 완료 주와 비교하며, 변화가 의미를 가질 만큼 사람이 모이기 전에는 판단을 내리지 않습니다.