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

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

ฟีด

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

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

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

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

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

  • บีบอัดฟีดของคุณโดยใช้ gzip

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

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

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

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

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

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