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

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

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

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

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

CrUX API कुंजी

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

क्रेडेंशियल पेज पर जाकर, क्रेडेंशियल बनाया जा सकता है और Chrome UX Report 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

इसका मतलब यह है कि जब Chrome की UX रिपोर्ट में ऑरिजिन को http://www.example.com पर सेट किया जाता है, तो 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 }
      }
    ]

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

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

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

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

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

ध्यान दें कि हर दिन के CrUX API के queryRecord की जगह, queryHistoryRecord का इस्तेमाल किया जा रहा है.

उदाहरण के लिए:

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

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

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
  • first_input_delay
  • interaction_to_next_paint
  • largest_contentful_paint
  • experimental_time_to_first_byte
  • navigation_types
  • round_trip_time
  • form_factors (सिर्फ़ तब रिपोर्ट की जाती है, जब अनुरोध में कोई formFactor मौजूद न हो)

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

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

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

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

रोलिंग औसत

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

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

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

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

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

स्कीमा

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

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

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

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

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

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

उदाहरण के लिए, 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"` के तौर पर दिखाया जाता है जो मौजूद नहीं हैं.

बिन

bin, डेटा का ऐसा हिस्सा होता है जो शुरू से आखिर तक फैला होता है या शुरुआत से पॉज़िटिव इनफ़िनिटी तक कोई आखिरी हिस्सा नहीं होता.

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

{
  "start": value,
  "end": value,
  "densities": [number, number, number...etc.]
}
फ़ील्ड
start

(integer | string)

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

(integer | string)

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

array[number]

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

डेंसिटी को दशमलव के बाद चार अंकों तक कर दिया जाता है.

पर्सेंटाइल

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

{
  "P75": value
}
फ़ील्ड
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% पेज लोड होते हैं उनकी टाइम सीरीज़ में, दी गई मेट्रिक का अनुभव, इस वैल्यू से कम या इसके बराबर होता है.

UrlNormalization

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

{
  "originalUrl": string,
  "normalizedUrl": string
}
फ़ील्ड
originalUrl

string

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

string

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

रेट लिमिट

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