แนวทางปฏิบัติที่ดี
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
แนวทางปฏิบัติแนะนำต่อไปนี้ใช้กับการผสานรวมโฆษณาบริการในพื้นที่แบบครบวงจรของศูนย์การดําเนินการ และสามารถใช้ประโยชน์เพื่อหลีกเลี่ยงปัญหาด้านความสามารถในการใช้งานและประสิทธิภาพ
คุณภาพของข้อมูลต่ำอาจส่งผลให้มีการลบสินค้าคงคลัง
ฟีด
เซิร์ฟเวอร์การจอง
หากต้องการเพิ่มประสิทธิภาพการผสานรวม 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% ของเวลา
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-26 UTC
[null,null,["อัปเดตล่าสุด 2025-07-26 UTC"],[[["\u003cp\u003eMaintain high data quality in feeds to prevent inventory removal and ensure accurate service representation.\u003c/p\u003e\n"],["\u003cp\u003eUtilize the BookingNotifications API for real-time updates to booking details like start times, duration, and status changes.\u003c/p\u003e\n"],["\u003cp\u003eOptimize the Booking Server integration by using UTC timestamps and generating unique booking IDs for new bookings.\u003c/p\u003e\n"],["\u003cp\u003eWhen implementing Inventory Real-Time Updates, use batch updates, restrict edit targets, and incorporate exponential backoff to avoid errors.\u003c/p\u003e\n"],["\u003cp\u003eEnsure API response times are under one second and the server can handle at least five queries per second with minimal latency.\u003c/p\u003e\n"]]],["Integrate feeds with specific `Category` values and set service durations in `duration_sec`, avoiding zero values. Use `gzip` for feed compression. In the booking server, employ UNIX timestamps, generate unique booking IDs, and ensure real-time updates via the BookingNotifications API for any booking changes. Update availability in batches, use `Restrict` fields, and manage threads with exponential backoff to avoid quota errors. Maintain API response times under one second, and five QPS at sub-second latency.\n"],null,["# Best practices\n\nThe following best practices apply to the Actions Center Local Services Ads End-to-End\nintegration and can be leveraged to avoid usability and performance issues.\nLow data quality might lead to inventory takedown.\n\nFeeds\n-----\n\n- If a service doesn't have a set length, set `duration_sec` in the Availability feed to one of the following:\n - The number of seconds it takes to perform the service in a reasonable manner.\n - The average number of seconds required to complete the service.\n\n | **Note:** If a length of `0` is submitted in the feed, our system counts that availability slot as invalid and doesn't show it on the Actions Center.\n- Make the `Category` field input in the merchant's feed is specific. For example, a restaurant might submit a specific type, such as French or Japanese. For details, see [Place types](/maps/documentation/places/web-service/supported_types) for potential category values.\n- Set merchant-specific terms of service in the `Terms` field\n of the Merchant feed so that the following note appears below the\n **Book** button:\n\n \u003cbr /\u003e\n\n \u003e By continuing, you agree to \u003cvar translate=\"no\"\u003e<merchant>\u003c/var\u003e's Terms of Service.\n In this case, \"Terms of Service\" is a link that, when clicked, displays the text set in the *terms* text field.\n\n \u003cbr /\u003e\n\n- [Compress your feeds using `gzip`](/actions-center/verticals/local-services/e2e/reference/tutorials/compression)\n\nBooking Server\n--------------\n\nTo optimize your integration of the Maps Booking API, do the following:\n\n- Always use UNIX timestamps in UTC format.\n- Generate a unique booking ID when a new booking in the [`CreateBooking`](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-methods/createbooking-method) API is called.\n\nReal-time updates\n-----------------\n\nTo ensure the best user experience during the booking process, do the\nfollowing:\n\n- For a standard implementation, use the BookingNotifications API to change the start time, duration, and booking state, such as cancellation or no-show, of an appointment.\n- Upon any change on the Actions Center booking from your side, always send real-time booking updates from the system with the BookingNotification API in real-time so that the data doesn't become stale on the Actions Center side. For example, you can cancel, reschedule, or update a booking from your system in the Actions Center.\n- For every booking update from `UpdateBookingRequest`, make sure that the `UpdateBookingResponse` value contains the booking ID and that **all** updated fields must reflect the new value.\n- If [Inventory RTU](/actions-center/verticals/local-services/e2e/integration-steps/real-time-api-updates) are implemented\n - Only update availability in batches of 100-1000 slots per API call.\n - Use `*Restrict` (such as `startTimeRestrict`) fields to narrow the edit target, reduce payload size and avoid re-sending too much unchanged data.\n - If you spin off several threads, implement an [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff) to prevent throttle errors. If you don't implement an exponential backoff correctly, you might get a `RESOURCE_EXHAUSTED` [quota error](/actions-center/verticals/local-services/e2e/integration-steps/real-time-api-updates#api-quotas). You can retry the exponential backoff to handle them, but, if you find that your server often reaches quotas when you run `ReplaceServiceAvailability`, configure your server to [batch replace for availability](/maps-booking/reference/maps-booking-api/rest/v1alpha/inventory.partners.availability/replace). This solution prevents quota errors because it reduces the number of API calls your serve has to make.\n- Set your API call response time limits to less than one second. Ensure that your server can handle five queries per second (QPS) with sub-second latency at least 95% of the time."]]
