CrUX एपीआई

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

इसे आज़माएं!

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

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

CrUX API कुंजी

CrUX API का इस्तेमाल करने के लिए, Chrome UX Report API के इस्तेमाल के लिए Google Cloud API कुंजी का प्रावधान करना ज़रूरी है.

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

डिजिटल सुरक्षा कुंजी पाएं

या क्रेडेंशियल पेज में जाकर क्रेडेंशियल बनाएं.

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

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

क्वेरी के उदाहरण देखें.

डेटा मॉडल

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

रिकॉर्ड करें

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

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

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

डिवाइस का नाप या आकार

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

कनेक्शन का टाइप

इफ़ेक्टिव कनेक्शन टाइप, पेज पर नेविगेट करते समय डिवाइस के कनेक्शन की अनुमानित क्वालिटी होती है. यह एक सामान्य क्लास है जो offline, slow-2G, 2G, 3G, और 4G में बंटी हुई है.

मेट्रिक

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

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

हिस्टोग्राम

जब मेट्रिक को हिस्टोग्राम में दिखाया जाता है, तो हम किसी खास रेंज में बदलाव कर सकते हैं.

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

{
  "histogram": [
    {
      "start": 0,
      "end": 1000,
      "density": 0.3818
    },
    {
      "start": 1000,
      "end": 3000,
      "density": 0.4991
    },
    {
      "start": 3000,
      "density": 0.1192
    }
  ]
}

इस डेटा से पता चलता है कि 38.18% पेज लोड के लिए, उदाहरण मेट्रिक को मेज़र किया गया था 0 मि॰से॰ से 1,000 मि॰से॰ के बीच. मेट्रिक की इकाइयां इस हिस्टोग्राम में शामिल नहीं हैं, इस मामले में हम मिलीसेकंड मान लेंगे.

इसके अलावा, 49.91% पेज लोड को मेट्रिक वैल्यू 1,000 मि॰से॰ से 3,000 मि॰से॰ और 11.92% के बीच दिखी वैल्यू 3,000 मि॰से॰ से ज़्यादा दिखी.

पर्सेंटाइल

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

{
  "percentiles": {
    "p75": 2063
  }
}

इस उदाहरण में, कम से कम 75% पेज लोड को मेट्रिक वैल्यू <= 2063 का इस्तेमाल करके मेज़र किया गया था.

फ़्रैक्शन

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

उदाहरण के लिए, form_factors मेट्रिक में एक fractions ऑब्जेक्ट होता है. इसमें, किसी क्वेरी के लिए उपलब्ध अलग-अलग नाप या आकार वाले डिवाइसों या डिवाइसों के ब्रेकडाउन की जानकारी होती है:

"form_factors": {
  "fractions": {
    "desktop": 0.0377,
    "tablet": 0.0288,
    "phone": 0.9335
  }
}

इस मामले में, डेस्कटॉप पर 3.77% पेज लोड होने की दर, टैबलेट पर 2.88%, और फ़ोन पर 93.35% पेज लोड होने की दर को कुल मिलाकर 100% मापा गया.

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

CrUX API की मेट्रिक का नाम	डेटा टाइप	मेट्रिक इकाइयां	आंकड़ों के एग्रीगेशन	दस्तावेज़
cumulative_layout_shift	दशमलव के बाद दो अंक, स्ट्रिंग के तौर पर कोड में बदले गए	यूनिटलेस	तीन बिन के साथ हिस्टोग्राम, p75 के साथ पर्सेंटाइल	cls
first_contentful_paint	int	मिलीसेकंड	तीन बिन के साथ हिस्टोग्राम, p75 के साथ पर्सेंटाइल	fcp
interaction_to_next_paint	int	मिलीसेकंड	तीन बिन के साथ हिस्टोग्राम, p75 के साथ पर्सेंटाइल	inp
largest_contentful_paint	int	मिलीसेकंड	तीन बिन के साथ हिस्टोग्राम, p75 के साथ पर्सेंटाइल	lcp
experimental_time_to_first_byte	int	मिलीसेकंड	तीन बिन के साथ हिस्टोग्राम, p75 के साथ पर्सेंटाइल	ttfb
form_factors	4-दशमलव स्थान (डबल)	प्रतिशत	डिवाइस के नाप या आकार से फ़्रैक्शन में मैपिंग	डिवाइस का नाप या आकार
navigation_types	दशमलव के बाद चार अंकों वाला डबल	प्रतिशत	नेविगेशन टाइप से फ़्रैक्शन में मैप करना	नेविगेशन के टाइप
round_trip_time	int	मिलीसेकंड	p75 के साथ पर्सेंटाइल	आरटीटी

BigQuery मेट्रिक के नाम की मैपिंग

CrUX API की मेट्रिक का नाम	BigQuery मेट्रिक का नाम
cumulative_layout_shift	layout_instability.cumulative_layout_shift
first_contentful_paint	first_contentful_paint
interaction_to_next_paint	interaction_to_next_paint
largest_contentful_paint	largest_contentful_paint
experimental_time_to_first_byte	experimental.time_to_first_byte
navigation_types	navigation_types
form_factors	लागू नहीं
round_trip_time	लागू नहीं

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

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

    "collectionPeriod": {
      "firstDate": {
        "year": 2022,
        "month": 9,
        "day": 12
      },
      "lastDate": {
        "year": 2022,
        "month": 10,
        "day": 9
      }
    }

इससे डेटा को बेहतर तरीके से समझने में मदद मिलती है. साथ ही, इससे यह भी पता चलता है कि क्या उसे अभी तक उस दिन के लिए अपडेट किया गया है या क्या इसमें कल की तरह ही डेटा दिख रहा है.

ध्यान दें कि CrUX API, आज की तारीख से करीब दो दिन पीछे है. ऐसा इसलिए होता है, क्योंकि यह दिन के पूरे डेटा का इंतज़ार करता है. साथ ही, एपीआई में उपलब्ध होने से पहले, डेटा को प्रोसेस करने में भी कुछ समय लगता है. इसके लिए, पैसिफ़िक स्टैंडर्ड टाइम (पीएसटी) फ़ॉर्मैट का इस्तेमाल किया जाता है. इसमें डेलाइट सेविंग में कोई बदलाव नहीं किया जाता.

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

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

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

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

क्वेरी के ज़्यादा उदाहरण के लिए, Chrome UX Report API का इस्तेमाल करना देखें.

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

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

रोलिंग औसत

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

यह BigQuery पर CrUX डेटासेट के हिसाब से हर महीने की रिपोर्ट इकट्ठा करता है.

रोज़ के अपडेट

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

स्कीमा

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

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

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

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

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

अनुरोध के मुख्य हिस्से में, यहां दिए गए स्ट्रक्चर का डेटा होना चाहिए:

{
  "effectiveConnectionType": string,
  "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.
}

फ़ील्ड
effectiveConnectionType	string असरदार कनेक्शन टाइप एक क्वेरी डाइमेंशन होता है, जो उस असरदार नेटवर्क क्लास के बारे में बताता है जिससे रिकॉर्ड का डेटा होना चाहिए. इस फ़ील्ड में ["offline", "slow-2G", "2G", "3G", "4G"] वैल्यू का इस्तेमाल किया जाता है, जैसा कि Network Information API की खास बातों में बताया गया है ध्यान दें: अगर कोई असरदार कनेक्शन टाइप तय नहीं किया गया है, तो सभी असरदार कनेक्शन टाइप के लिए एग्रीगेट किए गए डेटा के साथ एक खास रिकॉर्ड दिखाया जाएगा.
formFactor	enum (FormFactor) डिवाइस का साइज़, डाइमेंशन या कॉन्फ़िगरेशन एक क्वेरी डाइमेंशन है. इससे उस डिवाइस क्लास के बारे में पता चलता है जिससे रिकॉर्ड का डेटा जुड़ा होना चाहिए. इस फ़ील्ड में DESKTOP, PHONE, या TABLET. ध्यान दें: अगर डिवाइस का कोई नाप या आकार नहीं दिया गया है, तो एक खास रिकॉर्ड दिखाया जाएगा. इसमें, सभी डिवाइस टाइप के हिसाब से इकट्ठा किए गए डेटा वाला खास रिकॉर्ड दिया जाएगा.
metrics[]	string वे मेट्रिक जिन्हें जवाब में शामिल किया जाना चाहिए. अगर कोई मेट्रिक तय नहीं की गई है, तो कोई भी मेट्रिक दिखाई जाएगी. इस्तेमाल की जा सकने वाली वैल्यू: ["cumulative_layout_shift", "first_contentful_paint", "interaction_to_next_paint", "largest_contentful_paint", "experimental_time_to_first_byte"]
यूनियन फ़ील्ड url_pattern. url_pattern, रिकॉर्ड लुकअप का मुख्य आइडेंटिफ़ायर है. यह इनमें से सिर्फ़ एक हो सकता है:
origin	string url_pattern "शुरुआत की जगह" एक ऐसे यूआरएल पैटर्न के बारे में बताता है जो किसी वेबसाइट का ऑरिजिन होता है. उदाहरण: "https://example.com", "https://cloud.google.com"
url	string url_pattern url से, यूआरएल पैटर्न के बारे में पता चलता है. यह कोई भी आर्बिट्रेरी यूआरएल होता है. उदाहरण: "https://example.com/, https://cloud.google.com/why-google-cloud/"

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

{
  "url": "https://developer.chrome.com/docs/",
  "formFactor": "DESKTOP",
  "metrics": [
    "largest_contentful_paint"
  ]
}

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

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

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

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

{
  "record": {
    "key": {
      "formFactor": "DESKTOP",
      "url": "https://developer.chrome.com/docs/"
    },
    "metrics": {
      "largest_contentful_paint": {
        "histogram": [
          {
            "start": 0,
            "end": 2500,
            "density": 0.9815
          },
          {
            "start": 2500,
            "end": 4000,
            "density": 0.0108
          },
          {
            "start": 4000,
            "density": 0.0077
          }
        ],
        "percentiles": {
          "p75": 651
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2022,
        "month": 9,
        "day": 12
      },
      "lastDate": {
        "year": 2022,
        "month": 10,
        "day": 9
      }
    }
  }
}

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

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

{
  "effectiveConnectionType": string,
  "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) डिवाइस का नाप या आकार, डिवाइस की वह क्लास है जिसका इस्तेमाल सभी उपयोगकर्ताओं ने इस रिकॉर्ड के लिए साइट ऐक्सेस करने के लिए किया था. अगर डिवाइस के नाप या आकार की जानकारी नहीं दी गई है, तो सभी डिवाइस टाइप के हिसाब से इकट्ठा किया गया डेटा दिखाया जाएगा.
effectiveConnectionType	string असरदार कनेक्शन टाइप, कनेक्शन की सामान्य क्लास होती है. इस रिकॉर्ड के लिए, सभी उपयोगकर्ताओं को यह कनेक्शन मिला. यह फ़ील्ड वैल्यू के तौर पर ["ऑफ़लाइन", "slow-2G", "2G", "3G", "4G"] का इस्तेमाल करता है, जैसा कि https://wicg.github.io/netinfo/#effective-connection-types में बताया गया है अगर असरदार कनेक्शन टाइप तय नहीं किया गया है, तो सभी असरदार कनेक्शन टाइप का एग्रीगेट किया गया डेटा दिखाया जाएगा.
यूनियन फ़ील्ड url_pattern. यूआरएल पैटर्न, वह यूआरएल होता है जिस पर रिकॉर्ड लागू होता है. url_pattern इनमें से सिर्फ़ एक हो सकता है:
origin	string origin उस ऑरिजिन के बारे में बताता है जिसके लिए यह रिकॉर्ड है. ध्यान दें: origin के बारे में बताते समय, इस ऑरिजिन में सभी पेजों पर लोड होने वाले डेटा को ऑरिजिन लेवल के उपयोगकर्ता अनुभव से जुड़े डेटा में शामिल किया जाता है.
url	string url उस खास यूआरएल के बारे में बताता है जिसके लिए यह रिकॉर्ड है. ध्यान दें: url तय करने पर, सिर्फ़ उस यूआरएल के लिए डेटा इकट्ठा किया जाएगा.

मेट्रिक

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

{
  "histogram": [
    {
      object (Bin)
    }
  ],
  "percentiles": {
    object (Percentiles)
  }
}

या

{
  "fractions": {
    object (Fractions)
  }
}

फ़ील्ड
histogram[]	object (Bin) किसी मेट्रिक के लिए, उपयोगकर्ता अनुभव का हिस्टोग्राम. हिस्टोग्राम में कम से कम एक बिन होगा और सभी बिन की डेंसिटी का जोड़ ~1 होगा.
percentiles	object (Percentiles) मेट्रिक के सामान्य उपयोगी पर्सेंटाइल. पर्सेंटाइल के लिए वैल्यू का टाइप, हिस्टोग्राम बिन के लिए दी गई वैल्यू टाइप से मेल खाता है.
fractions	object (Fractions) इस ऑब्जेक्ट में लेबल किए हुए फ़्रैक्शन हैं, जिनका कुल योग ~1 है. फ़्रैक्शन को दशमलव के बाद चार अंकों में बदल दिया जाता है.

बिन

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

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

{
  "start": value,
  "end": value,
  "density": number
}

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

पर्सेंटाइल

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

{
  "P75": value
}

फ़ील्ड
p75	(integer | string) कुल 75% पेज लोड में, इस मेट्रिक का इस्तेमाल किया गया. यह मेट्रिक, इस वैल्यू से कम या इसके बराबर थी.

फ़्रैक्शन

Fractions में लेबल किए गए ऐसे भिन्न शामिल हैं जिनका योग ~1 होता है. हर लेबल पेज लोड होता है, इसलिए इस तरह से पेश की गई मेट्रिक का मतलब भिन्न मान के बजाय भिन्न मान बनाते हैं और भिन्न, किसी खास वैल्यू को कितनी बार मेज़र किया गया.

{
  "label_1": fraction,
  "label_2": fraction,
  ...
  "label_n": fraction
}

हिस्टोग्राम बिन में डेंसिटी की वैल्यू की तरह ही, हर fraction एक संख्या होती है 0.0 <= value <= 1.0 और कुल मिलाकर ~1.0 है.

UrlNormalization

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

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

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

रेट लिमिट

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