Android का In-App Review API: बिना परेशान किए रेटिंग माँगना

Android पर ज़्यादातर “हमें रेट करें” प्रॉम्प्ट दो बटन वाला एक कस्टम डायलॉग होते हैं: एक Play Store लिस्टिंग खोलता है, दूसरा उसे बंद कर देता है। ये ऐप लॉन्च पर या किसी मनमाने सेशन काउंट के बाद दिखते हैं, और उपयोगकर्ता जो भी असल में करने की कोशिश कर रहा था उसमें बाधा डालते हैं। जो व्यक्ति “रेट करें” पर टैप करता है वह आपके ऐप से निकलकर Play Store पर पहुँच जाता है, और अब उसे शुरू से एक रिव्यू लिखना पड़ता है — यह घर्षण उस इरादे का ज़्यादातर हिस्सा खत्म कर देता है जिसे आपने अभी-अभी पकड़ा था। जो व्यक्ति “अभी नहीं” पर टैप करता है उसने आपको कुछ नहीं बताया, और आप शायद अगले हफ्ते फिर से पूछेंगे।

Google का In-App Review API इस समस्या के मैकेनिकल हिस्से को हल करता है: एक नेटिव रेटिंग शीट जो आपके ऐप के ऊपर दिखाई देती है, उपयोगकर्ता को ऐप छोड़े बिना स्टार चुनने (और वैकल्पिक रूप से कुछ शब्द लिखने) देती है, और उसे बिल्कुल उसी जगह वापस ले जाती है जहाँ वह था। यह UX वाला हिस्सा हल नहीं करता — आप इसे कब ट्रिगर करते हैं यह अब भी इससे ज़्यादा मायने रखता है कि कैसे — लेकिन यह “कैसे” गलत करने का बहाना खत्म कर देता है।

यह असल में कैसे काम करता है

यह API Play Core (com.google.android.play:review-ktx) का हिस्सा है। आप पहले से एक ReviewInfo ऑब्जेक्ट का अनुरोध करते हैं, फिर जब दिखाने के लिए तैयार हों तब फ़्लो लॉन्च करते हैं:

val manager = ReviewManagerFactory.create(context)

manager.requestReviewFlow().addOnCompleteListener { request ->
    if (request.isSuccessful) {
        val reviewInfo = request.result
        manager.launchReviewFlow(activity, reviewInfo)
            .addOnCompleteListener {
                // The flow is finished — you don't get a signal on
                // whether the user actually rated. Treat this as "done,"
                // not "succeeded."
            }
    }
}

दो बातें लोगों को उलझा देती हैं। पहला, requestReviewFlow() चुपचाप विफल हो सकता है या बिना कोई डायलॉग दिखाए वापस आ सकता है — Google सीमित करता है कि एक ही उपयोगकर्ता को यह शीट कितनी बार दिखे (प्रति ऐप लगभग साल में एक बार, ठीक-ठीक दस्तावेज़ीकृत नहीं और आपके नियंत्रण से बाहर), इसलिए टेस्टिंग के दौरान ज़्यादातर कॉल बिना कुछ दिखाए ही पूरे हो जाएँगे। दूसरा, कम्प्लीशन कॉलबैक तब भी चलता है जब उपयोगकर्ता ने रेट किया हो, स्किप किया हो, या कोटा ने डायलॉग को पूरी तरह ब्लॉक कर दिया हो। कोई onRatingSubmitted नहीं है — जानबूझकर, ताकि ऐप्स नतीजे के आधार पर फीचर लॉक न कर सकें या बार-बार न टोक सकें।

जो हिस्सा असल में मायने रखता है: समय

API का घर्षण-रहित होना तब काम नहीं आता जब आप इसे गलत क्षण पर ट्रिगर करते हैं। सबसे आम गलती जो मैं देखता हूँ वह है onCreate() के तुरंत बाद requestReviewFlow() को कॉल करना, इस सोच के साथ कि ज़्यादा इंप्रेशन का मतलब ज़्यादा रिव्यू होता है। असल में इसका उल्टा होता है — आप उपयोगकर्ता की कोई राय बनने से पहले ही पूछ रहे हैं, और वह भी तब जब वह उसी काम के बीच में है जिसके लिए वह उस दिन ऐप में आया था।

जो क्षण काम करता है वह है ऐप के अपना काम स्पष्ट रूप से कर दिखाने के ठीक बाद। Mintly बनाते समय, यह वह क्षण है जब एक फोकस सेशन पूरा होता है और उपयोगकर्ता अपनी स्ट्रीक बढ़ती हुई देखता है — पहला सेशन नहीं, बल्कि वह जिसमें ऐप पहले ही कुछ भरोसा कमा चुका हो। कुछ ठोस नियम जो सभी ऐप श्रेणियों में लागू होते हैं:

• किसी तय सेशन गिनती पर नहीं, बल्कि पूरे हुए सकारात्मक नतीजे पर ट्रिगर करें। बजट ऐप में उपयोगकर्ता के महीने को साफ-सुथरे तरीके से मिलाने के बाद, आदत ट्रैकर में स्ट्रीक माइलस्टोन के बाद, रिमाइंडर ऐप में वाकई काम आई किसी बचत के बाद — “5वाँ सेशन” नहीं।
• किसी एरर पथ पर कभी ट्रिगर न करें। अगर अभी कुछ विफल हुआ है या उपयोगकर्ता किसी फ़्लो से बाहर निकला है, तो पूछने के लिए यह सबसे बुरा क्षण है।
• API के आपको सीमित करने के बावजूद खुद को भी सीमित करें। Google का कोटा ज़्यादातर अनुरोधों को चुपचाप बेअसर बना देता है, लेकिन आपके अपने ट्रिगर लॉजिक को फिर भी हर योग्य इवेंट पर फायर होने से बचना चाहिए — किसी उपयोगकर्ता के लिए फ़्लो एक बार पूरा हो जाने पर, उसे महीनों तक दोबारा न बुलाएँ, भले ही आपकी अपनी ट्रैकिंग यह पुष्टि न कर सके कि वह वाकई दिखा या नहीं।
• इसे कभी अपने खुद के प्री-प्रॉम्प्ट के साथ न मिलाएँ। एक कस्टम “क्या आपको ऐप पसंद आ रहा है?” डायलॉग जो असली प्रॉम्प्ट तक पहुँच को छानता है, वही दो-टैप वाला घर्षण फिर से लाता है जिसे हटाने के लिए यह API बना था, और यह आपको यह चुनने देता है कि असली प्रॉम्प्ट कौन देखे — जो ठीक वही चालबाज़ी है जिसे Play के दिशानिर्देश स्पष्ट रूप से मना करते हैं।

यह क्या नहीं कर सकता, और लोग फिर भी क्या आज़माते हैं

आप यह पता नहीं लगा सकते कि उपयोगकर्ता ने वाकई रेटिंग दी या नहीं, स्टार वैल्यू नहीं पढ़ सकते, और नाखुश उपयोगकर्ताओं को फ़्लो से दूर व खुश उपयोगकर्ताओं को फ़्लो की ओर रीडायरेक्ट नहीं कर सकते। यह आखिरी माँग आम है और यह Play की डेवलपर पॉलिसी के स्पष्ट रूप से खिलाफ है — इस API का पूरा मकसद यह है कि इसे ट्रिगर करने वाला हर व्यक्ति वही, बिना फ़िल्टर की गई शीट देखे। अगर आपको “मुश्किल समय चल रहा है?” जैसा सपोर्ट चैनल चाहिए, तो उसे रिव्यू प्रॉम्प्ट के आगे एक कांटा बनाने के बजाय एक अलग, ईमानदार फीडबैक लिंक के रूप में बनाएँ।

जानने लायक दूसरी सीमा: यह सिर्फ Play के लिए है। अन्य Android ऐप स्टोरों पर इसकी समकक्ष कोई गारंटी नहीं है, और वहाँ आप वापस मैनुअल “हमें रेट करें” लिंक या स्टोर के अपने तंत्र पर आ जाते हैं।

अपना कोटा खर्च किए बिना टेस्ट करना

चूँकि असली कोटा अपारदर्शी है, अपने प्रोडक्शन बिल्ड की बजाय Play Core के टेस्टिंग टूल्स के ज़रिए टेस्ट करें — com.google.android.play:review-ktx टेस्टिंग आर्टिफ़ैक्ट और इंटरनल ऐप-शेयरिंग ट्रैक्स आपको Google की असली थ्रॉटलिंग का इंतज़ार किए बिना फ़्लो को बार-बार ट्रिगर करने देते हैं। डेवलपमेंट के दौरान ट्रिगर को एक डिबग मेन्यू में जोड़ें ताकि आप इसे माँग पर फायर कर सकें, फिर रिलीज़ से पहले वह शॉर्टकट हटा दें। प्रोडक्शन में, हर कॉल को फायर-एंड-फॉरगेट की तरह लें: अनुरोध करें, लॉन्च करें, आगे बढ़ें, और यह तय करने दें कि शीट को असल में कौन देखेगा — यह Google के अपने लॉजिक पर छोड़ दें।