בפידים הארגוניים, הגרסה של הישות נקבעת באמצעות השדה dateModified
בתוך המעטפת של הפיד:
{
"@context": "http://schema.googleapis.com",
"dateModified": "2018-12-28T06:30:00:123-07:00",
"@type": "DataFeed",
"dataFeedElement": [
/* All the items that are part of this feed go here */
]
}
לכל הישויות שמפורטות בשדה dataFeedElement
תהיה אותה חותמת זמן, כפי שמופיעה באריזת ה-envelope.
לדוגמה, יכול להיות שתשתמשו בפיד הבא עם שתי ישויות:
{
"@context": "http://schema.googleapis.com",
"@type": "DataFeed",
"dateModified": "2018-12-28T06:30:00:123-07:00",
"dataFeedElement": [
{
"@type": "Restaurant",
"@id": "http://www.provider.com/somerestaurant",
...
},
{
"@type": "Menu",
"@id": "http://www.provider.com/somerestaurant/menu/1"
...
}
]
}
לאחר קבלה ועיבוד, גם הישות של התפריט וגם הישות של המסעדה יקבלו גרסה נפרדת, שתהיה '2018-12-28T06:30:00:123-07:00'.
ניהול גרסאות באמצעות עדכונים מצטברים
כששולחים ישות באמצעות עדכוני מלאי, הגרסה מוגדרת דרך השדה update_time
(במקרה של קריאה להוספה/עדכון) או השדה delete_time
(במקרה של קריאה למחיקה). מכיוון שהשדות האלה אופציונליים, חותמת הזמן שמוגדרת כברירת מחדל היא מועד קבלת השיחה על ידי Google.
דוגמה 1: הגדרה מפורשת של update_time
נניח שהקריאה המצטברת הבאה התקבלה ב-28 בדצמבר 2018 בשעה 06:30:10:123-07:00 למסעדה חדשה לגמרי. זוהי בקשת ה-HTTP POST של הישות הזו עם המזהה 'http://www.provider.com/somerestaurant', בהנחה שפיד הנתונים משתמש בסכימת המלאי v1:
POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
בהמשך, גוף המטען הייעודי ב-JSON מכיל את השדה update_time
. הישות עם המזהה 'http://www.provider.com/somerestaurant' תקבל את הגרסה 6:30:00 ולא את הגרסה שבה היא התקבלה (עשר שניות מאוחר יותר, בשעה 6:30:10):
{
// This envelope is to be used for incremental.
"entity": {
// Note: "data" is not serialized as a string in our example for readability.
"data": "[entity in JSON format serialized as a string]",
"vertical": "FOODORDERING"
},
"update_time":"2018-12-28T06:30:00:123-07:00"
}
דוגמה 2: הגדרה משתמעת של update_time
נניח שהקריאה המצטברת הבאה התקבלה ב-28 בדצמבר 2018 בשעה 06:30:10:123-07:00 למסעדה חדשה לגמרי. זוהי בקשת ה-HTTP POST של הישות הזו עם המזהה 'http://www.provider.com/somerestaurant', בהנחה שהפיד משתמש בסכימת המלאי של v1:
POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
בהמשך, תוכן המטען הייעודי (payload) של ה-JSON לא מכיל את השדה update_time
. לכן, הישות עם המזהה 'http://www.provider.com/somerestaurant' תקבל את הגרסה 6:30:10:
{
// This envelope is to be used for incremental.
"entity": {
//Note: "data" is not serialized as a string in our example for readability.
"data": "[entity in JSON format serialized as a string]",
"vertical": "FOODORDERING"
}
}
ניהול גרסאות בין גרסאות אצווה לגרסאות מצטברות
ישות שנשלחת ל-Google עוברת עיבוד והצגה רק אם היא בגרסה העדכנית ביותר. חשוב לזכור שבדרך כלל נדרש כמה ימים כדי לעבד ישויות שנשלחות בקבוצה, ואילו ישויות שנשלחות דרך ה-API המצטבר עוברות עיבוד באופן מיידי.
שיטות מומלצות
- מגדירים את השדות
update_time
ו-dateModified
ב-incremental וב-batch, בהתאמה, בהתאם למועד שבו הישות שונתה במערכות שלכם. - אם בפיד (קובץ) של קבוצה מפורטות יותר מישות אחת ברמה העליונה (לדוגמה, התאמת המסעדות לשירותים ולתפריטים), צריך לעדכן את חותמת הזמן כשהנתונים של הישות מתעדכנים.
- בקריאות מצטברות, מומלץ מאוד להגדיר באופן מפורש את השדה
update_time
. - חשוב מאוד לעדכן את חותמת הזמן המתאימה של הפיד (
dateModified
) אחרי שליחת קריאה מצטברת, לפני ש-Google תאחזר אותו שוב.
דוגמה
Google מאחזרת את הקובץ הבא בשעה 11:00 ב-28 בדצמבר 2018 עבור מסעדה חדשה לגמרי:
{
"@context": "http://schema.googleapis.com",
"@type": "DataFeed",
"dateModified": "2018-12-28T06:30:00-07:00",
"dataFeedElement": [
{
"@type": "Restaurant",
"@id": "http://www.provider.com/newrestaurant",
...
},
{
"@type": "Menu",
"@id": "http://www.provider.com/newrestaurant/menu/1"
...
}
{
"@type": "Service",
"@id": "http://www.provider.com/newrestaurant/service/1"
...
}
]
}
הישות האלה עוברות עיבוד בהצלחה ומקבלות גרסה בשם '2018-12-28T06:30:00-07:00'. עיבוד של פידים בכמות גדולה (batch) נמשך זמן מה, ולכן בדרך כלל הם מוצגים 2 ימים מאוחר יותר.
עם זאת, בשעה 13:00 מתבצע עדכון של מספר הטלפון של המסעדה במערכת של השותף, וכתוצאה מכך מתבצעת השיחה המצטברת הבאה, ש-Google מקבלת בשעה 13:05 (5 שניות לאחר מכן):
POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
{
// This envelope is to be used for incremental.
"entity": {
//Note: "data" is not serialized as a string in our example for readability.
"data": "[entity in JSON format serialized as a string]",
"vertical": "FOODORDERING"
},
"update_time":"2018-12-28T13:00:00-07:00"
}
השדה update_time
מסופק במפורש, והוא גדול (עדכני יותר) מהגרסה הקודמת (6:30 בבוקר באותו יום), כך שהגרסה של ישות המסעדה היא עכשיו '2018-12-28T13:00:00-07:00'. עם זאת, יש עדיין גרסה של ישויות התפריט והשירות עם הערך '2018-12-28T06:30:00-07:00'.
הייתה קריאה מצטברת, ולכן פיד האצווה מתעדכן עם חותמת הזמן המתאימה החדשה. בנוסף, השינויים המתאימים חלים על הישות הרלוונטית (מספר הטלפון של הישות של המסעדה מתעדכן).
{
"@context": "http://schema.googleapis.com",
"@type": "DataFeed",
"dateModified": "2018-12-28T13:00:00-07:00",
"dataFeedElement": [
{
"@type": "Restaurant",
"@id": "http://www.provider.com/newrestaurant",
...
},
{
"@type": "Menu",
"@id": "http://www.provider.com/newrestaurant/menu/1"
...
}
{
"@type": "Service",
"@id": "http://www.provider.com/newrestaurant/service/1"
...
}
]
}
ביום הבא (29 בדצמבר 2018) בשעה 23:00, הפיד ייאחזר שוב. לבית המלון עדיין יש את אותה גרסה (13:00 ב-28 בדצמבר), ולכן הישות הזו תוסר והגרסה הנוכחית תישמר. עם זאת, ישויות התפריט והשירות מתעדכנות בגרסה חדשה.
חותמות זמן של Sitemap
כותרת התגובה last-modified
ב-sitemap לא משפיעה על הגרסה של הישות. היא משפיעה על מתי Google מאחזרת את הפיד.
שיטות מומלצות
- מעדכנים את כותרת התגובה רק כשכל הקבצים מעודכנים ומוכנים לאחזור.
- משתמשים באופן מפורש ב-
update_time
וב-delete_time
ב-incremental. - מגדירים את
update_time
,delete_time
ו-dateModified
למועד שבו הנתונים משתנים אצלכם.