ניהול גרסאות בגרסה 1 בפידים של קבוצות מודעות

בפידים הארגוניים, הגרסה של הישות נקבעת באמצעות השדה 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 למועד שבו הנתונים משתנים אצלכם.