Рекомендации
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Следующие рекомендации применимы к сквозной интеграции с Рекламой местных услуг Центра действий и могут быть использованы, чтобы избежать проблем с удобством использования и производительностью. Низкое качество данных может привести к удалению инвентаря.
Ленты
Сервер бронирования
Чтобы оптимизировать интеграцию Maps Booking API, выполните следующие действия:
- Всегда используйте временные метки UNIX в формате UTC.
- Создавайте уникальный идентификатор бронирования при вызове нового бронирования в API
CreateBooking .
Обновления в реальном времени
Чтобы обеспечить максимальное удобство взаимодействия с пользователем во время процесса бронирования, выполните следующие действия:
- В стандартной реализации используйте API BookingNotifications, чтобы изменить время начала, продолжительность и состояние бронирования, например отмену или неявку встречи.
- При любых изменениях в бронировании в Центре действий с вашей стороны всегда отправляйте обновления бронирования в режиме реального времени из системы с помощью API BookingNotification в режиме реального времени, чтобы данные не устаревали на стороне Центра действий. Например, вы можете отменить, перенести или обновить бронирование из своей системы в Центре действий.
- Для каждого обновления бронирования из
UpdateBookingRequest убедитесь, что значение UpdateBookingResponse содержит идентификатор бронирования и что все обновленные поля должны отражать новое значение. - Если Inventory RTU реализован
- Обновляйте доступность только партиями по 100–1000 слотов на вызов API.
- Используйте поля
*Restrict (например, startTimeRestrict ), чтобы сузить область редактирования, уменьшить размер полезных данных и избежать повторной отправки слишком большого количества неизмененных данных. - Если вы выделяете несколько потоков, реализуйте экспоненциальную отсрочку , чтобы предотвратить ошибки регулирования. Если вы неправильно реализуете экспоненциальную отсрочку, вы можете получить ошибку квоты
RESOURCE_EXHAUSTED . Вы можете повторить экспоненциальную отсрочку, чтобы справиться с ними, но если вы обнаружите, что ваш сервер часто достигает квот при запуске ReplaceServiceAvailability , настройте свой сервер на пакетную замену для обеспечения доступности . Это решение предотвращает ошибки квоты, поскольку уменьшает количество вызовов API, которые должен выполнить ваш сервис.
- Установите ограничение времени ответа на вызов API менее одной секунды. Убедитесь, что ваш сервер может обрабатывать пять запросов в секунду (QPS) с задержкой менее секунды как минимум в 95 % случаев.
Если не указано иное, контент на этой странице предоставляется по лицензии Creative Commons "С указанием авторства 4.0", а примеры кода – по лицензии Apache 2.0. Подробнее об этом написано в правилах сайта. Java – это зарегистрированный товарный знак корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-24 UTC.
[null,null,["Последнее обновление: 2025-07-24 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."]]
