Cách theo dõi hoàn tiền App Store và bảo vệ doanh thu gói đăng ký

Cách theo dõi hoàn tiền App Store và bảo vệ doanh thu gói đăng ký

Bộ phận tài chính báo doanh thu tháng này giảm khoảng bốn trăm đô la. Không ai nói được là giảm từ đâu.

Đó là tình huống hầu hết các team gặp đầu tiên. Một con số thay đổi, còn chi tiết đằng sau nó nằm ở nơi team phát triển khó tiếp cận. Giao dịch nào? Khách hàng nào? Họ còn quyền truy cập không? Một sản phẩm hay cả một xu hướng? Chuyện này đã diễn ra nhiều tháng rồi chăng?

Theo dõi hoàn tiền App Store chính là thứ lấp khoảng trống đó. Nó không nhằm ngăn hoàn tiền — Apple là bên quyết định, và không có gì bạn xây dựng thay đổi được điều đó. Nó nhằm giữ một hồ sơ đáng tin cậy về các sự kiện hoàn tiền và kết nối từng sự kiện với một giao dịch, một khách hàng, một gói đăng ký và một dòng trong báo cáo của bạn.

Bài viết này hướng dẫn cách xây dựng hồ sơ đó. Về quy trình xung quanh, hướng dẫn của chúng tôi về quản lý hoàn tiền App Store bao quát quy trình làm việc rộng hơn.

Điểm chính

• Theo dõi hoàn tiền không đồng nghĩa với ngăn chặn hoàn tiền. Apple đưa ra quyết định hoàn tiền; theo dõi là để bạn có khả năng quan sát ở phía mình.

• Chỉ server notification thôi chưa phải là một hệ thống theo dõi hoàn chỉnh. Apple cung cấp riêng một API tra cứu cho những khoản hoàn tiền bạn đã bỏ lỡ.

• Một sự kiện hoàn tiền chỉ hữu ích khi đã được liên kết với một giao dịch, một khách hàng và một gói đăng ký.

• Trạng thái entitlement phải phản ánh khoản hoàn tiền, kể cả thu hồi một phần khi áp dụng.

• Các giao dịch gói đăng ký đã hoàn tiền không nên nằm trong báo cáo như những lần gia hạn thông thường.

• Tự động hóa phát huy giá trị khi khối lượng tăng và nhiều team cùng cần chung một dữ liệu.

Theo dõi hoàn tiền App Store là gì?

Theo dõi hoàn tiền App Store là việc ghi lại mọi sự kiện hoàn tiền ảnh hưởng đến ứng dụng của bạn và kết nối nó với những thứ xung quanh: giao dịch, tài khoản khách hàng, sản phẩm, gói đăng ký, trạng thái entitlement và báo cáo doanh thu của bạn.

Từ khóa ở đây là kết nối. Một sự kiện hoàn tiền đứng riêng gần như vô dụng — một mã giao dịch kèm ngày thu hồi chỉ cho bạn biết có thứ gì đó đã được hoàn tiền, chứ không biết là ai, họ mất quyền truy cập gì, hay chuyện đó có đáng kể không. Hệ thống theo dõi là thứ biến một sự kiện thành một câu trả lời.

Vì sao developer cần theo dõi hoàn tiền App Store

Lý do hiển nhiên là tiền, nhưng đáng để nói chính xác về hình hài của khoản doanh thu mất đi do hoàn tiền App Store. Một giao dịch được hoàn tiền sẽ đảo ngược khoản doanh thu bạn đã tính, và nếu đó là một kỳ đăng ký, mối quan hệ thường kết thúc theo — nên các lần gia hạn phía sau cũng mất theo. Những lần gia hạn đó từng nằm trong dự báo của ai đó.

Rồi đến phần trông không giống tài chính. Nếu một khoản hoàn tiền không bao giờ đến được hệ thống của bạn, khách hàng vẫn giữ quyền truy cập. Bộ phận hỗ trợ nhận câu hỏi mà không có hồ sơ nào để kiểm tra. Bộ phận tài chính đối chiếu báo cáo thanh toán bằng tay. Và không ai nói được liệu có sản phẩm nào bị hoàn tiền nhiều hơn hẳn các sản phẩm khác không, vì chẳng có lịch sử nào để truy vấn. Mỗi vấn đề đều nhỏ; gộp lại, chúng là lý do các vấn đề hoàn tiền bị phát hiện muộn.

Cách theo dõi hoàn tiền App Store

Developer theo dõi hoàn tiền App Store thông qua server notification của Apple và hồ sơ giao dịch của chính mình, rồi kết nối các sự kiện đó với người dùng, gói đăng ký, entitlement và báo cáo doanh thu. Bảy bước.

1. Nhận các server notification liên quan từ Apple

Sự kiện hoàn tiền đến với bạn dưới dạng App Store Server Notifications tại một URL do bạn cấu hình. Bạn có thể xem tài liệu App Store Server Notifications của Apple để biết cách thiết lập và các loại sự kiện. Sự kiện quan trọng nhất ở đây là REFUND, cho bạn biết một khoản hoàn tiền đã được chấp thuận. REFUND_REVERSED cũng quan trọng: Apple có thể đảo ngược một khoản hoàn tiền đã cấp trước đó, và hồ sơ của bạn cần phản ánh điều này.

2. Xác minh notification

Notification đến dưới dạng payload JWS có chữ ký. Hãy xác minh chữ ký với chứng chỉ của Apple và kiểm tra bundle ID trước khi ghi bất cứ thứ gì vào cơ sở dữ liệu. Một endpoint tin bất cứ thứ gì gửi đến là một endpoint mà người khác có thể ghi vào.

3. Xác định giao dịch

Payload sau khi giải mã chứa các mã định danh giao dịch và, với giao dịch đã hoàn tiền, một revocationDate và revocationReason. Trường lý do đó hữu ích hơn hầu hết các team nghĩ: nó phân biệt khoản hoàn tiền được cấp vì sự cố trong ứng dụng với khoản hoàn tiền vì lý do khác. Hoàn tiền thuộc nhóm đầu là một tín hiệu về sản phẩm, không chỉ là một sự kiện doanh thu.

4. Khớp giao dịch với người dùng

Mã định danh của Apple không phải ID tài khoản của bạn. Cầu nối giữa hai bên chính là mục đích của appAccountToken: một UUID mà ứng dụng của bạn gắn vào lúc mua và sẽ quay lại trong payload giao dịch. Không có nó, bạn phải khớp dựa trên thời điểm và suy luận, vốn không đáng tin cậy chính trong những trường hợp bạn quan tâm nhất.

5. Ghi lại sự kiện hoàn tiền

Lưu nó thành một bản ghi riêng, không phải một cờ trên giao dịch mua. Bạn cần sự kiện, dấu thời gian, những gì Apple nói và những gì bạn đã làm với nó. Phần tiếp theo nói về các trường cần lưu.

6. Cập nhật trạng thái gói đăng ký và entitlement

Quyền truy cập phải khớp với giao dịch. Khi một khoản hoàn tiền xảy ra, hãy thu hồi quyền truy cập sau khi hoàn tiền. Khi một khoản bị đảo ngược, hãy khôi phục lại. Apple cũng hỗ trợ hoàn tiền theo tỷ lệ, khi chỉ một phần giao dịch bị thu hồi và tỷ lệ phần trăm bị thu hồi được trả về trong payload giao dịch — nên logic entitlement nào giả định mọi khoản hoàn tiền đều là toàn bộ hoặc không gì cả sẽ xử lý sai một số trường hợp này.

7. Kết nối hoạt động hoàn tiền với báo cáo doanh thu

Một khoản hoàn tiền chỉ tồn tại trong cơ sở dữ liệu của team kỹ thuật thì chưa đi hết hành trình. Tài chính cần nó nằm đúng kỳ; sản phẩm cần nó gắn với SKU. Nếu các team đó đọc những con số khác nhau, dữ liệu chỉ đang được lưu chứ không thực sự được theo dõi.

Developer nên theo dõi những gì cho mỗi khoản hoàn tiền?

Một phần trong số này đến từ Apple. Phần còn lại do bạn tạo ra. Giữ rõ ranh giới này là quan trọng, vì chỉ nhóm đầu mới có tính xác thực.

Hai dấu thời gian âm thầm chứng minh giá trị của mình. Khoảng cách giữa lúc Apple gửi sự kiện và lúc hệ thống của bạn hành động là thước đo rõ nhất cho việc theo dõi có đang hoạt động hay không.

Vì sao chỉ notification là chưa đủ

Đây là phần khiến những team tưởng đã giải quyết xong vấn đề bị bất ngờ. Notification có thể bị bỏ lỡ. Endpoint của bạn ngừng hoạt động, một lần deploy làm hỏng handler, một payload không parse được — và phía bạn không có lỗi nào, vì sự kiện đơn giản là chưa bao giờ đến. Apple đã tính đến điều này: App Store Server API có một endpoint lịch sử hoàn tiền, và tài liệu của Apple mô tả rõ đây là cách lấy lại những notification hoàn tiền bạn có thể đã bỏ lỡ, chẳng hạn khi máy chủ gặp sự cố.

Vì vậy một hệ thống theo dõi hoàn chỉnh có hai nửa. Notification xử lý sự kiện gần như theo thời gian thực; một lượt đối chiếu định kỳ với lịch sử hoàn tiền bắt lại bất cứ thứ gì lọt qua. Hầu hết các team xây nửa đầu và cho rằng thế là đủ. Không phải vậy, và lỗi này diễn ra trong im lặng.

Cách developer theo dõi hoàn tiền Apple trên các gói đăng ký

Gói đăng ký nâng mức độ rủi ro: đằng sau giao dịch là một mối quan hệ, không chỉ là một lần mua.

Một kỳ đăng ký bị hoàn tiền không phải một lần đảo ngược đơn lẻ. Nó thường kết thúc gói đăng ký, nên kỳ entitlement đóng sớm, các lần gia hạn dừng lại, và lịch sử của khách hàng giờ mang theo một khoản hoàn tiền cần được hạch toán.

Đó là lý do một giao dịch gói đăng ký đã hoàn tiền không nên nằm trong báo cáo nội bộ như một lần gia hạn thành công thông thường. Nếu số liệu doanh thu của bạn được tổng hợp từ các sự kiện gia hạn mà không có lớp hoàn tiền phủ lên, chúng sẽ âm thầm trôi lên cao theo cách không ai nhận ra cho đến khi đối chiếu.

Server API của Apple cũng cung cấp các endpoint về trạng thái gói đăng ký và lịch sử giao dịch, hữu ích để đối chiếu góc nhìn của bạn về một khách hàng với góc nhìn của Apple thay vì tin vào cơ sở dữ liệu của mình mãi mãi. Phiên trình bày của Apple về hỗ trợ khách hàng và xử lý hoàn tiền giải thích cách các mảnh ghép này khớp với nhau từ phía developer.

Hoàn tiền App Store ảnh hưởng thế nào đến doanh thu gói đăng ký

Một khoản hoàn tiền có thể ảnh hưởng nhiều hơn giao dịch ban đầu, nhất là khi giao dịch mua bị hoàn tiền là một phần của mối quan hệ đăng ký.

Tác động trực tiếp là việc đảo ngược. Ngoài ra, giá trị đăng ký trong tương lai từ khách hàng đó có thể không thành hiện thực — dù không phải mọi khoản hoàn tiền đều kết thúc bằng churn, nên hãy đo lường thay vì giả định. Giá trị vòng đời tính trên tổng giao dịch mua sẽ phóng đại thực tế cho đến khi trừ đi hoàn tiền, và dự báo thừa hưởng sai số đó. Không có gì trong số này là nghiêm trọng với từng khoản hoàn tiền. Nó tích lũy một cách vô hình, và đó là lý do nên theo dõi thay vì ước tính.

Theo dõi hoàn tiền gói đăng ký App Store giúp bảo vệ doanh thu như thế nào

Nói rõ về những gì theo dõi làm được và không làm được: nó không ảnh hưởng đến quyết định hoàn tiền của Apple. Nó thay đổi những gì bạn có thể nhìn thấy và hành động.

Với một lịch sử hoàn tiền có thể truy vấn, nhiều thứ mở ra. Bạn có thể phát hiện sản phẩm hay mức giá nào bị hoàn tiền nhiều bất thường, tìm ra chỗ rò rỉ khi người dùng đã được hoàn tiền vẫn giữ quyền truy cập, tách các khoản hoàn tiền do lỗi ứng dụng khỏi phần còn lại và xử lý nhóm đầu như một hàng đợi bug, xem hoàn tiền có tăng vọt sau một bản phát hành không, và cho hỗ trợ lẫn tài chính cùng một góc nhìn. Đó là những chỉnh sửa về sản phẩm và vận hành, và chính chúng mới là nơi việc bảo vệ doanh thu thực sự bắt nguồn.

Vì sao theo dõi hoàn tiền App Store thủ công sụp đổ

Theo dõi thủ công hoạt động được ở khối lượng thấp và thất bại theo cách dễ đoán khi khối lượng tăng.

Notification đến trong đêm. Người phụ trách bảng tính chuyển team. Mã giao dịch nằm ở một hệ thống, dữ liệu tài khoản ở hệ thống khác, nên mỗi lần tra cứu là một nhiệm vụ điều tra nhỏ. Dữ liệu lịch sử mỏng vì không ai bổ sung ngược. Trạng thái gói đăng ký và entitlement lệch nhau mà không ai cảnh báo. Tài chính phát hiện chênh lệch lúc chốt quý.

Vấn đề không nằm ở nỗ lực. Khối lượng công việc tăng theo doanh thu trong khi vai trò của chẳng ai được mở rộng tương ứng.

Khi nào developer nên tự động hóa theo dõi hoàn tiền App Store?

Đại khái là khi bất kỳ điều nào sau đây xảy ra: sự kiện hoàn tiền đến nhanh hơn tốc độ ai đó xử lý được, nhiều team cần cùng một dữ liệu, việc cập nhật entitlement đã trở nên thiếu nhất quán, hoặc tài chính cần khả năng quan sát sớm hơn kỳ chốt sổ tiếp theo.

Tự động hóa đảm nhận các phần có tính xác định — nhận và xác minh notification, khớp giao dịch với tài khoản, ghi bản ghi, đối chiếu với lịch sử hoàn tiền, cập nhật entitlement, làm nổi bật xu hướng. Nó sẽ không hạ tỷ lệ hoàn tiền của bạn, và những tuyên bố ngược lại đáng bị nghi ngờ. Thứ nó thay đổi là tính nhất quán và độ trễ.

Phần mềm giám sát hoàn tiền App Store nên làm gì?

Câu hỏi hữu ích là liệu một công cụ có lấp được những khoảng trống cụ thể nêu trên không. Nó phải xử lý và xác minh App Store Server Notifications, để sự kiện không biến mất vào một endpoint đang lỗi. Nó phải đối chiếu với lịch sử hoàn tiền của Apple, vì theo dõi chỉ dựa vào notification có một điểm mù. Nó phải ánh xạ giao dịch với tài khoản, vì đó là nơi thời gian thủ công đổ vào. Và nó phải theo dõi tác động lên gói đăng ký thay vì coi mọi khoản hoàn tiền như nhau.

Tiếp đến: lịch sử hoàn tiền có thể tìm kiếm, quy trình entitlement bao gồm cả thu hồi toàn bộ lẫn một phần, báo cáo mà cả tài chính và sản phẩm đều dùng được, và cảnh báo khi có việc cần đến con người. Độ bao phủ quan trọng hơn số lượng tính năng.

Lời kết

Bạn không quyết định Apple chấp thuận khoản hoàn tiền nào. Bạn quyết định mình có nhìn thấy chúng hay không.

Theo dõi tốt nghĩa là biết cái gì đã được hoàn tiền, khách hàng nào bị ảnh hưởng, quyền truy cập của họ giờ nên ra sao, nó được ghi vào báo cáo thế nào, và nó có nằm trong một xu hướng hay không. Đó là một bảng dữ liệu và vài handler, không phải một dự án đồ sộ.

Nếu bạn chỉ làm một việc sau khi đọc bài này, hãy thêm lượt đối chiếu. Xử lý notification là phần hầu hết các team đã có; kiểm tra nó với lịch sử hoàn tiền của Apple mới là phần cho bạn biết nó có thực sự hoạt động hay không.

Nếu khối lượng hoàn tiền đã vượt quá khả năng theo dõi thủ công

Khi hoạt động hoàn tiền tăng lên, việc kiểm tra notification, khớp giao dịch, theo dõi tác động lên gói đăng ký và cập nhật lịch sử hoàn tiền bằng tay không còn thực tế. RefundSensor tự động hóa và sắp xếp phía developer của quy trình đó, để hồ sơ luôn chính xác mà không cần ai duy trì thủ công.