संक्षिप्त उत्तर: हर रिफंड किसी असंतुष्ट कस्टमर की वजह से नहीं होता। एक बड़ा हिस्सा पहले से अनुमानित एब्यूज़ पैटर्न का होता है, ट्रायल एब्यूज़ (प्रीमियम फीचर्स का उपयोग करें, फिर चार्ज होने के तुरंत बाद रिफंड ले लें), यूज़-एंड-रिफंड (जिस एक चीज़ की ज़रूरत थी वह पा लें, फिर पैसे वापस माँग लें), और उन अकाउंट्स पर "एक्सीडेंटल" खरीदारी जो महीनों से एक्टिव हैं। ये पैटर्न आपके डेटा में निशान छोड़ जाते हैं, और जो विवादित किए जा सकते हैं, वे ठीक वही हैं जिन्हें आपको जवाब देने की समय-सीमा चूककर नहीं खोना चाहिए।
यह अंतर क्यों महत्वपूर्ण है
अगर आप हर रिफंड को एक ही चीज़ मानते हैं एक नाराज़ यूज़र जिसे आप संतुष्ट नहीं कर पाए तो आप गलत नतीजों पर पहुँचेंगे और गलत कदम उठाएंगे।
कुछ रिफंड वास्तव में असंतोष को दर्शाते हैं, और इसका समाधान प्रोडक्ट और UX पर काम करना है। लेकिन ऐप रिफंड एब्यूज़ के लिए एक अलग विश्लेषण की ज़रूरत होती है, क्योंकि कुछ रिफंड एक्टिविटी ऐसे पैटर्न दिखा सकती है जो सामान्य कस्टमर बिहेवियर से मेल नहीं खाते।
दोनों को एक साथ मिला देने से दोनों समस्याएं छिप जाती हैं। इससे आपका प्रोडक्ट असल से ज़्यादा खराब दिख सकता है, जबकि संभावित रूप से रिकवर किए जा सकने वाले या रिव्यू किए जा सकने वाले रिफंड वास्तविक कस्टमर रिफंड के साथ उसी श्रेणी में खो जाते हैं।
कस्टमर असंतोष को संभावित एब्यूज़ पैटर्न से अलग करना, दोनों के बारे में कुछ भी उपयोगी करने का पहला कदम है।
मुख्य एब्यूज़ पैटर्न
कुछ पैटर्न पर ध्यान देना ज़रूरी है:
ट्रायल एब्यूज़। यूज़र फ्री ट्रायल शुरू करता है, अपनी ज़रूरत के लिए प्रीमियम फीचर्स का उपयोग करता है, और ट्रायल के पेड सब्सक्रिप्शन में बदलने के आस-पास रिफंड की माँग करता है। ट्रांज़ैक्शन का मूल्यांकन करते समय टाइमिंग और कंज़म्पशन हिस्ट्री उपयोगी संकेत हो सकते हैं।
यूज़ एंड रिफंड। यह यूटिलिटी और वन-ऑफ-वैल्यू ऐप्स में सामान्य है। कोई व्यक्ति एक खास काम पूरा करने के लिए सब्सक्रिप्शन खरीदता है, फाइल कन्वर्ट करना, कोई फीचर अनलॉक करना, वॉटरमार्क हटाना, या किसी सर्विस का उपयोग करना, काम पूरा करता है, और फिर तुरंत अपने पैसे वापस माँग लेता है। यहाँ महत्वपूर्ण संकेत है उपयोग की गई वैल्यू और रिफंड रिक्वेस्ट की टाइमिंग के बीच का संबंध।
स्थापित अकाउंट्स पर "एक्सीडेंटल" खरीदारी। यूज़र दावा करता है कि उसने गलती से खरीदारी की, जबकि उसका अकाउंट महीनों से एक्टिव है और उसकी उपयोग की सार्थक हिस्ट्री है। वास्तविक एक्सीडेंटल खरीदारी होती भी है, लेकिन एक्सीडेंटल परचेज़ रिफंड रिक्वेस्ट का मूल्यांकन करते समय अकाउंट टेन्योर और उपयोग हिस्ट्री अतिरिक्त संदर्भ दे सकती है।
बार-बार रिफंड लेने वाले यूज़र्स। एक छोटा समूह कई खरीदारियों में बार-बार रिफंड लेने का व्यवहार दिखा सकता है। एक रिफंड अलग-थलग घटना है; रिफंड का लंबा इतिहास एक पैटर्न है जिसकी जाँच ज़रूरी है। Apple के कंज़म्पशन डेटा में लाइफटाइम रिफंड अमाउंट, अकाउंट टेन्योर, लाइफटाइम परचेज़ अमाउंट, और कंज़म्पशन से जुड़ी जानकारी शामिल हो सकती है, जो संदर्भ देने में मदद कर सकती है।
हर पैटर्न जो निशान छोड़ता है
ऑटोमेशन के लिए इन पैटर्न का महत्व इस वजह से है कि ये हमेशा अदृश्य नहीं होते। ये उस ट्रांज़ैक्शन और कंज़म्पशन डेटा में दिखाई दे सकते हैं जिसका उपयोग रिफंड रिक्वेस्ट का मूल्यांकन करने के लिए किया जाता है:
ज़्यादा उपयोग, तुरंत रिफंड। महत्वपूर्ण उपयोग के साथ जल्दी ही रिफंड रिक्वेस्ट होना संभावित यूज़ एंड रिफंड पैटर्न का संकेत दे सकता है।
ट्रायल-कन्वर्ज़न चार्ज के समय हुआ रिफंड। ट्रायल कन्वर्ज़न के आस-पास केंद्रित रिफंड रिक्वेस्ट ट्रायल एब्यूज़ का मूल्यांकन करते समय एक उपयोगी संकेत हो सकता है।
अकाउंट टेन्योर बनाम "एक्सीडेंटल" दावा। लंबे समय से स्थापित और सक्रिय रूप से उपयोग किए जा रहे अकाउंट द्वारा एक्सीडेंटल खरीदारी का दावा एक बेमेलता पैदा करता है, जिसे फ्रॉड मानने के बजाय रिव्यू करना बेहतर है।
बार-बार रिफंड का इतिहास। जिस कस्टमर का रिफंड इतिहास बार-बार दोहराया गया हो, वह एक अलग-थलग घटना के बजाय एक पैटर्न दर्शा सकता है।
Apple के मौजूदा कंज़म्पशन-रिक्वेस्ट डॉक्युमेंटेशन में अकाउंट टेन्योर, कंज़म्पशन स्टेटस, प्ले टाइम, लाइफटाइम डॉलर्स रिफंडेड, लाइफटाइम डॉलर्स परचेज़्ड, डिलीवरी स्टेटस, और सैंपल कंटेंट या ट्रायल दिया गया था या नहीं, जैसे फील्ड्स शामिल हैं।
इसका मतलब है कि डेवलपर्स योग्य Apple रिफंड रिक्वेस्ट का जवाब देते समय उपलब्ध सबूतों का उपयोग करके ज़्यादा संदर्भ दे सकते हैं। Apple का कहना है कि यह कंज़म्पशन जानकारी उसके रिफंड फैसलों में मदद करती है, और डेवलपर्स को CONSUMPTION_REQUEST का जवाब 12 घंटे के भीतर देना चाहिए।
एब्यूज़ रिफंड ही क्यों विवादित करने लायक हैं
यहाँ रणनीतिक बात है।
वास्तविक असंतोष वाले रिफंड को आम तौर पर एक अलग तरह के जवाब की ज़रूरत होती है। वास्तविक कस्टमर शिकायतों से लड़ना कस्टमर एक्सपीरियंस को नुकसान पहुँचा सकता है और इससे प्रोडक्ट की मूल समस्या हल नहीं होती।
संभावित सब्सक्रिप्शन रिफंड एब्यूज़ अलग मामला है। जब उपलब्ध सबूत काफी उपयोग, दी गई वैल्यू, या बार-बार रिफंड लेने का व्यवहार दिखाते हैं जो कस्टमर के दावे से मेल नहीं खाता, तो मामले को और करीब से रिव्यू करना ज़रूरी हो सकता है।
महत्वपूर्ण अंतर यह है कि डेवलपर्स हर रिफंड को अकेले अपने फैसले से मना नहीं कर सकते। अंतिम फैसला Apple और Google लेते हैं, और हर रिफंड में डेवलपर को जवाब देने का मौका नहीं मिलता।
Apple पर, योग्य CONSUMPTION_REQUEST नोटिफिकेशन डेवलपर्स को कंज़म्पशन जानकारी देने की अनुमति देते हैं, जिसका उपयोग Apple अपने रिफंड फैसले में करता है।
Google Play पर, जिन चार्जबैक के लिए डेवलपर रिव्यू की ज़रूरत होती है, वे PendingRefundReviewNotification जनरेट कर सकते हैं। डेवलपर्स ReviewRefund API के ज़रिए 24 घंटे के भीतर अपनी रिफंड प्राथमिकता और संबंधित परचेज़-उपयोग सबूत दे सकते हैं।
इसीलिए रिफंड फ्रॉड ऐप्स की समस्या को डिटेक्शन और सबूत की समस्या के रूप में देखना चाहिए, न कि सिर्फ रिफंड मना करने की समस्या के रूप में।
आप इस बारे में क्या कर सकते हैं और क्या नहीं
सीमा के बारे में साफ बात करें तो:
आप नहीं कर सकते किसी कस्टमर को रिफंड रिक्वेस्ट करने से रोक सकते, और न ही आप अकेले अपने फैसले से किसी रिफंड को मना कर सकते हैं। अंतिम फैसला Apple और Google लेते हैं।
आप नहीं कर सकते हर एब्यूज़ रिफंड को विवादित कर सकते; हर रिफंड में डेवलपर रिव्यू का मौका नहीं मिलता, और Apple व Google के बीच उपलब्ध प्रक्रिया अलग-अलग है।
आप कर सकते हैं लागू समय-सीमा के भीतर उपलब्ध कंज़म्पशन और परचेज़ सबूत के साथ हर योग्य रिक्वेस्ट का जवाब दे सकते हैं।
आप कर सकते हैं पैटर्न पहचान सकते हैं कौन से ऐप्स, कौन-से कारण, कौन-से प्रोडक्ट्स, और कौन-सा कस्टमर बिहेवियर जिससे आप वास्तविक प्रोडक्ट फ्रिक्शन को संभावित एब्यूज़ से अलग कर सकें।
बड़ी मात्रा में सब्सक्रिप्शन प्रोसेस करने वाली टीमों के लिए, रिफंड एब्यूज़ डिटेक्शन सॉफ़्टवेयर रिफंड इवेंट्स को एक जगह लाने, संदिग्ध पैटर्न पहचानने, और योग्य रिक्वेस्ट को बिना जवाब के छूटने से बचाने में मदद कर सकता है।
RefundSensor दोनों हिस्सों का काम करता है। यह योग्य Apple CONSUMPTION_REQUEST इवेंट्स और Google Play चार्जबैक रिव्यू का जवाब देता है, जबकि इसकी एनालिटिक्स रिफंड को ऐप और कारण के अनुसार अलग-अलग दिखाती है, जिससे संभावित एब्यूज़ पैटर्न एक ही "रिफंड रेट" नंबर में छिपने के बजाय दिखाई देने लगते हैं।
इससे आप टाइमिंग की वजह से रिव्यू किए जा सकने वाले मामलों को खोना बंद करते हैं, और साथ ही यह जान पाते हैं कि समस्या का कितना हिस्सा संभावित एब्यूज़ से और कितना वास्तविक प्रोडक्ट फ्रिक्शन से आता है।
आगे पढ़ें
https://developers.google.com/android-publisher/voided-purchases
https://developer.android.com/google/play/billing/provide-refund-and-chargeback-suggestions
https://developer.android.com/reference/com/android/billingclient/api/BillingFlowParams.Builder
https://developer.apple.com/documentation/appstoreserverapi/appaccounttoken
https://developer.apple.com/documentation/appstoreserverapi/consumptionrequest
https://support.google.com/googleplay/android-developer/answer/17068375
देखें कि आपकी रिफंड रेट का कितना हिस्सा संभावित एब्यूज़ से जुड़ा हो सकता है। RefundSensor योग्य Apple और Google Play रिफंड एक्टिविटी को मॉनिटर करने में मदद करता है और रिफंड इवेंट्स को ऐप व कारण के अनुसार अलग-अलग दिखाता है, जिससे संभावित एब्यूज़ आपके कुल रिफंड नंबरों के भीतर छिपा नहीं रहता। मुफ़्त में शुरू करें
अक्सर पूछे जाने वाले प्रश्न
बिना पैसे चुकाए वैल्यू पाने के लिए रिफंड सिस्टम का उपयोग करना - जैसे ट्रायल एब्यूज़, यूज़-एंड-रिफंड, या झूठे "एक्सीडेंटल परचेज़" दावे। यह वास्तविक असंतोष से अलग है, जहाँ रिफंड उचित होता है।
आप रिक्वेस्ट को रोक नहीं सकते या अकेले उसे मना नहीं कर सकते; यह फैसला स्टोर्स लेते हैं। आप जो कर सकते हैं, वह है योग्य रिक्वेस्ट का जवाब कंज़म्पशन सबूत के साथ देना जो एब्यूज़ को उजागर करे, और स्पष्ट ट्रायल व पेवॉल डिज़ाइन के ज़रिए ट्रायल एब्यूज़ को स्रोत पर ही कम करना।
डेटा का पैटर्न ही आपको बता देता है: तुरंत रिफंड के साथ ज़्यादा उपयोग, ट्रायल कन्वर्ज़न के समय हुआ रिफंड, या लंबे समय से एक्टिव अकाउंट पर "एक्सीडेंटल" दावा। कारण के अनुसार रिफंड एनालिटिक्स इन पैटर्न को दिखाई देने योग्य बनाती है।
एब्यूज़ के मामले, जहाँ वैल्यू स्पष्ट रूप से दी गई थी और दावा कमज़ोर है। वास्तविक असंतोष वाले रिफंड को आम तौर पर स्वीकार करना बेहतर होता है। समस्या यह है कि एब्यूज़ वाले रिफंड अक्सर जवाब की समय-सीमा चूकने की वजह से डिफ़ॉल्ट रूप से खो जाते हैं।
इससे रिक्वेस्ट रुकती नहीं है, लेकिन सटीक कंज़म्पशन डेटा जमा करने से Apple को अपने फैसले में एब्यूज़ को शामिल करने का संदर्भ मिलता है - ऐसा संदर्भ जो अगर आप समय पर जवाब न दें तो उसे कभी नहीं मिलता।
