המדיניות בנושא שילוב של מוצרים להזמנות
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כללי המדיניות הבאים לגבי שילובים חלים על השילוב של 'הזמנות'.
מדיניות המבצעים
דף נחיתה (דף ואפליקציה לנייד)
- כל המבצעים ששותפו עם Google לגבי כל מסעדה צריכים להיות גלויים עם כל המידע הרלוונטי, לפחות בדף הנחיתה לנייד.
- ערך המבצע וטקסט התיאור שלו חייבים להיות גלויים ישירות בדף הנחיתה.
- בדפי הנחיתה צריך לפרט בבירור ובאופן מקיף את דרישות הסף לכל מבצע. ההגבלות האלה כוללות הגבלות שקשורות לפלחים של משתמשים, לאמצעי תשלום, לימים או לשעות ספציפיים, לסכומי הוצאה מינימליים ולמספר הפעמים שאפשר להשתמש במבצע.
- כל שאר ההגבלות על המבצע (למשל: תנאי הזכאות, הוראות למשיכה, תנאים וכו') חייבות להיות גלויות בדף הנחיתה או נגישות בלחיצה אחת מדף הנחיתה (למשל: תיבת דו-שיח קופצת).
- בכל המבצעים, מלבד מבצעים מסוג
OFFER_MODE_WALK_IN, תהליך הפעולות שמשויך למבצע (למשל, הזמנת שולחן) חייב לאפשר למשתמש לבחור את המבצעים הרלוונטיים שמשויכים לבחירה שלו (למשל, להזמנה, מבצעים שחלים על חלון הזמן ומספר המשתתפים שנבחרו)
- ההוראות והשיטות למשיכת השובר צריכות להיות ברורות וניתנות לביצוע (לדוגמה, אם כדי לממש את השובר צריך לשלם את החשבונית במערכת של השותף בקופה, צריך לציין את ההוראה לשלם במערכת, והמשתמש צריך להיות מסוגל לשלם את החשבונית במערכת של השותף בקופה).
- כשכתובת URL של מבצע מפנה לכתובת של אפליקציה לנייד שמותקנת אצל השותף, דף הנחיתה של האפליקציה צריך לעמוד בכל הדרישות שמפורטות בקטע הזה לגבי דפי נחיתה של מבצעים.
- כשמשתמשים חוזרים אחורה (למשל, באמצעות לחיצה על לחצן החזרה אחורה או באמצעות ניווט באמצעות תנועות) מיד אחרי אינטראקציה עם מבצע בחוויית Google, הם צריכים לחזור לחוויית Google המקורית.
נתונים ותבנית של מבצעים
- השותפים חייבים לפעול בהתאם לדרישות הטכניות ולפורמטים של הנתונים המפורטים במסמכים הרלוונטיים. אי-עמידה בדרישות האלה עלולה לגרום לשגיאות או לעיכובים בעיבוד הפיד.
- המבצע צריך להיות זמין לכל משתמש באופן כללי. יכול להיות שתצטרכו להציע מינויים בתשלום כדי להשתמש במבצעים, כל עוד כל אחד יכול להירשם למינוי.
- כל המטא-נתונים שסופקו חייבים להיות מדויקים ועדכניים במועד ההעלאה של הפיד (צריך להעלות אותם לפחות על בסיס יומי). המבצעים שמוצגים בפיד חייבים להיות פעילים וזמינים למשתמשים באופן מיידי או מראש, כפי שמצוין ב-
ValidityPeriod. יש להסיר מהפיד מבצעים לא עדכניים, מבצעים שרוצים למכור או מבצעים שפג תוקפם.
- השותפים חייבים להשתמש בפורמטים עקביים של מבצעים בכל הפלטפורמות. אסור שיהיה אי-התאמה בין פרטי המבצע בפיד לבין הפרטים שמוצגים באפליקציה או באתר של השותף.
- השותפים חייבים לספק פרטי מבצע ברורים ותמציתיים בשדה
offer_display_text, שמשקפים במדויק את הערך של המבצע ואת כל המגבלות.
- השותפים חייבים לציין בבירור את קטגוריית המבצע (מבצע בסיסי או מבצע להוספה) ואת מצבי המבצע הרלוונטיים (
OFFER_MODE_FREE_RESERVATION, OFFER_MODE_PAID_RESERVATION, OFFER_MODE_WALK_IN) לכל מבצע.
- השותפים צריכים לוודא שמתבצע מיפוי מדויק של סוגי אמצעי התשלום לכל מבצע.
- השותף צריך לספק עדכונים באופן אוטומטי לפחות פעם ביום, או בהתאם למסמכי התיעוד למפתחים.
תדירות עדכון הנתונים צריכה להיות מספקת כדי לעמוד ברמת דיוק של 95%.
אלא אם צוין אחרת, התוכן של דף זה הוא ברישיון Creative Commons Attribution 4.0 ודוגמאות הקוד הן ברישיון Apache 2.0. לפרטים, ניתן לעיין במדיניות האתר Google Developers. Java הוא סימן מסחרי רשום של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-05-26 (שעון UTC).
[null,null,["עדכון אחרון: 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."]]
