Tôi biết hai đội ngũ cùng vận hành một ứng dụng nhưng báo cáo tỷ lệ hoàn tiền lần lượt là 3.1% và 5.8% cho cùng một tháng. Không ai nói dối cả. Họ chỉ định nghĩa chỉ số đó khác nhau, và chẳng ai ghi lại định nghĩa đó bằng văn bản.
Đó chính là điều về phân tích hoàn tiền ứng dụng di động mà không ai đưa lên trang giới thiệu tính năng. Con số chỉ tốt bằng quy tắc quy kết (attribution) đứng sau nó, và hầu hết các dashboard không nói rõ họ dùng quy tắc nào.
Vì vậy, bài viết này sẽ trình bày những gì các công cụ này làm được, cùng với một câu hỏi về phương pháp luận mà bạn cần đặt ra trước khi tin tưởng bất kỳ công cụ nào. Riêng về cơ chế theo dõi, cách theo dõi hoàn tiền trên App Store sẽ đi sâu hơn vào phía Apple.
Những điểm chính
Quy kết theo cohort tốt hơn quy kết theo kỳ (period). Hãy tính hoàn tiền vào tháng diễn ra giao dịch mua, không phải tháng khoản hoàn tiền thực sự xảy ra.
Độ trễ hoàn tiền kéo dài hàng tuần, đôi khi cả một chu kỳ thanh toán. Bất kỳ dashboard nào hiển thị tỷ lệ của tháng này đều đang hiển thị một con số chưa đầy đủ.
Chargeback không phải là hoàn tiền. RevenueCat nói rõ ràng rằng họ không tính chargeback là một khoản hoàn tiền, vì vậy bạn cần một nguồn dữ liệu riêng.
Console của các store thì miễn phí nhưng yếu về mặt theo dõi xu hướng. Apple cung cấp báo cáo, còn Google cung cấp một API với giới hạn số lượt gọi mỗi ngày.
Những công cụ tốt nhất để theo dõi tỷ lệ hoàn tiền ứng dụng di động là những công cụ công khai rõ mẫu số (denominator) mà họ sử dụng.
Trước tiên, vấn đề về định nghĩa
Có hai cách để theo dõi tỷ lệ hoàn tiền ứng dụng, và chúng cho ra kết quả không khớp nhau.
Phương pháp theo kỳ (Period method): số khoản hoàn tiền phát sinh trong tháng 3, chia cho số giao dịch được tính phí trong tháng 3. Dễ xây dựng. Nhưng sai, vì một khoản hoàn tiền trong tháng 3 thường thuộc về một giao dịch mua từ tháng 1.
Phương pháp cohort (Cohort method): trong tất cả các giao dịch được tính phí vào tháng 1, bao nhiêu phần trăm đã được hoàn tiền kể từ đó. Khó hơn, vì con số này không bao giờ ngừng thay đổi.
Apphud ghi lại điều này một cách trung thực. Mẫu số của họ là các giao dịch được tính phí trong kỳ, tử số là số lượng được hoàn tiền sau đó, kể cả sau khi kỳ đó đã kết thúc. Đó là cách tiếp cận cohort, và nó phản ánh đúng cách hoàn tiền thực sự diễn ra.
Vì vậy bạn cần một mốc cắt (cutoff). Các gói đăng ký hàng tháng thường ổn định sau khoảng 30 đến 45 ngày, trong khi các gói hàng năm thì trôi dạt trong nhiều tháng. So sánh một con số mới 10 ngày tuổi với một con số đã 90 ngày tuổi chỉ là so sánh nhiễu (noise).
Lớp miễn phí: Console của các store
Hãy bắt đầu từ đây. Nó không tốn gì cả, và đây cũng là nơi hầu hết các đội ngũ dừng lại.
App Store Connect. Mục Sales and Trends cùng với Financial Reports sẽ cho bạn thấy các khoản hoàn tiền, và báo cáo tài chính này khớp với khoản thanh toán bạn nhận được. Nó dựa trên kỳ (period-based), thủ công, và không có phân đoạn theo sản phẩm hay kênh. Phù hợp để kiểm tra nhanh hàng tháng. Nhưng vô dụng nếu muốn tìm ra paywall nào đang gây thất thoát.
Nguồn dữ liệu miễn phí tốt hơn thậm chí không nằm trong console. Endpoint Get Refund History của Apple trả về một danh sách phân trang gồm mọi giao dịch đã hoàn tiền theo từng khách hàng, mà bạn có thể đưa vào kho dữ liệu của riêng mình. Nó bị giới hạn tốc độ gọi (rate limited), và Apple khuyến nghị dùng notification thay vì polling, vì vậy hãy xem đây như một công cụ đối soát.
Google Play Console. Cũng có financial reports, cộng thêm Voided Purchases API, liệt kê các giao dịch đã hoàn tiền, bị chargeback hoặc bị thu hồi trong một khoảng thời gian. Giới hạn ở mức 6,000 lượt gọi mỗi ngày và 30 lượt mỗi 30 giây, nên nó được thiết kế cho việc quét theo lịch, không phải cho dữ liệu thời gian thực.
Cả hai console đều có chung một điểm yếu khi dùng để theo dõi xu hướng. Chúng báo cáo những gì đã được xử lý xong (settled), chứ không phải những gì đã được yêu cầu, nên bạn không bao giờ thấy được những yêu cầu mà bạn đã bảo vệ thành công.
RevenueCat
Nếu các gói đăng ký của bạn đã chạy qua nền tảng này, đây là lựa chọn mặc định.
Tỷ lệ hoàn tiền là một trong những chỉ số benchmark của họ: tỷ lệ các gói đăng ký trả phí bị hoàn tiền trong kỳ thanh toán đầu tiên, được so sánh với các ứng dụng khác trong cùng store và danh mục của bạn. Việc đối chiếu benchmark này chính là phần hữu ích, vì một tỷ lệ thô không có ngữ cảnh so sánh thì rất khó để hành động. Báo cáo State of Subscription Apps của họ bao phủ hơn 75,000 ứng dụng và đưa ra mức trung vị khoảng 3% đến 5%.
Ngoài ra còn có biểu đồ App Store Refund Requests, phân tách theo trạng thái: được chấp thuận, bị từ chối, bị đảo ngược và đang chờ xử lý. Đây là dữ liệu ở cấp độ yêu cầu (request-level), điều mà hầu hết các công cụ khác bỏ qua.
Có hai lưu ý. Các khoản hoàn tiền trên Play do Google quyết định (thay vì do bạn) có thể mất tới 24 giờ mới hiển thị, và những khoản hoàn tiền được cấp mà không tích vào ô thu hồi (revoke box) thì hoàn toàn không được phát hiện. Và RevenueCat không tính chargeback là hoàn tiền. Trạng thái giao dịch mua có cập nhật, nhưng tỷ lệ hoàn tiền thì không thay đổi.
Adapty
Mạnh hơn hầu hết các công cụ khác về khả năng phân đoạn. Việc theo dõi hoàn tiền được chia nhỏ theo ngày, gói, sản phẩm và kênh thu hút người dùng, đây mới là cách phân tích thực sự giúp phát hiện vấn đề. Một tỷ lệ trông ổn ở mức tổng thể nhưng tệ hại ở một kênh cụ thể là lỗi về thông điệp (messaging), không phải lỗi sản phẩm.
Các benchmark của họ được tổng hợp từ 1.9 tỷ USD doanh thu được theo dõi trên hơn 11,000 ứng dụng, và sự chênh lệch giữa các danh mục đủ lớn để đáng lưu ý: giáo dục và sức khỏe ở mức gần 4.7% đến 5.1%, du lịch và tiện ích gần 1.5% đến 2.1% hơn. Các gói hàng năm có tỷ lệ hoàn tiền cao hơn gói hàng tuần. Paywall cứng (hard paywall) có tỷ lệ khoảng 5.8% so với 3.4% của freemium.
Điểm hạn chế cũng giống như ở những phần khác trong sản phẩm của họ: các phân tích tốt này giả định rằng bạn đang dùng Adapty SDK.
Apphud
Nhỏ hơn, rẻ hơn, và minh bạch bất thường về phương pháp luận, đây là lý do riêng nó đã đủ để tôi đưa vào danh sách rút gọn. Tài liệu của họ trình bày rõ logic cohort thay vì giấu đi. Dashboard thời gian thực, khoảng 18 sự kiện đăng ký, ít yếu tố marketing hơn so với các lựa chọn khác.
Nếu bạn muốn một con số có thể bảo vệ được trong cuộc họp hội đồng quản trị, sự rõ ràng quan trọng hơn một danh sách tính năng dài.
Công cụ chuyên biệt để theo dõi hoàn tiền và chargeback
Đây chính là khoảng trống. Các nền tảng đăng ký chỉ đếm những khoản hoàn tiền đã được xử lý xong. Không nền tảng nào nằm trong cửa sổ phản hồi, nên không nền tảng nào có thể cho bạn biết bạn đã bảo vệ thành công bao nhiêu yêu cầu, hay tỷ lệ thắng của bạn theo từng lý do hoàn tiền.
Đó là một tập dữ liệu khác, và nó chỉ tồn tại nếu có thứ gì đó đang phản hồi các yêu cầu này. Refund Sensor theo dõi các yêu cầu hoàn tiền trên Apple và các lượt xem xét chargeback trên Google Play dưới dạng từng case, với dòng thời gian, kết quả và doanh thu đã được bảo vệ, cả hai store trong cùng một dashboard. Nó cho bạn thấy những yêu cầu chưa bao giờ trở thành khoản hoàn tiền.
Đáng để kết hợp, chứ không phải thay thế. Một nền tảng đăng ký để phân tích cohort, một phần mềm bảo vệ doanh thu ứng dụng di động để theo dõi xu hướng ở cấp độ yêu cầu. Đây là hai câu hỏi khác nhau, và cái này không bao phủ được cái kia.
Theo dõi chargeback riêng biệt
Xu hướng chargeback không phải là một tập con của xu hướng hoàn tiền, và việc coi chúng là một chính là sai lầm phổ biến nhất tôi thấy trong việc theo dõi hoàn tiền của ứng dụng di động.
Trên Google Play, các tín hiệu khác nhau. Real-time developer notifications sẽ đẩy một voidedPurchaseNotification khi có giao dịch bị hủy, và một pendingRefundReviewNotification khi một chargeback cần ý kiến của bạn. Voided Purchases API mang một trường voidedReason với chín giá trị, bao gồm fraud, friendly_fraud và chargeback. Đây là thứ gần nhất với một đường xu hướng chargeback miễn phí.
Trên Apple, đó là một thông báo REFUND kèm lý do thu hồi, cộng với REFUND_DECLINED và REFUND_REVERSED cho những trường hợp không được giữ nguyên.
Để có một xu hướng chargeback đáng tin cậy, hãy vẽ biểu đồ voidedReason bằng chargeback theo thời gian, chia theo sản phẩm. Sau đó vẽ riêng fraud và friendly_fraud, vì những tài khoản đó lặp lại và cần một cách xử lý khác. Chúng tôi đã trình bày nguồn dữ liệu nào làm gì trong bài Voided Purchases API versus real-time developer notifications.
Cách theo dõi tỷ lệ hoàn tiền và chargeback trong ứng dụng di động
Đây là bộ công cụ tôi thực sự sẽ xây dựng, theo thứ tự:
Chọn một quy tắc quy kết và ghi lại rõ ràng: theo cohort, với một mốc cắt được nêu rõ cho từng độ dài gói.
Kết nối các nguồn dữ liệu từ store. App Store Server Notifications V2, và RTDN trên Play. Nếu không có chúng, bạn chỉ đang đọc các file CSV hàng tháng.
Lưu mọi sự kiện hoàn tiền gắn với giao dịch gốc, không phải ngày hiện tại.
Thêm các sự kiện ở cấp độ yêu cầu, nếu không bạn sẽ không bao giờ thấy được những gì mình đã ngăn chặn.
Tách riêng chargeback với mã lý do riêng của chúng.
So sánh benchmark với danh mục của bạn, không phải với mức trung bình toàn cầu.
Bước 3 là nơi các hệ thống tự xây dựng âm thầm gãy đổ, và bước 6 là nơi các dashboard âm thầm đánh lừa. Cả hai đều không khó. Nhưng cả hai đều thường bị bỏ qua.
Về khía cạnh chi phí thay vì khía cạnh tỷ lệ, hoàn tiền thực sự tốn kém doanh thu ứng dụng của bạn như thế nào sẽ tính toán điều đó. Một tỷ lệ đơn thuần không cho bạn biết bước tiếp theo nên làm gì.
Nguồn tham khảo
Câu hỏi thường gặp
RevenueCat nếu bạn muốn có benchmark theo danh mục và biểu đồ Apple ở cấp độ yêu cầu. Adapty nếu bạn cần phân đoạn theo kênh và gói. Apphud nếu bạn muốn phương pháp luận được công bố rõ ràng nhất. Thêm một công cụ phòng vệ (defense tool) nếu bạn cũng muốn thấy những yêu cầu chưa bao giờ trở thành khoản hoàn tiền.
Số giao dịch được hoàn tiền chia cho số giao dịch đã thanh toán, được quy về kỳ mà giao dịch mua diễn ra. Sau đó, hãy quyết định bạn sẽ để một cohort "chín" trong bao lâu trước khi coi con số đó là cuối cùng. Với gói hàng tháng, khoảng 30 đến 45 ngày. Với gói hàng năm thì lâu hơn.
Khoảng từ 2% đến 5% số giao dịch đã thanh toán đối với các ứng dụng đăng ký. Giáo dục, sức khỏe và thể hình thường có tỷ lệ cao hơn, du lịch và tiện ích thấp hơn. Nếu vượt quá 10%, hãy ngừng nhìn vào marketing và đi xem lại paywall của bạn.
Không thực sự đầy đủ. Báo cáo tài chính của Apple chỉ hiển thị các khoản hoàn tiền đã được xử lý xong. Voided Purchases API của Google hiển thị các giao dịch bị hủy kèm mã lý do, đây là thứ gần nhất, nhưng nó bị giới hạn ở mức 6,000 lượt gọi mỗi ngày và cần được quét theo lịch.
Hầu như luôn là do độ trễ quy kết (attribution lag). Báo cáo doanh thu dựa trên kỳ (period-based), trong khi tỷ lệ hoàn tiền nên được tính theo cohort, và hai con số này chỉ khớp nhau khi mọi khoản hoàn tiền đã được xử lý xong. Cũng nên kiểm tra xem chargeback có được tính vào hay không, vì một số công cụ loại trừ chúng.
Apple không công bố một ngưỡng cụ thể nào, và tôi sẽ nghi ngờ bất kỳ ai khẳng định chắc chắn một con số nào đó. Điều được ghi nhận chính thức là tỷ lệ hoàn tiền và tranh chấp cao kéo dài có thể ảnh hưởng đến tình trạng tài khoản trên Google Play. Đó là lý do thuyết phục hơn để theo dõi xu hướng thay vì chỉ theo dõi tỷ lệ.
