The following integration policies apply to the Reservations Offers integration.
Offers policy
Landing Page (mobile page & application)
- All Offers shared with Google for any restaurant must be visible with all
relevant information on the mobile web landing page.
- The offer value and description text must be visible on the landing page directly.
- Landing pages must clearly and comprehensively outline the eligibility requirements for each offer. This includes restrictions related to user segments, payment methods, specific days or times, minimum spending amounts, the number of times the offer can be used, type of meals (lunch/dinner), limitation to certain courses, and requirement for any subscription.
- All other offer restrictions (ex: conditions of eligibility, redeeming instruction, terms …) must be visible on the landing page or accessible within 1 click of the landing page (ex: pop-up dialog).
- For all offers except
OFFER_MODE_WALK_INoffers, the user must be able to complete the associated action flow (placing a booking, paying for a prepaid reservation …) on mobile web and the user must be able to select the offer(s) applicable with their selection (example: For reservation, offers applicable for the time slot and party size selected). - The redeeming instructions and methods must be clearly stated and actionable (ex: if redeeming the offer requires paying the bill on the partner system at checkout, the instruction to pay on the system should be mentioned and the user should be able to pay the bill on the partner system at checkout).
- When an offer URL redirects to a partner's installed mobile application, the
application's landing page must meet all requirements outlined in this
section for offer landing pages.
- Upon navigating back (e.g., using the back button, gesture navigation) immediately after interacting with an offer on a Google experience, users must be returned to the originating Google experience.
Offers Data & Format
- Partners must adhere to the specified technical requirements and data formats outlined in the relevant documentation. Failure to meet these requirements can result in feed processing errors or delays.
- The offer must be generally available to any user. Offers may require a paid subscription, as long as anyone can subscribe.
- All metadata provided must be accurate and up-to-date at the time of feed
upload (must be uploaded at least on a daily basis). Offers listed must be
active and available to users either immediately or in advance as indicated
using in the
ValidityPeriod; outdated, sold out or expired offers must be removed from the feed. - Partners must use consistent offer formats across platforms. Discrepancies between the offer details in the feed and those displayed on the partner's app or website are prohibited.
- Partners must provide clear and concise offer details in the
offer_display_textfield, accurately reflecting the offer's value and any limitations. - Partners must clearly indicate the offer category (Base Offer or Add-On
Offer) and applicable offer modes (
OFFER_MODE_FREE_RESERVATION,OFFER_MODE_PAID_RESERVATION,OFFER_MODE_WALK_IN) for each offer. - Partners must ensure accurate mapping of payment instrument types for each offer.
- Partner must provide updates automatically at least once a day or as per the developer documentation. Data update frequency must be sufficient to meet 95% accuracy.
- Offer title detail text must fulfill these requirements:
- Must not include special characters to emphasize a certain part (examples: !, ★, ☆, ♪, ◇, ◆, ◎, ■, \, /).
- Must not include half-width katakana. Use full-width katakana instead.
- Must not include full-width numbers. Use half-width numbers instead.
- Must not include full-width symbols (e.g. '％'). Use half-width symbols (e.g. ‘%’)
- Offers are required to present a genuine discount from the standard price or deliver additional value. Offers merely reflecting the standard retail price of an item or service are not permissible.