इस पेज का अनुवाद Cloud Translation API से किया गया है.

CrUX हिस्ट्री एपीआई

CrUX इतिहास एपीआई से, पेज और ऑरिजिन से जुड़े विवरण के स्तर पर, छह महीने के उपयोगकर्ता अनुभव के पुराने डेटा को ऐक्सेस करने में कम समय लगता है.

इस्तेमाल का सामान्य उदाहरण

CrUX इतिहास एपीआई, किसी खास यूआरआई के लिए उपयोगकर्ता अनुभव की पुरानी मेट्रिक की क्वेरी करने की अनुमति देता है. जैसे, "https://example.com ऑरिजिन के लिए पुराने UX ट्रेंड पाएं."

इतिहास एपीआई उसी स्ट्रक्चर का पालन करता है जिसका इस्तेमाल रोज़ का CrUX API किया जाता है. इसमें हर दिन की वैल्यू नहीं दी जाती हैं. इसके अलावा, कुंजियों को बहुवचन नामों से लेबल किया जाता है. जैसे, histogram के बजाय histogramTimeseries या p75 की जगह p75s.

CrUX एपीआई पासकोड

हर दिन के एपीआई की तरह, CrUX History API का इस्तेमाल करने के लिए, Google Cloud API पासकोड की ज़रूरत होती है. 'रोज़ाना और इतिहास' एपीआई के लिए, एक ही कुंजी का इस्तेमाल किया जा सकता है.

क्रेडेंशियल पेज पर जाकर, नया क्रेडेंशियल बनाया जा सकता है और Chrome UX Report API के इस्तेमाल के लिए इसका प्रावधान किया जा सकता है.

आपको API कुंजी मिल जाने के बाद, आपका ऐप्लिकेशन सभी अनुरोध यूआरएल में क्वेरी पैरामीटर key=[YOUR_API_KEY] जोड़ सकता है. क्वेरी के उदाहरण देखें.

एपीआई पासकोड, यूआरएल में एम्बेड करने के लिए सुरक्षित है. इसे कोड में बदलने के लिए किसी तरह की ज़रूरत नहीं होती.

डेटा मॉडल

इस सेक्शन में, अनुरोधों और जवाबों में डेटा के स्ट्रक्चर की जानकारी दी गई है.

रिकॉर्ड करें

किसी पेज या साइट के बारे में अलग-अलग जानकारी. रिकॉर्ड में ऐसा डेटा हो सकता है जो किसी आइडेंटिफ़ायर और डाइमेंशन के खास कॉम्बिनेशन के लिए होता है. रिकॉर्ड में एक या उससे ज़्यादा मेट्रिक का डेटा हो सकता है.

आइडेंटिफ़ायर

आइडेंटिफ़ायर तय करते हैं कि किन रिकॉर्ड को खोजना चाहिए. CrUX में, ये आइडेंटिफ़ायर वेबपेज और वेबसाइट होते हैं.

शुरुआत की जगह

अगर आइडेंटिफ़ायर एक ऑरिजिन होता है, तो उस ऑरिजिन पर मौजूद सभी पेजों पर मौजूद सारा डेटा एक साथ एग्रीगेट किया जाता है. उदाहरण के लिए, मान लें कि http://www.example.com ऑरिजिन में ऐसे पेज थे जो इस साइटमैप के हिसाब से तय किए गए थे:

http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html

इसका मतलब यह है कि जब ऑरिजिन को http://www.example.com पर सेट करके Chrome UX रिपोर्ट की क्वेरी की जाएगी, तो http://www.example.com/, http://www.example.com/foo.html, और http://www.example.com/bar.html का डेटा एक साथ एग्रीगेट किया जाएगा, क्योंकि ये सभी उस ऑरिजिन में मौजूद होते हैं.

यूआरएल

अगर आइडेंटिफ़ायर कोई यूआरएल है, तो सिर्फ़ उस यूआरएल का डेटा दिखेगा. http://www.example.com के ऑरिजिन साइटमैप को फिर से खोजा जा रहा है:

http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html

अगर आइडेंटिफ़ायर को http://www.example.com/foo.html वैल्यू के साथ यूआरएल पर सेट किया गया है, तो सिर्फ़ उस पेज का डेटा दिखाया जाएगा.

डाइमेंशन

डाइमेंशन, डेटा के एक खास ग्रुप की पहचान करते हैं, जिसके आधार पर रिकॉर्ड को एग्रीगेट किया जा रहा है. उदाहरण के लिए, PHONE के नाप या आकार से पता चलता है कि रिकॉर्ड में, मोबाइल डिवाइस पर हुए लोड की जानकारी शामिल है.

CrUX इतिहास एपीआई को सिर्फ़ डिवाइस के नाप या आकार के हिसाब से एग्रीगेट किया जा सकता है. यह डिवाइस का एक सामान्य क्लास है जो PHONE, TABLET, और DESKTOP में बंटा है.

मेट्रिक

हम स्टैटिस्टिकल एग्रीगेशन की टाइम सीरीज़ में मेट्रिक की रिपोर्ट करते हैं. ये हिस्टोग्राम, पर्सेंटाइल, और फ़्रैक्शन हैं.

हिस्टोग्राम

जब मेट्रिक को हिस्टोग्राम कलेक्शन में दिखाया जाता है, तो हर टाइम सीरीज़ एंट्री, पेज लोड होने का वह प्रतिशत दिखाती है जिसके लिए मेट्रिक, सभी के अनुपात में एक इंटरवल में गिरी. डेटा पॉइंट, एपीआई से मिलने वाली डेटा इकट्ठा करने की अवधि की तारीखों के हिसाब से दिखाए जाते हैं. इसमें पहला पॉइंट, सबसे पुरानी अवधि होती है और आखिरी पॉइंट, डेटा इकट्ठा करने की सबसे हाल की अवधि होता है.

उदाहरण मेट्रिक के लिए, तीन बिन वाला सामान्य हिस्टोग्राम ऐसा दिखता है:

{
  "histogramTimeseries": [
    {
      "start": 0,
      "end": 2500,
      "densities": [0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187]
    },
    {
      "start": 2500,
      "end": 4000,
      "densities": [0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527]
    },
    {
      "start": 4000,
      "densities": [0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285]
    }
  ],
}

इस डेटा से पता चलता है कि इतिहास में पहली बार डेटा इकट्ठा करने की अवधि के दौरान, 91.90% पेज लोड में उदाहरण वाली मेट्रिक की वैल्यू 0 मि॰से॰ से 2,500 मि॰से॰ के बीच थी. इसके बाद, यह संख्या 92.03%, 91.94%... मेट्रिक की इकाइयां इस हिस्टोग्राम में शामिल नहीं हैं. इस मामले में, हम मिलीसेकंड मान लेंगे.

इसके अलावा, 5.21% पेज लोड में उदाहरण के तौर पर मेट्रिक की वैल्यू 2,500 मि॰से॰ से 4,000 मि॰से॰ के बीच थी. इतिहास में पहली बार डेटा इकट्ठा करने की अवधि में, 2.88% पेज लोड की वैल्यू 4,000 मि॰से॰ से ज़्यादा थी.

पर्सेंटाइल

मेट्रिक में पर्सेंटाइल की टाइम सीरीज़ भी हो सकती है. ये अतिरिक्त विश्लेषण के लिए काम के हो सकते हैं.

डेटा पॉइंट, एपीआई से मिलने वाली डेटा इकट्ठा करने की अवधि की तारीखों के हिसाब से दिखाए जाते हैं. इसमें पहला पॉइंट, सबसे पुरानी अवधि होती है और आखिरी पॉइंट, डेटा इकट्ठा करने की सबसे हाल की अवधि होता है.

{
  "percentilesTimeseries": {
    "p75s": [1362, 1352, 1344, 1356, 1366, 1377]
  },
}

ये पर्सेंटाइल, दिए गए पर्सेंटाइल पर किसी मेट्रिक की वैल्यू दिखा सकते हैं. ये बाइंड किए गए फ़ाइनल डेटा पर नहीं, बल्कि उपलब्ध डेटा के पूरे सेट पर आधारित होते हैं. इसलिए, ज़रूरी नहीं है कि वे बाइंड किए गए आखिरी हिस्टोग्राम पर आधारित इंटरपोलेट किए गए पर्सेंटाइल से मेल खाएं.

फ़्रैक्शन

मेट्रिक को लेबल किए गए फ़्रैक्शन के टाइम सीरीज़ के तौर पर दिखाया जा सकता है; हर लेबल, पेज लोड होने के बारे में एक खास तरह से बताता है. डेटा पॉइंट, एपीआई से मिलने वाली डेटा इकट्ठा करने की अवधि की तारीखों के हिसाब से दिखाए जाते हैं. इसमें पहला पॉइंट, सबसे पुरानी अवधि होती है और आखिरी पॉइंट, डेटा इकट्ठा करने की सबसे हाल की अवधि होता है.

उदाहरण:

{    
  "fractionTimeseries": {
    "desktop": {"fractions": [0.3195, 0.2115, 0.1421]},
    "phone": {"fractions": [0.6295, 0.7544, 0.8288]},
    "tablet": {"fractions": [0.051, 0.0341, 0.029]}
  }
}

इस उदाहरण में, सबसे हाल के डेटा पॉइंट से पता चलता है कि 14.21% पेज लोड डेस्कटॉप से और 82.88% फ़ोन से आए.

मेट्रिक वैल्यू के टाइप

CrUX History API, एक ही तरह की मेट्रिक की वैल्यू का इस्तेमाल करता है. इसलिए, ज़्यादा जानकारी के लिए, हर दिन की CrUX API मेट्रिक वैल्यू टाइप के दस्तावेज़ देखे जा सकते हैं.

मेट्रिक की ज़रूरी शर्तें

ज़रूरी शर्तों के हिसाब से, हो सकता है कि ऑरिजिन या यूआरएल सिर्फ़ CrUX History API के दायरे में आने वाली कुछ दिनों की स्टोरेज की ज़रूरी शर्तें पूरी करता हो. इन मामलों में, CrUX इतिहास एपीआई, histogramTimeseries डेंसिटी के लिए "NaN" दिखाएगा और इकट्ठा करने की अवधि के लिए percentilesTimeseries के लिए null देगा. साथ ही, इसमें ज़रूरी शर्तें पूरी करने वाला डेटा नहीं होगा. इस अंतर की वजह यह है कि हिस्टोग्राम डेंसिटी में हमेशा संख्याएं होती हैं, जबकि पर्सेंटाइल में संख्या या स्ट्रिंग हो सकती हैं (सीएलएस, स्ट्रिंग का इस्तेमाल करता है, भले ही वे संख्याओं की तरह दिखें).

उदाहरण के लिए, अगर दूसरी अवधि में ज़रूरी शर्तें पूरी करने वाला कोई डेटा नहीं था, तो यह इस तरह दिखेगा:

{
  "histogramTimeseries": [
    {
      "start": 0,
      "end": 2500,
      "densities": [0.9190, "NaN", 0.9194, 0.9195, 0.9183, 0.9187]
    },
    {
      "start": 2500,
      "end": 4000,
      "densities": [0.0521, "NaN", 0.0518, 0.0518, 0.0526, 0.0527]
    },
    {
      "start": 4000,
      "densities": [0.0288, "NaN", 0.0286, 0.0285, 0.0290, 0.0285]
    }
  ],
  "percentilesTimeseries": {
    "p75s": [1362, null, 1344, 1356, 1366, 1377]
  },
}

ऐसे यूआरएल या ऑरिजिन में कई बार एंट्री हो सकती हैं जो समय के साथ तय शर्तों के मुताबिक नहीं होती हैं.

कलेक्शन की अवधि

CrUX इतिहास एपीआई में एक collectionPeriods ऑब्जेक्ट होता है, जिसमें firstDate और endDate फ़ील्ड की कलेक्शन होता है. ये फ़ील्ड, हर एग्रीगेशन विंडो के शुरू और खत्म होने की तारीख दिखाते हैं. उदाहरण के लिए:

    "collectionPeriods": [{
        "firstDate": { "year": 2022, "month": 7, "day": 10 },
        "lastDate": { "year": 2022, "month": 8, "day": 6 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 17 },
        "lastDate": { "year": 2022, "month": 8, "day": 13 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 24 },
        "lastDate": { "year": 2022, "month": 8, "day": 20 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 31 },
        "lastDate": { "year": 2022, "month": 8, "day": 27 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 7 },
        "lastDate": { "year": 2022, "month": 9, "day": 3 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 14 },
        "lastDate": { "year": 2022, "month": 9, "day": 10 }
      }
    ]

डेटा इकट्ठा करने की ये अवधियां बढ़ते क्रम में होती हैं. साथ ही, जवाब के दूसरे सेक्शन में मौजूद हर डेटा पॉइंट की तारीख की सीमा दिखाते हैं.

इतिहास एपीआई को हर सोमवार को अपडेट किया जाता है. इसमें पिछले शनिवार तक का डेटा (स्टैंडर्ड दो दिन के अंतर के हिसाब से) तक का डेटा शामिल होता है. इसमें पिछले 25 हफ़्तों का डेटा शामिल होता है—हर हफ़्ते एक इकट्ठा करने की अवधि.

इकट्ठा करने की हर अवधि में पिछले 28 दिनों का एग्रीगेट किया गया डेटा शामिल होता है और इकट्ठा करने की अवधि हर हफ़्ते की होती है. इसका मतलब है कि इकट्ठा करने की अवधि ओवरलैप होगी. ये आंकड़े, डेटा के घटने-बढ़ने वाले औसत की तरह होते हैं. इसमें, हर बाद की अवधि में तीन हफ़्ते का डेटा शामिल किया जाता है और एक हफ़्ते का डेटा अलग-अलग होता है.

क्वेरी के उदाहरण

https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=[YOUR_API_KEY]" को POST अनुरोध का इस्तेमाल करके, क्वेरी को JSON ऑब्जेक्ट के तौर पर सबमिट किया जाता है. POST के मुख्य हिस्से में क्वेरी डेटा को JSON ऑब्जेक्ट के तौर पर शामिल किया जाता है.

ध्यान दें कि हर दिन के CrUX API के queryRecord को बदलने के लिए, queryHistoryRecord के इस्तेमाल पर ध्यान दें.

उदाहरण के तौर पर दिया गया मुख्य हिस्सा:

{
  "origin": "https://example.com",
  "formFactor": "PHONE",
  "metrics": [
    "largest_contentful_paint",
    "experimental_time_to_first_byte"
  ]
}

उदाहरण के लिए, इसे curl से इस कमांड लाइन का इस्तेमाल करके कॉल किया जा सकता है (API_KEY को अपनी कुंजी से बदलें):

curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord?key=API_KEY' \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --data '{"formFactor":"PHONE","origin":"https://www.example.com","metrics":["largest_contentful_paint", "experimental_time_to_first_byte"]}'

ध्यान दें: पिछला उदाहरण, macOS या Linux पर आधारित सिस्टम के लिए है—इसमें Windows के लिए Git BASH शेल भी शामिल है. अन्य सिस्टम में थोड़े बदलाव की ज़रूरत पड़ सकती है. उदाहरण के लिए, cmd.exe कमांड लाइन, पैरामीटर के लिए सिंगल कोट और लाइन कंटिन्यूशंस (\) की अनुमति नहीं देती. इसलिए, डबल कोट का इस्तेमाल करना ज़रूरी है (\" के साथ इनर कोट को एस्केप करना).

पेज लेवल का डेटा, एपीआई की मदद से origin के बजाय, क्वेरी में url प्रॉपर्टी पास करके उपलब्ध होता है:

{
  "url": "https://example.com/page",
  "formFactor": "PHONE",
  "metrics": [
    "largest_contentful_paint",
    "experimental_time_to_first_byte"
  ]
}

अगर metrics प्रॉपर्टी सेट नहीं है, तो सभी उपलब्ध मेट्रिक दिखेंगी:

cumulative_layout_shift
first_contentful_paint
first_input_delay
interaction_to_next_paint
largest_contentful_paint
experimental_time_to_first_byte
navigation_types
form_factors (सिर्फ़ तब रिपोर्ट किया जाता है, जब अनुरोध में formFactor के बारे में न बताया गया हो)

अगर formFactor वैल्यू नहीं दी जाती है, तो वैल्यू को सभी नाप या आकार वाले डिवाइसों के साथ एग्रीगेट किया जाएगा.

क्वेरी के और उदाहरणों के लिए, CrUX इतिहास एपीआई का इस्तेमाल करना गाइड देखें.

डेटा पाइपलाइन

CrUX डेटासेट को प्रोसेस किया जाता है, ताकि एपीआई के ज़रिए डेटा उपलब्ध होने से पहले ही उसे इकट्ठा किया जा सके, इकट्ठा किया जा सके, और फ़िल्टर किया जा सके.

रोलिंग औसत

Chrome की उपयोगकर्ता अनुभव रिपोर्ट में मौजूद डेटा, एग्रीगेट की गई मेट्रिक का 28 दिनों का रोलिंग औसत होता है. इसका मतलब यह है कि किसी खास समय पर, Chrome की उपयोगकर्ता अनुभव रिपोर्ट में दिखने वाला डेटा, असल में पिछले 28 दिनों का कुल डेटा होता है.

इतिहास एपीआई में इकट्ठा करने की कई अवधि शामिल हैं. हर अवधि पिछले 28 दिनों में पूरी होती है. इकट्ठा करने की हर अवधि में पिछले 28 दिनों का एग्रीगेट किया गया डेटा शामिल होता है और इकट्ठा करने की अवधि हर हफ़्ते की होती है. इसका मतलब है कि इकट्ठा करने की अवधि ओवरलैप होगी. ये आंकड़े, डेटा के घटने-बढ़ने वाले औसत की तरह होते हैं. इसमें, हर बाद की अवधि में तीन हफ़्ते का डेटा शामिल किया जाता है और एक हफ़्ते का डेटा अलग-अलग होता है.

हर हफ़्ते के अपडेट

इतिहास का एपीआई हर सोमवार को करीब 04:00 यूटीसी पर अपडेट किया जाता है. इसमें पिछले शनिवार तक का डेटा (स्टैंडर्ड दो दिन के लैग के हिसाब से) तक का डेटा शामिल होता है. इसमें पिछले 25 हफ़्तों (करीब छह महीने) का डेटा शामिल होता है. इस डेटा को हर हफ़्ते एक बार इकट्ठा किया जाता है.

अपडेट के समय के लिए कोई सेवा स्तर समझौता नहीं है; यह हर दिन सबसे बेहतर कोशिश के आधार पर चलाया जाता है.

स्कीमा

CrUX इतिहास एपीआई के लिए एक ही एंडपॉइंट होता है, जो POST एचटीटीपी अनुरोधों को स्वीकार करता है. एपीआई, अनुरोध किए गए ऑरिजिन या पेज के परफ़ॉर्मेंस डेटा से जुड़े एक या ज़्यादा metrics वाले record दिखाता है.

एचटीटीपी अनुरोध

POST https://chromeuxreport.googleapis.com/v1/records:queryHistoryRecord

यह यूआरएल gRPC ट्रांसकोडिंग सिंटैक्स का इस्तेमाल करता है.

अनुरोध का मुख्य भाग

CrUX इतिहास एपीआई, effectiveConnectionType अनुरोध फ़ील्ड के साथ काम न करने के अलावा, उन चीज़ों का इस्तेमाल करता है जिनका इस्तेमाल रोज़ के CrUX API में किया जाता है.

उदाहरण के लिए, web.dev होम पेज के लिए डेस्कटॉप के सबसे बड़े कॉन्टेंटफ़ुल पेंट की वैल्यू का अनुरोध करने के लिए:

{
  "origin": "https://web.dev/",
  "formFactor": "DESKTOP",
  "metrics": [
    "largest_contentful_paint"
  ]
}

जवाब का मुख्य भाग

अनुरोध पूरा होने पर, इस स्ट्रक्चर में record ऑब्जेक्ट और urlNormalizationDetails के साथ रिस्पॉन्स दिखाए जाते हैं:

{
  "record": {
    "key": {
      object (Key)
    },
    "metrics": [
      string: {
        object (Metric)
      }
    ]
  },
  "urlNormalizationDetails": {
    object (UrlNormalization)
  }
}

उदाहरण के लिए, पिछले अनुरोध में अनुरोध के मुख्य हिस्से का जवाब यह हो सकता है:

{
  "record": {
    "key": {
      "origin": "https://web.dev"
    },
    "metrics": {
      "largest_contentful_paint": {
        "histogramTimeseries": [{
            "start": 0, "end": 2500, "densities": [
              0.9190, 0.9203, 0.9194, 0.9195, 0.9183, 0.9187, ...
            ]
          }, {
            "start": 2500, "end": 4000, "densities": [
              0.0521, 0.0513, 0.0518, 0.0518, 0.0526, 0.0527, ...
            ]
          },  {
            "start": 4000, "densities": [
              0.0288, 0.0282, 0.0286, 0.0285, 0.0290, 0.0285, ...
            ]
          }
        ],
        "percentilesTimeseries": {
          "p75s": [
            1362, 1352, 1344, 1356, 1366, 1377, ...
          ]
        }
      }
    },
    "collectionPeriods": [{
        "firstDate": { "year": 2022, "month": 7, "day": 10 },
        "lastDate": { "year": 2022, "month": 8, "day": 6 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 17 },
        "lastDate": { "year": 2022, "month": 8, "day": 13 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 24 },
        "lastDate": { "year": 2022, "month": 8, "day": 20 }
      }, {
        "firstDate": { "year": 2022, "month": 7, "day": 31 },
        "lastDate": { "year": 2022, "month": 8, "day": 27 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 7 },
        "lastDate": { "year": 2022, "month": 9, "day": 3 }
      }, {
        "firstDate": { "year": 2022, "month": 8, "day": 14 },
        "lastDate": { "year": 2022, "month": 9, "day": 10 }
      }, {
        ...
      }
    ]
  }
}

सुरक्षा कुंजी

Key उन सभी डाइमेंशन के बारे में बताता है जो इस रिकॉर्ड की पहचान यूनीक के तौर पर करते हैं.

{
  "formFactor": enum (FormFactor),

  // Union field url_pattern can be only one of the following:
  "origin": string,
  "url": string
  // End of list of possible types for union field url_pattern.
}

फ़ील्ड
`formFactor`	`enum (FormFactor)` डिवाइस का नाप या आकार, डिवाइस की उस क्लास को दिखाता है जिसका इस्तेमाल सभी उपयोगकर्ताओं ने इस रिकॉर्ड के लिए, साइट को ऐक्सेस करने के लिए किया था. अगर डिवाइस के नाप या आकार की जानकारी नहीं दी गई है, तो डिवाइस के सभी नाप या आकार के हिसाब से इकट्ठा किया गया डेटा दिखाया जाएगा.
यूनियन फ़ील्ड `url_pattern`. यूआरएल पैटर्न, वह यूआरएल होता है जिस पर रिकॉर्ड लागू होता है. `url_pattern` इनमें से सिर्फ़ एक हो सकती है:
`origin`	`string` ऑरिजिन से उस ऑरिजिन की जानकारी मिलती है जिसके लिए यह रिकॉर्ड बनाया गया है. ध्यान दें: ऑरिजिन की जानकारी देते समय, सभी पेजों पर इस ऑरिजिन में लोड किए गए डेटा को, ऑरिजिन लेवल के उपयोगकर्ता अनुभव के डेटा के तौर पर एग्रीगेट किया जाता है.
`url`	`string` `url` उस यूआरएल के बारे में बताता है जिसके लिए यह रिकॉर्ड है. ध्यान दें: `url` तय करते समय, सिर्फ़ उस खास यूआरएल का डेटा एग्रीगेट किया जाएगा.

मेट्रिक

metric किसी वेब परफ़ॉर्मेंस मेट्रिक के लिए, उपयोगकर्ता अनुभव के डेटा का सेट होता है, जैसे कि फ़र्स्ट कॉन्टेंटफ़ुल पेंट. इसमें bins की सीरीज़ के रूप में, Chrome के असल इस्तेमाल के बारे में खास जानकारी देने वाला हिस्टोग्राम है.

{
  "histogramTimeseries": [
    {
      object (Bin)
    }
  ],
  "percentilesTimeseries": {
    object (Percentiles)
  }
}

या

"fractionTimeseries": {
  object (Fractions)
}

फ़ील्ड

फ़ील्ड
`histogramTimeseries[]`	`object (Bin)` किसी मेट्रिक के लिए उपयोगकर्ता अनुभवों का टाइम सीरीज़ हिस्टोग्राम. टाइम सीरीज़ हिस्टोग्राम में कम से कम एक बिन होगा और सभी बिन की डेंसिटी ~1 होगी. कलेक्शन की उस अवधि में जो वैल्यू मौजूद नहीं हैं उन्हें `"NaN"` के तौर पर मार्क किया जाएगा.
`percentilesTimeseries`	`object (Percentiles)` मेट्रिक के सामान्य उपयोगी पर्सेंटाइल. पर्सेंटाइल के लिए वैल्यू टाइप, हिस्टोग्राम बिन के लिए दिए गए वैल्यू टाइप के जैसा ही होगा. कलेक्शन की उस अवधि में जो वैल्यू मौजूद नहीं हैं उन्हें `null` के तौर पर मार्क किया जाएगा.
`fractionTimeseries`	`object (Fractions)` इस ऑब्जेक्ट में लेबल किए गए भिन्नों की टाइम सीरीज़ शामिल हैं, जिनका योग ~1 प्रति एंट्री है. भिन्नों को दशमलव के बाद चार अंकों तक पूरा किया जाता है. जो एंट्री मौजूद नहीं हैं उन्हें सभी फ़्रैक्शन में `"NaN"` के तौर पर दिखाया जाता है.

histogramTimeseries[]

object (Bin)

किसी मेट्रिक के लिए उपयोगकर्ता अनुभवों का टाइम सीरीज़ हिस्टोग्राम. टाइम सीरीज़ हिस्टोग्राम में कम से कम एक बिन होगा और सभी बिन की डेंसिटी ~1 होगी.

कलेक्शन की उस अवधि में जो वैल्यू मौजूद नहीं हैं उन्हें "NaN" के तौर पर मार्क किया जाएगा.

percentilesTimeseries

object (Percentiles)

मेट्रिक के सामान्य उपयोगी पर्सेंटाइल. पर्सेंटाइल के लिए वैल्यू टाइप, हिस्टोग्राम बिन के लिए दिए गए वैल्यू टाइप के जैसा ही होगा.

कलेक्शन की उस अवधि में जो वैल्यू मौजूद नहीं हैं उन्हें null के तौर पर मार्क किया जाएगा.

fractionTimeseries

object (Fractions)

इस ऑब्जेक्ट में लेबल किए गए भिन्नों की टाइम सीरीज़ शामिल हैं, जिनका योग ~1 प्रति एंट्री है.

भिन्नों को दशमलव के बाद चार अंकों तक पूरा किया जाता है.

जो एंट्री मौजूद नहीं हैं उन्हें सभी फ़्रैक्शन में `"NaN"` के तौर पर दिखाया जाता है.

बिन

A bin, शुरू से लेकर आखिर तक फैला डेटा का डिस्क्रीट (अलग-अलग वैल्यू) हिस्सा होता है. अगर शुरू से लेकर पॉज़िटिव इनफ़िनिटी तक कोई एंड न दिया गया हो.

बिन की शुरुआती और आखिरी वैल्यू, उस मेट्रिक के वैल्यू टाइप में दी जाती हैं जिसे वह दिखाता है. उदाहरण के लिए, फ़र्स्ट कॉन्टेंटफ़ुल पेंट, मिलीसेकंड में मापा जाता है और इंटरट के रूप में दिखाया जाता है. इसलिए, इसके मेट्रिक बिन, शुरू और खत्म होने के टाइप के लिए int32s का इस्तेमाल करेंगे. हालांकि, कुल लेआउट शिफ़्ट को यूनिटलेस दशमलव में मापा जाता है और इसे स्ट्रिंग के तौर पर एन्कोड किए गए दशमलव के रूप में दिखाया जाता है. इसलिए, इसके मेट्रिक बिन, वैल्यू टाइप के लिए स्ट्रिंग का इस्तेमाल करेंगे.

{
  "start": value,
  "end": value,
  "densities": [number, number, number...etc.]
}

फ़ील्ड

फ़ील्ड
`start`	`(integer \| string)` डेटा बिन की शुरुआत से शुरू होता है.
`end`	`(integer \| string)` डेटा बिन का आखिरी हिस्सा एंड है. अगर आखिरी वैल्यू भरी हुई नहीं है, तो इसका मतलब है कि बिन का कोई आखिरी हिस्सा नहीं है और यह शुरू से +inf तक मान्य है.
`densities`	`array[number]` ऐसी उपयोगकर्ताओं के अनुपात की टाइम सीरीज़ जिन्होंने दी गई मेट्रिक के लिए इस बिन की वैल्यू का अनुभव किया है. सघनता को दशमलव के बाद चार अंकों तक पूरा किया जाता है.

start

(integer | string)

डेटा बिन की शुरुआत से शुरू होता है.

end

(integer | string)

डेटा बिन का आखिरी हिस्सा एंड है. अगर आखिरी वैल्यू भरी हुई नहीं है, तो इसका मतलब है कि बिन का कोई आखिरी हिस्सा नहीं है और यह शुरू से +inf तक मान्य है.

densities

array[number]

ऐसी उपयोगकर्ताओं के अनुपात की टाइम सीरीज़ जिन्होंने दी गई मेट्रिक के लिए इस बिन की वैल्यू का अनुभव किया है.

सघनता को दशमलव के बाद चार अंकों तक पूरा किया जाता है.

पर्सेंटाइल

Percentiles में, दिए गए आंकड़ों के पर्सेंटाइल पर किसी मेट्रिक की एआई से जनरेट की गई वैल्यू शामिल होती है. इनका इस्तेमाल, किसी मेट्रिक की वैल्यू का अनुमान लगाने के लिए किया जाता है. यह आकलन, कुल उपयोगकर्ताओं में से कुछ उपयोगकर्ताओं के प्रतिशत के आधार पर किया जाता है.

{
  "P75": value
}

फ़ील्ड

फ़ील्ड
`p75s`	`array[(integer \| string)]` 75% पेज लोड होने वाली वैल्यू की टाइम सीरीज़ में, दी गई मेट्रिक इस वैल्यू पर या इससे कम थी.

p75s

array[(integer | string)]

75% पेज लोड होने वाली वैल्यू की टाइम सीरीज़ में, दी गई मेट्रिक इस वैल्यू पर या इससे कम थी.

फ़्रैक्शन

Fractions में लेबल किए गए फ़्रैक्शन का टाइम सीरीज़ होता है. इसमें हर एंट्री के हिसाब से, ~1 वैल्यू मिलती है. हर लेबल, पेज लोड के बारे में कुछ हद तक जानकारी देता है, इसलिए इस तरह से दिखाई गई मेट्रिक को संख्या वाली वैल्यू के बजाय अलग-अलग वैल्यू देने के तौर पर देखा जा सकता है. साथ ही, फ़्रैक्शन यह दिखाते हैं कि किसी खास वैल्यू को कितनी बार मापा गया.

{
  "label_1": { "fractions": array[fraction]},
  "label_1": { "fractions": array[fraction]},
  ...
  "label_n": { "fractions": array[fraction]}
}

हिस्टोग्राम बिन में दी गई डेंसिटी की वैल्यू की तरह, हर fraction एक संख्या 0.0 <= value <= 1.0 होती है और उनका योग करीब ~1.0 होता है. अगर इकट्ठा करने की किसी खास अवधि के लिए मेट्रिक उपलब्ध नहीं है, तो फ़्रैक्शन के सभी कलेक्शन में उससे जुड़ी एंट्री "NaN" होगी.

फ़ील्ड

फ़ील्ड
`p75s`	`array[(integer \| string)]` 75% पेज लोड होने वाली वैल्यू की टाइम सीरीज़ में, दी गई मेट्रिक इस वैल्यू पर या उससे कम थी.

p75s

array[(integer | string)]

75% पेज लोड होने वाली वैल्यू की टाइम सीरीज़ में, दी गई मेट्रिक इस वैल्यू पर या उससे कम थी.

UrlNormalization

यह एक ऑब्जेक्ट है, जो किसी यूआरएल को सामान्य बनाने के लिए की गई सामान्य कार्रवाइयों को दिखाता है, ताकि लुकअप की प्रोसेस पूरी होने की संभावना बढ़ सके. दिए गए url_pattern को देखते समय, अपने-आप होने वाले ये आसान बदलाव किए जा सकते हैं. ऐसा हो सकता है. इन रीडायरेक्ट जैसी जटिल कार्रवाइयां हैंडल नहीं की जाती हैं.

{
  "originalUrl": string,
  "normalizedUrl": string
}

फ़ील्ड

फ़ील्ड
`originalUrl`	`string` नॉर्मलाइज़ेशन की किसी भी कार्रवाई से पहले, अनुरोध किया गया ओरिजनल यूआरएल.
`normalizedUrl`	`string` नॉर्मलाइज़ेशन की सभी कार्रवाइयों के बाद इस्तेमाल होने वाला यूआरएल. यह एक मान्य उपयोगकर्ता अनुभव यूआरएल है, जिसे सही तरीके से खोजा जा सकता है.

originalUrl

string

नॉर्मलाइज़ेशन की किसी भी कार्रवाई से पहले, अनुरोध किया गया ओरिजनल यूआरएल.

normalizedUrl

string

नॉर्मलाइज़ेशन की सभी कार्रवाइयों के बाद इस्तेमाल होने वाला यूआरएल. यह एक मान्य उपयोगकर्ता अनुभव यूआरएल है, जिसे सही तरीके से खोजा जा सकता है.

दर की सीमाएं

CrUX इतिहास एपीआई, किसी भी एपीआई के लिए हर Google Cloud प्रोजेक्ट के लिए हर मिनट 150 क्वेरी के लिए CrUX API के साथ एक ही सीमा शेयर करता है जो बिना किसी शुल्क के उपलब्ध कराई जाती है. इस सीमा और आपके मौजूदा इस्तेमाल की जानकारी को Google Cloud Console में देखा जा सकता है. इस्तेमाल के ज़्यादातर उदाहरणों के लिए, यह कोटा काफ़ी होना चाहिए. साथ ही, बढ़े हुए कोटा के लिए पैसे चुकाना संभव नहीं है.