App Store & Play Store Development

Thông Báo CONSUMPTION_REQUEST Là Gì? Phân Tích Chi Tiết Từng Trường

CONSUMPTION_REQUEST của Apple yêu cầu dữ liệu tiêu thụ có cấu trúc trước khi quyết định hoàn tiền. Đây là ý nghĩa của từng trường và cách mỗi trường ảnh hưởng đến kết quả.

6 min read
Thông Báo CONSUMPTION_REQUEST Là Gì? Phân Tích Chi Tiết Từng Trường

Trả lời nhanh: CONSUMPTION_REQUEST là thông báo mà Apple gửi đến server của bạn khi khách hàng yêu cầu hoàn tiền cho một giao dịch mua trong ứng dụng hoặc gói đăng ký đủ điều kiện. Để phản hồi, bạn gửi lại một ConsumptionRequest có cấu trúc — một tập hợp các trường mô tả cách khách hàng đã sử dụng thứ họ mua, liệu họ có đồng ý hay không, và tùy chọn hoàn tiền của bạn. Apple sẽ cân nhắc các trường đó khi ra quyết định. Hướng dẫn này giải thích ý nghĩa của từng trường và lý do nó quan trọng.

Thông báo này là gì

Khi khách hàng yêu cầu Apple hoàn tiền, App Store sẽ gửi một CONSUMPTION_REQUEST đến server của bạn thông qua App Store Server Notifications. Đây là cách Apple nói: hãy cho chúng tôi biết những gì bạn biết về cách khách hàng này đã sử dụng giao dịch mua này, và chúng tôi sẽ đưa điều đó vào quyết định của mình.

Bạn phản hồi bằng cách gửi lại một nội dung ConsumptionRequest. Mỗi giá trị là một tín hiệu. Gửi dữ liệu hoàn tiền apple chính xác, đầy đủ thì Apple sẽ có đủ ngữ cảnh; để trống các trường thì Apple sẽ quyết định với ít thông tin hơn. Bạn không tự phê duyệt hay từ chối khoản hoàn tiền — Apple luôn là bên đưa ra quyết định cuối cùng — nhưng chất lượng của những gì bạn gửi sẽ ảnh hưởng đến khả năng thành công. Để biết toàn bộ quy trình, xem Cách Tự Động Hóa Yêu Cầu Hoàn Tiền Của Apple.

Các trường Apple chấp nhận

Dưới đây là những gì có trong một ConsumptionRequest và ý nghĩa của từng trường đối với Apple. Các trường consumption request này cung cấp dữ liệu có cấu trúc được sử dụng trong quy trình consumption api:

Trường

Ý nghĩa

Tại sao quan trọng

customerConsented

Liệu khách hàng có đồng ý chia sẻ dữ liệu này hay không

Bắt buộc. Phải là true, nếu không Apple sẽ không xử lý phản hồi.

consumptionStatus

Chưa sử dụng / sử dụng một phần / đã sử dụng hết

Một giao dịch mua đã sử dụng hết là một trường hợp rất khác so với một giao dịch chưa được sử dụng.

deliveryStatus

Liệu giá trị hoặc dịch vụ đã được giao thành công hay chưa

Phân biệt giữa "chúng tôi đã giao, họ đã dùng" với một lỗi giao hàng thực sự.

refundPreference

Khuyến nghị của bạn: chưa xác định / ưu tiên chấp thuận / ưu tiên từ chối

Một trong các yếu tố đầu vào của Apple — khi bằng chứng của bạn ủng hộ điều đó, đây là tiếng nói của bạn trong quyết định.

accountTenure

Khách hàng đã có tài khoản với bạn bao lâu

Một tài khoản lâu năm được nhìn nhận khác với một tài khoản hoàn toàn mới.

playTime

Khách hàng đã dành bao nhiêu thời gian trong ứng dụng của bạn

Bằng chứng trực tiếp về mức độ tương tác với thứ họ đang yêu cầu hoàn tiền.

lifetimeDollarsPurchased

Tổng số tiền khách hàng đã chi tiêu trên các ứng dụng của bạn

Ngữ cảnh cho biết đây là một lần mua đơn lẻ hay một khách hàng lâu năm, có giá trị.

lifetimeDollarsRefunded

Tổng số tiền đã hoàn trước đó cho khách hàng này

Một khuôn mẫu hoàn tiền lặp lại là một tín hiệu đáng chú ý.

sampleContentProvided

Liệu khách hàng có thể dùng thử trước khi mua hay không

Cho biết liệu giao dịch mua có được thực hiện với đầy đủ thông tin hay không.

userStatus

Trạng thái tài khoản hiện tại (đang hoạt động, bị khóa, v.v.)

Phản ánh tình trạng của khách hàng tại thời điểm yêu cầu.

Apple ánh xạ hầu hết các trường này vào các tập giá trị được xác định sẵn (ví dụ, consumptionStatus và deliveryStatus sử dụng các mã liệt kê cụ thể). Các mã chính xác được liệt kê trong tài liệu của Apple, liên kết ở bên dưới, và có thể thay đổi — đây là một phần lý do vì sao việc duy trì một phản hồi luôn cập nhật là công việc liên tục, không phải chỉ xây dựng một lần.

Ba trường quan trọng nhất

Nếu bạn chỉ tập trung vào một vài điều, hãy tập trung vào đây:

customerConsented: Trường này không chỉ quan trọng, mà còn là một cánh cổng. Apple sẽ từ chối toàn bộ phản hồi nếu giá trị này không phải true, và bạn chịu trách nhiệm pháp lý về việc đã thu được sự đồng ý đó trong ứng dụng của mình trước khi gửi bất kỳ dữ liệu nào. Đây vừa là một trường tuân thủ, vừa là một trường kỹ thuật. Chúng tôi trình bày chi tiết yêu cầu về sự đồng ý trong Sự Đồng Ý Của Khách Hàng & Consumption API.

refundPreference: Đây là thứ gần giống nhất với một "lá phiếu" mà bạn có. Khi bằng chứng của bạn thực sự ủng hộ việc từ chối, việc thể hiện tùy chọn đó là một trong các yếu tố đầu vào mà Apple xem xét. Khi bằng chứng không ủng hộ, việc ép đặt tùy chọn từ chối không phải là một cách ghi đè thần kỳ — Apple vẫn là bên quyết định.

consumptionStatus: Việc khách hàng có thực sự sử dụng thứ họ đã mua hay không thường là trọng tâm của vụ việc. Đây cũng là một trong những trường dễ bị sai nhất nếu dữ liệu sử dụng của bạn không chính xác và không được cập nhật vào thời điểm yêu cầu đến.

Vì sao việc điền đúng các trường này khó hơn vẻ ngoài của nó

Khi đọc một bảng các trường, việc này có thể trông như chỉ cần một buổi chiều để hoàn thành. Nhưng trên thực tế, để phản hồi tốt, bạn cần:

  • Lấy dữ liệu sử dụng và thanh toán chính xác, cập nhật tức thời cho từng khách hàng ngay khi yêu cầu đến — không phải ảnh chụp dữ liệu từ hôm trước.

  • Ánh xạ dữ liệu nội bộ của bạn sang đúng các tập giá trị của Apple, và giữ cho ánh xạ đó chính xác khi Apple sửa đổi chúng.

  • Thực hiện tất cả trong khoảng thời gian ~12 giờ, vào bất kỳ giờ nào, mà không cần ai đó theo dõi.

  • Xử lý trạng thái đồng ý, các lần thử lại, lỗi, và ghi log để bạn có thể chứng minh những gì mình đã gửi và biết liệu nó có hiệu quả hay không.

Không điều gì trong số đó khó về mặt khái niệm. Nhưng tất cả đều là hạ tầng mà bạn sẽ phải sở hữu và duy trì cho một quy trình không phải là sản phẩm của bạn. Đó là bài toán mà hầu hết các nhóm cuối cùng phải tính đến: các trường dữ liệu là điều có thể hiểu được, nhưng việc xây dựng và duy trì một hệ thống phản hồi đáng tin cậy, đúng hạn và tuân thủ cho chúng là một chi phí thường trực mà không mang lại lợi ích gì cho ứng dụng thực tế của bạn.

Đó là khoảng trống mà RefundSensor lấp đầy. Nó ánh xạ mọi trường từ dữ liệu của bạn, luôn cập nhật theo các thay đổi của Apple, và tự động phản hồi trong khung thời gian cho phép, nhờ đó độ chính xác quyết định kết quả hoàn tiền được xử lý mà bạn không cần xây dựng hay giám sát nó. Đối với các nhóm đang so sánh các phần mềm tự động hóa hoàn tiền của Apple, điều này loại bỏ gánh nặng hạ tầng khỏi quy trình làm việc.

Nguồn chính thức

Các tập giá trị và yêu cầu của Apple có thể thay đổi, vì vậy hãy coi tài liệu của Apple là nguồn thông tin chính thức cuối cùng:

Các trường dữ liệu là điều có thể hiểu được. Việc duy trì một hệ thống phản hồi cho chúng không phải là công việc của bạn. RefundSensor ánh xạ mọi trường ConsumptionRequest từ dữ liệu của bạn và tự động phản hồi trong khung thời gian của Apple — chính xác, cập nhật và tuân thủ. Bắt đầu miễn phí

Câu hỏi thường gặp

Đây là App Store Server Notification mà Apple gửi khi khách hàng yêu cầu hoàn tiền cho một giao dịch mua đủ điều kiện. Nó yêu cầu bạn gửi lại dữ liệu tiêu thụ mà Apple sẽ cân nhắc khi ra quyết định hoàn tiền.

Các trường mô tả sự đồng ý, trạng thái tiêu thụ, trạng thái giao hàng, thời gian sử dụng tài khoản, thời gian chơi, tổng chi tiêu và hoàn tiền trong suốt thời gian sử dụng, nội dung mẫu, trạng thái tài khoản, và tùy chọn hoàn tiền của bạn. Mỗi trường là một tín hiệu mà Apple đưa vào quyết định.

customerConsented là một cánh cổng bắt buộc — thiếu nó, phản hồi sẽ bị từ chối. refundPreference và consumptionStatus là hai trường ảnh hưởng trực tiếp nhất đến kết quả khi bằng chứng của bạn ủng hộ lập luận của mình.

Một tùy chọn sẽ có trọng lượng lớn hơn khi được hỗ trợ bởi dữ liệu tiêu thụ và giao hàng chính xác. Phản hồi sơ sài cho Apple ít thông tin để hành động, vì vậy chỉ riêng tùy chọn sẽ yếu hơn so với tùy chọn kèm bằng chứng.

Không. Apple luôn là bên đưa ra quyết định cuối cùng. Dữ liệu chính xác giúp cải thiện khả năng thành công của bạn; nó không mang lại cho bạn quyền phủ quyết.

#consumption request notification#consumption request fields#consumption api#apple refund data#customerConsented#refundPreference
Refund SensorRefund Sensor TeamRefund defense for App Store and Google Play developers