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

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

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

Catalog Management API

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

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

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

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

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

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

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

बैच के तरीके

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

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

अपडेट के फैलने में लगने वाला समय बनाम थ्रूपुट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस तरह के अपडेट तब सबसे सही होते हैं, जब:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कैटलॉग से जुड़े समाधान

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

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

डिफ़ सिस्टम के बारे में जानकारी

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

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

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

Google Play डेवलपर एपीआई, आपके प्रॉडक्ट को बंद करने में आपकी मदद करने के लिए ये तरीके उपलब्ध कराता है:

वन-टाइम प्रॉडक्ट के लिए:

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

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

कई स्थितियों में किसी प्रॉडक्ट को बंद करना ज़रूरी हो सकता है. जैसे:

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

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