Các phương pháp hay nhất
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Các phương pháp hay nhất sau đây áp dụng cho việc tích hợp Quảng cáo dịch vụ địa phương toàn diện trong Trung tâm hành động và có thể được tận dụng để tránh các vấn đề về hiệu suất và khả năng hữu dụng.
Chất lượng dữ liệu thấp có thể dẫn đến việc gỡ bỏ khoảng không quảng cáo.
Nguồn cấp dữ liệu
Máy chủ đặt phòng
Để tối ưu hoá việc tích hợp API Đặt trước trên Maps, hãy làm như sau:
- Luôn sử dụng dấu thời gian UNIX ở định dạng UTC.
- Tạo mã đặt phòng duy nhất khi một lượt đặt phòng mới trong API
CreateBooking
được gọi.
Thông tin cập nhật theo thời gian thực
Để đảm bảo người dùng có trải nghiệm tốt nhất trong quá trình đặt phòng, hãy làm như sau:
- Để triển khai theo tiêu chuẩn, hãy sử dụng API BookingNotifications để thay đổi thời gian bắt đầu, thời lượng và trạng thái đặt phòng, chẳng hạn như huỷ hoặc không đến của một cuộc hẹn.
- Khi có bất kỳ thay đổi nào về lượt đặt phòng trên Actions Center từ phía bạn, hãy luôn gửi thông tin cập nhật về lượt đặt phòng theo thời gian thực từ hệ thống bằng BookingNotification API theo thời gian thực để dữ liệu không bị lỗi thời trên Actions Center. Ví dụ: bạn có thể huỷ, lên lịch lại hoặc cập nhật một yêu cầu đặt phòng từ hệ thống của mình trong Trung tâm hành động.
- Đối với mỗi nội dung cập nhật về lượt đặt phòng từ
UpdateBookingRequest, hãy đảm bảo rằng giá trị UpdateBookingResponse chứa mã đặt phòng và tất cả trường đã cập nhật phải phản ánh giá trị mới.
-
Nếu Inventory RTU được triển khai
- Chỉ cập nhật tình trạng còn chỗ theo lô từ 100 đến 1.000 chỗ mỗi lệnh gọi API.
-
Sử dụng các trường
*Restrict (chẳng hạn như startTimeRestrict) để thu hẹp mục tiêu chỉnh sửa, giảm kích thước tải trọng và tránh gửi lại quá nhiều dữ liệu không thay đổi.
-
Nếu bạn tạo nhiều luồng, hãy triển khai thời gian đợi luỹ thừa để ngăn lỗi điều tiết. Nếu không triển khai thời gian đợi luỹ thừa đúng cách, bạn có thể gặp phải lỗi hạn mức
RESOURCE_EXHAUSTED.
Bạn có thể thử lại thời gian đợi luỹ thừa để xử lý các lỗi này, nhưng nếu bạn thấy máy chủ thường đạt đến hạn mức khi chạy ReplaceServiceAvailability, hãy định cấu hình máy chủ để thay thế hàng loạt cho tình trạng còn hàng.
Giải pháp này ngăn chặn lỗi hạn mức vì giúp giảm số lượng lệnh gọi API mà máy chủ của bạn phải thực hiện.
- Đặt giới hạn thời gian phản hồi lệnh gọi API thành dưới một giây. Đảm bảo rằng máy chủ của bạn có thể xử lý 5 truy vấn mỗi giây (QPS) với độ trễ dưới một giây ít nhất 95% thời gian.
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-07-26 UTC.
[null,null,["Cập nhật lần gần đây nhất: 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."]]
