Zasady integracji ofert rezerwacji
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
W przypadku integracji z ofertami rezerwacji obowiązują te zasady integracji:
Zasady dotyczące ofert
Strona docelowa (strona i aplikacja na urządzenia mobilne)
- Wszystkie oferty udostępnione Google dla każdej restauracji powinny być widoczne ze wszystkimi istotnymi informacjami co najmniej na stronie docelowej na urządzeniu mobilnym.
- Wartość oferty i tekst opisu muszą być widoczne bezpośrednio na stronie docelowej.
- Strony docelowe muszą w wyraźny i wyczerpujący sposób określać wymagania dotyczące kwalifikowania się do każdej oferty. Obejmuje to ograniczenia związane z segmentami użytkowników, metodami płatności, konkretnymi dniami lub godzinami, minimalnymi kwotami wydatków oraz liczbą razów, w których można skorzystać z oferty.
- Wszystkie inne ograniczenia oferty (np. warunki kwalifikowania się, instrukcje dotyczące realizacji, warunki) muszą być widoczne na stronie docelowej lub dostępne w 1 kliknięciu od strony docelowej (np. w wyskakującym oknie).
- W przypadku wszystkich ofert oprócz ofert
OFFER_MODE_WALK_IN
przepływ czynności powiązany z ofertą (np. rezerwacja stolika) musi umożliwiać użytkownikowi wybranie ofert dostępnych w ramach jego wyboru (np. W przypadku rezerwacji oferty dostępne w wybranym przedziale czasowym i dla wybranej liczby osób
- Instrukcje i metody korzystania z oferty muszą być wyraźnie określone i możliwe do wykonania (np. jeśli skorzystanie z oferty wymaga opłacenia rachunku w systemie partnera podczas płatności, należy podać instrukcje dotyczące płatności w systemie i umożliwić użytkownikowi opłacenie rachunku w systemie partnera podczas płatności).
- Gdy adres URL oferty przekierowuje do zainstalowanej aplikacji mobilnej partnera, strona docelowa aplikacji musi spełniać wszystkie wymagania opisane w tej sekcji dotyczącej stron docelowych ofert.
- Po przejściu do poprzedniej strony (np. za pomocą przycisku Wstecz lub gestów) bezpośrednio po interakcji z ofertą w interfejsie Google użytkownicy muszą zostać przeniesieni do pierwotnego interfejsu Google.
Data i format oferty
- Partnerzy muszą przestrzegać określonych wymagań technicznych i formatów danych opisanych w odpowiedniej dokumentacji. Niezastosowanie się do tych wymagań może spowodować błędy lub opóźnienia w przetwarzaniu pliku danych.
- Oferta musi być ogólnodostępna dla każdego użytkownika. Oferty mogą wymagać płatnej subskrypcji, o ile każdy może ją wykupić.
- Wszystkie metadane muszą być prawidłowe i aktualne w momencie przesłania pliku danych (należy go przesyłać co najmniej raz dziennie). Wyświetlane oferty muszą być aktywne i dostępne dla użytkowników od razu lub z wyprzedzeniem, zgodnie z informacjami podanymi w sekcji
ValidityPeriod
. Oferty, które są nieaktualne, wyprzedane lub wygasłe, muszą zostać usunięte z pliku danych.
- Partnerzy muszą używać spójnych formatów ofert na wszystkich platformach. Niedopuszczalne są rozbieżności między szczegółami oferty w pliku danych a szczegółami wyświetlanymi w aplikacji lub na stronie partnera.
- Partnerzy muszą podać w polu
offer_display_text
przejrzyste i zwięzłe informacje o ofercie, które dokładnie odzwierciedlają jej wartość i wszelkie ograniczenia.
- Partnerzy muszą wyraźnie wskazać kategorię oferty (oferta podstawowa lub oferta dodatkowa) oraz odpowiednie tryby oferty (
OFFER_MODE_FREE_RESERVATION
, OFFER_MODE_PAID_RESERVATION
, OFFER_MODE_WALK_IN
) w przypadku każdej oferty.
- Partnerzy muszą zapewnić dokładne mapowanie typów instrumentów płatniczych w przypadku każdej oferty.
- Partner musi automatycznie przesyłać aktualizacje co najmniej raz dziennie lub zgodnie z dokumentacją dla deweloperów.
Częstotliwość aktualizacji danych musi być wystarczająca, aby zapewnić dokładność na poziomie 95%.
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-05-26 UTC.
[null,null,["Ostatnia aktualizacja: 2025-05-26 UTC."],[],[],null,["# Reservations Offers Integration Policies\n\nThe following integration policies apply to the Reservations Offers integration.\n\nOffers policy\n-------------\n\n### Landing Page (mobile page \\& application)\n\n- All Offers shared with Google for any restaurant should be visible with all relevant information on at least the mobile landing page.\n - The offer value and description text must be visible on the landing page directly.\n - 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, and the number of times the offer can be used.\n - 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).\n- For all offers except `OFFER_MODE_WALK_IN` offers, the action flow associated with the offer (ex. reserving a table) must allow the user to select the offer(s) applicable associated with their selection (ex. For reservation, offers applicable for the time slot and party size selected)\n- 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).\n- 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.\n - 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.\n\n### Offers Data \\& Format\n\n- 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.\n- The offer must be generally available to any user. Offers may require a paid subscription, as long as anyone can subscribe.\n- 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.\n- 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.\n- Partners must provide clear and concise offer details in the `offer_display_text` field, accurately reflecting the offer's value and any limitations.\n- 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.\n- Partners must ensure accurate mapping of payment instrument types for each offer.\n- Partner must provide updates automatically at least once a day or as per the [developer documentation](/actions-center/verticals/reservations/offers/integration-steps/overview). Data update frequency must be sufficient to meet 95% accuracy."]]