แนวทางปฏิบัติที่ดี

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

ฟีด

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

  • จำนวนวินาทีโดยเฉลี่ยที่ใช้ในการดำเนินการบริการให้เสร็จสมบูรณ์

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

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

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

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

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

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

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

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

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

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

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