बैच फ़ीड में v1 वर्शन का इस्तेमाल

आपके बैच फ़ीड में, इकाई के वर्शन को फ़ीड के एन्वेलप में मौजूद 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"
      ...
    }
  ]
}

मेन्यू और रेस्टोरेंट की इकाइयों के मिलने और प्रोसेस होने के बाद, उनके अलग-अलग वर्शन "28-12-2018T06:30:00:123-07:00" के तौर पर दिखेंगे.

अतिरिक्त अपडेट वाले वर्शन

इन्वेंट्री अपडेट का इस्तेमाल करके कोई इकाई भेजते समय, वर्शन को update_time फ़ील्ड (ऐड/अपडेट कॉल के मामले में) या delete_time फ़ील्ड (मिटाएं कॉल के मामले में) के ज़रिए सेट किया जाता है. ये फ़ील्ड ज़रूरी नहीं हैं, इसलिए डिफ़ॉल्ट टाइमस्टैंप उस समय पर सेट होता है, जब Google को कॉल आया था.

उदाहरण 1: update_time को साफ़ तौर पर सेट किया गया है

मान लें कि एक पूरी तरह से नए रेस्टोरेंट के लिए, 28-12-2018T06:30:10:123-07:00 पर यह इंक्रीमेंटल कॉल आता है. यह मानते हुए कि डेटा फ़ीड v1 इन्वेंट्री स्कीमा का इस्तेमाल करता है, उस इकाई के लिए "http://www.provider.com/somerestaurant" आईडी वाला एचटीटीपी पोस्ट अनुरोध यह है:

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"
}

दूसरा उदाहरण: update_time को इंप्लिसिटली सेट के तौर पर सेट किया गया है

मान लें कि एक पूरी तरह से नए रेस्टोरेंट के लिए, 28-12-2018T06:30:10:123-07:00 पर यह इंक्रीमेंटल कॉल आता है. यह मानते हुए कि फ़ीड, v1 इन्वेंट्री स्कीमा का इस्तेमाल करती है, उस इकाई के लिए "http://www.provider.com/somerestaurant" आईडी वाला एचटीटीपी पोस्ट अनुरोध यह है:

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: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 को भेजी गई इकाई को तभी प्रोसेस और दिखाया जाता है, जब उसके पास सबसे नया वर्शन हो. ध्यान दें कि बैच से भेजी गई इकाइयों को प्रोसेस होने में आम तौर पर कुछ दिन लगते हैं, जबकि इंक्रीमेंटल एपीआई से भेजी गई इकाइयों को तुरंत प्रोसेस कर दिया जाता है.

सबसे सही तरीके

  • आपके सिस्टम में इकाई में कब बदलाव किया गया था, इसके मुताबिक update_time और dateModified फ़ील्ड को इंक्रीमेंटल और बैच में सेट करें.
  • अगर किसी बैच फ़ीड (फ़ाइल) में एक से ज़्यादा टॉप लेवल इकाई की जानकारी दी जाती है (जैसे कि आप अपने रेस्टोरेंट को सेवाओं और मेन्यू के साथ पेयर करें), तो इकाई का डेटा अपडेट होते ही टाइमस्टैंप को अपडेट करें.
  • हमारा सुझाव है कि इंक्रीमेंटल कॉल के मामले में, आप update_time फ़ील्ड को ही सेट करें.
  • यह ज़रूरी है कि इंक्रीमेंटल कॉल किए जाने के बाद, Google के फिर से फ़ेच करने से पहले उससे जुड़े फ़ीड का टाइमस्टैंप (dateModified) भी अपडेट किया जाए.

उदाहरण

Google इस फ़ाइल को 28-12-2018 को सुबह 11 बजे एक पूरी तरह से नए रेस्टोरेंट के लिए फ़ेच करता है:

{
  "@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"
      ...
    }
  ]
}

इन इकाइयों को प्रोसेस कर दिया गया है और इनके वर्शन को "28-12-2018T06:30:00-07:00" के तौर पर दिखाया गया है. बैच फ़ीड को प्रोसेस होने में समय लगता है, इसलिए आम तौर पर इन्हें दो दिन बाद दिखाया जाता है.

हालांकि, दोपहर 1 बजे पार्टनर के सिस्टम में रेस्टोरेंट के फ़ोन नंबर को अपडेट किया जाता है, जिसकी वजह से कॉल बढ़ता है. यह कॉल 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" के रूप में वर्शन कर दी गई है. हालांकि, मेन्यू और सेवा इकाइयों का वर्शन अब भी "28-12-2018T06: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-12-2018 को दोपहर 11 बजे), फ़ीड को फिर से फ़ेच किया जाता है. रेस्टोरेंट का वर्शन अब भी वही है (28 दिसंबर को दोपहर 1 बजे), इसलिए इस रेस्टोरेंट को हटाया जाता है और मौजूदा वर्शन बना रहता है. हालांकि, मेन्यू और सेवा इकाइयों को नए वर्शन से अपडेट किया गया है.

साइटमैप के टाइमस्टैंप

साइटमैप में मौजूद last-modified रिस्पॉन्स हेडर, किसी इकाई के वर्शन पर असर नहीं डालता. इसका असर इस बात पर पड़ता है कि Google, कब फ़ीड को फ़ेच करता है.

सबसे सही तरीके

  • रिस्पॉन्स हेडर को सिर्फ़ तब अपडेट करें, जब सभी फ़ाइलें अप-टू-डेट हों और फ़ेच करने के लिए तैयार हों.
  • इंक्रीमेंटल (बढ़ने वाले) वर्शन में update_time और delete_time का इस्तेमाल साफ़ तौर पर करें.
  • update_time, delete_time, और dateModified को डेटा में बदलाव होने पर सेट करें.