แนวทางปฏิบัติแนะนำ

แนวทางปฏิบัติแนะนําต่อไปนี้มีผลกับการผสานรวมจาก "จองกับ Google" ตั้งแต่ต้นจนจบ รวมทั้งยังใช้เพื่อหลีกเลี่ยงปัญหาด้านการใช้งานและประสิทธิภาพได้ ข้อมูลคุณภาพต่ําอาจทําให้พื้นที่โฆษณาถูกลบ

ฟีด

• หากบริการไม่ได้กําหนดความยาวไว้ ให้กําหนด duration_sec ในฟีดความพร้อมจําหน่ายสินค้าเป็นแบบใดแบบหนึ่งต่อไปนี้
  • จํานวนวินาทีที่ใช้ในการให้บริการในลักษณะที่เหมาะสม

  • จํานวนวินาทีโดยเฉลี่ยที่จําเป็นในการให้บริการ

    หมายเหตุ: หากระบบส่งความยาวของ 0 ในฟีด ระบบของเราจะนับช่องเวลาว่างนั้นไม่ถูกต้องและไม่แสดงในช่อง "จองกับ Google"
• ตรวจสอบว่าข้อมูลที่ป้อนในช่อง Category ในฟีดของผู้ขายเฉพาะเจาะจง ตัวอย่างเช่น ร้านอาหารอาจส่งประเภทที่เจาะจง เช่น ฝรั่งเศสหรือญี่ปุ่น โปรดดูรายละเอียดที่หัวข้อประเภทสถานที่สําหรับค่าหมวดหมู่ที่เป็นไปได้

• ตั้งค่าข้อกําหนดในการให้บริการเฉพาะผู้ขายในช่อง Terms ของฟีดผู้ขาย เพื่อให้หมายเหตุต่อไปนี้ปรากฏขึ้นใต้ปุ่มจอง

  การดําเนินการต่อหมายความว่าคุณยอมรับข้อกําหนดในการให้บริการของ <merchant>

  ในกรณีนี้ "ข้อกําหนดในการให้บริการ" เป็นลิงก์ที่เมื่อคลิกจะแสดงข้อความในช่องข้อความข้อกําหนด

• บีบอัดฟีดโดยใช้ gzip

เซิร์ฟเวอร์การจอง

หากต้องการเพิ่มประสิทธิภาพการผสานรวม Maps Booking API ให้ทําดังนี้

• ใช้การประทับเวลา UNIX ในรูปแบบ UTC เสมอ
• สร้างรหัสการจองที่ไม่ซ้ํากันเมื่อมีการจองใหม่ใน API ของ CreateBooking

การอัปเดตแบบเรียลไทม์

ทําตามขั้นตอนต่อไปนี้เพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีที่สุดระหว่างขั้นตอนการจอง

• สําหรับการใช้งานมาตรฐาน ให้ใช้ BookingNotifications API เพื่อเปลี่ยนเวลาเริ่มต้น ระยะเวลา และสถานะการจอง เช่น การยกเลิกหรือไม่แสดงการนัดหมาย
• เมื่อทําการเปลี่ยนแปลง "จองกับ Google" จากฝั่งของคุณ ให้ส่งข้อมูลอัปเดตเกี่ยวกับการจองแบบเรียลไทม์จากระบบด้วย BookingNotification API แบบเรียลไทม์เสมอ เพื่อไม่ให้ข้อมูลกลายเป็นข้อมูลเก่าในฟีเจอร์จองกับ Google เช่น ยกเลิก กําหนดเวลาใหม่ หรืออัปเดตการจองจากระบบได้ใน "จองกับ Google"
• สําหรับการอัปเดตการจองทุกรายการจาก UpdateBookingRequest ให้ตรวจสอบว่าค่า UpdateBookingResponse มีรหัสการจอง และช่องที่อัปเดตทั้งหมดต้องแสดงค่าใหม่
• หากใช้ RTU ของพื้นที่โฆษณา
  • อัปเดตความพร้อมจําหน่ายสินค้าเป็นกลุ่มในช่อง 100-1,000 ช่องต่อการเรียก API เท่านั้น
  • ใช้ช่อง *Restrict (เช่น startTimeRestrict) เพื่อจํากัดเป้าหมายการแก้ไขให้แคบลง ลดขนาดเพย์โหลด และหลีกเลี่ยงการส่งข้อมูลที่ไม่เปลี่ยนแปลงมากเกินไปมากเกินไป
  • หากเลิกใช้ชุดข้อความหลายชุด ให้ใช้ Exponential Backoff เพื่อป้องกันข้อผิดพลาดควบคุม หากคุณไม่ได้ใช้ Exponential Backoff อย่างถูกต้อง คุณอาจได้รับ RESOURCE_EXHAUSTED ข้อผิดพลาดโควต้า คุณสามารถลองใช้ Exponential Backoff เพื่อจัดการข้อผิดพลาดดังกล่าวได้ แต่หากพบว่าเซิร์ฟเวอร์มักจะถึงโควต้าเมื่อเรียกใช้ ReplaceServiceAvailability ให้กําหนดค่าเซิร์ฟเวอร์เป็นการแทนที่แบบกลุ่มเพื่อความพร้อมใช้งาน โซลูชันนี้ป้องกันข้อผิดพลาดเกี่ยวกับโควต้าเพราะลดจํานวนการเรียก API ที่บริการของคุณต้องดําเนินการ
• จํากัดเวลาในการตอบกลับของการเรียก API ไม่เกิน 1 วินาที ตรวจสอบว่าเซิร์ฟเวอร์ของคุณจัดการคําค้นหา 5 รายการต่อวินาที (QPS) ได้โดยมีเวลาในการตอบสนองต่ํากว่า 95% ของเวลาทั้งหมด