הצוות שלנו מתזמן את ההשקה לתאריך ולשעה ספציפיים. יכול להיות שתראו עיכוב של כמה שעות בהעלאת נתוני מוכרים לאונליין.
אנחנו עוקבים אחרי השילוב במשך שבוע אחרי ההשקה. אם שרת ההזמנות או העדכונים בזמן אמת (RTU) חורגים מסף השגיאות, נודיע לכם על כך כדי שתוכלו לתקן אותם. אם הבעיות לא ייפתרו, Google תסיר את השילוב.
שרת הזמנות
בכל ההטמעות של שרת ההזמנות, יש מסלול HealthCheck שחובה לכלול. מערכת Actions Center בודקת את HealthCheck המסלול שלכם באופן תקופתי.
אם הוא לא מגיב או מחזיר תגובה לא תקינה, אנחנו משביתים באופן זמני את השילוב. אנחנו ממשיכים לבדוק מעת לעת את HealthCheck המסלול
שלך, ואחרי שהוא מחזיר תגובה תקינה, אנחנו משחזרים באופן אוטומטי את האינטגרציה שלך.
| שיטות הטמעה רגילות | ספי שגיאות | ערכי סף של זמן האחזור |
|---|---|---|
CheckAvailability
הערה: נקודת הקצה הזו של שרת ההזמנות היא מדור קודם. אינטגרציות חדשות לא יכולות להטמיע את נקודת הקצה הזו.
|
<10% | <5 שנ' |
BatchAvailabilityLookup
|
פחות מ-3% | <1.5 שנ' |
CreateBooking
|
פחות מ-5% | <4 שנ' |
RTUs
במקרה של RTU, זמן האחזור נמדד לפי ההפרש בין הזמן שבו מתבצעת פעולה (לדוגמה, שינוי הזמנה) לבין הזמן שבו מרכז הפעולות מקבל את בקשת ה-RTU.
| API | ספי שגיאות | ערכי סף של זמן האחזור |
|---|---|---|
BookingNotification RTU
|
פחות מ-10% בכל יום ובכל מדינה | פחות מ-5 דקות |
אפשר לעקוב אחרי שיעורי השגיאות באמצעות מרכזי הבקרה השונים בפורטל השותפים, כלומר מרכזי הבקרה Feeds, Booking Server ו-RTU.
דרישות התאימות לגבי מלאי שטחי הפרסום
חשוב להקפיד על הדרישות בנושא תאימות למלאי שטחי הפרסום. בקטע הסרת קישורים של צדדים שלישיים במאמר העזרה מוסבר איך מוֹכרים יכולים לבטל את ההסכמה לשימוש בשירות שלכם. הפרה של מדיניות התאימות למלאי שטחי הפרסום עלולה להוביל להשבתה או לביטול של השילוב.