सबसे सही तरीके

यहां दिए गए सबसे सही तरीके, ऐक्शन सेंटर के Local Services Ads के एंड-टू-एंड इंटिग्रेशन पर लागू होते हैं. इनका इस्तेमाल, इस्तेमाल करने और परफ़ॉर्मेंस से जुड़ी समस्याओं से बचने के लिए किया जा सकता है. डेटा की खराब क्वालिटी की वजह से, इन्वेंट्री हटाई जा सकती है.

फ़ीड

• अगर किसी सेवा की अवधि तय नहीं है, तो उपलब्धता फ़ीड में duration_sec को इनमें से किसी एक पर सेट करें:
  • सेवा को सही तरीके से पूरा करने में लगने वाले सेकंड की संख्या.

  • सेवा पूरी करने में लगने वाले औसत सेकंड.

• व्यापारी/कंपनी/कारोबारी के फ़ीड में Category फ़ील्ड का इनपुट, खास हो. उदाहरण के लिए, कोई रेस्टोरेंट किसी खास तरह का खाना, जैसे कि फ़्रेंच या जैपनीज़ सबमिट कर सकता है. ज़्यादा जानकारी के लिए, संभावित कैटगरी वैल्यू के लिए जगह के टाइप देखें.

• व्यापारी/कंपनी/कारोबारी के फ़ीड के Terms फ़ील्ड में, सेवा की ऐसी शर्तें सेट करें जो व्यापारी/कंपनी/कारोबारी के हिसाब से हों. इससे, बुक करें बटन के नीचे यह नोट दिखेगा:

  जारी रखने का मतलब है कि आप <merchant> की सेवा की शर्तों से सहमत हैं.

  इस मामले में, "सेवा की शर्तें" एक लिंक है. इस पर क्लिक करने पर, शर्तें टेक्स्ट फ़ील्ड में सेट किया गया टेक्स्ट दिखता है.

• gzip का इस्तेमाल करके अपने फ़ीड को कंप्रेस करना

बुकिंग सर्वर

Maps Booking API के इंटिग्रेशन को ऑप्टिमाइज़ करने के लिए, यह तरीका अपनाएं:

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

रीयल-टाइम अपडेट

बुकिंग की प्रोसेस के दौरान, उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, ये काम करें:

• स्टैंडर्ड तरीके से लागू करने के लिए, BookingNotifications API का इस्तेमाल करके अपॉइंटमेंट के शुरू होने का समय, समयसीमा, और बुकिंग की स्थिति बदलें. जैसे, बुकिंग रद्द करना या अपॉइंटमेंट पर न आना.
• अगर आपने ऐक्शन सेंटर में बुकिंग में कोई बदलाव किया है, तो BookingNotification API की मदद से सिस्टम से रीयल-टाइम में बुकिंग के अपडेट भेजें. इससे, ऐक्शन सेंटर में डेटा पुराना नहीं होगा. उदाहरण के लिए, ऐक्शन सेंटर में जाकर, अपने सिस्टम से किसी बुकिंग को रद्द किया जा सकता है, फिर से शेड्यूल किया जा सकता है या अपडेट किया जा सकता है.
• UpdateBookingRequest से मिली हर बुकिंग के अपडेट के लिए, पक्का करें कि UpdateBookingResponse वैल्यू में बुकिंग आईडी शामिल हो और अपडेट किए गए सभी फ़ील्ड में नई वैल्यू दिखे.
• अगर इन्वेंट्री आरटीयू लागू किए गए हैं
  • हर एपीआई कॉल के लिए, सिर्फ़ 100 से 1,000 स्लॉट के बैच में उपलब्धता अपडेट करें.
  • बदलाव के टारगेट को छोटा करने, पेलोड का साइज़ कम करने, और बदलाव न किए गए ज़्यादा डेटा को फिर से भेजने से बचने के लिए, *Restrict (जैसे कि startTimeRestrict) फ़ील्ड का इस्तेमाल करें.
  • अगर कई थ्रेड शुरू की जाती हैं, तो ट्रैफ़िक कम करने से जुड़ी गड़बड़ियों से बचने के लिए, एक्सपोनेंशियल बैकऑफ़ लागू करें. एक्सपोनेंशियल बैकऑफ़ को सही तरीके से लागू न करने पर, आपको RESOURCE_EXHAUSTED कोटा से जुड़ी गड़बड़ी का मैसेज मिल सकता है. इन्हें मैनेज करने के लिए, एक्सपोनेंशियल बैकऑफ़ को फिर से आज़माया जा सकता है. हालांकि, अगर आपको लगता है कि ReplaceServiceAvailability को चलाने पर, आपका सर्वर अक्सर कोटा तक पहुंच जाता है, तो अपने सर्वर को उपलब्धता के लिए एक साथ कई बदलाव करने के लिए कॉन्फ़िगर करें. यह समाधान कोटा से जुड़ी गड़बड़ियों को रोकता है, क्योंकि इससे आपकी सेवा को एपीआई कॉल की संख्या कम करनी पड़ती है.
• एपीआई कॉल के जवाब मिलने में लगने वाले समय की सीमा को एक सेकंड से कम पर सेट करें. पक्का करें कि आपका सर्वर, कम से कम 95% समय के लिए, एक सेकंड में पांच क्वेरी (क्यूपीएस) को एक सेकंड से कम के इंतज़ार के साथ मैनेज कर सकता हो.