ये सबसे सही तरीके, 'Google से रिज़र्व' में शुरू से लेकर आखिर तक इंटिग्रेशन पर लागू होते हैं. उपयोगिता और परफ़ॉर्मेंस से जुड़ी समस्याओं से बचने के लिए, इन तरीकों का इस्तेमाल किया जा सकता है. डेटा क्वालिटी कम होने की वजह से इन्वेंट्री को हटाया जा सकता है.
फ़ीड
- अगर किसी सेवा की लंबाई तय नहीं है, तो उपलब्धता फ़ीड में
duration_secको इनमें से किसी एक पर सेट करें:- सही तरीके से सेवा देने में लगने वाले सेकंड.
-
इस सेवा को पूरा करने के लिए, सेकंड की औसत संख्या.
- व्यापारी/कंपनी के फ़ीड में
Categoryफ़ील्ड डालें. उदाहरण के लिए, कोई रेस्टोरेंट खास तरह का सामान सबमिट कर सकता है, जैसे कि फ़्रेंच या जैपनीज़. जानकारी के लिए, संभावित कैटगरी की वैल्यू के लिए जगह के टाइप देखें. -
व्यापारी/कंपनी फ़ीड के
Termsफ़ील्ड में खास तौर पर व्यापारी के लिए सेवा की शर्तें सेट करें, ताकि यह जानकारी बुक करें बटन के नीचे दिखाई दे:जारी रखने का मतलब है कि आप <merchant> की सेवा की शर्तों से सहमत हैं.
इस मामले में, "सेवा की शर्तें" ऐसा लिंक है जिस पर क्लिक करने पर, टेक्स्ट की शर्तें शर्तें टेक्स्ट फ़ील्ड में दिखती हैं. -
gzipका इस्तेमाल करके अपने फ़ीड कंप्रेस करना
बुकिंग सर्वर
Maps Booking API के इंटिग्रेशन को ऑप्टिमाइज़ करने के लिए, ये करें:
- UTC फ़ॉर्मैट में, UNIX टाइमस्टैंप का इस्तेमाल करें.
CreateBookingमें नई बुकिंग को कॉल करने पर, यूनीक बुकिंग आईडी जनरेट करें.
रीयल-टाइम अपडेट
बुकिंग के दौरान, उपयोगकर्ता को सबसे अच्छा अनुभव मिले, यह पक्का करने के लिए ये करें:
- एक स्टैंडर्ड तरीके के लिए, BookingNotifications के एपीआई का इस्तेमाल करके, अपॉइंटमेंट शुरू होने का समय, अवधि, और बुकिंग की स्थिति बदलें. जैसे, अपॉइंटमेंट रद्द करना या नहीं दिखाना.
- Reserve with Google की बुकिंग में किसी भी तरह का बदलाव करने पर, सिस्टम से बुकिंग के अपडेट रीयल-टाइम में हमेशा भेजें. इससे Reserve with Google पर डेटा पुराना नहीं होगा. उदाहरण के लिए, 'Google से रिज़र्व' में जाकर, अपने सिस्टम से बुकिंग रद्द की जा सकती है, उसमें बदलाव किए जा सकते हैं या उसे अपडेट किया जा सकता है.
UpdateBookingRequestसे बुकिंग के हर अपडेट के लिए, पक्का करें किUpdateBookingResponseवैल्यू में बुकिंग आईडी शामिल हो. साथ ही, सभी अपडेट किए गए फ़ील्ड में नई वैल्यू दिखनी चाहिए.-
अगर इन्वेंट्री RTU
लागू की गई है
- हर एपीआई कॉल के लिए, 100 से 1,000 स्लॉट की उपलब्धता की जानकारी अपडेट करें.
-
बदलाव टारगेट को सीमित करने, पेलोड का साइज़ कम करने, और बहुत ज़्यादा बिना बदलाव किए डेटा भेजने से बचने के लिए,
*Restrict(जैसेstartTimeRestrict) फ़ील्ड का इस्तेमाल करें. -
अगर आप कई थ्रेड को स्पिन करते हैं, तो थ्रॉटल गड़बड़ियों को रोकने के लिए, एक्स्पोनेंशियल बैकऑफ़ लागू करें. अगर एक्स्पोनेंशियल बैकऑफ़ को सही तरीके से लागू नहीं किया जाता है, तो आपको
RESOURCE_EXHAUSTEDकोटा गड़बड़ी दिख सकती है. उन्हें हैंडल करने के लिए एक्स्पोनेंशियल बैकऑफ़ फिर से करने की कोशिश की जा सकती है. हालांकि, अगर आपको लगता है किReplaceServiceAvailabilityको चलाने पर, आपका सर्वर अक्सर कोटा तक पहुंच जाता है, तो अपने सर्वर को उपलब्धता के लिए बैच रिप्लेसमेंट पर कॉन्फ़िगर करें. यह समाधान कोटा से जुड़ी गड़बड़ियों को रोकता है, क्योंकि यह आपके विज्ञापन से किए जाने वाले एपीआई कॉल की संख्या कम करता है.
- अपने एपीआई कॉल के जवाब देने की समय सीमा एक सेकंड से कम पर सेट करें. पक्का करें कि आपका सर्वर पांच सेकंड प्रति सेकंड (क्यूपीएस) हैंडल कर सकता हो. साथ ही, इंतज़ार का समय कम से कम 95% समय सकता है.