כללי המדיניות בנושא שילוב של Reservations End-to-End

כללי המדיניות הבאים חלים על השילוב של Reservations End-to-End.

מדיניות מקצה לקצה

לפני שמתחילים בשילוב, חשוב לקרוא את הקריטריונים הבאים לזכאות לשילוב. כדי לעמוד בדרישות ולפעול בהתאם לכללי המדיניות הבאים, השותפים יכולים לבצע שילוב מקצה לקצה של הזמנות ב-Actions Center.

הדרישות הבאות הן רכיבים נחוצים להשתתפות בתוכנית Actions Center, אבל עמידה בדרישות לא מבטיחה שהשותף יהיה כשיר לשלב את Actions Center או להפעיל אותו.

אי-ציות לדרישות ולמדיניות עלולה להוביל להשעיה או להסרה של השילוב, המוכר או השירותים מהפלטפורמה.

דרישות כלליות לפלטפורמה

1. השותפים חייבים לאסוף ולטפל בכל נתוני המוכרים והמשתמשים, כולל פרטים אישיים מזהים, באופן שתואם לתקנה הכללית להגנה על מידע (GDPR) ולכל חוקי הפרטיות החלים האחרים.
2. השותפים צריכים להיות מורשים לבצע הזמנות בשם המוכרים שלהם.

3. לשותפים צריכה להיות גישה ישירה למועדים הפנויים או לשעות הפנויות של המוכרים בזמן אמת (כלומר, השותפים צריכים להיות מסוגלים להגיב לבקשות של Google לגבי זמינות תוך פחות משנייה).

   • מקרה מיוחד: אנחנו תומכים בהזמנות שדורשות אישור אסינכרוני מהמוכר, אבל תהליך ההזמנה חייב להתבסס על חלון זמן פנוי. השותפים צריכים לקבל נתוני זמינות בזמן אמת, למשל דרך המערכות אונליין של המוכר, גם אם צריך אישור מהמוכר כדי להשלים את ההזמנה.

4. השותפים חייבים לספק מלאי שטחי פרסום מקיף למוכרים שלהם. יכול להיות שמוכרים עם מלאי חלקי או מלאי במצוקה לא יעמדו בדרישות.

5. השותפים צריכים להציג נתוני זמינות של מוכרים במשך 30 ימים או יותר.

6. השותפים חייבים לתמוך בביטול הזמנות אונליין.

7. שותפים שמחייבים תשלומים מראש חייבים לציית למדיניות התשלומים של Actions Center, ספקי התשלומים שלהם חייבים להופיע ברשימת הספקים הנתמכים הבאה ולקבל תשלומים באמצעות אסימונים.

8. השותפים צריכים לספק נתוני תמחור מדויקים של עלות השירותים ולפעול בהתאם למדיניות התמחור של מרכז הפעולות.

9. השותפים צריכים לעמוד בדרישות הטכניות של שילוב של הזמנות מקצה לקצה ב-Actions Center.

10. השותפים חייבים לציית לדרישות הסף של מוכרים ושירותים ב-Actions Center.

11. השותפים חייבים לפעול בהתאם להנחיות התמיכה והתחזוק של Actions Center.

12. השותפים צריכים לשמור על שיעורי שגיאות סבירים כפי שמוגדר בהנחיות להשקה ולמעקב.

13. כל ההזמנות חייבות להתקבל באופן אוטומטי בזמן אמת, למעט הזמנות שבוצעו באמצעות שילוב אסינכרוני. הזמנות שמבוצעות דרך שילוב אסינכרוני חייבות לעמוד בהנחיות לאסינכרוניות.

14. השותפים חייבים לפעול בהתאם למדיניות הספציפית לתחום או לתכונה של מרכז הפעולות (מבצעים, תשלום, שירותים אונליין ומסעדות).

15. השותף צריך להקפיד על תוכן באיכות סטנדרטית לגבי שם המוכר, הכתובת, שם השירותים והתיאור שלהם, בהתאם להנחיה.

translation: human page_type: lcat

מדיניות המבצעים

דף נחיתה (דף ואפליקציה לנייד)

• כל המבצעים ששותפו עם Google לגבי כל מסעדה צריכים להיות גלויים עם כל המידע הרלוונטי, לפחות בדף הנחיתה לנייד.
  • ערך המבצע וטקסט התיאור שלו חייבים להיות גלויים ישירות בדף הנחיתה.
  • בדפי הנחיתה צריך לפרט בבירור ובאופן מקיף את דרישות הסף לכל מבצע. ההגבלות האלה כוללות הגבלות שקשורות לפלחים של משתמשים, לאמצעי תשלום, לימים או לשעות ספציפיים, לסכומי הוצאה מינימליים ולמספר הפעמים שאפשר להשתמש במבצע.
  • כל שאר ההגבלות על המבצע (למשל: תנאי הזכאות, הוראות למשיכה, תנאים וכו') חייבות להיות גלויות בדף הנחיתה או נגישות בלחיצה אחת מדף הנחיתה (למשל: תיבת דו-שיח קופצת).
• בכל המבצעים, מלבד מבצעים מסוג OFFER_MODE_WALK_IN, תהליך הפעולות שמשויך למבצע (למשל, הזמנת שולחן) חייב לאפשר למשתמש לבחור את המבצעים הרלוונטיים שמשויכים לבחירה שלו (למשל, להזמנה, מבצעים שחלים על חלון הזמן ומספר המשתתפים שנבחרו)
• ההוראות והשיטות למשיכת השובר צריכות להיות ברורות וניתנות לביצוע (לדוגמה: אם כדי לממש את השובר צריך לשלם את החשבונית במערכת של השותף בקופה, צריך לציין את ההוראה לשלם במערכת, והמשתמש צריך להיות מסוגל לשלם את החשבונית במערכת של השותף בקופה).
• כשכתובת URL של מבצע מפנה לאפליקציה לנייד שמותקנת אצל השותף, דף הנחיתה של האפליקציה צריך לעמוד בכל הדרישות שמפורטות בקטע הזה לגבי דפי נחיתה של מבצעים.
  • כשמשתמשים חוזרים אחורה (למשל, באמצעות לחצן החזרה אחורה או ניווט באמצעות תנועות) מיד אחרי אינטראקציה עם מבצע בחוויית Google, הם צריכים לחזור לחוויית Google המקורית.

נתונים ותבנית של מבצעים

• השותפים חייבים לפעול בהתאם לדרישות הטכניות ולפורמטים של הנתונים המפורטים במסמכים הרלוונטיים. אי-עמידה בדרישות האלה עלולה לגרום לשגיאות או לעיכובים בעיבוד הפיד.
• המבצע צריך להיות זמין באופן כללי לכל משתמש. יכול להיות שהמבצעים ידרשו מינוי בתשלום, כל עוד כל אחד יוכל להירשם למינוי.
• כל המטא-נתונים שסופקו חייבים להיות מדויקים ועדכניים במועד העלאת הפיד (צריך להעלות אותם לפחות על בסיס יומי). המבצעים שמוצגים בפיד חייבים להיות פעילים וזמינים למשתמשים באופן מיידי או מראש, כפי שמצוין ב-ValidityPeriod. יש להסיר מהפיד מבצעים לא עדכניים, מבצעים שרוצים למכור אותם במחיר מלא או מבצעים שפג תוקפם.
• השותפים חייבים להשתמש בפורמטים עקביים של מבצעים בכל הפלטפורמות. אסור שתהיה אי-התאמה בין פרטי המבצע בפיד לבין הפרטים שמוצגים באפליקציה או באתר של השותף.
• השותפים חייבים לספק פרטי מבצע ברורים ותמציתיים בשדה offer_display_text, כך שישקפו במדויק את הערך של המבצע ואת כל המגבלות.
• השותפים חייבים לציין בבירור את קטגוריית המבצע (מבצע בסיסי או מבצע להוספה) ואת מצבי המבצע הרלוונטיים (OFFER_MODE_FREE_RESERVATION,‏ OFFER_MODE_PAID_RESERVATION, ‏ OFFER_MODE_WALK_IN) לכל מבצע.
• השותפים צריכים לוודא שמתבצע מיפוי מדויק של סוגי אמצעי התשלום לכל מבצע.

המדיניות והדרישות לגבי תפריטי אוכל

לפני שמתחילים לשלב שירות, חשוב לקרוא את הקריטריונים הבאים לזכאות לשילוב. כדי לעמוד בדרישות השילוב, השותפים חייבים לפעול בהתאם למדיניות בנושא תפריטי מזון ולעמוד בדרישות הבאות: לתשומת ליבכם: Google שומרת לעצמה את הזכות להציג את נתוני התפריט והמנות בדרכים שיועילו למשתמשים.

אי-ציות לדרישות ולמדיניות עלולה להוביל להשעיה או להסרה של השילוב, של המוכרים או של השירותים מהפלטפורמה.

המדיניות והדרישות

1. אסור לשותפים לשלוח מידע אסור (פרטים) בפיד התפריט, כמו שפה גסה, תמונות אסורות, פרטים אישיים מזהים (PII) או תוכן שנוצר על ידי משתמשים.
2. שותפים לא צריכים להשתמש בפיד התפריט כדי לשתף פריטים שאינם בתפריט, כמו שירותים (למשל: שירות 'מעבר ליד הרכב', קודי קידום מכירות וכו').
3. השותפים נדרשים לספק את כל הנתונים הנדרשים במפרט התפריט של ההזמנות מקצה לקצה או במפרט התפריט של ההפניה האוטומטית להזמנה (גודל קובץ מקסימלי: 2MB). הדרישות הטכניות מפורטות במפרט התפריט של ההזמנות מקצה לקצה או במפרט התפריט של הפניה אוטומטית להזמנה, שם השדות מסומנים כאופציונליים או כחובה.
4. השותפים צריכים לספק רק את הפריטים בתפריט שזמינים במיקומי המסעדות המתאימים.
5. השותפים חייבים לשלוח תפריט מלא לכל מיקום. יכול להיות שמוכרים עם תפריטים חלקיים לא יעמדו בדרישות להצגה.
6. השותפים והמוכרים נדרשים לוודא שהתפריטים מדויקים, ולספק עדכונים מדי יום.
7. התמונות של פריטי התפריט צריכות להיות מוארות היטב, להציג פריט תפריט אחד בфокус, לא לכלול אנשים או תמונות אחרות שאינן של אוכל, ולעמוד בדרישות לגבי תמונות (ראו הנחיות לתמונות).
8. המחירים צריכים להופיע לכל פריט בתפריט, ללא טיפים, מיסים או עמלות, אלא אם נדרש על פי חוקים ותקנות מקומיים. השותפים חייבים לציין במפורש את המטבע המקומי.
9. יש תמיכה בתפריטים מיוחדים, וצריך להסיר אותם כשהם כבר לא זמינים (למשל: תפריט 'מחיר קבוע', תפריט עונתי, מבצעים לזמן מוגבל).

כללי מדיניות להפניה אוטומטית של תשלומים

בקטע הזה מפורטות כללי המדיניות הכלליים והמדיניות הספציפית למאפיינים להטמעת הפניה אוטומטית של תשלומים במרכז הפעולות. כדי להבטיח חוויה עקבית לצרכנים, למוכרים ולשותפים שמשתמשים ב-Actions Center, מלאי שטחי הפרסום שדורש תשלום חייב לעמוד בהנחיות המתאימות. אי-ציות לכללי המדיניות האלה יוביל להשעיה של השילוב.

כללי

המדיניות הזו חלה על כל העסקאות והמלאי של התשלומים ב-'הזמנה מראש דרך Google':

1. הסכום שחויב המשתמש חייב להיות זהה לסכום שצוין בתנאים של העסקה, בהתאם לדינים החלים.
2. השותפים אחראים לעדכן את הזמינות באמצעות עדכון בזמן אמת (RTU) או לוודא שהקריאות ל-BatchAvailabilityLookup משקפות את הזמינות המדויקת של המשבצות.
3. אסור לחייב את המשתמש על עסקאות שמחייבות כרטיס אשראי.
4. אסור לחייב משתמש בסכומים שלא אושרו במפורש בקופה, כפי שמפורט בתהליך הגדרת התשלומים שלנו.
   • תנאי התשלום שמופיעים בדף התנאים וההגבלות המקושר לא עומדים בדרישות האלה.
5. בשירותים פנים-אל-פנים¹, כל התשלומים חייבים להתבצע בזמן ביצוע ההזמנה או באופן אישי בלבד. אסור לבקש תשלום באמצעים אחרים.
6. העסקה צריכה להופיע ולהחויב במטבע של המיקום של המוכר (המטבע מצוין בתהליך הגדרת התשלומים). לא תתבצע המרת מטבעות.

^{1. כל השירותים שנשלמים במזומן, לא כולל שירותים שניתנים דרך השילוב הזה, כמו תשלומים מראש ודפי חשבון}

הדרישות בנוגע לדפי נחיתה

1. דף הנחיתה חייב להיות ההתחלה של תהליך ההזמנה, עם מספר האנשים והמועד שנבחרו מראש.
2. דף הנחיתה לא יכול להיות דף הבית של ספק הפלטפורמה או דפים אחרים.
3. השלב הראשון בדף הנחיתה עם הקישור העומק לא יכול להיות חומת תשלום, שבה המשתמשים לא יכולים לראות את המטא-נתונים הקשורים להזמנה שלהם אלא אם הם מספקים פרטי תשלום.
4. השלב הראשון בדף הנחיתה עם הקישור העומק לא יכול להיות דף התחברות. תהליך ההזמנה חייב לכלול אפשרות לתשלום כאורח, שבה המשתמשים יכולים להשלים הזמנה בלי להתחבר או ליצור חשבון.
5. הקישור לדף אחר והדף הנחיתה לא יכולים לדרוש מהמשתמש להוריד אפליקציה כדי להשלים את תהליך ההזמנה.