שלב 5: השקה ומעקב
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
במהלך ההשקה, 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 דקות |
אפשר לעקוב אחרי שיעורי השגיאות במרכזי הבקרה השונים בפורטל השותפים, כלומר במרכזי הבקרה פידים, שרת ההזמנות ועדכונים בזמן אמת.
אלא אם צוין אחרת, התוכן של דף זה הוא ברישיון Creative Commons Attribution 4.0 ודוגמאות הקוד הן ברישיון Apache 2.0. לפרטים, ניתן לעיין במדיניות האתר Google Developers. Java הוא סימן מסחרי רשום של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-26 (שעון UTC).
[null,null,["עדכון אחרון: 2025-07-26 (שעון UTC)."],[[["\u003cp\u003eGoogle enables eligible inventory for external user booking upon integration launch through Actions Center.\u003c/p\u003e\n"],["\u003cp\u003eMaintaining specific thresholds for feeds, booking server, and real-time updates is crucial for sustained integration.\u003c/p\u003e\n"],["\u003cp\u003eFailure to consistently meet these performance benchmarks, including error rates and latency, will result in integration takedown.\u003c/p\u003e\n"],["\u003cp\u003ePartners can monitor integration health and error rates through dedicated dashboards within the Partner Portal, covering feeds, booking server, and real-time updates.\u003c/p\u003e\n"]]],["Upon launch, all eligible inventory is enabled for external user booking. Post-launch, daily feeds must be sent error-free with `PROCESS_AS_COMPLETE` and no `_restrict` fields in Availability feeds. A functioning HealthCheck route is crucial; failure results in temporary integration disablement. Booking server and real-time updates have strict error and latency thresholds. These are monitored via the Feeds, Booking Server, and Real-time Updates dashboards. Consistent failure to meet standards will result in integration removal.\n"],null,["# Step 5: Launch and monitoring\n\nAt launch, Google enables all of your eligible inventory in our production\nenvironment. This completes the integration and allows any external user to\nbook or reserve your inventory through the Actions Center.\n\nOnce you've launched, it's important to monitor the health of your\nintegration. The following thresholds must be maintained. Failure to maintain\nthese thresholds consistently will result in integration take-down.\n\nFeeds\n-----\n\n- Feeds should be sent on a daily basis with no errors or warnings\n - Processing instructions should be set to PROCESS_AS_COMPLETE\n - For Availability feeds, the full inventory daily feed upload should not set any `_restrict` fields.\n\nBooking server\n--------------\n\nFor all booking server implementations, there is a HealthCheck route that\nshould be included. Google will periodically check your HealthCheck route\nand should it not respond or return an unhealthy response, we will\ntemporarily disable your integration. We will continue to periodically\ncheck your HealthCheck route and once it resumes returning a healthy\nresponse we will automatically restore your integration.\n\n| Standard implementation |||\n| Method | Error Rate Thresholds | Latency Thresholds |\n|-------------------------------|-----------------------|--------------------|\n| CheckAvailability | \\\u003c10% | \\\u003c5s |\n| BatchAvailabilityLookup | \\\u003c3% | \\\u003c1.5s |\n| CreateLease | \\\u003c10% | \\\u003c5s |\n| CreateBooking UpdateBooking | \\\u003c5% | \\\u003c4s |\n| CreateBooking (with payments) | \\\u003c5% | \\\u003c15s |\n| SetMarketingPreference | \\\u003c5% | \\\u003c5s |\n\nReal-time updates\n-----------------\n\nFor real-time updates, latency is measured by the time difference between\nwhen an action is taken (e.g. modifying a booking) and when Reserve with\nGoogle receives the real-time update request.\n\n| API | Error Rate Thresholds | Latency Thresholds |\n|-------------------------|----------------------------------|--------------------|\n| AvailabilityReplace RTU | \\\u003c10% each day | \\\u003c5 mins |\n| BookingNotification RTU | \\\u003c10% each day \\& for each state | \\\u003c5 mins |\n\nError rates can be monitored through the various Partner Portal dashboards,\nnamely the\n[Feeds](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/feeds),\n[Booking Server](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/bookingserver), and\n[Real-time Updates](https://partnerdash.google.com/apps/reservewithgoogle/dashboards/realtimeupdates) dashboards."]]
