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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

पब्लिश करने की तारीख: 7 फ़रवरी, 2023, पिछली बार अपडेट करने की तारीख: 11 अप्रैल, 2025

CrUX History API, पेज और ऑरिजिन के हिसाब से, उपयोगकर्ता अनुभव के पिछले छह महीनों के डेटा को कम इंतज़ार के साथ ऐक्सेस करने की सुविधा देता है.

इसे आज़माएं!

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

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

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

CrUX API पासकोड

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

एपीआई पासकोड हासिल करना और उसका इस्तेमाल करना

इसके अलावा, क्रेडेंशियल पेज पर जाकर भी एक OAuth क्लाइंट आईडी बनाया जा सकता है.

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

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

उदाहरण के तौर पर दी गई क्वेरी देखें.

डेटा मॉडल

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

रिकॉर्ड करें

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

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

आइडेंटिफ़ायर से यह तय होता है कि किन रिकॉर्ड को खोजना है. 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 Report से क्वेरी करने पर, 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 History API, सिर्फ़ डिवाइस के साइज़, डाइमेंशन या कॉन्फ़िगरेशन के डाइमेंशन के हिसाब से एग्रीगेट किया गया डेटा उपलब्ध कराता है. यह डिवाइस की सामान्य क्लास है, जिसे 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 History API, इकट्ठा करने की उन अवधियों के लिए 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 History API में 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 }
      }
    ]

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

इतिहास से जुड़े एपीआई को हर सोमवार अपडेट किया जाता है. इसमें पिछले शनिवार तक का डेटा होता है. यह डेटा, दो दिन की देरी के हिसाब से होता है. इसमें पिछले 40 हफ़्तों का डेटा होता है. हर हफ़्ते के लिए, डेटा इकट्ठा करने की एक अवधि होती है. डिफ़ॉल्ट रूप से, कलेक्शन की 25 अवधियां दिखती हैं. अनुरोध में "collectionPeriodCount" को 1 से 40 के बीच के किसी नंबर पर सेट करके, इसे बदला जा सकता है.

हर कलेक्शन पीरियड में, पिछले 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"]}'

पेज-लेवल का डेटा, एपीआई के ज़रिए उपलब्ध होता है. इसके लिए, 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
• interaction_to_next_paint
• largest_contentful_paint
• experimental_time_to_first_byte
• largest_contentful_paint_resource_type
• largest_contentful_paint_image_time_to_first_byte
• largest_contentful_paint_image_resource_load_delay
• largest_contentful_paint_image_resource_load_duration
• largest_contentful_paint_image_element_render_delay
• navigation_types
• round_trip_time
• form_factors (अनुरोध में कोई formFactor तय न होने पर ही रिपोर्ट किया जाता है)

अगर formFactor की कोई वैल्यू नहीं दी जाती है, तो सभी फ़ॉर्म फ़ैक्टर के लिए वैल्यू इकट्ठा की जाएंगी.

ज़्यादा क्वेरी के उदाहरणों के लिए, CrUX History API का इस्तेमाल करना गाइड देखें.

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

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

रोलिंग औसत

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

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

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

History API हर सोमवार को यूटीसी समय के हिसाब से सुबह 04:00 बजे अपडेट होता है. इसमें पिछले शनिवार तक का डेटा होता है. ऐसा, दो दिन के स्टैंडर्ड अंतर के हिसाब से होता है. इसमें पिछले 40 हफ़्तों (लगभग 10 महीने) का डेटा होता है. हर हफ़्ते के लिए, डेटा इकट्ठा करने की एक अवधि होती है. ध्यान दें कि डिफ़ॉल्ट रूप से, हम हर टाइमसीरीज़ के लिए 25 एंट्री दिखाते हैं. हालांकि, collectionPeriodCount अनुरोध पैरामीटर की जानकारी देकर, इस संख्या को बदला जा सकता है.

अपडेट के समय के लिए, सेवा स्तर का कोई समझौता नहीं है. इसे हर दिन, पूरी कोशिश के साथ चलाया जाता है.

स्कीमा

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

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

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

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

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

CrUX History API, हर दिन के लिए CrUX API के जैसे अनुरोध बॉडी का इस्तेमाल करता है. साथ ही, इसमें एक अतिरिक्त और वैकल्पिक "collectionPeriodCount" फ़ील्ड भी होता है:

{
  "formFactor": enum (FormFactor),
  "metrics": [
    string
  ],

  // 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.

  "collectionPeriodCount": int32 // Optional: Number of periods to collect
}

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

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

इस मिलते-जुलते अनुरोध में, collectionPeriodCount फ़ील्ड शामिल है. इससे https://web.dev ऑरिजिन के लिए, वेब परफ़ॉर्मेंस का करीब 10 महीने का इतिहास देने वाली 40 टाइमसीरीज़ एंट्री मिलती हैं:

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

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

सही तरीके से किए गए अनुरोधों के जवाब, 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.
}

मेट्रिक

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

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

या

"fractionTimeseries": {
  object (Fractions)
}

बिन

bin, डेटा का एक अलग हिस्सा होता है, जो शुरू से लेकर आखिर तक होता है. अगर कोई आखिरी तारीख नहीं दी गई है, तो यह शुरू से लेकर अनंत तक होता है.

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

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

पर्सेंटाइल

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

{
  "P75": value
}

फ़्रैक्शन

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" होगी.

UrlNormalization

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

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

दर की सीमाएं

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