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

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

ฟีด

• หากบริการไม่ได้กำหนดความยาวไว้ ให้ตั้งค่า 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% ของเวลาทั้งหมด