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

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

פידים

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

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

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

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

  המשך הפעולה מבטא את הסכמתך לתנאים ולהגבלות של <merchant>.

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

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

שרת הזמנות

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

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

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

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

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