권장사항
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
다음 권장사항은 액션 센터 지역 서비스 광고 엔드 투 엔드 통합에 적용되며 사용성 및 성능 문제를 방지하는 데 활용할 수 있습니다.
데이터 품질이 낮으면 인벤토리가 게시 중단될 수 있습니다.
피드
예약 서버
Maps Booking API 통합을 최적화하려면 다음 단계를 따르세요.
- 항상 UTC 형식의 UNIX 타임스탬프를 사용하세요.
-
CreateBooking
API에서 새 예약이 호출될 때 고유한 예약 ID를 생성합니다.
실시간 업데이트
예약 절차 중에 최상의 사용자 환경을 제공하려면 다음 단계를 따르세요.
- 표준 구현의 경우 BookingNotifications API를 사용하여 상담의 시작 시간, 기간, 예약 상태(예: 취소 또는 불참)를 변경합니다.
- 내 측에서 액션 센터 예약을 변경할 때마다 항상 BookingNotification API를 사용하여 시스템에서 실시간 예약 업데이트를 실시간으로 전송하여 액션 센터 측에서 데이터가 비활성화되지 않도록 합니다. 예를 들어 작업 센터에서 시스템의 예약을 취소, 일정 변경 또는 업데이트할 수 있습니다.
UpdateBookingRequest의 모든 예약 업데이트의 경우 UpdateBookingResponse 값에 예약 ID가 포함되어야 하며 업데이트된 모든 필드에 새 값이 반영되어야 합니다.
-
인벤토리 RTU가 구현된 경우
- API 호출당 100~1,000개의 시간대를 일괄적으로만 이용 가능 여부를 업데이트합니다.
-
*Restrict (예: startTimeRestrict) 필드를 사용하여 수정 타겟을 좁히고, 페이로드 크기를 줄이며, 변경되지 않은 데이터를 너무 많이 다시 전송하지 않습니다.
-
여러 스레드를 분할하는 경우 제한 오류를 방지하기 위해 지수 백오프를 구현합니다. 지수 백오프를 올바르게 구현하지 않으면
RESOURCE_EXHAUSTED
할당량 오류가 발생할 수 있습니다.
지수 백오프를 다시 시도하여 이를 처리할 수 있지만 ReplaceServiceAvailability를 실행할 때 서버가 할당량에 자주 도달하는 경우 가용성을 위해 일괄 교체하도록 서버를 구성하세요.
이 솔루션은 서비스에서 실행해야 하는 API 호출 수를 줄여주므로 할당량 오류를 방지합니다.
- API 호출 응답 시간 제한을 1초 미만으로 설정합니다. 서버가 시간의 95% 이상 동안 지연 시간을 1초 미만으로 유지하면서 초당 5개의 쿼리 (QPS)를 처리할 수 있는지 확인합니다.
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 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."]]
