मैं दो ऐसी टीमों को जानता हूं जो एक ही ऐप चलाती हैं और उन्होंने एक ही महीने के लिए 3.1% और 5.8% के रिफंड रेट रिपोर्ट किए। दोनों में से कोई झूठ नहीं बोल रहा था। उन्होंने इस मेट्रिक को अलग-अलग तरीके से परिभाषित किया था, और किसी ने भी इसकी परिभाषा लिखकर नहीं रखी थी।
मोबाइल ऐप रिफंड एनालिटिक्स की यही बात है जिसे कोई फीचर पेज पर नहीं बताता। यह नंबर उतना ही सही होता है जितना इसके पीछे का अट्रिब्यूशन नियम, और ज्यादातर डैशबोर्ड यह नहीं बताते कि उन्होंने कौन-सा नियम इस्तेमाल किया।
तो यह पोस्ट बताती है कि ये टूल्स क्या करते हैं, और किसी पर भी भरोसा करने से पहले कौन-सा एक मेथडोलॉजी सवाल पूछना चाहिए। सिर्फ ट्रैकिंग मैकेनिक्स के लिए, App Store रिफंड कैसे ट्रैक करें Apple वाले पक्ष पर और गहराई से बताता है।
मुख्य बातें
कोहॉर्ट अट्रिब्यूशन, पीरियड अट्रिब्यूशन से बेहतर है। रिफंड को उस महीने के हिसाब से गिनें जब खरीदारी हुई थी, न कि जिस महीने रिफंड आया।
रिफंड में हफ्तों की देरी हो सकती है, कभी-कभी पूरा बिलिंग पीरियड भी। कोई भी डैशबोर्ड जो इस महीने की रेट दिखा रहा है, वह अधूरी रेट दिखा रहा है।
चार्जबैक, रिफंड नहीं होते। RevenueCat साफ तौर पर कहता है कि वह इसे रिफंड नहीं मानता, इसलिए आपको एक अलग फीड की जरूरत है।
स्टोर कंसोल फ्री हैं लेकिन ट्रेंड के लिए कमजोर। Apple आपको रिपोर्ट्स देता है, Google एक ऐसा API जिसकी डेली कैप है।
मोबाइल ऐप रिफंड रेट ट्रैक करने के लिए सबसे अच्छे टूल्स वही हैं जो अपना डिनॉमिनेटर पब्लिश करते हैं।
पहले, परिभाषा की समस्या
ऐप रिफंड रेट ट्रैकिंग करने के दो तरीके हैं, और दोनों एक-दूसरे से अलग नतीजे देते हैं।
पीरियड मेथड: मार्च में आए रिफंड्स को मार्च में बिल हुए ट्रांजैक्शंस से भाग दें। बनाना आसान है। लेकिन गलत है, क्योंकि मार्च का रिफंड अक्सर जनवरी की खरीदारी से जुड़ा होता है।
कोहॉर्ट मेथड: जनवरी में बिल हुई हर चीज में से, अब तक कितना हिस्सा रिफंड हुआ है। यह मुश्किल है, क्योंकि यह नंबर कभी स्थिर नहीं रहता।
Apphud इसे ईमानदारी से डॉक्यूमेंट करता है। उनका डिनॉमिनेटर उस पीरियड में बिल हुए ट्रांजैक्शंस हैं, और न्यूमरेटर है कि बाद में कितने रिफंड हुए, यहां तक कि पीरियड बंद होने के बाद भी। यही कोहॉर्ट अप्रोच है, और यह रिफंड के व्यवहार से मेल खाता है।
इसलिए आपको एक कटऑफ चाहिए। मंथली सब्सक्रिप्शंस लगभग 30 से 45 दिन में स्थिर हो जाते हैं, जबकि एनुअल प्लान महीनों तक बदलते रहते हैं। 10 दिन पुराने नंबर की तुलना 90 दिन पुराने नंबर से करना सिर्फ शोर की तुलना करना है।
फ्री टियर: स्टोर कंसोल
यहां से शुरू करें। इसकी कोई लागत नहीं है, और ज्यादातर टीमें यहीं रुक जाती हैं।
App Store Connect. Sales and Trends के साथ Financial Reports आपको रिफंड्स की जानकारी देंगे, और फाइनेंशियल रिपोर्ट आपके पेआउट से मेल खाती है। यह पीरियड-बेस्ड है, मैनुअल है, और इसमें प्रोडक्ट या चैनल के हिसाब से सेगमेंटेशन नहीं है। मंथली सैनिटी चेक के लिए ठीक है। यह पता लगाने के लिए बेकार है कि कौन-सा पेवॉल रेवेन्यू खो रहा है।
बेहतर फ्री फीड कंसोल में है ही नहीं। Apple का Get Refund History एंडपॉइंट हर कस्टमर के लिए हर रिफंड हुए ट्रांजैक्शन की पेजिनेटेड लिस्ट देता है, जिसे आप अपने वेयरहाउस में ला सकते हैं। यह रेट-लिमिटेड है, और Apple पोलिंग के बजाय नोटिफिकेशंस की सलाह देता है, इसलिए इसे रीकंसिलिएशन के तौर पर इस्तेमाल करें।
Google Play Console. यहां भी फाइनेंशियल रिपोर्ट्स हैं, साथ ही Voided Purchases API, जो किसी समय अवधि में रिफंड हुई, चार्जबैक हुई या रिवोक हुई खरीदारियों की लिस्ट देता है। यह रोजाना 6,000 कॉल्स और हर 30 सेकंड में 30 कॉल्स तक सीमित है, इसलिए यह शेड्यूल्ड स्वीप के लिए बना है, किसी लाइव काम के लिए नहीं।
ट्रेंड के काम के लिए दोनों कंसोल में एक जैसी कमी है। वे यह बताते हैं कि क्या सेटल हुआ, न कि क्या रिक्वेस्ट किया गया था, इसलिए आपको कभी पता नहीं चलता कि आपने कितनी रिक्वेस्ट्स को सफलतापूर्वक रोका।
RevenueCat
अगर आपके सब्सक्रिप्शंस पहले से इसी के जरिए चलते हैं, तो यह डिफॉल्ट जवाब है।
रिफंड रेट उनके बेंचमार्क मेट्रिक्स में से एक है: पेड सब्सक्रिप्शंस का वह हिस्सा जो उनके पहले बिलिंग पीरियड के दौरान रिफंड हुआ, जिसकी तुलना आपके स्टोर और कैटेगरी के अन्य ऐप्स से की जाती है। यह बेंचमार्किंग ही काम की चीज है, क्योंकि बिना किसी तुलनात्मक संदर्भ के सिर्फ एक रॉ रेट पर कार्रवाई करना मुश्किल होता है। उनकी State of Subscription Apps रिपोर्ट 75,000 से ज्यादा ऐप्स को कवर करती है और मीडियन को लगभग 3% से 5% बताती है।
इसमें एक App Store Refund Requests चार्ट भी है जो ग्रांटेड, डिक्लाइंड, रिवर्स्ड और रिजॉल्यूशन का इंतजार कर रहे मामलों को अलग-अलग दिखाता है। यह रिक्वेस्ट-लेवल डेटा है, जिसे ज्यादातर टूल्स छोड़ देते हैं।
दो बातें ध्यान देने लायक हैं। Play पर जो रिफंड आपकी बजाय Google द्वारा दिए जाते हैं, उन्हें दिखने में 24 घंटे तक लग सकते हैं, और जिन रिफंड्स में revoke बॉक्स टिक नहीं किया गया, वे बिल्कुल भी डिटेक्ट नहीं होते। और RevenueCat चार्जबैक को रिफंड नहीं मानता। प्रचेज स्टेटस अपडेट होता है, लेकिन रिफंड रेट नहीं बदलती।
Adapty
ज्यादातर टूल्स की तुलना में सेगमेंटेशन में बेहतर। रिफंड ट्रैकिंग को दिन, प्लान, प्रोडक्ट और एक्विजिशन चैनल के हिसाब से बांटा जाता है, और यही वह ब्रेकडाउन है जो असल में समस्याएं ढूंढता है। अगर कोई रेट ओवरऑल ठीक दिखे लेकिन किसी एक चैनल पर बहुत खराब हो, तो यह मैसेजिंग की गड़बड़ी है, प्रोडक्ट की नहीं।
उनके बेंचमार्क 11,000 से ज्यादा ऐप्स में ट्रैक किए गए $1.9 बिलियन रेवेन्यू से आते हैं, और कैटेगरी के बीच का फर्क इतना बड़ा है कि मायने रखता है: एजुकेशन और हेल्थ लगभग 4.7% से 5.1%, ट्रैवल और यूटिलिटीज लगभग 1.5% से 2.1%। एनुअल प्लान, वीकली प्लान से ज्यादा रिफंड होते हैं। हार्ड पेवॉल्स की रेट करीब 5.8% है, जबकि फ्रीमियम की 3.4%।
दिक्कत वही है जो उनके प्रोडक्ट में और जगह भी है: अच्छे एनालिटिक्स यह मान लेते हैं कि आप Adapty SDK पर हैं।
Apphud
छोटा, सस्ता, और मेथडोलॉजी को लेकर असामान्य रूप से स्पष्ट, जिस वजह से मैं इसे सिर्फ इसी कारण शॉर्टलिस्ट करूंगा। उनके डॉक्स कोहॉर्ट लॉजिक को छिपाने के बजाय साफ-साफ बताते हैं। रियल-टाइम डैशबोर्ड्स, लगभग 18 सब्सक्रिप्शन इवेंट्स, और बाकी विकल्पों की तुलना में कम मार्केटिंग।
अगर आपको एक ऐसा नंबर चाहिए जिसे आप बोर्ड मीटिंग में सही ठहरा सकें, तो स्पष्टता एक लंबी फीचर लिस्ट से बेहतर है।
डेडिकेटेड रिफंड और चार्जबैक ट्रैकिंग
यहीं पर कमी है। सब्सक्रिप्शन प्लेटफॉर्म्स सिर्फ उन रिफंड्स को गिनते हैं जो सेटल हो चुके हैं। कोई भी रिस्पॉन्स विंडो के अंदर मौजूद नहीं होता, इसलिए कोई भी आपको यह नहीं बता सकता कि आपने कितनी रिक्वेस्ट्स को सफलतापूर्वक रोका, या रिफंड रीजन के हिसाब से आपकी विन रेट क्या है।
यह एक अलग डेटासेट है, और यह तभी मौजूद होता है जब कोई चीज रिक्वेस्ट्स का जवाब दे रही हो। Refund Sensor Apple रिफंड रिक्वेस्ट्स और Google Play चार्जबैक रिव्यूज़ को केस के रूप में ट्रैक करता है, टाइमलाइन, नतीजों और बचाए गए रेवेन्यू के साथ, दोनों स्टोर एक ही डैशबोर्ड में। यह उन रिक्वेस्ट्स को दिखाता है जो कभी रिफंड नहीं बनीं।
इन्हें साथ में इस्तेमाल करना फायदेमंद है, एक को दूसरे से बदलना नहीं। कोहॉर्ट एनालिटिक्स के लिए सब्सक्रिप्शन प्लेटफॉर्म, और रिक्वेस्ट-लेवल ट्रेंड्स के लिए मोबाइल ऐप रेवेन्यू प्रोटेक्शन सॉफ्टवेयर। ये अलग-अलग सवाल हैं, और कोई भी दूसरे को कवर नहीं करता।
चार्जबैक को अलग से ट्रैक करना
चार्जबैक ट्रेंड्स, रिफंड ट्रेंड्स का हिस्सा नहीं हैं, और इन्हें एक मानना वह सबसे आम गलती है जो मैं मोबाइल ऐप्स के रिफंड ट्रैकिंग में देखता हूं।
Google Play पर सिग्नल अलग होते हैं। Real-time developer notifications कुछ वॉयड होने पर voidedPurchaseNotification भेजते हैं, और जब किसी चार्जबैक पर आपके इनपुट की जरूरत होती है तो pendingRefundReviewNotification भेजते हैं। Voided Purchases API में एक voidedReason फील्ड होता है जिसमें नौ वैल्यूज़ होती हैं, जिनमें fraud, friendly_fraud और chargeback शामिल हैं। यह एक फ्री चार्जबैक ट्रेंड लाइन के सबसे करीब की चीज है।
Apple पर यह एक REFUND नोटिफिकेशन होता है जिसमें रिवोकेशन रीजन होता है, साथ ही उन मामलों के लिए REFUND_DECLINED और REFUND_REVERSED जो टिक नहीं पाए।
एक सही चार्जबैक ट्रेंड के लिए, समय के साथ voidedReason को chargeback के बराबर प्लॉट करें, प्रोडक्ट के हिसाब से बांटकर। फिर fraud और friendly_fraud को अलग से प्लॉट करें, क्योंकि ये अकाउंट्स बार-बार आते हैं और इनके लिए अलग रिस्पॉन्स चाहिए। हमने बताया है कि कौन-सी फीड क्या करती है Voided Purchases API versus real-time developer notifications में।
मोबाइल ऐप्स में रिफंड रेट और चार्जबैक कैसे ट्रैक करें
वह स्टैक जो मैं असल में बनाऊंगा, क्रम में:
एक अट्रिब्यूशन रूल चुनें और उसे लिखकर रखें: कोहॉर्ट, जिसमें हर प्लान लेंथ के लिए एक तय कटऑफ हो।
स्टोर फीड्स सेट करें। App Store Server Notifications V2, और Play पर RTDN। इनके बिना आप सिर्फ मंथली CSVs पढ़ रहे होंगे।
हर रिफंड इवेंट को ओरिजिनल ट्रांजैक्शन के खिलाफ स्टोर करें, आज की तारीख के खिलाफ नहीं।
रिक्वेस्ट-लेवल इवेंट्स जोड़ें, वरना आपको कभी पता नहीं चलेगा कि आपने क्या रोका।
चार्जबैक को उनके अपने रीजन कोड्स के साथ अलग करें।
अपनी कैटेगरी के मुकाबले बेंचमार्क करें, किसी ग्लोबल औसत के मुकाबले नहीं।
स्टेप 3 वह जगह है जहां खुद बनाए गए सेटअप चुपचाप टूट जाते हैं, और स्टेप 6 वह जगह है जहां डैशबोर्ड चुपचाप गुमराह करते हैं। दोनों मुश्किल नहीं हैं। दोनों को ही नजरअंदाज कर दिया जाता है।
रेट वाले पक्ष के बजाय लागत वाले पक्ष के लिए, रिफंड असल में आपके ऐप रेवेन्यू को कैसे नुकसान पहुंचाते हैं वह गणना करता है। सिर्फ एक रेट यह नहीं बताती कि आगे क्या करना है।
स्रोत
अक्सर पूछे जाने वाले प्रश्न
अगर आपको कैटेगरी बेंचमार्क और रिक्वेस्ट-लेवल Apple चार्ट चाहिए तो RevenueCat। अगर आपको चैनल और प्लान के हिसाब से सेगमेंटेशन चाहिए तो Adapty। अगर आपको सबसे स्पष्ट पब्लिश्ड मेथडोलॉजी चाहिए तो Apphud। अगर आप उन रिक्वेस्ट्स को भी देखना चाहते हैं जो कभी रिफंड नहीं बनीं, तो एक डिफेंस टूल जोड़ें।
रिफंड हुए ट्रांजैक्शंस को पेड ट्रांजैक्शंस से भाग दें, जो उस पीरियड को अट्रिब्यूट हो जिसमें खरीदारी हुई थी। फिर यह तय करें कि आप किसी कोहॉर्ट को फाइनल मानने से पहले कितना समय दें। मंथली प्लान के लिए, 30 से 45 दिन। एनुअल के लिए, ज्यादा समय।
सब्सक्रिप्शन ऐप्स के लिए पेड ट्रांजैक्शंस का 2% से 5% के बीच। एजुकेशन, हेल्थ और फिटनेस में यह ज्यादा होती है, ट्रैवल और यूटिलिटीज में कम। अगर यह 10% से ज्यादा हो जाए, तो मार्केटिंग देखना बंद करें और अपना पेवॉल पढ़ें।
ठीक से नहीं। Apple की फाइनेंशियल रिपोर्ट्स वे रिफंड दिखाती हैं जो सेटल हो चुके हैं। Google का Voided Purchases API रीजन कोड के साथ वॉयड हुई खरीदारियां दिखाता है, जो सबसे करीब की चीज है, लेकिन यह रोजाना 6,000 कॉल्स तक सीमित है और इसके लिए एक शेड्यूल्ड स्वीप चाहिए।
लगभग हमेशा अट्रिब्यूशन लैग की वजह से। रेवेन्यू रिपोर्ट्स पीरियड-बेस्ड होती हैं, जबकि रिफंड रेट कोहॉर्ट-बेस्ड होनी चाहिए, और दोनों तभी मेल खाते हैं जब हर रिफंड आ चुका हो। यह भी जांचें कि क्या चार्जबैक शामिल हैं, क्योंकि कुछ टूल्स उन्हें बाहर रखते हैं।
Apple कोई थ्रेशहोल्ड पब्लिश नहीं करता, और अगर कोई इसे भरोसे से बताए तो मुझे उस पर शक होगा। जो डॉक्यूमेंटेड है वह यह है कि लगातार ऊंची रिफंड और डिस्प्यूट रेट Google Play पर अकाउंट की स्थिति को प्रभावित कर सकती है। यह रेट से ज्यादा ट्रेंड को ट्रैक करने का एक मजबूत कारण है।
