Lần đầu tiên tôi kiểm toán một ứng dụng để tìm doanh thu bị mất, tôi suýt báo cáo rằng mọi thứ đều ổn. Tỷ lệ hoàn tiền ở mức 2,4%, một con số tốt theo bất kỳ chuẩn mực nào. Đội ngũ trả lời các consumption request trong thời hạn của Apple. Trên giấy tờ, không có gì để khôi phục.
Sau đó tôi chạy thêm một truy vấn nữa, phần lớn là vì bướng bỉnh. Có bao nhiêu người hiện đang giữ entitlement trả phí trên một giao dịch mà Apple đã hoàn tiền? Bốn mươi mốt. Trên một ứng dụng có khoảng 900 thuê bao trả phí. Tôi chạy lại hai lần vì không tin vào kết quả.
Đó là gần 5% cơ sở người dùng đang sử dụng sản phẩm miễn phí, tháng này qua tháng khác, trong khi dashboard vẫn xanh. Và tỷ lệ hoàn tiền thì chẳng hề thay đổi. Tôi đã viết riêng về cách khắc phục entitlement này trong bài cách thu hồi quyền truy cập sau khi hoàn tiền.
Nếu bạn đang cố tìm cách khôi phục doanh thu thuê bao bị mất do hoàn tiền trên App Store, hãy bắt đầu từ đó, vì khoản hoàn tiền chỉ là nơi nhỏ nhất trong bốn nơi mà tiền của bạn thực sự chảy đến. Đây là bức tranh toàn cảnh.
Bốn Nhóm Vấn Đề, Xếp Hạng Theo Giá Trị Mang Lại
Tôi coi đây là bốn nhóm, và thứ hạng về tỷ lệ công sức bỏ ra so với lợi ích thu về không giống như hầu hết mọi người đoán.
Rò rỉ: người dùng đã được hoàn tiền nhưng chưa bao giờ mất quyền truy cập. Cách khắc phục rẻ nhất, nhưng cũng thường bị bỏ sót nhất.
Phòng thủ: trả lời các consumption request của Apple kèm bằng chứng. Đây là nhóm mà mọi nhà cung cấp phần mềm đều nói đến, vì đây là nhóm duy nhất phần mềm có thể tự động hóa.
Win-back: giành lại những người đã hoàn tiền hoặc đã rời bỏ. Chậm mang lại kết quả nhất. Apple đã âm thầm giúp việc này dễ dàng hơn trong năm nay.
Thử lại thanh toán: các lỗi thanh toán tự khôi phục nếu bạn không can thiệp vào.
Hầu hết các đội ngũ chỉ xử lý nhóm thứ hai. Những bất ngờ lại nằm ở nhóm một và ba.
Nhóm Một: Tìm Ra Rò Rỉ, Chỉ Mất Một Giờ
Đây là truy vấn, nói một cách sơ lược. Lấy tất cả các giao dịch có revocation date trong 12 tháng gần nhất, join với bảng entitlement của bạn, và đếm xem ai vẫn đang hiển thị quyền truy cập đang hoạt động.
Nếu kết quả thực sự bằng 0, hãy bỏ qua phần này. Nhưng nếu không, bạn đã tìm ra khoản doanh thu thuê bao đang thất thoát mỗi tháng cho đến khi có thứ gì đó tắt nó đi. Apple hoàn lại khoản thanh toán của họ. Apple không đụng đến database của bạn. Hai hệ thống này vẫn tách biệt cho đến khi bạn kết nối chúng lại. Consumable còn tệ hơn, vì một khi vật phẩm đã được sử dụng thì không còn gì để StoreKit thu hồi.
(Chính tôi cũng đã làm sai điều này trong nhiều tháng. Trình xử lý thông báo chỉ ghi log sự kiện REFUND vào một bảng mà chẳng ai đọc. Ghi log không phải là xử lý.)
Cách khắc phục: lắng nghe sự kiện REFUND, thu hồi quyền truy cập vào đúng revocation date, và xử lý REFUND_REVERSED bằng cách cấp lại quyền truy cập. Đôi khi Apple tự đảo ngược khoản hoàn tiền của chính mình, sau khi khách hàng khiếu nại, và bạn không nên trừng phạt khách hàng vì điều đó.
Thêm một truy vấn nữa trong lúc bạn đang ở đó. Đếm số khoản hoàn tiền mà bạn chưa từng nhận được bất kỳ server notification nào. Nếu con số đó khác 0, endpoint của bạn đang bị hỏng, và nhóm hai cũng vậy.
Nhóm Hai: Bảo Vệ Những Yêu Cầu Bạn Vẫn Có Thể Tác Động
Apple cho bạn khoảng 12 giờ kể từ khi nhận CONSUMPTION_REQUEST để gửi consumption data. Ba trường bắt buộc, hai trường tùy chọn, một tùy chỉnh ưu tiên, và giờ đây nó áp dụng cho mọi loại sản phẩm, không chỉ consumable.
Lời khuyên của tôi ở đây khá ngắn gọn vì nhóm này đã được nói đến quá nhiều ở nơi khác. Hãy trả lời mọi yêu cầu. Từ chối những trường hợp mà sản phẩm rõ ràng đã được giao và sử dụng nhiều. Chấp nhận những tai nạn thực sự. Một sự nhượng bộ thiện chí thì rẻ. Nhưng tranh đấu với mọi khoản hoàn tiền thì không, vì Apple có tính điểm dựa trên lịch sử của bạn.
Yếu tố phụ thuộc mà không ai nhắc đến chính là bằng chứng. Bạn chỉ có thể bảo vệ những gì bạn chứng minh được. Nếu không ai trả lời được câu hỏi "họ thực sự đã dùng bao nhiêu" cho một giao dịch mua từ bảy tuần trước, thì không có tự động hóa nào cứu được bạn. Đó là một lỗ hổng trong mô hình dữ liệu đáng để khắc phục, bất kể bạn dùng nhà cung cấp nào.
Về khía cạnh chi phí, hoàn tiền thực sự khiến doanh thu ứng dụng của bạn tổn thất bao nhiêu đã tính toán cụ thể, bao gồm cả chi phí thu hút người dùng đứng sau mỗi khoản hoàn tiền.
Nhóm Ba: Giành Lại Thuê Bao
Đây là nơi việc bảo vệ doanh thu thuê bao không còn mang tính phòng thủ nữa. Và đây cũng là lĩnh vực mà Apple đã xây dựng lại theo hướng có lợi cho bạn trong năm qua.
Win-back offers. Mới ra mắt từ WWDC24, dành cho iOS 18 trở lên. Bạn cấu hình chúng theo từng sản phẩm thuê bao trong App Store Connect và thiết lập điều kiện đủ điều kiện: thời gian trả phí tối thiểu, thời gian kể từ lần đăng ký cuối cùng, khoảng chờ từ 2 đến 24 tháng giữa các ưu đãi. Sau đó Apple sẽ lo việc phân phối. Chúng xuất hiện trên trang Manage Subscription của khách hàng, trang sản phẩm của bạn, trong các đề xuất cá nhân hóa, đôi khi ở các vị trí biên tập trên tab Today.
Đọc lại câu đó lần nữa. Apple hiển thị ưu đãi giảm giá của bạn cho một thuê bao đã rời bỏ ở những nơi mà bạn không bao giờ có thể tiếp cận được bằng email. Giới hạn: 350 ưu đãi cho mỗi gói thuê bao, 5 ưu đãi đang hoạt động cho mỗi storefront. Trong ứng dụng, StoreKit sẽ kích hoạt thông điệp winBackOffer khi ai đó đủ điều kiện, và eligibleWinBackOfferIDs trong renewal info sẽ cho biết họ có thể đổi ưu đãi nào. Hướng dẫn thiết lập win-back của Apple có đề cập đến các trường điều kiện đủ điều kiện.
Promotional offers. Tối đa 10 ưu đãi cho mỗi gói thuê bao, đã có từ thời iOS 12.2, và cần chữ ký JWS từ server của bạn. Tốn công hơn win-back. Nhưng bạn kiểm soát hoàn toàn việc nhắm mục tiêu, điều này quan trọng khi lý do hoàn tiền cho bạn biết điều gì đó cụ thể, chẳng hạn như một vấn đề về giá ở một quốc gia nào đó.
Offer codes. Có thể đổi trong hoặc ngoài ứng dụng. Điều đó khiến chúng trở thành cách thực tế duy nhất để tiếp cận ai đó đã hoàn tiền rồi gỡ ứng dụng. Những người khác, bạn có thể tiếp cận trong ứng dụng. Còn những người này thì không.
Extend a Subscription Renewal Date. Theo tôi, đây là tính năng bị đánh giá thấp. Server API của Apple cho phép bạn đẩy lùi ngày gia hạn của thuê bao, cho từng giao dịch hoặc hàng loạt. Chúng tôi dùng tính năng này như một cử chỉ thiện chí sau các bản phát hành có lỗi: ai đó gửi email cho bộ phận hỗ trợ về lỗi thanh toán, bạn gia hạn thêm một tháng, gần như không tốn gì cả và hiệu quả hơn bất kỳ coupon nào. Một khoản hoàn tiền được ngăn chặn vẫn tốt hơn một khoản hoàn tiền giành lại được.
Có một ngoại lệ. Nếu ai đó hoàn tiền vì bất ngờ về khoản thanh toán chứ không phải vì bản thân sản phẩm, đừng đeo bám họ bằng ưu đãi giảm giá. Hãy sửa lại nội dung paywall trước, rồi để họ tự khám phá lại sản phẩm. Quản lý hoàn tiền App Store đề cập đến khía cạnh vận hành đó.
Nhóm Bốn: Churn Tự Khắc Phục
Apple thử lại việc thanh toán thất bại trong tối đa 60 ngày, hoặc cho đến khi khách hàng sửa lại thẻ hoặc hủy. Nếu thuê bao gia hạn thành công trong khoảng thời gian đó, dịch vụ trả phí sẽ tiếp tục kể từ ngày khôi phục.
Vì vậy, một phần doanh thu thuê bao trông như đã mất thực ra chưa bao giờ mất. Nó chỉ đang chờ xử lý. Có hai thứ có thể phá hỏng điều này: một grace period mà bạn chưa bao giờ bật lên, và một email dunning gần như đang bảo người dùng hãy hủy đăng ký. Hãy kiểm tra cả hai trước khi chi tiền cho công cụ giữ chân người dùng.
Đo Lường Mà Không Tự Đánh Lừa Chính Mình
Quản lý hoàn tiền mà không có cohort attribution sẽ tạo ra những con số vô nghĩa nhưng đầy tự tin.
Gán mỗi khoản hoàn tiền vào giai đoạn mà giao dịch mua ban đầu diễn ra, chứ không phải thời điểm khoản hoàn tiền xảy ra. Sau đó để cohort đó trưởng thành. Từ 30 đến 45 ngày đối với các gói hàng tháng, lâu hơn đối với gói hàng năm, vì yêu cầu hoàn tiền có thể đến sau nhiều tháng.
Đây cũng là nơi việc theo dõi hoàn tiền thuê bao trở nên khó khăn, và là nơi hầu hết các dashboard âm thầm gian lận. Một win-back được chấp nhận vào tháng 11 thuộc về cohort đã rời bỏ vào tháng 8. Nếu báo cáo của bạn không kết nối hai điều đó, con số khôi phục của bạn chỉ là hư cấu.
Hãy theo dõi bốn con số, không chỉ một.
Tỷ lệ hoàn tiền theo cohort.
Số yêu cầu được trả lời trong thời hạn.
Doanh thu được bảo vệ, phân theo lý do hoàn tiền.
Số lượng rò rỉ entitlement còn tồn đọng, con số này nên tiến dần về 0 và giữ nguyên ở đó.
Nếu chỉ được chọn một con số để đưa lên dashboard, tôi sẽ chọn số lượng rò rỉ. Đó là con số duy nhất chắc chắn sai bất cứ khi nào nó khác 0.
Phần Mềm Phù Hợp Ở Đâu, Nói Thật
Nhóm hai và nhóm bốn có thể tự động hóa một cách gọn gàng. Nhóm một chỉ cần tự động hóa một lần, sau đó chỉ cần giám sát. Nhóm ba là vấn đề cấu hình và đánh giá, và không có công cụ nào đưa ra đánh giá thay bạn.
Refund Sensor xử lý khía cạnh phòng thủ trên cả hai store, trả lời mọi yêu cầu đủ điều kiện trong thời hạn kèm bằng chứng giao dịch và theo dõi những gì bạn đã giữ được. Nó sẽ không giành lại được ai cả và cũng không sửa được một paywall gây khó hiểu. Không có gì làm được điều đó ngoài chính bạn.
Nguồn Tham Khảo
Câu hỏi thường gặp
Có bốn hướng đi, theo thứ tự tôi sẽ thử. Tìm những người dùng vẫn đang giữ quyền truy cập trên một giao dịch đã được hoàn tiền và tắt nó đi. Trả lời mọi consumption request trong vòng 12 giờ. Giành lại những người đã rời bỏ bằng win-back offer hoặc promotional offer. Sau đó kiểm tra billing retry và grace period, vì một số trường hợp churn chưa bao giờ là vĩnh viễn.
Không thể trực tiếp. Đôi khi Apple tự đảo ngược khoản hoàn tiền sau khi khách hàng khiếu nại và gửi thông báo REFUND_REVERSED. Khi thông báo đó đến, hãy khôi phục lại quyền truy cập. Đó là khoản khôi phục mà bạn không cần phải tranh đấu để có được.
Chúng nhắm đến những thuê bao đã rời bỏ, tức là đã tắt auto-renew, và điều kiện đủ điều kiện dựa trên thời gian trả phí cộng với thời gian kể từ lần đăng ký gần nhất. Một thuê bao đã hoàn tiền được tính là đã rời bỏ, nên thường thì câu trả lời là có. Tuy nhiên, hãy cấu hình các quy tắc và kiểm tra lại.
Truy vấn entitlement. Chỉ mất một giờ làm việc, không cần nhà cung cấp, không cần phát hành ứng dụng mới. Trên mọi ứng dụng mà tôi từng chạy truy vấn này, kết quả luôn khác 0.
Nhiều hơn số tiền hoàn lại. Tỷ lệ thông thường dao động từ 2% đến 5% số giao dịch trả phí. Chi phí thực sự còn bao gồm cả chi phí thu hút người dùng đó, khoản rò rỉ entitlement nếu bạn bỏ lỡ thông báo, và LTV bị thổi phồng khiến bạn trả quá nhiều cho người dùng tiếp theo.
Không nên. Khắc phục rò rỉ không tốn tiền và đó là một lỗi. Phần mềm giúp trả lời những yêu cầu mà bạn chưa trả lời, đó là một vấn đề thực sự, chỉ là không phải vấn đề đầu tiên cần giải quyết.
