שיטות מומלצות

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

פידים

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

    • מספר השניות הממוצע שנדרשות להשלמת השירות.

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

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

    המשך השימוש פירושו שמוסכמים עליך התנאים וההגבלות של <merchant>.
    במקרה הזה, "תנאים והגבלות" הוא קישור שכאשר לוחצים עליו, מוצג הטקסט שהוגדר בשדה הטקסט terms (מונחים).

  • דחיסת הפידים באמצעות gzip

שרת הזמנות

כדי לשפר את השילוב של Maps Booking API, צריך לבצע את הפעולות הבאות:

  • צריך להשתמש תמיד בחותמות זמן UNIX בפורמט UTC.
  • המערכת יוצרת מזהה הזמנה ייחודי בעת קריאה להזמנה חדשה ב- CreateBooking API.

עדכונים בזמן אמת

כדי להבטיח את חוויית המשתמש הטובה ביותר בתהליך ההזמנה, כדאי לבצע את הפעולות הבאות:

  • להטמעה רגילה, אפשר להשתמש ב-BookingNotifications API כדי לשנות את שעת ההתחלה, משך הפגישה ומצב ההזמנה (למשל: ביטול או אי-הגעה) של פגישה.
  • בכל שינוי בהזמנה דרך Actions Center, תמיד צריך לשלוח עדכונים לגבי הזמנות בזמן אמת מהמערכת באמצעות BookingNotification API בזמן אמת, כדי שהנתונים לא הופכים ללא פעילים בצד של Actions Center. לדוגמה, אפשר לבטל הזמנה, לקבוע מועד חדש או לעדכן הזמנה מהמערכת שלך במרכז הפעולות.
  • בכל עדכון הזמנה מ-UpdateBookingRequest, צריך לוודא שהערך UpdateBookingResponse מכיל את מזהה ההזמנה, ושכל השדות המעודכנים חייבים לשקף את הערך החדש.
  • אם מוטמעות RTU של מלאי שטחי פרסום
    • מומלץ לעדכן את הזמינות רק בקבוצות של 100 עד 1,000 יחידות קיבולת (Slot) בכל קריאה ל-API.
    • אפשר להשתמש בשדות *Restrict (כמו startTimeRestrict) כדי לצמצם את יעד העריכה, להקטין את המטען הייעודי (payload) ולהימנע משליחה מחדש של יותר מדי נתונים שלא השתנו.
    • אם מבצעים הרצה של כמה שרשורים, מטמיעים השהיה מעריכית לפני ניסיון חוזר כדי למנוע שגיאות של ויסות נתונים. אם לא תטמיעו השהיה מעריכית בצורה נכונה, יכול להיות שתתקבל שגיאת מכסה של RESOURCE_EXHAUSTED. אפשר לנסות להשתמש שוב בהשהיה מעריכית לפני ההשבתה, אבל אם מתברר שהשרת שלכם מגיע למכסות לעיתים קרובות כשמריצים את ReplaceServiceAvailability, צריך להגדיר את השרת כך במקום כמות גדולה של זמינות. הפתרון הזה מונע שגיאות מכסה כי הוא מצמצם את מספר הקריאות ל-API שהשירות צריך לבצע.
  • מגדירים את מגבלות זמן התגובה לקריאות ל-API כך של פחות משנייה אחת. צריך לוודא שהשרת יכול לטפל בחמש שאילתות בשנייה (QPS) עם זמן אחזור של תת-שנייה לפחות 95% מהזמן.