בפידים מסוג אצווה, הגרסה של ישות נקבעת באמצעות השדה 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
תהיה חותמת זמן זהה,
כפי שמצוין במעטפה.
לדוגמה, הפיד הבא יכול לכלול שתי ישויות:
{
"@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 מוגדר באופן מפורש
נניח שהשיחה המצטברת הבאה התקבלה ב-2018-12-28T06: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: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 מוגדר באופן מרומז
נניח שהשיחה המצטברת הבאה התקבלה ב-2018-12-28T06: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
בו-זמנית ובאצווה, בהתאם למועד שבו הישות שונתה במערכות שלכם. - אם פיד אצווה (קובץ) מכיל יותר מישות אחת ברמה העליונה (לדוגמה, מתאימים את המסעדות עם שירותים ותפריטים), ומעדכנים את חותמת הזמן בכל פעם שהנתונים של ישות מתעדכנים.
- בשיחות מצטברות, מומלץ מאוד להגדיר באופן מפורש את השדה
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". בגלל שהעיבוד של פידים באצווה לוקח זמן, הם בדרך כלל מוצגים יומיים אחרי כן.
אבל בשעה 13:00, במערכת של השותף יש עדכון למספר הטלפון של המסעדה, וכתוצאה מכך השיחה המצטברת הבאה מתקבלת ב-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
במצטבר. - מגדירים את
update_time
,delete_time
ו-dateModified
כשהנתונים משתנים בצד שלכם.