अपना प्रॉडक्ट कैटलॉग मैनेज करना

इस गाइड में, Google Play Developer API का इस्तेमाल करके, अपने Play ऐप्लिकेशन के लिए प्रॉडक्ट कैटलॉग बनाने और मैनेज करने का तरीका बताया गया है.

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

Catalog Management APIs

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

  • वन-टाइम प्रॉडक्ट
  • शुल्क लेकर सेवा देने वाले प्रॉडक्ट

वन-टाइम प्रॉडक्ट

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

शुल्क लेकर सेवा देने वाले प्रॉडक्ट

monetization.subscriptions एंडपॉइंट की मदद से, डेवलपर बैकएंड से सदस्यता वाले प्रॉडक्ट मैनेज किए जा सकते हैं. सदस्यताएं बनाना, अपडेट करना, और मिटाना या क्षेत्र के हिसाब से उनकी उपलब्धता और कीमत कंट्रोल करना जैसे काम किए जा सकते हैं. monetization.subscriptions एंडपॉइंट के अलावा, हम सदस्यताओं के बुनियादी प्लान और ऑफ़र को मैनेज करने के लिए, monetization.subscriptions.basePlans और monetization.subscriptions.basePlans.offers एंडपॉइंट भी उपलब्ध कराते हैं.

बैच के तरीके

inappproducts और monetization.subscriptions एंडपॉइंट, एक साथ कई इकाइयों को मैनेज करने या उन्हें वापस पाने के कई तरीके उपलब्ध कराते हैं. इनकी मदद से, एक ही ऐप्लिकेशन में एक साथ 100 इकाइयों को मैनेज किया जा सकता है या उन्हें वापस पाया जा सकता है.

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

अपडेट के इंतज़ार का समय बनाम थ्रूपुट

प्रॉडक्ट बनाने या उसमें बदलाव करने का अनुरोध पूरा होने के बाद, हो सकता है कि असली उपयोगकर्ताओं को अपने डिवाइसों पर बदलाव तुरंत न दिखें. ऐसा, नेटवर्क या बैकएंड प्रोसेस में लगने वाले समय की वजह से हो सकता है. डिफ़ॉल्ट रूप से, प्रॉडक्ट में बदलाव करने के सभी अनुरोध, इंतज़ार के समय के हिसाब से होते हैं. इसका मतलब है कि इन्हें बैकएंड सिस्टम के ज़रिए तेज़ी से प्रोपेगेट करने के लिए ऑप्टिमाइज़ किया गया है. आम तौर पर, ये कुछ ही मिनटों में असली उपयोगकर्ता के डिवाइसों पर दिखने लगते हैं. हालांकि, बदलाव के ऐसे अनुरोधों की संख्या पर हर घंटे की सीमा होती है. जिन मामलों में आपको कई प्रॉडक्ट बनाने या अपडेट करने हैं (उदाहरण के लिए, बड़े कैटलॉग को शुरू करते समय), latencyToleranceफ़ील्ड को PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT पर सेट करके, एक साथ कई प्रॉडक्ट अपलोड करने के तरीकों का इस्तेमाल किया जा सकता है. इससे अपडेट की संख्या काफ़ी बढ़ जाएगी. लैटेंसी-टॉलरेंट अपडेट को एंड-यूज़र डिवाइसों पर लागू होने में 24 घंटे लग सकते हैं.

कोटा कॉन्फ़िगरेशन

अपने प्रॉडक्ट कैटलॉग को मैनेज करने के लिए, Play Developer API का इस्तेमाल करते समय आपको कोटे से जुड़ी कई सीमाओं के बारे में पता होना चाहिए:

  1. Google Play Developer API की डिफ़ॉल्ट सीमा, हर दिन 2,00,000 क्वेरी होती है. कोटा की यह सीमा, सभी एंडपॉइंट में इस्तेमाल के एग्रीगेशन पर लागू होती है. इसमें कैटलॉग मैनेजमेंट एपीआई भी शामिल हैं.
  2. प्रॉडक्ट में बदलाव करने वाले एंडपॉइंट पर भी, हर घंटे 7,200 क्वेरी की सीमा लागू होती है. यह सीमा, एक बार खरीदे जाने वाले प्रॉडक्ट और सदस्यताओं, दोनों पर लागू होती है. साथ ही, बदलाव करने के सभी अनुरोधों पर भी लागू होती है. जैसे, प्रॉडक्ट बनाना, अपडेट करना, चालू करना, और मिटाना. एक साथ कई बदलाव करने के तरीके से किए गए कॉल, इस कोटे के लिए एक क्वेरी के तौर पर गिने जाते हैं. भले ही, इसमें शामिल अलग-अलग अनुरोधों की संख्या या उनके इंतज़ार का समय कितना भी हो.
  3. इंतज़ार का समय कम करने के लिए किए जाने वाले बदलावों की संख्या भी, हर घंटे 7,200 से ज़्यादा नहीं होनी चाहिए. एक साथ कई बदलाव करने के तरीकों के लिए, इस कोटे के मकसद से, नेस्ट किए गए हर बदलाव के अनुरोध को अलग से गिना जाता है. इस कोटे का असर सिर्फ़ उन उपयोगकर्ताओं पर पड़ता है जो बैच एपीआई का इस्तेमाल करके, इंतज़ार का समय कम करने वाले अपडेट करते हैं. ऐसा इसलिए है, क्योंकि दूसरे मामलों में कोटा 2, इस कोटे के पहले या उसी समय खत्म हो जाएगा.

अलग-अलग अनुरोधों के कोटा के इस्तेमाल को समझने के लिए, यहां कुछ उदाहरण दिए गए हैं:

  • किसी एक आइटम को फ़ेच करने के लिए किए गए एक get अनुरोध में, कोटा 1 का एक टोकन खर्च होगा. साथ ही, कोटा 2 और 3 का कोई टोकन खर्च नहीं होगा, क्योंकि ये सिर्फ़ बदलाव वाले एंडपॉइंट से जुड़े हैं.
  • 100 आइटम तक फ़ेच करने के लिए, एक साथ कई आइटम get रिक्वेस्ट करने पर भी, कोटा 1 का एक टोकन खर्च होगा. साथ ही, कोटा 2 और 3 का कोई टोकन खर्च नहीं होगा.
  • किसी एक आइटम के लिए एक modification अनुरोध करने पर, कोटा 1 का एक टोकन और कोटा 2 का एक टोकन खर्च होगा. अगर अनुरोध में इंतज़ार का समय ज़्यादा है, तो यह तीसरे कोटे का एक टोकन भी खर्च करेगा. कोटा C और कोटा 2 की सीमा एक जैसी है. इसलिए, सिर्फ़ एक तरह के बदलाव के तरीकों का इस्तेमाल करने वाले उपयोगकर्ताओं पर इसका कोई असर नहीं पड़ता.
  • 100 ऐसे आइटम के लिए बैच modification अनुरोध करने पर, कोटा 1 का एक टोकन और कोटा 2 का एक टोकन इस्तेमाल होगा जिनमें इंतज़ार का समय ज़्यादा हो सकता है. कोटा सेटअप करने से, आपके कैटलॉग को अपडेट रखने के लिए ज़रूरत के मुताबिक मार्जिन मिल सकता है. हालांकि, अगर आपका एल्गोरिदम इस कोटे के बारे में नहीं जानता और इस दर से ज़्यादा हो जाता है, तो आपको हर अतिरिक्त कॉल के लिए गड़बड़ी का मैसेज मिल सकता है.
  • 100 ऐसे आइटम के लिए एक साथ कई अनुरोध modification करने पर, कोटा 1 का एक टोकन, कोटा 2 का एक टोकन, और कोटा 3 का 100 टोकन इस्तेमाल होगा.

Catalog Management API के इस्तेमाल के सुझाव

इन दिशा-निर्देशों का पालन करके, एपीआई के साथ अपने इंटरैक्शन को ऑप्टिमाइज़ किया जा सकता है. इससे, कैटलॉग को आसानी से और बेहतर तरीके से मैनेज करने में मदद मिलती है.

डेटा के इस्तेमाल पर नज़र रखना

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

एपीआई कोटा के इस्तेमाल को ऑप्टिमाइज़ करना

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

  • कैटलॉग मैनेजमेंट की सही रणनीति चुनें. एपीआई कोटा को समझने के बाद, आपको अपने ऐप्लिकेशन के लिए सही रणनीति चुननी होगी, ताकि आप अपने कैटलॉग मैनेजमेंट के लक्ष्यों को बेहतर तरीके से हासिल कर सकें.
  • अपने बदलावों को दिखाने के लिए, सिर्फ़ उतने ही कॉल करें जितने ज़रूरी हैं.
  • एपीआई को बदलाव करने के लिए, ग़ैर-ज़रूरी या ज़रूरत से ज़्यादा कॉल न भेजें. इसके लिए, आपको अपने बैकएंड कैटलॉग में बदलावों की जानकारी रखने की ज़रूरत पड़ सकती है.
  • प्रॉडक्ट में बदलाव करने के लिए, हर घंटे 7,200 क्वेरी से ज़्यादा न भेजें. हो सकता है कि आप ऐसी सिंक प्रोसेस बनाना चाहें जिनमें आपको कम समय में प्रॉडक्ट में बहुत सारे बदलाव करने पड़ें. उदाहरण के लिए, शुरुआती कैटलॉग बनाना. अगर आपको लगता है कि ये प्रोसेस हर घंटे की सीमा से ज़्यादा समय ले सकती हैं, तो ज़रूरत के हिसाब से इंतज़ार की अवधि लागू करें, ताकि इनका इस्तेमाल सुरक्षित लेवल तक कम हो सके. ज़्यादा थ्रूपुट पाने के लिए, बैच के तरीकों का इस्तेमाल करें. साथ ही, अपडेट के लिए थोड़ी देरी की अनुमति दें.
  • बड़े पैमाने पर काम करने के लिए पहले से तैयार रहें. आपके ऐप्लिकेशन के बड़े होने पर, आपको एपीआई और अलग-अलग एंडपॉइंट के इस्तेमाल को बढ़ाना पड़ सकता है. ज़्यादा से ज़्यादा इस्तेमाल के करीब पहुंचने पर, कोटा बढ़ाने का तरीका जानने के लिए, Google Play Developer API के कोटा से जुड़ा दस्तावेज़ पढ़ें.
  • ज़्यादा डेटा प्रोसेस करने के लिए, रणनीति के हिसाब से शेड्यूल बनाएं. कैटलॉग से जुड़ी ज़्यादा समय लेने वाली प्रोसेस को, इस्तेमाल के व्यस्त समय के आस-पास शेड्यूल करें. उदाहरण के लिए, हफ़्ते के उन दिनों में कैटलॉग को पूरी तरह से सिंक करने से बचें जब बिक्री सबसे ज़्यादा होती है.

कोटा से जुड़ी गड़बड़ी को मैनेज करने का लॉजिक जोड़ना

भले ही, आपने कैटलॉग मैनेजमेंट लॉजिक को कितनी अच्छी तरह से बनाया हो, आपको इसे कोटा की अचानक से होने वाली सीमाओं के हिसाब से बनाना चाहिए. ऐसा इसलिए, क्योंकि आपके इंटिग्रेशन के अलग-अलग मॉड्यूल में इस्तेमाल किए जाने वाले एंडपॉइंट, हर दिन के कोटा को शेयर करते हैं. पक्का करें कि आपने गड़बड़ी को मैनेज करने की प्रोसेस में, कोटा को कम करने से जुड़ी गड़बड़ियों को शामिल किया हो. साथ ही, सही समय के लिए इंतज़ार करने की सुविधा लागू की हो. Google Play डेवलपर एपीआई को किए गए हर कॉल से एक रिस्पॉन्स जनरेट होगा. कॉल पूरा न होने पर, आपको गड़बड़ी का जवाब मिलेगा. इसमें एचटीटीपी रिस्पॉन्स स्टेटस कोड और errors ऑब्जेक्ट शामिल होता है. इससे, गड़बड़ी वाले डोमेन और डीबग मैसेज के बारे में ज़्यादा जानकारी मिलती है. उदाहरण के लिए, अगर आपने रोज़ की तय सीमा से ज़्यादा अनुरोध किए, तो आपको इस तरह की गड़बड़ी दिख सकती है:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "usageLimits",
    "message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
  Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
  "reason" : "dailyLimitExceeded",
  "extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
  } ],
}

कैटलॉग मैनेजमेंट लागू करना

डेवलपर, Google Play Developer API के प्रॉडक्ट पब्लिश करने वाले एंडपॉइंट का इस्तेमाल करके, अपने कैटलॉग को अपने बैकएंड और Google Play के बीच सिंक रखते हैं. यह पक्का करना कि आपका Google Play कैटलॉग, बैकएंड के कैटलॉग की नई जानकारी के साथ हमेशा अप-टू-डेट रहे, इससे उपयोगकर्ताओं को बेहतर अनुभव मिलता है. उदाहरण के लिए:

  • आपको उपलब्ध ऑफ़र की पूरी सूची दिखेगी. साथ ही, ऑफ़र और बुनियादी प्लान टैग को मैनेज करके, अपनी ज़रूरी शर्तों और ऑफ़र दिखाने के लॉजिक पर असर डाला जा सकता है.
  • अलग-अलग प्लैटफ़ॉर्म पर, लोगों को दिखने वाले अलग-अलग प्राइस पॉइंट और प्रॉडक्ट की जानकारी देखी जा सकती है. साथ ही, यह पक्का किया जा सकता है कि वे एक जैसे हों.
  • नई खरीदारी प्रोसेस करते समय, आपके पास बैकएंड में प्रॉडक्ट की जानकारी होगी. इससे, उपयोगकर्ता के अहम फ़्लो के दौरान, Google Play डेवलपर एपीआई को अतिरिक्त कॉल करके, इंतज़ार का समय बढ़ाने और गड़बड़ी होने के जोखिम को कम करने में मदद मिलेगी.

Google Play पर प्रॉडक्ट कैटलॉग बनाते समय, आपको कुछ सीमाओं और बातों का ध्यान रखना चाहिए. इन सीमाओं को समझने और अपने कैटलॉग के स्ट्रक्चर के बारे में जानने के बाद, सिंक करने की रणनीति तय करें.

कैटलॉग सिंक करने की रणनीतियां

Google Play Developer API के पब्लिशिंग एंडपॉइंट की मदद से, बदलाव होने पर अपने कैटलॉग में अपडेट किए जा सकते हैं. कभी-कभी, आपको समय-समय पर अपडेट करने का तरीका अपनाना पड़ सकता है. इसमें, एक ही प्रोसेस में कई बदलाव भेजे जाते हैं. हर तरह के ऐप्लिकेशन के लिए, डिज़ाइन के अलग-अलग विकल्पों की ज़रूरत होती है. सिंक करने की हर रणनीति, इस्तेमाल के कुछ उदाहरणों के लिए दूसरों के मुकाबले बेहतर होगी. साथ ही, हो सकता है कि आपके पास ऐसी ज़रूरतें हों जिनके लिए दोनों रणनीतियों का इस्तेमाल करना पड़े. कभी-कभी, किसी नए बदलाव के बारे में पता चलने पर, आपको प्रॉडक्ट में तुरंत अपडेट करना पड़ सकता है. उदाहरण के लिए, प्रॉडक्ट में तुरंत अपडेट करने के लिए, जैसे कि गलत कीमत को जल्द से जल्द ठीक करना. इसके अलावा, समय-समय पर बैकग्राउंड में सिंक करने की सुविधा का इस्तेमाल करके, यह पक्का किया जा सकता है कि आपका बैकएंड और Play के कैटलॉग हमेशा एक जैसे हों. कैटलॉग मैनेजमेंट की इन अलग-अलग रणनीतियों को लागू करने के कुछ सामान्य उदाहरण पढ़ें.

लोकल कैटलॉग में बदलाव होने पर, अपडेट कब भेजने चाहिए

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

इस तरह के अपडेट तब एक अच्छा विकल्प होते हैं, जब:

  • आपको यह पक्का करना होगा कि आपके प्रॉडक्ट हमेशा अप-टू-डेट हों.
  • आपको हर दिन अपने प्रॉडक्ट में कुछ बदलाव करने होंगे.
  • आपको उन प्रॉडक्ट की जानकारी अपडेट करनी होगी जो पहले से ही प्रोडक्शन में हैं और बेचे जा रहे हैं.

इस तरीके को लागू करना आसान है. इससे आपको अपने कैटलॉग को कम से कम अंतर वाली विंडो के साथ सिंक करने में मदद मिलती है.

समय-समय पर अपडेट करने की सुविधा का इस्तेमाल कब करना चाहिए

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

  • आपको यह पक्का करने की ज़रूरत नहीं है कि आपके प्रॉडक्ट कम समय में अपडेट हो जाएं.
  • आपको एक साथ कई अपडेट करने या समझौता करने की प्रक्रियाओं को प्लान करना होगा.
  • आपके पास अपने डिजिटल प्रॉडक्ट मैनेज करने के लिए, पहले से ही कॉन्टेंट या कैटलॉग मैनेजमेंट सिस्टम है और वह आपके कैटलॉग को लगातार अपडेट करता है

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

अपना प्रॉडक्ट कैटलॉग बनाना

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

वन-टाइम प्रॉडक्ट बनाना

एक बार में कई प्रॉडक्ट का बड़ा कैटलॉग बनाने के लिए, हमारा सुझाव है कि आप inappproducts.batchUpdate तरीके का इस्तेमाल करें. इसके लिए, allowMissing फ़ील्ड को true पर और latencyTolerance फ़ील्ड को PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT पर सेट करें. इससे कोटा की सीमाओं के अंदर कैटलॉग बनाने में लगने वाला समय कम हो जाएगा.

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

सदस्यता वाले प्रॉडक्ट बनाना

सदस्यता की शुरुआत में बड़े कैटलॉग बनाने के लिए, हमारा सुझाव है कि आप monetization.subscriptions.batchUpdate तरीके का इस्तेमाल करें. इसके लिए, allowMissing फ़ील्ड को true पर और latencyTolerance फ़ील्ड को PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT पर सेट करें. इससे कोटा की सीमाओं के अंदर कैटलॉग बनाने में लगने वाला समय कम हो जाएगा.

छोटे सदस्यता कैटलॉग के लिए, Play Developer API monetization.subscriptions.create तरीका उपलब्ध कराता है. इसके अलावा, प्रॉडक्ट अपडेट सेक्शन में बताए गए तरीके के मुताबिक, allowMissing पैरामीटर के साथ monetization.subscriptions.patch का इस्तेमाल करके भी सदस्यताएं बनाई जा सकती हैं.

पहले के सभी तरीके, सदस्यताओं के साथ उनके बुनियादी प्लान भी बनाते हैं (जो सदस्यता ऑब्जेक्ट में दिए जाते हैं). ये बुनियादी प्लान शुरू में बंद रहते हैं. बुनियादी प्लान की स्थिति मैनेज करने के लिए, monetization.subscriptions.basePlans एंडपॉइंट का इस्तेमाल किया जा सकता है. इसमें, बुनियादी प्लान को खरीदारी के लिए उपलब्ध कराने के लिए, उसे चालू करना भी शामिल है. इसके अलावा, monetization.subscriptions.basePlans.offers एंडपॉइंट की मदद से ऑफ़र बनाए और मैनेज किए जा सकते हैं.

प्रॉडक्ट के अपडेट

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

एक बार खरीदे जाने वाले प्रॉडक्ट अपडेट करना

एक बार खरीदे जाने वाले मौजूदा प्रॉडक्ट को अपडेट करने के लिए, आपके पास तीन तरीके उपलब्ध हैं.

  • inappproducts.patch : पैच एंडपॉइंट का इस्तेमाल, किसी रिसॉर्स को कुछ हद तक अपडेट करने के लिए किया जाता है. इसका मतलब है कि आपके पास, अनुरोध के मुख्य हिस्से में बताए गए खास फ़ील्ड को अपडेट करने का विकल्प है. पैच एंडपॉइंट का इस्तेमाल आम तौर पर तब किया जाता है, जब आपको किसी संसाधन के कुछ फ़ील्ड को अपडेट करना हो.
  • inappproducts.update : अपडेट एंडपॉइंट का इस्तेमाल, किसी संसाधन को पूरी तरह से अपडेट करने के लिए किया जाता है. इसका मतलब है कि आपको अनुरोध बॉडी में पूरा रिसॉर्स ऑब्जेक्ट भेजना होगा. आम तौर पर, अपडेट एंडपॉइंट का इस्तेमाल तब किया जाता है, जब आपको किसी संसाधन के सभी फ़ील्ड अपडेट करने हों. जब allowMissing पैरामीटर को true पर सेट किया जाता है और दिया गया प्रॉडक्ट आईडी पहले से मौजूद नहीं होता, तो एंडपॉइंट, प्रॉडक्ट को डालने के बजाय उसे अस्वीकार कर देगा.
  • inappproducts.batchUpdate : यह अपडेट एंडपॉइंट का एक बैच वर्शन है. इसकी मदद से, एक ही क्वेरी से कई प्रॉडक्ट में बदलाव किया जा सकता है. ज़्यादा थ्रूपुट पाने के लिए, इसे PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT पर सेट किए गए latencyTolerance फ़ील्ड के साथ इस्तेमाल करें.

सदस्यता वाले प्रॉडक्ट अपडेट करना

मौजूदा सदस्यताओं को अपडेट करने के लिए, monetization.subscriptions.patch का तरीका अपनाएं. इस तरीके में, ये ज़रूरी पैरामीटर इस्तेमाल किए जाते हैं:

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

उदाहरण के लिए, अगर आपको सिर्फ़ सदस्यता वाले प्रॉडक्ट की लिस्टिंग अपडेट करनी है, तो आपको updateMask पैरामीटर में listings फ़ील्ड की जानकारी देनी होगी.

एक साथ कई सदस्यताओं को अपडेट करने के लिए, monetization.subscriptions.batchUpdate का इस्तेमाल किया जा सकता है. ज़्यादा ट्रांज़ैक्शन दर पाने के लिए, latencyTolerance फ़ील्ड के साथ इसका इस्तेमाल करें. इसके लिए, latencyTolerance फ़ील्ड को PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT पर सेट करें.

बुनियादी प्लान चालू करने, बंद करने, मिटाने या सदस्यों को बुनियादी प्लान की नई कीमत वाले वर्शन पर माइग्रेट करने के लिए, monetization.subscriptions.basePlans एंडपॉइंट का इस्तेमाल करें.

इसके अलावा, monetization.subscriptions.basePlans.offers.patch के तरीके से, अपने बुनियादी प्लान के ऑफ़र अपडेट किए जा सकते हैं.

कैटलॉग को मिलाना

अगर आपके पास Google Play के कैटलॉग के बाहर कोई कैटलॉग मैनेजमेंट सिस्टम या डेटाबेस है, तो हो सकता है कि आपके बैकएंड के कैटलॉग में बदलाव होने पर या समय-समय पर, Google Play के कैटलॉग के साथ कैटलॉग सिंक न हो. ऐसा Console में कैटलॉग में मैन्युअल तरीके से किए गए आपातकालीन बदलावों, आपके कैटलॉग मैनेजमेंट सिस्टम के बंद होने या आपका नया डेटा मिट जाने की वजह से हो सकता है.

अंतर की अवधि को लंबे समय तक बने रहने से रोकने के लिए, कैटलॉग को मिलाने की प्रोसेस बनाई जा सकती है.

अलग-अलग सिस्टम के लिए ध्यान देने वाली बातें

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

  • डेटा मॉडल को समझना: पहला चरण, डेवलपर सीएमएस और Google Play Developer API के डेटा मॉडल को समझना है. इसमें, हर सिस्टम में सेव किए गए अलग-अलग तरह के डेटा के बारे में जानना और यह जानना शामिल है कि अलग-अलग डेटा एलिमेंट एक-दूसरे से कैसे मैप होते हैं.
  • डेटा मॉडल समझने के बाद, आपको डेटा में अंतर के नियम तय करने होंगे: इन नियमों से यह तय होगा कि दोनों सिस्टम के डेटा की तुलना कैसे की जाएगी. उदाहरण के लिए, हो सकता है कि आप प्रॉडक्ट आईडी मैच करना चाहें और सदस्यता के मुख्य एट्रिब्यूट और उससे जुड़े बुनियादी प्लान और ऑफ़र की तुलना करना चाहें.
  • डफ़रेंस एल्गोरिदम लागू करना: डेटा के बीच अंतर के नियम तय करने के बाद, आपको डफ़रेंस एल्गोरिदम लागू करना होगा. यह एल्गोरिदम, दोनों सिस्टम से डेटा लेगा और आपके तय किए गए नियमों के हिसाब से उसकी तुलना करेगा. Google Play से कैटलॉग डेटा पाने के लिए, inappproducts.list, inappproducts.batchGet, monetization.subscriptions.list, और monetization.subscriptions.batchGet तरीकों का इस्तेमाल किया जा सकता है.
  • डफ़रेंस रिपोर्ट जनरेट करना: डिफ़रेंस एल्गोरिदम, डिफ़रेंस रिपोर्ट जनरेट करेगा. इस रिपोर्ट में, दोनों सिस्टम के बीच के अंतर दिखेंगे.
  • अंतरों को मिलाना: अंतर की रिपोर्ट जनरेट करने के बाद, आपको अंतरों को ठीक करना होगा. इसके लिए, आपके सीएमएस में डेटा अपडेट करना पड़ सकता है. इसके अलावा, Developer API के कैटलॉग मैनेजमेंट एंडपॉइंट का इस्तेमाल करके, Google Play पर डेटा अपडेट करना पड़ सकता है. यह इस बात पर निर्भर करता है कि आम तौर पर आपके कैटलॉग को कैसे अपडेट किया जाता है. सिंक नहीं हुए प्रॉडक्ट को मिलान करने के लिए, अपडेट एंडपॉइंट का इस्तेमाल करें. इनके बारे में, प्रॉडक्ट अपडेट सेक्शन में बताया गया है.

प्रॉडक्ट का बंद होना

Google Play Developer API, डेवलपर को अपने प्रॉडक्ट बंद करने में मदद करने के लिए कई तरीके उपलब्ध कराता है: वन-टाइम प्रॉडक्ट के लिए, inappproducts.delete और सदस्यताओं के लिए, inappproducts.batchDelete और monetization.subscriptions.delete. किसी प्रॉडक्ट को बंद करना कई स्थितियों में ज़रूरी हो सकता है, जैसे कि:

  • गलती से बनाया गया हो.
  • किसी सुविधा या सेवा को बंद करना.

हमारा सुझाव है कि आप अपने कैटलॉग मैनेजमेंट की रणनीति में, प्रॉडक्ट को हटाने की सुविधा को शामिल करें.

वन-टाइम प्रॉडक्ट की सुविधा बंद करना

Google Play Developer API की मदद से, एक बार खरीदे जाने वाले प्रॉडक्ट मिटाने के लिए, आपको inappproducts.delete या inappproducts.batchDelete वाला तरीका अपनाना होगा.

सदस्यता वाले प्रॉडक्ट की सुविधा बंद करना

monetization.subscriptions.delete के तरीके का इस्तेमाल करके, सदस्यताएं मिटाई जा सकती हैं. कम से कम एक बुनियादी प्लान चालू होने के बाद, सदस्यता को हटाया नहीं जा सकता.