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

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

फ़ीड

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

  • सेवा को पूरा करने के लिए ज़रूरी सेकंड की औसत संख्या.

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

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

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

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

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

बुकिंग सर्वर

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

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

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

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

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