Google Play की नीति के बारे में जानकारी देने वाला एएमए

ठीक है।

Google Play की नीति को डिकोड करने के बारे में जानकारी देने वाले इस पैनल में शामिल होने के लिए, आप सभी का धन्यवाद.

मैं यान क्लाइनर्ट हूं. मैं कार के लिए Android टीम में डेवलपर रिलेशंस इंजीनियर हूं.

आज मैं इस पैनल की मॉडरेटर हूं.

अब मैं पैनल के सदस्यों, बोहदान और पॉल को अपना परिचय देने के लिए आमंत्रित करती हूं.

चलिए, बोहदान से शुरू करते हैं.

नमस्ते, दोस्तों.

मेरा नाम बोहदान है. मैं Google Play की भरोसा और सुरक्षा टीम में काम करता हूं.

मुझे यहां काम करते हुए चार साल से ज़्यादा हो गए हैं. साथ ही, मुझे टेक्नोलॉजी इंडस्ट्री में भरोसे और सुरक्षा से जुड़े मामलों में काम करने का एक दशक से ज़्यादा का अनुभव है.

मुझे यह देखना पसंद है कि टेक्नोलॉजी, इंडस्ट्री, और कल्चर एक-दूसरे से कैसे जुड़े हैं. साथ ही, इवेंट किस तरह नए ऐप्लिकेशन बनाने के लिए बढ़ावा देते हैं. मुझे इस तरह के इवेंट पसंद हैं, जहां हम आप जैसे डेवलपर को सफलता पाने में मदद करने के लिए अपना सबसे अच्छा योगदान दे सकते हैं.

सभी को नमस्ते।

मेरा नाम पॉल है.

मैं बोहडन की टीम में ही काम करता हूं. मैं भी बोहडन की तरह ही करीब एक दशक से भरोसा और सुरक्षा टीम में काम कर रहा हूं. इसमें से ज़्यादातर समय मैंने Google Play की भरोसा और सुरक्षा टीम के साथ बिताया है.

इसलिए, मुझे आज यहां स्टेज पर आकर बहुत खुशी हो रही है. चलिए, शुरू करते हैं.

ठीक है, धन्यवाद.

पैनल शुरू करने से पहले, मैं पॉल को माइक सौंपना चाहूंगा.

वे सबसे पहले नीति से जुड़े संसाधनों के बारे में खास जानकारी देंगे. साथ ही, सबसे सही तरीकों और ऐसी ही अन्य चीज़ों के बारे में बताएंगे, ताकि आपके ऐप्लिकेशन की नीति की समीक्षा आसानी से और बेहतर तरीके से हो सके.

हाँ।

तो, Google Play की नीति से हमारा क्या मतलब है?

ये बुनियादी नियम हैं. Google Play Store पर मोबाइल ऐप्लिकेशन पब्लिश और मैनेज करते समय, डेवलपर को इनका पालन करना होगा.

हमने स्क्रीन पर Play की नीति से जुड़े संसाधनों के कुछ छोटे लिंक दिए हैं.

पहले लिंक पर क्लिक करने से, डेवलपर नीति केंद्र खुलता है.

पेज पर सबसे ऊपर मौजूद, 'हाल ही के अपडेट' पर क्लिक करके, नई नीतियों के बारे में ज़्यादा जानकारी पढ़ी जा सकती है. साथ ही, मौजूदा नीतियों के अपडेट या उनके बारे में दी गई जानकारी भी पढ़ी जा सकती है.

अगर आपको विज़ुअल या ऑडियो के ज़रिए सीखना ज़्यादा पसंद है, तो दूसरे शॉर्ट लिंक पर क्लिक करें. इससे आपको हमारी Policy Bytes की प्लेलिस्ट पर रीडायरेक्ट कर दिया जाएगा.

इन वीडियो में, हम नीति से जुड़े अपडेट के बारे में बात करते हैं.

तीसरे लिंक पर क्लिक करने से, आपको एक पेज पर रीडायरेक्ट किया जाएगा. यहां आपको Android Studio में, Google Play की नीति से जुड़ी अहम जानकारी देने वाली सुविधा के बारे में ज़्यादा जानकारी मिलेगी. इस सुविधा का मकसद, Android Studio में लिंट चेक के तौर पर, समीक्षा से पहले ज़रूरी दिशा-निर्देश उपलब्ध कराना है.

ठीक है।

इसमें Android स्किल भी शामिल है. इसकी मदद से, Google Play की इन नीतियों के मुताबिक Android ऐप्लिकेशन की जांच की जा सकती है. इससे आपको यह पुष्टि करने में मदद मिलती है कि ऐप्लिकेशन, अनुमतियों, खाते को मिटाने, और डेटा की सुरक्षा से जुड़ी नीतियों का पालन कर रहा है या नहीं.

और आप इस स्किल को Android का सीएलआई का इस्तेमाल करके इंस्टॉल कर सकते हैं, ठीक वैसे ही जैसे अन्य स्किल इंस्टॉल की जाती हैं.

android skills list
android skills add play-policy-insights

इसके बाद, हम Play की नीति और ऐप्लिकेशन की समीक्षाओं के बारे में कुछ सबसे सही तरीके शेयर करेंगे. इसके बाद, हम जैन के पैनल से जुड़े कुछ सवालों के जवाब देंगे.

पहला, समीक्षकों को लॉगिन क्रेडेंशियल दें.

यह एक आसान वजह लगती है, लेकिन कॉन्टेंट का ऐक्सेस न होना, देरी या अस्वीकार होने की एक बहुत ही सामान्य वजह है.

अगर आपके ऐप्लिकेशन में लॉगिन करना ज़रूरी है या उसमें पेवॉल से सुरक्षित किया गया कॉन्टेंट, क्रेडिट या सदस्यताएं मौजूद हैं, तो आपको टेस्ट क्रेडेंशियल देने होंगे.

कुछ ऐप्लिकेशन के लिए, इसका मतलब है कि ऐप्लिकेशन के शुरू में ही लॉगिन क्रेडेंशियल देना. इसके बाद, अन्य ऐप्लिकेशन के लिए, आपके पास अलग-अलग सेक्शन हो सकते हैं. जैसे, पैसे चुकाकर लिया जाने वाला कॉन्टेंट, जिसके बारे में मैंने बताया था.

Play Console में जाकर, समीक्षा करने वाले लोगों के लिए ये लॉगिन क्रेडेंशियल उपलब्ध कराए जा सकते हैं.

इसे पहले ऐप्लिकेशन ऐक्सेस कहा जाता था, लेकिन अब इसे साइन-इन की जानकारी कहा जाता है. यह ऐप्लिकेशन कॉन्टेंट सेक्शन में मौजूद होता है.

इसके बाद, आपको यह पक्का करना होगा कि क्रेडेंशियल, दो तरीकों से पुष्टि करने की सुविधा, कैप्चा, पेवॉल वगैरह को बायपास कर सकें.

हां, पुराने वर्शन कोड बंद करें.

इसलिए, डेवलपर को अक्सर ऐसी स्थिति का सामना करना पड़ता है जिसे हम आम बोलचाल की भाषा में रिजेक्शन लूप कहते हैं. ऐसा इसलिए होता है, क्योंकि वे एक साफ़-सुथरा और नीति का पालन करने वाला प्रोडक्शन बिल्ड अपलोड करते हैं. हालांकि, वे अक्सर यह भूल जाते हैं कि नीति का पालन न करने वाला पुराना वर्शन, अब भी Play Console पर किसी दूसरे ट्रैक पर चालू है. भले ही, वह ओपन टेस्टिंग, क्लोज़्ड टेस्टिंग वगैरह हो. इसलिए, भले ही ऐप्लिकेशन बंडल किसी पुराने टेस्टिंग ट्रैक में हो, लेकिन उस पर Play की नीति की समीक्षा और Play की नीति लागू होती है.

इसलिए, अगर कोई ऐप्लिकेशन अतिरिक्त शर्तों और पाबंदियों के साथ अनुमति का अनुरोध करता है या पुराने और असुरक्षित एसडीके का इस्तेमाल करता है, तो उसकी समीक्षा की जाएगी.

इसलिए, सबमिट बटन पर क्लिक करने से पहले, पक्का करें कि आपने सभी ट्रैक पर मौजूद पुराने वर्शन कोड को बदल दिया हो या बंद कर दिया हो.

तीसरा, समीक्षाओं के लिए ज़्यादा समय दें और मैनेज करके पब्लिश करने की सुविधा का इस्तेमाल करें.

इसलिए, ऐप्लिकेशन की समीक्षा होने और उसे पब्लिश होने में सात दिन या कभी-कभी इससे ज़्यादा समय लग सकता है. ऐसा खास तौर पर तब होता है, जब कोई नया ऐप्लिकेशन हो या कोई ऐसा ऐप्लिकेशन हो जो संवेदनशील जानकारी ऐक्सेस करने की अनुमति मांग रहा हो.

इसलिए, आपको उन्हें काफ़ी लीड समय देना चाहिए.

अगर आपको कोई बड़ा ऐप्लिकेशन लॉन्च करना है, तो उसे लॉन्च की असल तारीख से कम से कम दो हफ़्ते पहले सबमिट करें.

इसके बाद, इसे मैनेज करके पब्लिश करने की सुविधा से लिंक किया जा सकता है.

मैनेज करके पब्लिश करने की सुविधा की मदद से, अनुमति पा चुके अपडेट को तब तक रोका जा सकता है, जब तक आप उन्हें रिलीज़ करने के लिए तैयार न हों. इससे मार्केटिंग कैंपेन या अन्य संवेदनशील लॉन्च के दौरान, अचानक होने वाली देरी से बचा जा सकता है.

ऐसा करते समय, आपको यह पक्का करना होगा कि समीक्षा के लिए सबमिट किए गए ऐप्लिकेशन को फिर से सबमिट न किया जाए.

ऐसा करने पर, घड़ी फिर से शुरू हो जाती है.

मुझे लगता है कि डेवलपर कभी-कभी इस बारे में भूल जाते हैं. वे ऐप्लिकेशन को आधा ही बनाते हैं और भूल जाते हैं कि "अरे, मुझे यह छोटा सा बदलाव करना है."

इसके बाद, वे इसे फिर से सबमिट करते हैं और समीक्षा की प्रोसेस फिर से शुरू हो जाती है.

ठीक है, अपने एलान देखें.

इसलिए, आपके ऐप्लिकेशन के कॉन्टेंट से जुड़े एलान, सभी ट्रैक पर मौजूद ऐक्टिव बंडल या वर्शन कोड के ऐप्लिकेशन मेनिफ़ेस्ट से मेल खाने चाहिए. जैसे, डेटा की सुरक्षा वाला सेक्शन, निजता नीति या फ़ोटो/वीडियो से जुड़ी अनुमतियां.

उदाहरण के लिए, अगर आपका ऐप्लिकेशन मेनिफ़ेस्ट, जगह की सटीक जानकारी ऐक्सेस करने का अनुरोध करता है, लेकिन अनुमतियों के एलान का फ़ॉर्म में इसके मकसद के बारे में नहीं बताया गया है, तो हो सकता है कि ऐप्लिकेशन पर नीति उल्लंघन ठीक करने का तरीका लागू किया जाए. ऐसा होने की संभावना बहुत ज़्यादा है.

इसलिए, पक्का करें कि तीसरे पक्ष के एसडीके, ऐसे डेटा को ट्रांसफ़र न कर रहे हों जिसके बारे में आपने एलान नहीं किया है.

भले ही आपका ऐप्लिकेशन किसी खास डेटा का इस्तेमाल न करता हो, लेकिन अगर आपने कोई ऐसा एसडीके इंटिग्रेट किया है जो उस डेटा का इस्तेमाल करता है, तो इससे नीति उल्लंघन ठीक करने का तरीका लागू हो सकता है.

इसलिए, Google Play एसडीके इंडेक्स देखें. इससे आपको 100 से ज़्यादा ऐसे कमर्शियल एसडीके के बारे में अहम जानकारी मिलेगी जो सबसे ज़्यादा इस्तेमाल किए जाते हैं.

आगे बढ़ने से पहले, मैं एक सवाल पूछना चाहूंगा.

नीति उल्लंघन ठीक करने के तरीकों से आपका क्या मतलब है?

इस शब्द का क्या मतलब है?

नीति उल्लंघन ठीक करने के तरीकों (एनफ़ोर्समेंट) में, कोई भी सख्त कार्रवाई शामिल हो सकती है. जैसे, चेतावनी देना, कॉन्टेंट को अस्वीकार करना, कॉन्टेंट को हटाना, खाते को निलंबित करना या खाते पर पाबंदी लगाना.

इसलिए, जब मैं नीति उल्लंघन ठीक करने के तरीकों की बात करता हूं, तो मेरा मतलब इन कार्रवाइयों से होता है.

चलिए.

धन्यवाद.

हाँ।

इसके बाद, अपील करें.

ऐप्लिकेशन अस्वीकार होने के बाद, उसका वही वर्शन फिर से सबमिट न करें.

इसके अलावा, कम समय में एक ही समस्या की वजह से बार-बार अस्वीकार किए जाने पर, एल्गोरिदम से जुड़ा फ़्लैग ट्रिगर हो सकता है. इससे, नीति उल्लंघन ठीक करने के ज़्यादा गंभीर तरीके लागू हो सकते हैं. इनके बारे में पॉल ने बताया है. जैसे, ऐप्लिकेशन हटाना या उसे निलंबित करना.

इसलिए, अगर कोई ऐप्लिकेशन अस्वीकार कर दिया जाता है, तो उसे बिना कोई बदलाव किए, अनुमान लगाए या सुझावों पर ध्यान दिए, तुरंत फिर से सबमिट न करें.

आपको कंसोल के इनबॉक्स और उससे जुड़े ईमेल पतों पर, उल्लंघन और उसे ठीक करने के तरीके के बारे में जानकारी मिलेगी.

अगर आप इस फ़ैसले से सहमत नहीं हैं या आपको यह समझ नहीं आया है, तो अपील करें.

अगर आपको लगता है कि आपके ऐप्लिकेशन को गलती से मैलवेयर के तौर पर फ़्लैग किया गया है, तो अपील करने के लिए ईमेल में दिए गए लिंक का इस्तेमाल करें.

यह तरीका, बिना कोई बदलाव किए वीडियो को फिर से सबमिट करने से बेहतर है.

अगर आपको कोई ईमेल मिलता है और आपको वह समझ नहीं आता है, तो हो सकता है कि उसमें बहुत ज़्यादा शब्द हों या बहुत ज़्यादा पैराग्राफ़ हों. चाहे जो भी हो, अपील पर वापस जाना बिलकुल ठीक है.

ऐसा करने पर, आपको किसी असल व्यक्ति से ईमेल पर बातचीत करने का मौका मिलेगा.

हालांकि, हो सकता है कि वे आपको पूरी जानकारी न दे पाएं, लेकिन आपको अक्सर अस्वीकार किए जाने की वजह के बारे में ज़्यादा जानकारी मिल सकती है.

कभी-कभी, अपील टीम को लगता है कि कम्यूनिकेशन काफ़ी लंबा हो सकता है.

इसलिए, वे उन सेक्शन को हाइलाइट या बोल्ड कर सकते हैं जो खास तौर पर आप पर और आपके ऐप्लिकेशन पर लागू होते हैं.

तो, हां.

अब मैं फिर से जैन को बुलाना चाहूंगा.

ठीक है।

धन्यवाद.

इसलिए, हमने अलग-अलग चैनलों और सोर्स से डेवलपर के सवाल इकट्ठा किए हैं.

इसलिए, आज हमारे पास जो सवाल हैं वे उन समस्याओं को दिखाते हैं जिनके बारे में हम अक्सर डेवलपर से सुनते हैं. ये समस्याएं नीति से जुड़ी होती हैं.

चलिए, इससे शुरुआत करते हैं.

अनुमतियों से जुड़ी ऐसी कौनसी सामान्य वजहें हैं जिनकी वजह से किसी ऐप्लिकेशन को अस्वीकार किया जा सकता है?

डेवलपर, अनुमति से जुड़ी नीति के उल्लंघन की वजह से ऐप्लिकेशन अस्वीकार होने से कैसे बच सकते हैं?

ठीक है।

अनुमतियां, मैं यह विकल्प चुनूंगा.

इसलिए, संवेदनशील जानकारी ऐक्सेस करने की अनुमतियां, आपके ऐप्लिकेशन के विज्ञापन में बताए गए मुख्य मकसद के लिए ज़रूरी होनी चाहिए.

इसलिए, अगर आपके पास कोई ऐसी सहायक सुविधा या कोई ऐसी सुविधा है जो ऐप्लिकेशन में मौजूद नहीं है और जिसका विज्ञापन भी नहीं दिया गया है, तो इस बात की काफ़ी संभावना है कि ऐप्लिकेशन को अस्वीकार कर दिया जाएगा.

इसलिए, पक्का करें कि एलान में दी गई जानकारी, ऐप्लिकेशन के इस्तेमाल के उदाहरण से मेल खाती हो.

इसके अलावा, कई बार किसी ऐप्लिकेशन को इसलिए अस्वीकार कर दिया जाता है, क्योंकि एलान में दिए गए वीडियो के लिंक ऐक्सेस नहीं किए जा सकते.

हमारी समीक्षा टीम को आपके ऐप्लिकेशन, आपके दिए गए वीडियो लिंक, और ऐप्लिकेशन में मौजूद हर चीज़ को ऐक्सेस करने की ज़रूरत होती है, ताकि ऐप्लिकेशन की पूरी समीक्षा की जा सके.

इसलिए, पक्का करें कि ऐप्लिकेशन, मेनिफ़ेस्ट, और एलान में सब कुछ ऐक्सेस किया जा सकता हो.

इसलिए, पक्का करें कि ये तीनों काम पूरे हो जाएं. इससे, प्रोसेस आसान हो जाएगी.

चलिए.

ठीक है।

इसलिए, ज़्यादा से ज़्यादा ऐप्लिकेशन डेवलपर अपने ऐप्लिकेशन में एआई से बनाए गए कॉन्टेंट के लिए, तीसरे पक्ष के प्लैटफ़ॉर्म का इस्तेमाल करने लगे हैं, है न?

अगर उन प्लैटफ़ॉर्म पर ऐसा कॉन्टेंट बनाया जाता है जो आपत्तिजनक है या तथ्यों के हिसाब से गलत है या इस तरह का कुछ और है, तो क्या डेवलपर के ऐप्लिकेशन को अस्वीकार किया जा सकता है? ऐसे मामलों में असल में ज़िम्मेदार कौन होता है?

हाँ।

हां, इस वजह से आपका आवेदन अस्वीकार हो सकता है.

Play Store की शुरुआत से ही, हमारा मानना रहा है कि ऐप्लिकेशन में मौजूद कॉन्टेंट या ऐप्लिकेशन में उपयोगकर्ता को मिलने वाले ऐक्सेस की ज़िम्मेदारी डेवलपर की होती है.

इसलिए, भले ही जेन एआई एक नया क्षेत्र है, लेकिन इसके लिए भी यही बात लागू होती है.

मुझे लगता है कि जनरेटिव एआई और यूज़र जनरेटेड कॉन्टेंट (यूजीसी) में काफ़ी समानताएं हैं. ऐसा इसलिए, क्योंकि दोनों के लिए बनी नीतियों में कई चीज़ें एक जैसी हैं. जैसे, अगर कोई कॉन्टेंट सही नहीं है, तो उसे फ़्लैग करने की सुविधा होनी चाहिए.

फ़िल्टर करने का कोई तरीका होना चाहिए.

मुझे लगता है कि इस पर अन्य नीतियां भी लागू होंगी. हालांकि, मेरा मानना है कि अगर आपके पास जेन एआई से तैयार किया गया कॉन्टेंट है, तो Google आपके ऐप्लिकेशन की समीक्षा करेगा. साथ ही, अगर उपयोगकर्ताओं को कुछ आपत्तिजनक दिखता है, तो वे उसे फ़्लैग करेंगे. इसके बाद, आपके पास फ़िल्टर करने के तरीके भी होंगे.

इसलिए, Google, डेवलपर, और उपयोगकर्ता, सभी मिलकर काम करते हैं, ताकि ऐप्लिकेशन को सभी के लिए ज़्यादा से ज़्यादा सुरक्षित बनाया जा सके.

ठीक है।

बहुत बढ़िया.

लेकिन आम तौर पर, क्या हम यह सुझाव देते हैं कि उपयोगकर्ताओं के लिए कॉन्टेंट को फ़्लैग करने के तरीकों के अलावा, डेवलपर को कुछ और भी करना चाहिए? क्या फ़िल्टर करने के तरीके से आपका यही मतलब है?

जैसे, कुछ खास तरह के कॉन्टेंट को उपयोगकर्ताओं को दिखाने से रोकना?

सही.

हाँ।

समीक्षा की प्रोसेस के दौरान, हमारी टीम आपके कोड की जांच नहीं करेगी. इसके अलावा, फ़िल्टर करने के आपके तरीके को समझने के लिए, रिवर्स इंजीनियरिंग भी नहीं करेगी.

वे बस यह देखना चाहते हैं कि क्या वे किसी ऐसे कॉन्टेंट को ऐक्सेस कर सकते हैं जो उनके लिए सही नहीं है?

अगर ऐसा हो सकता है, तो हम कुछ सुझाव भेजेंगे. इसके बाद, आपकी टीम को यह पता लगाना होगा कि वे फ़िल्टर करने के तरीके को और बेहतर कैसे बना सकते हैं.

ठीक है.

ठीक है, धन्यवाद.

इसलिए, एक नीति है जिसे किसी दूसरे के नाम पर काम करने या नकल करने से जुड़ी नीति कहा जाता है, है न?

अगर किसी ऐप्लिकेशन को किसी दूसरे के नाम पर काम करने से जुड़ी नीति के तहत अस्वीकार कर दिया जाता है, लेकिन डेवलपर को लगता है कि यह फ़ैसला गलत है, तो उसे क्या करना चाहिए?

साथ ही, वे इस तरह के अस्वीकार होने से कैसे बच सकते हैं?

अपील करें.

हां, मुझे लगता है कि यह पांचवां सबसे सही तरीका है, जो हमने बोर्ड पर दिखाया है. अगर आपको इस वजह से अस्वीकार किया जाता है, तो आपको अपील करनी चाहिए.

इसके बाद, आपको क्या करना चाहिए? आम तौर पर, ऐसा हो सकता है कि जिस ब्रैंड के नाम पर आपने चैनल बनाया है वह आपका ही ब्रैंड हो, है न?

या फिर, किसी दूसरे व्यक्ति के लिए ऐप्लिकेशन बनाया जा रहा हो. मुझे लगता है कि यह सबसे आम बात है. इसमें ऐसे डेवलपर शामिल हैं जो शायद अपनी फ़िटनेस सुविधाओं, SaaS, यानी कि किसी तरह के SaaS समाधान के लिए ऐप्लिकेशन बना रहे हैं.

इसलिए, उन्हें अपने डेवलपर खाते से पब्लिश करना आसान होता है, है न?

इसलिए, आपके पास अपील करने का विकल्प है. हमारी टीम यह देखेगी कि आपके पास अनुमति का सबूत है या नहीं.

मान लें कि आपका कोई क्लाइंट है, जिसका नाम जोज़ चिकन है. उसके पास मिसिसिपी के पश्चिम में सबसे अच्छा चिकन मिलता है.

वे आपको अनुमति का सबूत देने वाला एक पत्र देंगे. यह पत्र, कंपनी के आधिकारिक लेटरहेड पर होगा और इस पर कंपनी का लोगो भी होगा. इसमें लिखा होगा कि हम, Joe's Chicken, ABC Developer को अपने ऐप्लिकेशन में हमारी इमेज और हमारे जैसा कॉन्टेंट इस्तेमाल करने की अनुमति दे रहे हैं. साथ ही, यह सबसे अच्छा होगा कि वे अपने ऐप्लिकेशन का नाम और ऐप्लिकेशन पैकेज का नाम भी डालें.

जैसे, com.joeschicken.app या कुछ और. इसके बाद, डेवलपर को जवाब दिया जा सकता है और उसे वह दस्तावेज़ दिया जा सकता है.

ठीक है।

इसके बाद, मुझे लगता है कि दूसरा हिस्सा था--

क्या ऐसा कुछ है जो वे पहले से कर सकते हैं, ताकि उन्हें इस समस्या का सामना न करना पड़े?

उदाहरण के लिए, क्या पहली बार सबमिट करते समय, कोई सबूत अपलोड किया जा सकता है? मुझे उसका नाम याद नहीं है.

हां.

दाईं ओर.

Play Console पर, पहले से दी जाने वाली सूचना का फ़ॉर्म मौजूद होता है. इसे सबमिट किया जा सकता है. साथ ही, इस तरह के दस्तावेज़ अपलोड किए जा सकते हैं जो आपके खाते को दूसरी इकाई से जोड़ते हैं.

इसलिए, ऐसा करके सबमिट किए गए अपने ऐप्लिकेशन को, नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) से जुड़ी इस तरह की कार्रवाइयों से पहले ही बचाया जा सकता है.

हाँ।

चलिए.

ठीक है।

आपने सबसे सही तरीकों वाले सेक्शन में, तीसरे पक्ष के एसडीके इस्तेमाल करने के बारे में थोड़ी जानकारी दी थी. हालांकि, मुझे इस बारे में और जानना है.

इसलिए, जब ऐप्लिकेशन तीसरे पक्ष के एसडीके इस्तेमाल करते हैं, तो ऐसा लगता है कि ऐप्लिकेशन डेवलपर इस बात के लिए ज़िम्मेदार हैं कि तीसरे पक्ष के एसडीके, उपयोगकर्ता के डेटा जैसी चीज़ों का इस्तेमाल कैसे करते हैं.

डेवलपर को कैसे पता चलेगा कि एसडीके, डेटा की सुरक्षा और उपयोगकर्ता के डेटा से जुड़ी नीतियों का पालन करते हैं?

जैसे, वे इस लैंडस्केप को कैसे नेविगेट कर सकते हैं?

हां, यह एक अच्छा सवाल है.

मैंने Google में अपने शुरुआती दो सालों में, एसडीके के साथ काफ़ी काम किया. यह बात पिछले सवाल से जुड़ी है, जिसमें हमने जनरेटिव एआई और यूज़र जनरेटेड कॉन्टेंट के बारे में बात की थी. इसका मतलब है कि आपके ऐप्लिकेशन में जो भी कॉन्टेंट है उसकी ज़िम्मेदारी डेवलपर की होती है.

मुझे लगता है कि पॉल ने शुरुआत में ही, Google Play एसडीके इंडेक्स के बारे में बताया था. इसके बारे में जानने के लिए, Google पर जाकर इसे टाइप करें.

यह पहला या दूसरा नतीजा होना चाहिए, Google Play एसडीके इंडेक्स. इसके बाद, आपको एक वेबपेज मिलेगा, जिसमें सैकड़ों एसडीके होंगे. इन्हें अलग-अलग कैटगरी में बांटा गया होगा. जैसे, कमाई करने के लिए एसडीके, विज्ञापनों के लिए एसडीके, सेहत के लिए एसडीके या कुछ और?

यह पेज, सार्वजनिक तौर पर उपलब्ध डेटा को फ़ेच करता है.

यह एक ऐसा इवेंट है जिसे Google आयोजित करता है.

हालांकि, इन एसडीके की सूची में नीचे जाने पर, आपको कुछ एसडीके के बगल में एक बैज दिखेगा. इस पर लिखा होगा कि एसडीके, SDK Console में रजिस्टर है.

जिस तरह डेवलपर के पास अपने ऐप्लिकेशन के लिए Play Developer Console होता है उसी तरह एसडीके डेवलपर के पास SDK Developer Console का ऐक्सेस पाने का विकल्प होता है.

साथ ही, उन्हें भी समीक्षा की ऐसी ही प्रोसेस से गुज़रना पड़ता है.

वे हमें अपना SDK टूल भेजते हैं.

Google, कुछ अलग-अलग तरह की जांच करता है. अगर कोई कारोबार इन जांचों में पास हो जाता है और सभी ज़रूरी शर्तों को पूरा करता है, तो उसे यह बैज मिल जाता है.

डेवलपर के तौर पर आपके लिए इसका मतलब यह है कि आपके पास उस इंडेक्स में जाकर यह देखने का विकल्प है कि कौनसे एसडीके टूल इस प्रोसेस को पास कर चुके हैं.

हालांकि, इस बात की कोई गारंटी नहीं है कि ऐप्लिकेशन को मंज़ूरी मिल जाएगी या एसडीके टूल कभी भी नीति का उल्लंघन नहीं करेगा. हालांकि, इससे दो फ़ायदे ज़रूर होते हैं.

पहली वजह यह है कि अगर उस SDK टूल का इस्तेमाल किया जा रहा है, तो इस बात की संभावना बहुत ज़्यादा है कि ऐप्लिकेशन को अस्वीकार नहीं किया जाएगा.

यह सिर्फ़ एक संभावना है.

दूसरी बात, जो मुझे इस पूरी प्रोसेस के बारे में काफ़ी पसंद है, वह यह है कि अगर हमें पता चलता है कि एसडीके में कुछ ऐसा है जो नीति के मुताबिक नहीं है, तो हम दो तरह से कार्रवाई करेंगे.

सबसे पहले, हम एसडीके डेवलपर से संपर्क करके कहेंगे, "हमें पता चला है कि आपका एसडीके, उपयोगकर्ता का डेटा हमारी नीतियों का पालन किए बिना भेज रहा है."

इसके बाद, वे अपने ऐप्लिकेशन या एसडीके को नीतियों के मुताबिक बनाने के लिए काम करेंगे.

इसके बाद, हमारी टीम डेवलपर को सूचनाएं या चेतावनियां भेजेंगी.

सूचना में कुछ ऐसा लिखा होगा, "नमस्ते, हमने देखा कि आपका ऐप्लिकेशन, नीति का पालन न करने वाले तरीके से डेटा भेज रहा है. साथ ही, हमने देखा कि ऐसा ABC SDK में हो रहा है."

इसलिए, डेवलपर के तौर पर आपको SDK टूल को अपडेट करना होगा. इसके लिए, SDK टूल के उस वर्शन का इस्तेमाल करें जो नीति के मुताबिक हो.

अगर आपको ज़्यादा सख्त कदम उठाने हैं, तो SDK टूल को हटाया जा सकता है या उसे बदला जा सकता है. हालांकि, मुझे पता है कि इसमें बहुत मेहनत और काम करना पड़ता है.

हालांकि, मुझे Google Play एसडीके इंडेक्स की यही बात पसंद है.

हाँ।

इंडेक्स में यह नहीं बताया जाता कि वह किन नीतियों का पालन करता है या नहीं. हालांकि, आपको वह बैज मिलता है और यह एक तरह से भरोसे का वोट है.

ठीक है।

हाँ।

ठीक है, यह सही रहेगा.

आपकी बात से ऐसा लगता है कि अगर हम डेवलपर को यह मैसेज भेजें कि "आप इस SDK टूल का इस्तेमाल कर रहे हैं और इसमें कोई समस्या है."

क्या हम उन्हें बताते हैं कि अगर वे अपडेट करने जा रहे हैं, तो हम उन्हें कौनसा वर्शन बताते हैं. अगर डेवलपर इसे ठीक करता है, तो क्या हम उन्हें बताते हैं कि "अरे, बेहतर वर्शन ऐसा है"?

या फिर उन्हें खुद ही थोड़ी रिसर्च करनी होगी?

मुझे लगता है कि इसमें वर्शन कोड मौजूद है.

हां, मुझे इस बारे में पक्के तौर पर नहीं पता. हालांकि, मुझे लगता है कि वहां वर्शन कोड की सूची दी गई है, जिसे वे अपडेट कर सकते हैं.

हां, और पूरी पारदर्शिता के लिए, मैं खुद डेवलपर नहीं हूं, मैं इंजीनियर नहीं हूं. हालांकि, डेवलपर से बात करने पर, मुझे समझ आया कि कभी-कभी यह एक या दो बटन पर क्लिक करने जितना आसान होता है. इसके बाद, आपके ऐप्लिकेशन में SDK टूल के लिए अपडेट की प्रोसेस शुरू हो जाती है.

यह तो बहुत अच्छी बात है.

चलिए.

धन्यवाद.

ठीक है।

आपने लॉगिन क्रेडेंशियल के बारे में थोड़ी बात की. मुझे इस विषय के बारे में थोड़ी जानकारी है. साथ ही, मुझे पता है कि इसमें यह जानकारी होना कितना ज़रूरी है.

आपने दो तरीकों से पुष्टि करने की सुविधा को बायपास करने और पेवॉल या सदस्यता वाले कॉन्टेंट को ऐक्सेस करने का तरीका बताया है.

हालांकि, डेवलपर को और किन सामान्य स्थितियों पर ध्यान देना चाहिए?

उदाहरण के लिए, कभी-कभी ऐप्लिकेशन में ऐसा कॉन्टेंट होता है जिसे सिर्फ़ कुछ देशों या जगहों से ऐक्सेस किया जा सकता है. इसके अलावा, ऐसा भी हो सकता है कि किसी मैसेजिंग ऐप्लिकेशन को टेस्ट करने के लिए, दो लॉगिन की ज़रूरत हो.

क्या ऐसी अन्य स्थितियां भी हैं जहां लॉगिन क्रेडेंशियल देने के अलावा, डेवलपर को कुछ और भी करना पड़ सकता है?

हाँ।

मेरा मतलब है कि मुझे लगता है कि मैं हमेशा उन लॉगिन क्रेडेंशियल से शुरू और खत्म करूंगा जो आपने समीक्षा टीम को दिए हैं. बस यह पक्का करें कि इससे उन्हें ऐप्लिकेशन की सभी सुविधाओं का ऐक्सेस मिले.

Play Developer Console में मौजूद इस सेक्शन को पहले ऐप्लिकेशन ऐक्सेस कहा जाता था. मुझे लगता है कि करीब एक महीने पहले, इसका नाम बदलकर साइन-इन की जानकारी कर दिया गया था.

हां, इसमें उपयोगकर्ता नाम और पासवर्ड डालने की जगह होती है. इसके बाद, मुझे लगता है कि इसके नीचे एक फ़्रीफ़ॉर्म टेक्स्ट फ़ील्ड होता है.

इसलिए, अगर लॉगिन करने का तरीका आसान नहीं है, तो आपको इसके बारे में निर्देश देने होंगे.

अगर आपको उपयोगकर्ताओं को दूसरा, तीसरा, और चौथा लॉगिन देना है, तो वह भी दिया जा सकता है.

और आपको शायद कुछ अहम जानकारी देने के लिए, जब हमारी टीम ऐप्लिकेशन की समीक्षा करती है, तो ऐसा नहीं होता कि कोई व्यक्ति कमरे में बैठकर, ऐप्लिकेशन को इधर-उधर करके देखे और फिर उसे मंज़ूरी दे या अस्वीकार कर दे.

अलग-अलग नीतियों और वर्कफ़्लो को देखने के लिए कई टीमें होती हैं. इसलिए, ऐसा हो सकता है कि आपके ऐप्लिकेशन में एक से ज़्यादा लोग, कई डिवाइसों से लॉग इन करें. कभी-कभी, अलग-अलग इलाकों से भी लॉग इन किया जा सकता है.

मुझे इस बात का अंदाज़ा है कि ऐसा क्यों होता है. दरअसल, सुरक्षा से जुड़े कई सिस्टम यह मानते हैं कि अगर किसी खाते में कई बार लॉगिन करने की कोशिश की जाती है, तो उपयोगकर्ता की सुरक्षा के लिए उस खाते को ब्लॉक कर देना चाहिए.

हालांकि, आप जो भी करें, बस यह जान लें कि हम ऐप्लिकेशन की समीक्षा कई अलग-अलग वर्कफ़्लो के हिसाब से कर रहे हैं. इसलिए, आपको यह दिख सकता है.

इसलिए, कई लॉगिन उपलब्ध कराने से मदद मिल सकती है.

हाँ।

चलिए.

हां, मुझे डिक्लेरेशन में फ़्री-फ़ॉर्म टेक्स्ट का इस्तेमाल करने की अहमियत को हाइलाइट करना चाहिए.

इसलिए, अगर आपके डेमो खाते में सिर्फ़ उपयोगकर्ता नाम और पासवर्ड डालने के अलावा और भी चरण शामिल हैं, तो आपको यह पक्का करना चाहिए कि समीक्षा करने वाली हमारी टीम को आपके ऐप्लिकेशन में जाने का तरीका पता हो.

ऐसा हो सकता है कि आपको एक वीडियो उपलब्ध कराना पड़े, जिसमें यह दिखाया गया हो कि ऐप्लिकेशन में कैसे लॉगिन किया जाए. इससे हमारी टीम को यह समझने में मदद मिलेगी कि अगर लॉगिन करने की प्रोसेस, उपयोगकर्ता नाम और पासवर्ड डालने से ज़्यादा मुश्किल है, तो उसे कैसे पूरा किया जाए.

हाँ।

मेरा मतलब है कि कभी-कभी हम खुद ऐप्लिकेशन देखते हैं और उनमें कुछ फैंसी लॉगिन होते हैं.

मैंने ऐसे वीडियो देखे हैं जिनमें कहा जाता है कि इस बटन पर 17 बार टैप करें और फिर स्क्रीन पर X बनाएं. इसके बाद, डेवलपर मोड पॉप-अप होता है. फिर आपको 11 अन्य चरणों को फ़ॉलो करना होता है. कृपया ऐसा न करें.

क्योंकि इससे काम थोड़ा मुश्किल हो जाता है.

मैंने एक स्थिति के बारे में सुना है. कुछ ऐप्लिकेशन आपको एक ही समय पर, सिर्फ़ कुछ डिवाइसों पर लॉग इन करने की अनुमति देते हैं. इसके बाद, आपको "एक डिवाइस से लॉग आउट करना होगा."

इसलिए, अगर आपका ऐप्लिकेशन इस सुविधा के साथ काम करता है, तो मुझे लगता है कि उस पेज को ढूंढने का तरीका बताना भी मददगार होगा जहां से पिछले लॉगिन को ऐक्सेस करने की सुविधा हटाई जा सकती है.

हाँ।

चलिए.

इसलिए, जब हम नीतियों को अपडेट करते हैं या नई नीतियां लाते हैं, तो कभी-कभी डेवलपर को अपने ऐप्लिकेशन में बदलाव करने पड़ सकते हैं. बदलावों को लागू करने में कुछ समय लग सकता है. यह इस बात पर निर्भर करता है कि बदलाव किस तरह के हैं.

इसलिए, कभी-कभी इन ऑफ़र की समयसीमा तय होती है, है न?

जैसे, किसी नई नीति का पालन करने के लिए, आपको इस तारीख तक XYZ काम करना होगा.

अगर समयसीमा खत्म होने वाली है, लेकिन किसी डेवलपर को लगता है कि उसे नीति का पालन करने के लिए ज़्यादा समय चाहिए, तो उसके पास क्या विकल्प हैं?

हां, यह एक चेतावनी की तरह लग रहा है.

हाँ, यह एक चेतावनी की तरह लगता है.

हाँ।

हां, चेतावनियों के मामले में, मेरा मतलब है कि सबसे आसान तरीका यह है कि ज़्यादा समय मांगें, है न?

आम तौर पर, इस प्रोसेस के तहत हम नई नीतियां रिलीज़ करते हैं. इनमें नई नीतियां, मौजूदा नीतियों में किए गए अपडेट या नीतियों के बारे में साफ़ तौर पर दी गई जानकारी शामिल होती है.

मुझे लगता है कि Google आम तौर पर, लीड समय देने के मामले में काफ़ी अच्छा है.

साथ ही, कार्रवाई शुरू करने से छह महीने पहले, उस नीति का सार्वजनिक तौर पर एलान किया जा सकता है.

इसके बाद, हम चेतावनी भेजेंगे और कहेंगे, "आपका ऐप्लिकेशन इस नीति का उल्लंघन कर रहा है, जिसका एलान छह या 12 महीने पहले किया गया था."

हालांकि, एक बात यह है कि कभी-कभी पॉल और मैं इस बात से सहमत नहीं होते कि वे आपको बदलाव करने के लिए सात दिन का समय दें.

साथ ही, डेवलपमेंट में काफ़ी समय लगता है.

हम आपकी बात समझते हैं.

इसलिए, मैं बस जवाब देता.

इसके लिए, आपको अपील करनी होगी. इसमें कुछ ऐसा कहा जा सकता है, "नमस्ते, हमें नीति के बारे में पता है और यह भी पता है कि हमारा ऐप्लिकेशन इसका पालन नहीं करता.

हम इस पर पहले से ही काम कर रहे हैं या नीति से जुड़ी समस्या को हल करने के लिए, हम ये कदम उठाने जा रहे हैं. हालांकि, हमें और समय चाहिए."

इसलिए, वे आम तौर पर आपको थोड़ा ज़्यादा समय देते हैं.

अगर सात दिन और बीत जाते हैं और वह समयसीमा भी खत्म होने वाली है, तो फिर से अनुरोध किया जा सकता है.

ज़ाहिर है कि यह असीमित नहीं है.

लेकिन जैसा कि मैंने कहा, पॉल और मैं विरोध करते हैं. हालांकि, यह व्यक्तिगत तौर पर और उच्च स्तर पर होता है.

जैसे, जब हमें पता चलता है कि नई नीतियां आने वाली हैं और हमें यह भी पता होता है कि उन पर कौन काम कर रहा है, तो हम कहते हैं, "देखिए, क्या इसके लिए 7 या 14 दिनों के बजाय, 28 दिनों की चेतावनी दी जा सकती है?"

हाँ।

दाईं ओर.

अगर आपने अच्छी भावना के साथ, नीति का पालन करने के लिए बदलाव किए हैं, तो Google Play आपके साथ मिलकर काम करेगा. साथ ही, नीति का पालन करने के लिए नई समयसीमा तय करेगा.

आपके लिए बेहतर टाइमलाइन.

ठीक है।

इसका मतलब है कि अपील करने की सुविधा, कई तरह से काम करती है. इससे कई स्थितियों में मदद मिलती है. हालांकि, इसके लिए ज़रूरी है कि इसका इस्तेमाल सही तरीके से किया जाए.

जैसे, जब ज़रूरी हो, तब अपील करना और अपील सबमिट करने की वजह के बारे में पूरी जानकारी देना. इससे आपको मदद मिल सकती है और आपकी अपील पर विचार किया जा सकता है.

ठीक है।

इसलिए, अगर किसी डेवलपर के पास एक ही डेवलपर खाते में कई ऐप्लिकेशन हैं, तो मुझे पता है कि ऐसा हमेशा होता है.

अगर किसी नीति के उल्लंघन की वजह से एक ऐप्लिकेशन को निलंबित कर दिया जाता है, तो इसका डेवलपर खाते पर क्या असर पड़ेगा?

क्या इससे खाते या नीति का पालन करने वाले अन्य ऐप्लिकेशन को कोई खतरा है?

यह बटन कैसे काम करता है?

ऐसा हो सकता है.

यह आपके ब्लैंक-लेबल डेवलपर की तरह होगा.

मैंने पहले जो के चिकन के बारे में बात की थी, है न?

ऐसा हो सकता है कि आपके सभी क्लाइंट उसी इंडस्ट्री से हों.

इसलिए, मुझे लगता है कि यह बेसबॉल खेलने जैसा है. इसमें आपको स्ट्राइक आउट मिलते हैं, है न?

हालांकि, कुछ बुरे लोग भी हैं जो Play Store में घुसने की कोशिश करते हैं. इसलिए, हमारे पास नीति उल्लंघन ठीक करने के कई तरीके हैं. इनमें हल्के-फुल्के तरीकों से लेकर, ऐप्लिकेशन हटाने, निलंबित करने, और खाते पर पाबंदी लगाने जैसे सख्त तरीके भी शामिल हैं.

अगर आपके पास Play Store पर एक जैसे कई ऐप्लिकेशन हैं और उनमें से किसी एक को निलंबित कर दिया जाता है, तो…

हम्म.

आप बुरे मकसद से काम करने वाले व्यक्ति हैं, है न?

इसलिए, आपने इसे ठीक किया और फिर एक महीने बाद, इसे वापस लाने की कोशिश की.

इसके बाद, हमारी टीम को इसका पता चल जाता है और आपके खाते को फिर से निलंबित कर दिया जाता है, है न?

इसके बाद, आपने उसे अपने ऐप्लिकेशन से हटा दिया. फिर, एक महीने बाद उसे वापस डाल दिया. इसके बाद, ठीक है, अब हमारे पास व्यवहार का एक दोहराव वाला पैटर्न है. इसके बाद, आपने उसे फिर से डाल दिया. इस तरह, आपने तीन बार उल्लंघन किया. अब आपको बाहर कर दिया गया है, है न?

मान लें कि आपने चिकन रेस्टोरेंट के लिए कोई ऐप्लिकेशन बनाया है. इसमें नुकसान पहुंचाने वाला कॉन्टेंट या ऐसी कोई चीज़ नहीं होगी. इसमें सिर्फ़ लोगों को स्वादिष्ट खाने के बारे में बताया जाएगा.

मान लें कि आपने सीआई/सीडी पाइपलाइन या किसी अन्य तरीके से, एक ही समय पर ये सभी ऐप्लिकेशन सबमिट किए. इसके बाद, आपको एक ही समय पर 10 ऐप्लिकेशन के लिए, अस्वीकार या निलंबित किए जाने की सूचना मिलती है. ऐसे में, हम इसे सिर्फ़ एक स्ट्राइक के तौर पर देखेंगे. इसकी वजह यह है कि हमें पता है कि आपने एक ही समय पर कई ऐप्लिकेशन सबमिट किए हैं.

हम्म.

दिलचस्प है.

मुझे लगता है कि यह आपके सवाल का जवाब है.

हां, बहुत बढ़िया.

धन्यवाद.

मेरे पास एक और सवाल है.

इनमें से ज़्यादातर सवाल शायद जाने-माने डेवलपर के लिए ज़्यादा काम के हैं. हालांकि, यह सवाल Play Console में पहली बार सेट अप करने के बारे में है.

मान लें कि आपकी Google Play पेमेंट्स प्रोफ़ाइल की पुष्टि हो गई है.

पहचान की पुष्टि करने से जुड़ी गड़बड़ियां अब ठीक हो गई हैं. अब सिर्फ़ फ़ोन नंबर की पुष्टि करने से जुड़ी गड़बड़ी बची है.

जैसे, इस मामले में डेवलपर को क्या करना चाहिए, ताकि यह पक्का किया जा सके कि उसका डेवलपर खाता, ऐप्लिकेशन पब्लिश करने के लिए तैयार है?

जैसे, कभी-कभी ऐसा लगता है कि आप पहेली के अलग-अलग हिस्सों को चुन रहे हैं या अगर उन्हें इस तरह के मामले में प्रोसेस को पूरा करने का तरीका नहीं पता है, तो वे क्या कर सकते हैं?

हां, कुछ समय पहले एक अन्य इवेंट में मुझसे भी ऐसा ही सवाल पूछा गया था. मुझे लगता है कि नए डेवलपर के लिए यह बात सही है. हालांकि, मुझे लगता है कि कई मौजूदा डेवलपर को फिर से पुष्टि करनी पड़ी.

यह शायद एक साल पहले की बात है, क्या यह सही है?

मुझे ठीक से याद नहीं आ रहा.

इनमें से कई चैनलों की पुष्टि अपने-आप हो गई थी. हालांकि, कुछ चैनलों को पुष्टि करनी पड़ी.

ठीक है।

या फिर, हो सकता है कि उनका पता और उनकी Dun & Bradstreet प्रोफ़ाइल मैच न हुई हो, जैसे…

दाईं ओर.

दाईं ओर.

Google प्रोफ़ाइल.

ठीक है।

हां, तो मान लेते हैं कि यह फ़ोन नंबर है.

मैं इस सवाल का जवाब दो तरह से दूंगा.

ठीक है।

पहली बात यह है कि इन चरणों को पूरा करते समय, आपको Google Play Console में कई बार सूचनाएं दिखेंगी.

इसलिए, आपको सिर्फ़ एक सूचना मिलेगी, जिसमें लिखा होगा, "नमस्ते, अब आपको अपना फ़ोन नंबर रजिस्टर करना होगा."

यह बहुत आसान है.

आपने इसे अंतरराष्ट्रीय फ़ोन नंबर फ़ॉर्मैट में डाला हो. जैसे, +1 408, जो भी नंबर हो.

इसके लिए, आपको एसएमएस या फ़ोन कॉल से पुष्टि करने का विकल्प चुनना होगा और वहां दिए गए निर्देशों का पालन करना होगा.

हालांकि, कभी-कभी ऐसा हो सकता है कि आपने ऐसा करने की कोशिश की हो और आपको गड़बड़ी का कोई मैसेज या कुछ और मिला हो. ऐसा इसलिए, क्योंकि हमारे पास ऐसे डेवलपर भी थे जिनके साथ ऐसा हुआ था या उन्हें एसएमएस कोड नहीं मिल रहा था.

मैं आपको अपील टीम से संपर्क करने का तरीका बताऊंगी.

यह तो एक टीम है, लेकिन असल में ऐसी कई टीमें हैं. मुझे नहीं पता कि ऐसी आधा दर्जन टीमें हैं या दो दर्जन…

विल.

Play Console में उन सवालों के जवाब दें जिन्हें ऐक्सेस करने का विकल्प आपके पास उपलब्ध है. इसके लिए, सहायता मेन्यू पर जाएं.

अब यूज़र इंटरफ़ेस में थोड़ा बदलाव किया गया है.

पहले यह आपकी होम स्क्रीन पर बाईं ओर मौजूद मेन्यू में दिखता था.

सबसे नीचे, आपको सहायता बटन दिखता था.

अब यह विकल्प हटा दिया गया है. हालांकि, अगर अब किसी भी पेज के फ़ुटर में सबसे नीचे स्क्रोल किया जाए, तो आपको सहायता बटन दिखेगा.

इस पर क्लिक करने पर, आपको नीले रंग का एक छोटा बटन दिखेगा. इस पर 'सहायता टिकट बनाएं' लिखा होगा.

मुझे लगता है कि इसमें यही लिखा है.

हम्म.

हां.

इसके बाद, आपको कुछ ड्रॉप-डाउन दिखेंगे. इनमें मौजूद सवालों को पूछा जा सकता है.

साथ ही, यहां ड्रॉप-डाउन की एक सीरीज़ है, जो आपको सीधे फ़ोन नंबर पर ले जाएगी. मुझे लगता है कि मुझे यह याद है. हालांकि, यह आपके डेवलपर खाते की पुष्टि करने जैसा है. दूसरा ड्रॉप-डाउन भी काफ़ी मिलता-जुलता है. इसमें आपको कई रेडियो बटन मिलेंगे.

इनमें से एक तरीका, फ़ोन नंबर की पुष्टि करने के लिए है.

इसके बाद, हो सकता है कि आपको एसएमएस से पुष्टि करने के लिए कोड मिल रहा हो या उस प्रोसेस को पूरा करने की कोशिश करते समय, आपकी स्क्रीन पर कोई गड़बड़ी दिख रही हो.

इसलिए, फ़ोन नंबर की पुष्टि करने की सुविधा के लिए, इस फ़ॉर्म का इस्तेमाल किया जा सकता है. साथ ही, Google Play डेवलपर खाते से जुड़े अन्य सवालों के लिए भी इसका इस्तेमाल किया जा सकता है.

ज़्यादातर मामलों में, Play Console पर पुष्टि करने के अगले चरणों के बारे में साफ़ तौर पर बताया जाता है. इसलिए, बस उन चरणों को फ़ॉलो करें और आपका काम हो जाएगा.

बहुत बढ़िया.

चलिए.

अब हमारे पास ज़्यादा समय नहीं बचा है. इसलिए, इस पैनल में शामिल होने के लिए आप सभी का बहुत-बहुत धन्यवाद.