במהלך ההשקה, Google תפעיל את כל מלאי שטחי הפרסום שלכם שעומד בדרישות בסביבת הייצור שלנו. כך השילוב יושלם, וכל משתמש חיצוני יוכל להזמין או להזמין מראש את מלאי שטחי הפרסום שלכם דרך מרכז הפעולות.
אחרי ההשקה, חשוב לעקוב אחרי תקינות השילוב. צריך לשמור על ערכי הסף הבאים. אם לא תצליחו לעמוד בעקביות בדרישות הסף האלה, נצטרך להסיר את השילוב.
פידים
- יש לשלוח את הפיד מדי יום ללא שגיאות או אזהרות
- צריך להגדיר את הוראות העיבוד כ-PROCESS_AS_COMPLETE
- בפידים של זמינות, ההעלאה היומית של הפיד המלא של המלאי לא אמורה להגדיר שדות
_restrict.
שרת הזמנות
בכל הטמעות שרת ההזמנות, צריך לכלול מסלול HealthCheck. Google תבדוק מעת לעת את המסלול של HealthCheck, ואם הוא לא יגיב או ישלח תשובה לא תקינה, נשבית את השילוב באופן זמני. נמשיך לבדוק מדי פעם את המסלול של בדיקת תקינות השירות, וכשהמסלול יתחיל להחזיר שוב תשובה תקינה, נשחזר את השילוב באופן אוטומטי.
| יישום סטנדרטי | ||
|---|---|---|
| שיטה | ערכי סף של שיעור שגיאות | ערכי סף לזמן אחזור |
| CheckAvailability | <10% | פחות מ-5 שניות |
| BatchAvailabilityLookup | פחות מ-3% | פחות מ-1.5 שניות |
| CreateLease | <10% | פחות מ-5 שניות |
| CreateBooking UpdateBooking |
פחות מ-5% | פחות מ-4 שניות |
| CreateBooking (with payments) |
פחות מ-5% | פחות מ-15 שניות |
| SetMarketingPreference | פחות מ-5% | פחות מ-5 שניות |
עדכונים בזמן אמת
זמן האחזור של עדכונים בזמן אמת נמדד לפי הפרש הזמן בין ביצוע הפעולה (למשל, שינוי הזמנה) לבין קבלת הבקשה לעדכון בזמן אמת על ידי 'הזמנה דרך Google'.
| API | ערכי סף של שיעור שגיאות | ערכי סף לזמן אחזור |
|---|---|---|
| AvailabilityReplace RTU | פחות מ-10% בכל יום | פחות מ-5 דקות |
| BookingNotification RTU | פחות מ-10% בכל יום ובכל מצב | פחות מ-5 דקות |
אפשר לעקוב אחרי שיעורי השגיאות במרכזי הבקרה השונים בפורטל השותפים, כלומר במרכזי הבקרה פידים, שרת ההזמנות ועדכונים בזמן אמת.