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

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

פידים

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

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

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

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

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

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

שרת הזמנות

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

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

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

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

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