Hầu hết mọi người đều đọc một bài viết như thế này theo cùng một cách. Một khoản thanh toán về thấp hơn so với những gì bảng tính thể hiện, ai đó bắt đầu đào sâu tìm hiểu, và một giờ sau, có một con số xuất hiện trên màn hình mà chẳng ai muốn thấy.
Dữ liệu hoàn tiền của ứng dụng di động không hẳn là bị giấu đi, nó chỉ nằm rải rác ở nhiều nơi. Apple lưu dữ liệu này trong một báo cáo, Google thì trong một báo cáo khác cộng thêm một API, và không bên nào cho bạn biết lý do khách hàng muốn lấy lại tiền. Chúng tôi đã đề cập đến các công cụ xử lý hoàn tiền trong bài viết về lựa chọn công cụ quản lý hoàn tiền của Apple . Bài này nói về các công cụ chỉ đơn thuần cho bạn biết chuyện gì đang xảy ra, và chỗ nào mỗi công cụ lại "im lặng" với bạn.
Những điểm chính
Cả hai bảng điều khiển của store đều hiển thị hoàn tiền dưới dạng số đơn vị âm trong báo cáo doanh số, tức là một con số đếm chứ không phải lý do hay tỷ lệ.
Khoảng 2 đến 5 phần trăm số giao dịch trả phí là mức bình thường. Vượt qua 9 phần trăm thì việc theo dõi không còn là vấn đề của bạn nữa.
RevenueCat, Adapty và Qonversion đều vẽ biểu đồ tỷ lệ hoàn tiền, nhưng mỗi công cụ lại gán ngày cho khoản hoàn tiền theo cách khác nhau, nên cùng một tháng có thể cho ra hai con số khác nhau.
Google hiện tính phí chargeback cho nhà phát triển đối với các đơn hàng sau ngày 3 tháng 8 năm 2026, và rất ít công cụ theo dõi chargeback như một dòng dữ liệu riêng.
Con số chúng tôi sẽ theo dõi đầu tiên hoàn toàn không phải là tỷ lệ. Đó là có bao nhiêu yêu cầu hoàn tiền không được phản hồi.
Vì sao bảng điều khiển của store là chưa đủ
Sales and Trends của Apple thực sự có chứa dữ liệu hoàn tiền. Vào tab Trends, thêm bộ lọc, đặt Transaction Type thành Refunds, và bạn sẽ thấy chúng dưới dạng số đơn vị âm. Trang trợ giúp chính thức của Apple nói rằng dashboard là một "ước tính gần thời gian thực" trong khi các báo cáo có thể tải xuống là "đã hoàn tất", và hai con số này có thể khác nhau, thực tế là chúng khác nhau, thường đúng vào ngày bạn cần chúng khớp nhau.
Google hào phóng hơn về dữ liệu, nhưng lại kém hơn về cách trình bày. Voided Purchases API cung cấp cho bạn mọi đơn hàng bị hoàn tiền, hủy hoặc bị chargeback, mỗi đơn kèm theo một trong chín mã voidedReason, bao gồm remorse, friendly_fraud và chargeback. Nhưng đây là một API, không có biểu đồ, và bạn chỉ được gọi 6,000 lần mỗi ngày để tự xây dựng phần còn lại. Có một cái bẫy dễ bị bỏ qua: các khoản hoàn tiền được thực hiện từ Play Console mà không đánh dấu "Remove entitlement" sẽ không bao giờ xuất hiện trong đó. Chúng tôi đã viết về điều này trong bài viết về việc thu hồi quyền truy cập sau khi hoàn tiền . Và không store nào cho bạn tỷ lệ, chỉ có số đếm. Việc chia tỷ lệ là do bạn tự làm, và theo kinh nghiệm của tôi, mỗi tháng lại được thực hiện hơi khác nhau một chút.
Một con số tốt trông như thế nào
Báo cáo State of Subscription Apps 2026 của RevenueCat bao phủ hơn 115,000 ứng dụng, và với hầu hết các danh mục, tỷ lệ hoàn tiền trung vị nằm trong khoảng 3 đến 4 phần trăm. Nhóm ứng dụng năng suất cao nhất ở mức 4.7, du lịch thấp nhất ở mức 2.5. Giá cũng đẩy tỷ lệ này lên, từ khoảng 2.7 phần trăm ở mức giá rẻ đến 4.5 ở mức giá cao. Các trường hợp ngoại lệ dao động từ 9 đến 18 phần trăm, và gần như luôn là do lỗi phần mềm, paywall hứa hẹn quá mức, hoặc thẻ bị đánh cắp.
Báo cáo tháng 2 của Adapty, dựa trên khoảng 11,000 ứng dụng, nhìn chung cũng cho kết quả tương tự, với giáo dục gần mức cao nhất khoảng 5 phần trăm và du lịch ở mức thấp nhất gần 1.5. Hai báo cáo lại không thống nhất về nhóm năng suất, vì vậy tôi sẽ không dựa quá nhiều vào con số của riêng một danh mục nào.
Nếu bạn đang ở mức 3.5 phần trăm thì ổn. Nếu bạn ở mức 8, có điều gì đó cụ thể đang sai và bạn có thể tìm ra được. Nếu bạn không biết con số của mình, hãy khắc phục điều đó trước tiên.
Phần mềm theo dõi tỷ lệ hoàn tiền, xét từng công cụ
RevenueCat
Biểu đồ Refund Rate lấy các giao dịch trả phí trong một khoảng thời gian (không tính bản dùng thử) và cho biết tỷ lệ nào bị hoàn tiền. Điều cần biết là khoản hoàn tiền được gán vào ngày mua hàng gốc, vì vậy một khoản hoàn tiền phát sinh hôm nay cho giao dịch mua từ tháng 3 sẽ được tính vào tháng 3. Cách này đúng cho phân tích cohort, nhưng con số của tháng trước cứ thay đổi trong một thời gian, điều khiến nhiều người bất ngờ.
Adapty
Có hai biểu đồ, refund money và refund events, được gán ngày theo thời điểm khoản hoàn tiền được xử lý, ngược lại với cách làm của RevenueCat. Không cách nào sai cả, nhưng tôi đã thấy một đội nhóm chuyển đổi giữa hai công cụ này và mất cả tuần tin rằng tỷ lệ của họ đã thay đổi.
Qonversion
Các biểu đồ Refunds và Refund Rate nằm trong mục Revenue, có thể lọc theo sản phẩm, quốc gia và loại tiền tệ. Nó đáp ứng được nhu cầu cơ bản.
Một bảng tính
Hoạt động tốt khi khối lượng thấp, tôi sẽ không giả vờ điều ngược lại. Nhưng nó ngừng hiệu quả ngay khi bạn thêm một ứng dụng thứ hai, hoặc khi tỷ lệ thay đổi và bạn muốn biết lý do.
Đó gần như là bức tranh chung về phân tích hoàn tiền ứng dụng di động trên các nền tảng thông thường. Chúng trả lời khá tốt câu hỏi "bao nhiêu" và không công cụ nào thực sự trả lời được câu hỏi "tại sao".
Công cụ theo dõi chargeback ứng dụng di động: một mảng còn thưa thớt
Trong một thời gian dài, chargeback là vấn đề của Google trên Android và hầu như không phải vấn đề trên iOS. Rồi Google thay đổi điều khoản. Với các đơn hàng sau ngày 3 tháng 8 năm 2026, nhà phát triển phải gánh khoản tiền tranh chấp trừ đi phí của Google, cộng thêm phí mạng lưới thẻ thường từ $15 đến $25. Một giao dịch mua $4.99 bị chargeback có thể khiến bạn mất khoảng $23.
Điều đó đã đẩy phần mềm phân tích chargeback từ chỗ "có thì tốt" thành khá cấp bách, và các công cụ vẫn chưa bắt kịp. Voided Purchases API gắn nhãn chargeback bằng mã lý do riêng, nên ít nhất bạn có thể tự đếm chúng. RevenueCat cho biết trên diễn đàn cộng đồng của họ hồi tháng 7 rằng họ "không tính chargeback là một khoản hoàn tiền", vì vậy chargeback sẽ không xuất hiện trong biểu đồ tỷ lệ hoàn tiền đó. Chargeflow và các công cụ xử lý tranh chấp tương tự được xây dựng cho thanh toán web, và theo những gì tôi biết, chúng không đụng đến Play billing.
Refund Sensor theo dõi cả hai store trong một dashboard duy nhất, và tách riêng các khoản hoàn tiền do Google tự quyết định với các chargeback đã được đưa vào diện xem xét, cùng với thông tin phản hồi mà chúng tôi đã gửi cho từng trường hợp. Chỉ nhóm thứ hai là thứ bạn có thể tranh đấu để lấy lại. Chi tiết có tại trang bảo vệ trước hoàn tiền trên Google Play .
Nếu bạn đang so sánh các phần mềm quản lý chargeback cho ứng dụng di động, hãy hỏi xem chargeback có hiển thị như một dòng riêng hay bị gộp chung vào hoàn tiền. Nếu bị gộp chung, xu hướng sẽ biến mất, mà chính xu hướng mới là thứ cho bạn biết bạn đang gặp vấn đề về gian lận hay vấn đề về sản phẩm.
Cách theo dõi tỷ lệ hoàn tiền trong ứng dụng di động mà không tự đánh lừa chính mình
Đây là một vài điều chúng tôi rút ra được sau khi nhìn chằm chằm vào các dashboard này.
Hãy chọn một phương pháp gán ngày và đừng thay đổi nó. Ngày mua hàng cho bạn biết về chất lượng sản phẩm theo thời gian, ngày hoàn tiền cho bạn biết về dòng tiền trong tháng này, và việc trộn lẫn cả hai trong cùng một báo cáo khiến mọi biểu đồ âm thầm nói dối bạn.
Hãy đếm các yêu cầu, không chỉ kết quả. Khi khách hàng yêu cầu Apple hoàn tiền cho một giao dịch mua trong ứng dụng, Apple sẽ gửi tín hiệu đến server của bạn dưới dạng CONSUMPTION_REQUEST và chờ 12 giờ. Google giờ cũng gửi một thông báo xem xét trước khi quyết định về chargeback và cho bạn 24 giờ. Nếu công cụ của bạn chỉ hiển thị các khoản hoàn tiền đã được chấp nhận, bạn sẽ không biết được bao nhiêu tín hiệu đó đã không được phản hồi. Khoảng trống đó là con số tôi sẽ theo dõi trước cả tỷ lệ hoàn tiền, và đó cũng là cách chúng tôi biết tỷ lệ bảo vệ thành công 77 phần trăm của mình là có thật.
Phần mềm theo dõi hoàn tiền nào là tốt nhất?
Còn tùy vào thứ gì đang thiếu. Nếu bạn đã dùng RevenueCat, Adapty hoặc Qonversion, biểu đồ có sẵn là đủ tốt cho tỷ lệ hoàn tiền, chỉ cần biết công cụ đó đang dùng phương pháp gán ngày nào. Nếu bạn cần chargeback là một dòng dữ liệu riêng, mà trên Google Play thì giờ đây có lẽ bạn cần điều đó, các nền tảng thông thường phần lớn vẫn chưa có tính năng này. Đó chính là khoảng trống mà một công cụ chuyên về hoàn tiền sẽ lấp đầy. Và nếu bạn muốn biết có bao nhiêu yêu cầu mình chưa từng phản hồi, chỉ có thứ gì đó nằm ngay trên các thông báo của store mới cho bạn biết điều đó, bởi vì các nền tảng phân tích chỉ thấy kết quả chứ không bao giờ thấy câu hỏi.
Kết luận
Theo dõi tỷ lệ hoàn tiền của ứng dụng di động không phải là phần khó. Các store cung cấp cho bạn số đếm và mọi nền tảng subscription đều sẽ vẽ được đường xu hướng đó. Vấn đề là bản thân đường xu hướng đó gần như không cho bạn biết điều gì, bởi vì hai ứng dụng cùng ở mức 4 phần trăm có thể đang gặp phải những vấn đề hoàn toàn khác nhau.
Điều khiến việc theo dõi thực sự đáng giá chính là bối cảnh: những lý do mà store có cung cấp, chargeback được giữ như một xu hướng riêng, và một số liệu ghi lại có bao nhiêu yêu cầu bạn chưa từng tranh đấu để phản hồi. Cứ nắm được tỷ lệ trước, được thôi, nhưng bối cảnh mới là nơi tiền bạc thực sự nằm ở đó.
Câu hỏi thường gặp
Từ 2 đến 5 phần trăm số giao dịch trả phí, theo báo cáo năm 2026 của RevenueCat và Adapty. Nhóm ứng dụng năng suất và giáo dục thường có tỷ lệ cao hơn, còn du lịch và game thường thấp hơn.
Không có trong các báo cáo. Lý do duy nhất mà Apple cung cấp là trường revocationReason trong thông báo máy chủ REFUND, và về cơ bản đây chỉ là câu trả lời có/không cho việc khách hàng có đổ lỗi cho ứng dụng hay không.
Còn tùy công cụ. Voided Purchases API của Google có bao gồm chargeback với mã lý do riêng. RevenueCat cho biết họ không tính chargeback là một khoản hoàn tiền. Đáng để kiểm tra điều này trước khi bạn so sánh hai dashboard.
Trên Google Play, với các đơn hàng sau tháng 8 năm 2026 thì có, hoặc ít nhất bạn cần tách chargeback thành một chuỗi dữ liệu riêng. Giờ đây chargeback khiến bạn mất cả giá trị đơn hàng lẫn phí ngân hàng.
Đó là các yêu cầu bị bỏ lỡ, tức những lần Apple hoặc Google yêu cầu bạn phản hồi nhưng không ai xử lý kịp thời. Chỉ số này vô hình trên các dashboard chỉ hiển thị kết quả, và thường là đòn bẩy lớn nhất mà bạn có.
