Google Play प्रोडक्शन एक्सेस पर "More testing required": ईमेल का मतलब और दोबारा अप्लाई का तरीका (2026)

Google Play का "More testing required to access Google Play production" ईमेल बताता है कि Google ने आपका प्रोडक्शन एक्सेस आवेदन ठुकरा दिया है। यह कोई पॉलिसी स्ट्राइक नहीं है और इससे आपका ऐप सस्पेंड नहीं होता। लेकिन इससे समय ज़रूर जाता है: दोबारा अप्लाई करने से पहले आपको क्लोज़्ड टेस्टिंग का एक और 14-दिन का दौर चलाना होगा। यह गाइड ईमेल के हर कारण को समझाती है, बताती है कि अतिरिक्त 14 दिनों में क्या बदलना है, और दिखाती है कि प्रश्नावली को कैसे दोबारा लिखें ताकि आपका दूसरा आवेदन ही आख़िरी हो। अगर आपने अभी तक क्लोज़्ड टेस्ट शुरू नहीं किया है, तो हमारे 12 टेस्टर, 14 दिन वाले टेस्ट प्लान से शुरुआत करें।

"More testing required to access Google Play production" का क्या मतलब है?

इसका मतलब है कि Google के एक रिव्यूअर ने आपका Apply for production अनुरोध पढ़ा और तय किया कि आपके क्लोज़्ड टेस्ट से यह साबित करने लायक सबूत नहीं मिला कि ऐप पब्लिक के लिए तैयार है। जब तक आप और टेस्टिंग करके दोबारा अप्लाई नहीं करते, प्रोडक्शन और प्री-रजिस्ट्रेशन लॉक रहते हैं।

नवंबर 2026 तक, Google की ऐप टेस्टिंग आवश्यकताएँ 13 नवंबर 2023 के बाद बने पर्सनल डेवलपर अकाउंट पर लागू होती हैं। इन अकाउंट को "अपने ऐप के लिए कम से कम 12 ऐसे टेस्टर्स के साथ क्लोज़्ड टेस्ट चलाना होगा जो लगातार कम से कम 14 दिनों से ऑप्ट-इन हों।" ये संख्याएँ पूरी करने से आपको सिर्फ़ अप्लाई करने का हक़ मिलता है। आवेदन की खुद समीक्षा होती है, और Google दो कारण बताता है जिनकी वजह से आपको और टेस्टिंग करनी पड़ सकती है: "12 से कम ऑप्ट-इन टेस्टर होना या टेस्टिंग अवधि के दौरान टेस्टर्स का अपर्याप्त एंगेजमेंट।" Google कहता है कि समीक्षा में "आम तौर पर सात दिन या उससे कम लगते हैं, लेकिन कभी-कभी ज़्यादा समय लग सकता है," और अकाउंट ओनर को फ़ैसला ईमेल से मिलता है।

रिजेक्शन ईमेल के हर कारण का क्या मतलब है?

ईमेल की हर लाइन एक ख़ास कमी की ओर इशारा करती है: ऐसे टेस्टर जिन्होंने ऐप को सच में इस्तेमाल नहीं किया, ऐसा टेस्ट जिसमें फ़ीडबैक के जवाब में कोई बदलाव नहीं दिखा, या प्रश्नावली के ऐसे जवाब जो परखने लायक ठोस नहीं थे। ईमेल में एक, दो या तीनों कारण हो सकते हैं।

जिन डेवलपर्स ने यह ईमेल सार्वजनिक रूप से पोस्ट किया है, वे एक जैसे कारण बताते हैं: "Testers were not engaged with your app during your closed test" (आपके क्लोज़्ड टेस्ट के दौरान टेस्टर्स ऐप से एंगेज नहीं थे), "You didn't follow testing best practices, which may include gathering and acting on user feedback through updates to your app" (आपने टेस्टिंग की बेस्ट प्रैक्टिस नहीं अपनाईं, जिनमें यूज़र फ़ीडबैक इकट्ठा करना और ऐप अपडेट के ज़रिए उस पर अमल करना शामिल हो सकता है), और ऐप, क्लोज़्ड टेस्ट या प्रोडक्शन की तैयारी के बारे में ऐसे जवाब जो "incomplete or insufficient" (अधूरे या अपर्याप्त) थे। आख़िरी निर्देश होता है: "Before applying again, test your app using closed testing for an additional 14 days with real testers." (दोबारा अप्लाई करने से पहले असली टेस्टर्स के साथ अतिरिक्त 14 दिन क्लोज़्ड टेस्टिंग करें।) Google यह प्रकाशित नहीं करता कि वह एंगेजमेंट कैसे मापता है, इसलिए नीचे की टेबल हर कारण को Google के अपने हेल्प पेज के संबंधित टेक्स्ट और उसके समाधान से जोड़ती है।

रिजेक्शन के तुरंत बाद आपको क्या करना चाहिए?

क्लोज़्ड टेस्ट चालू रखें, अपने टेस्टर्स से ऑप्ट-इन बने रहने को कहें, और कुछ ही दिनों में नया क्लोज़्ड-ट्रैक बिल्ड शिप करें। Google का पेज कहता है कि अगर आपको मंज़ूरी नहीं मिलती, तो "आपको अपना क्लोज़्ड टेस्ट जारी रखना पड़ सकता है," इसलिए उसे बंद करके नया शुरू करने से आपका टेस्टर बेस बेकार हो जाता है।

1. क्लोज़्ड ट्रैक या टेस्टर लिस्ट न हटाएँ। Google चेतावनी देता है कि "अगर कोई टेस्टर ऑप्ट-आउट करता है और बाद में दोबारा ऑप्ट-इन करता है, तो 14 दिन लगातार होने चाहिए," इसलिए अभी छोड़ने वाले हर टेस्टर की अपनी गिनती फिर से शुरू हो जाती है।
2. हर टेस्टर को मैसेज करें। समझाएँ कि टेस्ट 14 दिन और चलेगा, उन्हें ऑप्ट-इन बने रहना है, और इस बार आप उनसे क्या आज़माने को कह रहे हैं।
3. Play Console में टेस्टर्स की गिनती जाँचें। जिन्होंने कभी ऐप इंस्टॉल नहीं किया, उनकी जगह ऐसे लोग लें जो सच में ऐप इस्तेमाल करेंगे। जो दोस्त ऐप इंस्टॉल करके कभी खोलते नहीं, वही आम तौर पर "not engaged" कारण की वजह बनते हैं।
4. एक फ़ीडबैक चैनल तय करें। Google ग्रुप चैट का सुझाव देता है; शेयर किया गया फ़ॉर्म भी काम करता है। जो भी चुनें, हर मैसेज तारीख़ के साथ सेव करें।
5. हर मुख्य फ़ीचर को कवर करने वाली टास्क लिस्ट लिखें: साइन अप, मुख्य एक्शन, सेटिंग्स, ख़रीदारी (अगर ऐप में बिलिंग है तो लाइसेंस टेस्टर्स के साथ) और कोई भी ऑफ़लाइन या नोटिफ़िकेशन फ़्लो।
6. पहले हफ़्ते में एक क्लोज़्ड-ट्रैक अपडेट शिप करें जो किसी टेस्टर की बताई समस्या ठीक करे, और रिलीज़ नोट्स में उस फ़िक्स का नाम लिखें। दिन 14 से पहले दूसरे अपडेट की योजना बनाएँ।
7. प्री-लॉन्च रिपोर्ट चलाएँ और उसमें मिले क्रैश और एक्सेसिबिलिटी चेतावनियाँ ठीक करें।
8. दोबारा अप्लाई करने से पहले जाँच लें कि आपकी कंटेंट रेटिंग, टारगेट ऑडियंस और Data safety फ़ॉर्म सही हैं। अगर ऐप में लॉगिन ज़रूरी है, तो Google के पेज के अनुसार "मान्य, काम करने वाले लॉगिन क्रेडेंशियल" शामिल करें।

अगर लाइव होने से पहले आपके ऐप को टारगेट SDK भी बढ़ाना है, तो वह इसी अवधि में कर लें। हमारी टारगेट API लेवल 36 गाइड 1 नवंबर 2026 की डेडलाइन को कवर करती है।

प्रोडक्शन एक्सेस प्रश्नावली के जवाब दोबारा कैसे लिखें?

सामान्य बातों की जगह ठोस जानकारी लिखें: टेस्टर्स ने कौन से फ़ीचर इस्तेमाल किए, कितनी रिपोर्ट आईं, आपने उन्हें कैसे इकट्ठा किया, किस वर्ज़न में क्या ठीक हुआ, और किस सबूत से पता चला कि ऐप स्थिर है। हर जवाब ऐसा होना चाहिए जिसे सिर्फ़ असली टेस्ट चलाने वाला डेवलपर ही लिख सके।

आप यह फ़ॉर्म Play Console के Dashboard से Apply for production के ज़रिए खोलते हैं। इसके तीन हिस्से हैं: आपका क्लोज़्ड टेस्ट, आपका ऐप, और प्रोडक्शन के लिए आपकी तैयारी। अगर आप Next पर क्लिक करने से पहले किसी हिस्से को छोड़ देते हैं तो प्रगति खो जाती है, इसलिए पहले किसी डॉक्यूमेंट में जवाबों का ड्राफ़्ट बना लें। itch.io पर एक डेवलपर ने "हर जवाब के लिए 300 कैरेक्टर की सीमा" बताई, जो पहले से ड्राफ़्ट बनाकर छोटा करने की एक और वजह है। भाग 2 के जवाब सार्वजनिक रूप से नहीं दिखाए जाते और आपके ऐप की विज़िबिलिटी पर असर नहीं डालते।

एक काल्पनिक हैबिट-ट्रैकर ऐप का उदाहरण। कमज़ोर जवाब उन आवेदनों में आम हैं जो "incomplete or insufficient" के साथ लौटते हैं:

"more testing" रिजेक्शन के बाद दूसरे डेवलपर्स ने क्या बताया है?

सार्वजनिक रिपोर्टों में एक पैटर्न दिखता है: जो टेस्टर ऑप्ट-इन तो हुए लेकिन कभी फ़ीडबैक नहीं भेजा, उनसे रिजेक्शन मिला, जबकि फ़ीडबैक भेजने वाले और ऐप में बदलाव देखने वाले छोटे ग्रुप को मंज़ूरी मिली। टेस्टर्स की संख्या से ज़्यादा इस्तेमाल का सबूत मायने रखता था।

• MIT App Inventor कम्युनिटी पर डेवलपर shigeki_suzuki ने जुलाई 2024 में बताया कि उनका ऐप Season Clock एक टेस्टर-एक्सचेंज ऐप के ज़रिए 14 दिनों तक 20 टेस्टर्स तक पहुँचा, फिर उन्हें "Testers were not engaged with your app during your closed test" के साथ "More testing required to access Google Play production" मिला। उन्होंने लिखा कि उन्हें पता नहीं था कि टेस्टर कौन थे और कोई फ़ीडबैक नहीं मिला था, इसलिए वे न तो टेस्टिंग का हाल बता सके और न ही यह कि क्या बदला। उन्हें टेस्ट दोहराना पड़ा।
• Adalo फ़ोरम पर यूज़र siang32195 ने अगस्त 2024 में रिक्रूट किए गए टेस्टर्स इस्तेमाल करने के बाद वही "More testing required" मैसेज मिलने की बात बताई। उन्होंने पूछा कि कैसे पुष्टि करें कि टेस्टर्स ने सच में ऐप इस्तेमाल किया। जवाब में टाइम-ट्रैकिंग टूल या ऐसी लिखित रिपोर्ट का सुझाव दिया गया जिसमें हर टेस्टर के कवर किए गए टेस्ट सिनेरियो हों। थ्रेड में यह नहीं बताया गया कि दूसरा आवेदन सफल हुआ या नहीं।
• itch.io पर लिखने वाले एक सोलो गेम डेवलपर के पास "मुश्किल से 12 टेस्टर" थे, लेकिन उन्होंने लिखा कि उन्होंने "गेम में कई अपडेट किए" और "टेस्टर्स के साथ अपनी बातचीत से जो कुछ हो सका, सब रिकॉर्ड किया।" उन्होंने आवेदन में उसी रिकॉर्ड का इस्तेमाल किया और बताया: "आवेदन भेजने के 36 घंटों के भीतर मुझे प्रोडक्शन एक्सेस मिल गया।"

तुलना साफ़ है: बिना फ़ीडबैक रिकॉर्ड वाले 20 टेस्टर्स को रिजेक्ट किया गया, जबकि फ़ीडबैक और अपडेट के दस्तावेज़ी रिकॉर्ड वाले 12 टेस्टर्स को मंज़ूरी मिली। दोबारा तब अप्लाई करें जब आपके नोट्स प्रश्नावली के हर फ़ील्ड का ठोस जवाब दे सकें, न कि दिनों की गिनती 14 होते ही।

Apply for production पर दोबारा कब क्लिक करना चाहिए?

दोबारा तब अप्लाई करें जब कम से कम 12 टेस्टर लगातार अगले 14 दिनों तक ऑप्ट-इन रहे हों और आपने उस दौरान फ़ीडबैक पर आधारित अपडेट शिप किए हों। Google के पेज में किसी प्रतीक्षा अवधि का ज़िक्र नहीं है, लेकिन वही सबूत लेकर अप्लाई करने पर वही जवाब मिलने की संभावना है।

• कम से कम 12 टेस्टर, बिना किसी ऑप्ट-आउट गैप के, लगातार अगले 14 दिनों तक ऑप्ट-इन (बफ़र के लिए 15 या ज़्यादा का लक्ष्य रखें)
• रिजेक्शन के बाद कम से कम दो क्लोज़्ड-ट्रैक रिलीज़, हर एक के रिलीज़ नोट्स में टेस्टर की बताई किसी समस्या के फ़िक्स का नाम
• तारीख़ वाला फ़ीडबैक लॉग, जिसमें प्रकार के अनुसार संख्या (बग, UX, अनुरोध) और हर आइटम कैसे इकट्ठा हुआ, यह दर्ज हो
• ऐसे टेस्टर जिन्होंने हर मुख्य फ़ीचर इस्तेमाल किया, जहाँ लागू हो वहाँ लॉगिन, ख़रीदारी और नोटिफ़िकेशन सहित
• बिना किसी अनसुलझे क्रैश वाली प्री-लॉन्च रिपोर्ट
• सही कंटेंट रेटिंग, टारगेट ऑडियंस और Data safety फ़ॉर्म, साथ में रिव्यूअर के लिए काम करने वाले लॉगिन क्रेडेंशियल
• किसी डॉक्यूमेंट में ड्राफ़्ट किए गए प्रश्नावली के जवाब, जिनमें फ़ीचर, संख्याएँ और वर्ज़न नंबर हों

Google का पेज यह भी चेतावनी देता है कि "नियमों का पालन न करने वाले ऐप इस उम्मीद में सबमिट करना कि रिव्यूअर समस्याएँ पहचान लेंगे, रिजेक्शन, समीक्षा में देरी और लंबी अपील प्रक्रियाओं की ओर ले जाता है," इसलिए कोई भी पॉलिसी समस्या अप्लाई करने से पहले ठीक करें, बाद में नहीं। अगर आप Play Console सेटअप, क्लोज़्ड टेस्ट प्लान और आवेदन किसी और को सौंपना चाहते हैं, तो हमारी App Store सबमिशन सर्विस $599 में दोनों स्टोर कवर करती है। डेवलपर अकाउंट फ़ीस अलग से लगती है।