제가 아는 두 팀이 같은 앱을 운영하면서 같은 달에 각각 3.1%와 5.8%의 환불율을 보고한 적이 있습니다. 둘 다 거짓말을 한 것은 아니었습니다. 지표를 서로 다르게 정의했을 뿐인데, 그 정의를 누구도 문서로 남기지 않았던 겁니다.
이것이 바로 아무도 기능 소개 페이지에 적지 않는, 모바일 앱 환불 분석의 함정입니다. 숫자는 그 뒤에 있는 귀속 규칙만큼만 신뢰할 수 있는데, 대부분의 대시보드는 어떤 규칙을 사용했는지 밝히지 않습니다.
이 글에서는 각 도구가 무엇을 하는지, 그리고 어떤 도구든 신뢰하기 전에 반드시 물어봐야 할 방법론 질문 하나를 다룹니다. 추적 메커니즘만 더 깊이 알고 싶다면, App Store 환불을 추적하는 방법에서 Apple 쪽 내용을 더 자세히 다룹니다.
핵심 요약
코호트 귀속이 기간 귀속보다 낫습니다. 환불이 반영된 달이 아니라 구매가 발생한 달을 기준으로 집계해야 합니다.
환불 지연은 몇 주, 때로는 결제 주기 전체에 걸쳐 발생합니다. 이번 달 환불율을 보여주는 대시보드는 사실상 불완전한 수치를 보여주는 것입니다.
차지백은 환불이 아닙니다. RevenueCat은 차지백을 환불로 집계하지 않는다고 명확히 밝히고 있으므로, 별도의 피드가 필요합니다.
스토어 콘솔은 무료지만 추세 분석에는 약합니다. Apple은 보고서를 제공하고, Google은 일일 호출 제한이 있는 API를 제공합니다.
모바일 앱 환불율을 추적하는 가장 좋은 도구는 분모를 공개하는 도구입니다.
먼저, 정의의 문제
앱 환불율을 추적하는 방식에는 두 가지가 있으며, 이 둘은 서로 다른 결과를 냅니다.
기간 방식: 3월에 발생한 환불을 3월에 청구된 거래로 나눕니다. 구축하기는 쉽지만, 3월 환불이 1월 구매에 해당하는 경우가 많으므로 부정확합니다.
코호트 방식: 1월에 청구된 전체 거래 중 이후 환불된 비율을 계산합니다. 숫자가 계속 변하기 때문에 더 까다롭습니다.
Apphud는 이 점을 솔직하게 문서화하고 있습니다. 분모는 해당 기간에 청구된 거래이고, 분자는 기간이 마감된 이후를 포함해 나중에 환불된 건수입니다. 이것이 바로 코호트 방식이며, 실제 환불이 발생하는 방식과 맞아떨어집니다.
그래서 기준 시점(컷오프)이 필요합니다. 월간 구독은 30~45일 전후로 안정되지만, 연간 플랜은 몇 달에 걸쳐 계속 변동합니다. 10일 된 숫자와 90일 된 숫자를 비교하는 것은 잡음을 비교하는 것이나 다름없습니다.
무료 단계: 스토어 콘솔
여기서부터 시작하세요. 비용이 전혀 들지 않으며, 대부분의 팀이 여기서 멈춥니다.
App Store Connect. Sales and Trends와 Financial Reports를 통해 환불 내역을 확인할 수 있으며, 재무 보고서는 실제 지급액과 일치합니다. 기간 기준이며 수작업이 필요하고, 제품이나 채널별 세분화도 없습니다. 매달 한 번씩 상태를 점검하기엔 충분하지만, 어떤 페이월이 매출을 갉아먹고 있는지 찾는 데는 쓸모가 없습니다.
더 나은 무료 피드는 콘솔 안에 있지 않습니다. Apple의 Get Refund History 엔드포인트는 고객별로 환불된 모든 거래 목록을 페이지 단위로 반환하며, 이를 자체 데이터 웨어하우스로 가져올 수 있습니다. 호출 속도 제한이 있고, Apple은 폴링보다 알림 사용을 권장하므로 이는 대사(reconciliation) 용도로 취급하는 것이 좋습니다.
Google Play Console. 마찬가지로 재무 보고서가 있으며, 여기에 더해 Voided Purchases API는 특정 기간 동안 환불, 차지백 또는 취소된 구매 목록을 제공합니다. 하루 6,000건, 30초당 30건으로 제한되어 있어 실시간이 아닌 예약된 스윕 방식에 맞게 설계되어 있습니다.
두 콘솔 모두 추세 분석에는 같은 약점을 가지고 있습니다. 요청된 내용이 아니라 정산된 내용만 보고하므로, 방어에 성공한 요청은 전혀 확인할 수 없습니다.
RevenueCat
이미 구독이 이 플랫폼을 거쳐 처리되고 있다면, 이것이 기본적인 답입니다.
환불율은 RevenueCat의 벤치마크 지표 중 하나로, 첫 결제 주기 동안 환불된 유료 구독의 비율을 같은 스토어 및 카테고리의 앱들과 비교해 보여줍니다. 동종 비교 없이 원시 수치만 보면 행동으로 옮기기 어렵기 때문에, 이 벤치마킹이 바로 유용한 부분입니다. 그들의 State of Subscription Apps 보고서는 75,000개 이상의 앱을 다루며, 중앙값은 3%~5% 수준입니다.
또한 승인, 거부, 반전, 해결 대기 중으로 구분되는 App Store Refund Requests 차트도 제공됩니다. 이는 요청 단위 데이터이며, 대부분의 도구는 이를 생략합니다.
단, 두 가지 유의할 점이 있습니다. 개발자가 아닌 Google이 직접 승인한 Play 환불은 반영되기까지 최대 24시간이 걸릴 수 있고, 취소(revoke) 체크박스 없이 처리된 환불은 아예 감지되지 않습니다. 또한 RevenueCat은 차지백을 환불로 집계하지 않습니다. 구매 상태는 업데이트되지만 환불율에는 반영되지 않습니다.
Adapty
다른 도구들보다 세분화 기능이 강력합니다. 환불 추적을 일별, 플랜별, 제품별, 유입 채널별로 나누어 보여주는데, 바로 이런 세분화가 실제 문제를 찾아내는 열쇠입니다. 전체적으로는 괜찮아 보이지만 특정 채널에서 유독 나쁜 수치는 제품 결함이 아니라 메시징 문제일 가능성이 큽니다.
Adapty의 벤치마크는 11,000개 이상의 앱에서 추적된 19억 달러 규모의 매출을 기반으로 하며, 카테고리별 편차도 주목할 만큼 넓습니다. 교육 및 건강 분야는 4.7%~5.1%에 가깝고, 여행 및 유틸리티는 1.5%~2.1%에 더 가깝습니다. 연간 플랜은 주간 플랜보다 환불률이 높습니다. 하드 페이월은 약 5.8%인 반면, 프리미엄 모델은 3.4%입니다.
단점은 이 제품의 다른 부분과 마찬가지입니다. 이런 우수한 분석 기능은 Adapty SDK를 사용하고 있다는 것을 전제로 합니다.
Apphud
규모는 작고 비용도 저렴하지만, 방법론에 대해서는 유독 명확합니다. 바로 이 점만으로도 후보 목록에 올릴 가치가 있습니다. 문서에서 코호트 로직을 숨기지 않고 명확히 설명합니다. 실시간 대시보드, 약 18개의 구독 이벤트를 제공하며, 다른 대안들보다 마케팅색이 덜합니다.
이사회에서 방어할 수 있는 숫자가 필요하다면, 긴 기능 목록보다 명확함이 더 중요합니다.
전용 환불 및 차지백 추적
여기에 공백이 있습니다. 구독 플랫폼들은 정산된 환불만 집계합니다. 그 어떤 플랫폼도 응답 가능 기간 안에 위치하지 않기 때문에, 몇 건의 요청을 방어했는지, 환불 사유별 승률이 어떤지는 알려줄 수 없습니다.
이는 완전히 다른 데이터 세트이며, 실제로 요청에 응답하는 무언가가 있을 때만 존재할 수 있습니다. Refund Sensor는 Apple 환불 요청과 Google Play 차지백 검토를 각각 하나의 사례(case)로 추적하며, 타임라인, 결과, 방어된 매출을 하나의 대시보드에서 두 스토어 모두 보여줍니다. 환불로 이어지지 않은 요청들도 확인할 수 있습니다.
대체가 아니라 함께 사용할 가치가 있습니다. 코호트 분석에는 구독 플랫폼을, 요청 단위 추세 파악에는 모바일 앱 매출 보호 소프트웨어를 사용하세요. 서로 다른 질문에 답하는 것이며, 어느 하나가 다른 하나를 대신할 수 없습니다.
차지백을 별도로 추적하기
차지백 추세는 환불 추세의 하위 집합이 아닙니다. 이 둘을 같은 것으로 취급하는 것이 모바일 앱 환불 추적에서 가장 흔히 보이는 실수입니다.
Google Play에서는 신호가 다릅니다. 실시간 개발자 알림(Real-time developer notifications)은 무언가가 취소되었을 때 voidedPurchaseNotification을 보내고, 차지백에 개발자의 입력이 필요할 때는 pendingRefundReviewNotification을 보냅니다. Voided Purchases API에는 fraud, friendly_fraud, chargeback을 포함한 아홉 가지 값을 갖는 voidedReason 필드가 있습니다. 이는 무료로 얻을 수 있는 차지백 추세선에 가장 가까운 방법입니다.
Apple에서는 취소 사유가 포함된 REFUND 알림을 사용하며, 결과가 확정되지 않은 사례를 위해 REFUND_DECLINED와 REFUND_REVERSED도 함께 제공됩니다.
정확한 차지백 추세를 확인하려면 voidedReason이 chargeback인 경우를 제품별로 나누어 시간에 따라 그려보세요. 그런 다음 fraud와 friendly_fraud는 별도로 그려야 합니다. 이런 계정들은 반복적으로 발생하며 다른 대응이 필요하기 때문입니다. 각 피드가 어떤 역할을 하는지는 Voided Purchases API와 실시간 개발자 알림 비교 글에서 다뤘습니다.
모바일 앱에서 환불율과 차지백을 추적하는 방법
실제로 구축한다면 순서대로 이렇게 할 것입니다:
귀속 규칙을 정하고 문서로 남기세요. 플랜 길이별로 명시된 컷오프를 가진 코호트 방식으로요.
스토어 피드를 연결하세요. App Store Server Notifications V2와 Play의 RTDN입니다. 이것 없이는 매달 CSV 파일을 읽는 수밖에 없습니다.
모든 환불 이벤트는 오늘 날짜가 아니라 원래 거래를 기준으로 저장하세요.
요청 단위 이벤트도 추가하세요. 그렇지 않으면 무엇을 막아냈는지 전혀 알 수 없습니다.
차지백은 고유한 사유 코드로 분리하세요.
전체 평균이 아니라 해당 카테고리를 기준으로 벤치마킹하세요.
3단계는 자체 구축한 시스템이 조용히 무너지는 지점이고, 6단계는 대시보드가 조용히 오해를 불러일으키는 지점입니다. 둘 다 어렵지 않습니다. 하지만 둘 다 자주 생략됩니다.
비율이 아닌 비용 측면을 알고 싶다면, 환불이 실제로 앱 매출에 미치는 비용에서 그 계산을 다루고 있습니다. 비율 하나만으로는 다음에 무엇을 해야 할지 알 수 없습니다.
출처
자주 묻는 질문
카테고리 벤치마크와 요청 단위의 Apple 차트를 원한다면 RevenueCat이 적합합니다. 채널 및 플랜별 세분화가 필요하다면 Adapty가 좋습니다. 가장 명확하게 공개된 방법론을 원한다면 Apphud를 선택하세요. 환불로 이어지지 않은 요청까지 확인하고 싶다면 방어 도구를 추가하세요.
환불된 거래 수를 유료 거래 수로 나누되, 구매가 발생한 기간을 기준으로 귀속시킵니다. 그런 다음 코호트를 최종 확정하기 전까지 얼마나 기다릴지 정해야 합니다. 월간 플랜은 30~45일, 연간 플랜은 더 길게 잡습니다.
구독형 앱의 경우 유료 거래의 2%~5% 수준입니다. 교육, 건강 및 피트니스는 더 높고, 여행과 유틸리티는 더 낮은 편입니다. 10%를 넘는다면 마케팅은 그만 살펴보고 페이월을 들여다봐야 합니다.
제대로는 안 됩니다. Apple의 재무 보고서는 정산된 환불만 보여줍니다. Google의 Voided Purchases API는 사유 코드와 함께 무효화된 구매를 보여주는데, 가장 근접한 방법이긴 하지만 하루 6,000건으로 제한되어 있어 예약된 스윕 방식이 필요합니다.
거의 항상 귀속 지연 때문입니다. 매출 보고서는 기간 기준이고 환불율은 코호트 기준이어야 하며, 모든 환불이 반영되어야만 두 수치가 일치합니다. 일부 도구는 차지백을 제외하므로 포함 여부도 확인해야 합니다.
Apple은 기준치를 공개하지 않으며, 이를 자신 있게 제시하는 사람이 있다면 의심해봐야 합니다. 문서화된 사실은 지속적으로 높은 환불 및 분쟁 비율이 Google Play에서 계정 상태에 영향을 줄 수 있다는 점입니다. 이는 환불율 자체보다 추세를 추적해야 할 더 강력한 이유입니다.
