סקירה כללית וכשירות

בהמשך מפורטים פרטי תהליך השילוב של Reservations End-to-End ב-Actions Center.

שילוב

מבצעים את תהליך ההטמעה הרגיל ברמה גבוהה שמתואר במדריך ההטמעה מקצה לקצה.

סקירה כללית על תהליך ההצטרפות לשילוב של Reservations End-to-End.
סקירה כללית על תהליך ההצטרפות לשילוב של Reservations End-to-End.

הנחיות מקצה לקצה בנושא הזמנת מפתחות

סקירת הנקודות הבאה כוללת דוגמאות ומדריך בנושא תכונות מרכזיות שנדרשות על ידי השילוב של ההזמנות מקצה לקצה:

  • פידים:
    • כדי לשלב את הזמנות החדרים מקצה לקצה, צריך לשלוח פידים של מוכרים, שירותים וזמינות מדי יום באמצעות SFTP.
    • בפידים של המוכרים, חשוב שהשם, הכתובת, מספר הטלפון וכתובת ה-URL של כל מיקום יהיו זהים לאלו של כרטיס המוצר ב-Google כדי שההתאמה תתבצע בהצלחה.
    • מוכרים שמשתמשים בהזמנות מקצה לקצה יכולים להשתמש רק בשירות אחד להצגת הזמינות.
    • מומלץ להגדיר את אותו ערך סטטי לכל המוכרים, אם ההזמנות הן השירות היחיד שהמוכרים מספקים. אם רלוונטי, צריך לציין את הע ביטול כללי ואת מדיניות הביטול בפיד השירותים.
    • ההבדל העיקרי בין מלאי שטחי הפרסום של Reservations End-to-End לבין מלאי שטחי הפרסום הרגיל הוא הצורך להגדיר את המאפיין party_size לכל הזמינות. למידע נוסף, אפשר לעיין במדריכים הבאים:
  • שרת ההזמנות:
  • עדכונים בזמן אמת:
    • העדכונים בזמן אמת לא נדרשים, אבל הם מאפשרים לכם לשלוח לנו עדכונים באופן אסינכררוני לגבי ביטולי הזמנות או שינויים בזמינות לפני שמשתמש מנסה לגשת לזמינות שלכם. כך, אם הפונקציה BatchAvailabilityLookup תיכשל, המשתמשים יראו פחות משבצות זמינות שאי אפשר להזמין. למידע נוסף, קראו את המאמר מבנה של עדכונים בזמן אמת.
  • הערות נוספות:
    • אם קובץ הפיד של הזמינות (אחרי דחיסת נתונים) גדול מ-200MB, צריך לבצע חלוקה לפלחים כדי לפצל את הפיד לקבצים שגודלם קטן מ-200MB (דחוסים).
    • מוכרים שמשתמשים בהזמנות מקצה לקצה יכולים להשתמש רק בשירות אחד

תכונות נוספות של Reservations End-to-End

אלה תכונות שכדאי להביא בחשבון כשמשלימים את השילוב של Reservations End-to-End. אף אחד מהם לא נדרש, אבל רבים מהם נחוצים כדי לוודא שמערכת מרכז הפעולות פועלת בהתאם ללוגיקת העסק של החברה שלכם כשהיא מציגה את מלאי שטחי הפרסום: