अपना मुफ़्त डिज़ाइन पाएँ
· Developers · 6 मिनट रीड

Google Play Developer API से अपनी Play Store लिस्टिंग अपडेट करना

Google Play Developer API से अपनी Play Store लिस्टिंग अपडेट करना
TL;DR. Android Publisher API से Play लिस्टिंग अपडेट करना एक ही ट्रांज़ैक्शन है। आप एक edit खोलते हैं (edits.insert), उसके अंदर लिस्टिंग टेक्स्ट और इमेज बदलते हैं (edits.listings.update, edits.images.upload), फिर validate करने और publish करने के लिए edits.commit चलाते हैं — या डिस्कार्ड करने के लिए edits.abandon। commit होने तक कुछ भी लाइव नहीं होता। ऑथ के लिए Google Cloud service account चाहिए, और वह एक स्टेप जिस पर लगभग हर कोई अटकता है: service account को सिर्फ Google Cloud IAM में role देना काफी नहीं — उसे Play Console में इनवाइट करना ज़रूरी है।

Google Play Developer API (इसका आधिकारिक नाम Android Publisher API है) आपको Play Console खोले बिना स्टोर लिस्टिंग — टाइटल, डिस्क्रिप्शन, स्क्रीनशॉट, फीचर ग्राफिक — बदलने देता है। अगर आप किसी CMS से लोकलाइज़्ड कॉपी पुश कर रहे हैं, बिल्ड पाइपलाइन से स्क्रीनशॉट सिंक कर रहे हैं, या एक साथ दर्जनों भाषाओं की लिस्टिंग अपडेट कर रहे हैं, तो यही सही तरीका है। यह इसे सही ढंग से करने का पूरा फ्लो है, उन हिस्सों समेत जो रेफरेंस डॉक्स में दबे रहते हैं।

एक edit एक ट्रांज़ैक्शन है, लाइव राइट्स का सेट नहीं

जो मेंटल मॉडल आपको सबसे ज़्यादा परेशानी से बचाता है: आप कभी भी लाइव लिस्टिंग को सीधे एडिट नहीं करते हैं। आप एक edit खोलते हैं, जो ऐप की मौजूदा डिप्लॉय्ड स्थिति की एक प्राइवेट स्टेजिंग कॉपी होती है — लिस्टिंग, इमेज, ट्रैक्स, सब कुछ उसमें कॉपी हो जाता है। आप अपने सारे बदलाव उसी कॉपी पर करते हैं। फिर या तो सब कुछ एक साथ commit करते हैं, या abandon कर देते हैं और कुछ भी नहीं होता।

Google की अपनी बात साफ है: "एडिट के अंदर किए गए बदलाव तब तक लाइव नहीं होते जब तक एडिट commit न हो जाए।" commit पर, अगर कोई validation error नहीं है, तो एडिट के सारे बदलाव एक साथ लाइव हो जाते हैं और मौजूदा स्थिति की जगह ले लेते हैं। अगर validation फेल होता है, तो API एरर देता है और लाइव लिस्टिंग जस की तस रहती है। तो लाइफसाइकल ठीक चार स्टेप्स का है:

  • edits.insert — edit बनाएं, वापस एक editId मिलेगा।
  • modify — हर भाषा के टेक्स्ट के लिए edits.listings.update, स्क्रीनशॉट और ग्राफिक्स के लिए edits.images.upload / deleteall।
  • edits.commit — सब कुछ validate करें, फिर सबको एक साथ (atomically) publish करें।
  • edits.abandon — ड्राफ्ट को छोड़ दें, लाइव लिस्टिंग वैसी की वैसी रहेगी।

एक सख्त सीमा जिसके हिसाब से डिज़ाइन करना चाहिए: किसी अकाउंट का एक समय में केवल एक ही edit खुला हो सकता है, और अगर कोई भी एडिट commit कर देता है या Play Console UI से ऐप एडिट करता है, तो उस ऐप के बाकी सारे खुले एडिट invalid हो जाते हैं। एडिट को कम समय के लिए ही रखें — खोलें, लिखें, commit करें। किसी इंसान के कंसोल में इधर-उधर क्लिक करते रहने के दौरान इसे घंटों खुला न रखें।

ऑथ: एक service account, और वह इनवाइट जिसे सब भूल जाते हैं

ऑटोमेटेड अपडेटर के लिए आपको service account चाहिए, यूज़र OAuth नहीं। इसमें दो सिस्टम शामिल हैं, और वे सचमुच अलग-अलग हैं:

  1. Google Cloud. एक service account बनाएं, प्रोजेक्ट पर Google Play Android Developer API इनेबल करें, और एक JSON key डाउनलोड करें। आपको बस यह scope चाहिए: https://www.googleapis.com/auth/androidpublisher।
  2. Play Console. Users & permissions में जाएं, Invite new users पर क्लिक करें, service account का ईमेल पेस्ट करें (...@...iam.gserviceaccount.com वाला एड्रेस), और उसे ऐप का एक्सेस दें। तभी वह key आपकी लिस्टिंग को छू सकती है।

एक और शर्त: ऐप पहले से मौजूद होना चाहिए और उसका कम से कम एक रिलीज़ हो चुका होना चाहिए (कंसोल के ज़रिए कम से कम एक APK/AAB अपलोड हो चुका हो)। सिर्फ API से किसी बिल्कुल नए ऐप को शुरू नहीं किया जा सकता।

चारों कॉल्स, REST के रूप में

लिस्टिंग टेक्स्ट अपडेट करना

edits.listings.update एक PUT है — उस भाषा की लिस्टिंग का पूरा रिप्लेस। आप जो भी भेजेंगे वही लिस्टिंग बन जाएगी; जो फील्ड्स आप छोड़ देंगे, वे प्रिज़र्व नहीं होंगी बल्कि क्लियर हो जाएंगी। इसलिए अगर आप सिर्फ short description बदलना चाहते हैं, तब भी टाइटल और फुल डिस्क्रिप्शन साथ भेजें, वरना वे मिट जाएंगी। जब आपको सचमुच पार्शियल बदलाव चाहिए, तो एक अलग edits.listings.patch है जो सिर्फ दी गई फील्ड्स को मर्ज करता है। ज़्यादातर पाइपलाइन के लिए पूरा PUT ही साफ-सुथरा है — आप वैसे भी अपने सोर्स ऑफ ट्रुथ से पूरी लिस्टिंग रेंडर कर रहे हैं, तो उसे पूरा रिप्लेस करना ही सही है।

तीन टेक्स्ट फील्ड्स और उनकी सीमाएं: title अधिकतम 30 कैरेक्टर, shortDescription अधिकतम 80, fullDescription अधिकतम 4000। हर भाषा के लिए एक लिस्टिंग रिसोर्स, जो URL में BCP-47 लैंग्वेज टैग से की होती है (en-US, de-DE, ja-JP, वगैरह)। दस भाषाएं अपडेट करने के लिए आप एक ही एडिट के अंदर दस listings.update कॉल करते हैं — फिर एक commit उन सबको एक साथ publish कर देता है।

स्क्रीनशॉट और फीचर ग्राफिक अपलोड करना

इमेज हर भाषा और हर इमेज टाइप के हिसाब से अटैच होती हैं। इमेज टाइप एक enum है, और लिस्टिंग का हर asset स्लॉट इनमें से किसी एक वैल्यू से मैप होता है:

  • phoneScreenshots, sevenInchScreenshots, tenInchScreenshots — फोन और टैबलेट स्क्रीनशॉट सेट्स।
  • tvScreenshots, wearScreenshots — Android TV और Wear OS।
  • featureGraphic — लिस्टिंग के ऊपर दिखने वाला 1024×500 बैनर।
  • icon, tvBanner — ऐप आइकन और TV बैनर।

edits.images.upload किसी दी गई भाषा और टाइप की एक इमेज एडिट में जोड़ता है। कोई "पूरा array सेट करो" वाली कॉल नहीं है, इसलिए स्क्रीनशॉट रिप्लेस करने का भरोसेमंद तरीका है — पहले उस भाषा और इमेज टाइप के लिए edits.images.deleteall चलाएं, फिर नए सेट को उसी क्रम में अपलोड करें जिस क्रम में आप उन्हें दिखाना चाहते हैं। edits.images.list यह पढ़ता है कि एडिट में फिलहाल क्या है, और edits.images.delete ज़रूरत पड़ने पर id से एक इमेज हटाता है। यह सब कुछ commit होने तक एडिट के अंदर ही रहता है।

Commit करना — और "लाइव" का असल मतलब क्या है

कुछ बातें जिनके बारे में साफ होना ज़रूरी है, क्योंकि ये लोगों को चौंका देती हैं:

  • नया बिल्ड ज़रूरी नहीं। सिर्फ लिस्टिंग वाले एडिट को commit करने के लिए नए APK/AAB की ज़रूरत नहीं। टेक्स्ट और इमेज मेटाडेटा हैं; आप इन्हें मौजूदा रिलीज़ के आधार पर जितनी बार चाहें अपडेट कर सकते हैं। (बस ऐप का वह पहला रिलीज़ मौजूद होना चाहिए।)
  • Commit पहले validate करता है, फिर publish करता है। अगर कोई स्क्रीनशॉट गलत डाइमेंशन का है या कोई फील्ड बहुत लंबी है, तो commit फेल हो जाता है और लाइव लिस्टिंग कभी नहीं बदलती — आप ठीक करके फिर से commit करते हैं।
  • यह तुरंत नहीं होता। सफल commit के बाद, बदलाव दिखने में कई घंटे तक लग सकते हैं, ठीक वैसे ही जैसे Play Console में हाथ से किए गए बदलावों में लगते हैं। commit पर मिले 200 को "यूज़र्स को पहले से दिख रहा है" मत मान लो।
  • Abandon मुफ्त है। अगर कोई ड्राई-रन गलत लगे, edits.abandon बिना लाइव लिस्टिंग पर कोई असर डाले ड्राफ्ट को डिस्कार्ड कर देता है। बिना किसी जोखिम के पाइपलाइन को वैलिडेट करने के लिए काम का है।

बिना-कोड वाला रास्ता: डिज़ाइन करो, ट्रांसलेट करो, पब्लिश करो

ऊपर बताया गया API तब सही टूल है जब आपके पास खर्च करने के लिए इंजीनियरिंग टाइम है और सिंक करने के लिए कोई सोर्स ऑफ ट्रुथ है। यह जो नहीं करता वह है asset बनाना। आपको फिर भी स्क्रीनशॉट डिज़ाइन करने हैं, टाइटल और दोनों डिस्क्रिप्शन लिखनी हैं, और यह सब हर भाषा के लिए तैयार करना है — API सिर्फ वही भेजता है जो आप उसे थमाते हैं।

यही हिस्सा Mokbi संभालता है। आप ब्राउज़र में स्क्रीनशॉट डिज़ाइन करते हैं, उनके साथ ही टाइटल, शॉर्ट डिस्क्रिप्शन और फुल डिस्क्रिप्शन ड्राफ्ट करते हैं, और पूरी लिस्टिंग को एक ही पास में 50 भाषाओं में ट्रांसलेट करते हैं — ताकि ऊपर वाली दस listings.update कॉल्स के पास भेजने के लिए असली, लोकलाइज़्ड कॉपी हो, प्लेसहोल्डर टेक्स्ट नहीं।

और खुद पब्लिश करना? यह भी Mokbi करता है। Google Play के लिए यह पर्दे के पीछे ठीक यही फ्लो चलाता है (edits.insert → listings.update → इमेज अपलोड → commit), ताकि आपकी लोकलाइज़्ड लिस्टिंग और asset ऊपर लिखा गया एक भी कोड लिखे बिना लाइव हो जाएं। App Store के लिए यह App Store Connect में वर्ज़न को स्टेज करता है, भरा हुआ और सबमिट के लिए तैयार, क्योंकि Apple के लिए ज़रूरी है कि आप खुद फाइनल Submit दबाएं और रिव्यू पास करें। स्क्रीनशॉट और फीचर ग्राफिक डिज़ाइन करना, लिस्टिंग लिखना, उसे 50 भाषाओं में ट्रांसलेट करना, और उसे लाइव करना — यह सब एक ही निरंतर पास है।

आगे क्या पढ़ें

एडिटर खोलें →