CrUX API, पेज और ऑरिजिन की ज़्यादा जानकारी के इकट्ठा किए गए असली उपयोगकर्ता अनुभव के डेटा के लिए इंतज़ार का समय कम करता है.
इस्तेमाल का सामान्य उदाहरण
CrUX API, "https://example.com
ऑरिजिन के लिए मेट्रिक पाएं" जैसे खास यूआरआई के लिए उपयोगकर्ता अनुभव मेट्रिक की क्वेरी करने की अनुमति देता है.
CrUX एपीआई पासकोड
CrUX 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
के नाप या आकार से पता चलता है कि रिकॉर्ड में, मोबाइल डिवाइस पर हुए लोड के बारे में जानकारी है. हर डाइमेंशन में वैल्यू की एक तय संख्या होगी. हालांकि, उस डाइमेंशन के बारे में जानकारी न देने का मतलब यह होगा कि डाइमेंशन को सभी वैल्यू के साथ एग्रीगेट किया गया है. उदाहरण के लिए, कोई नाप या आकार तय न करने का मतलब है कि रिकॉर्ड में किसी भी नाप या आकार में हुए लोड के बारे में जानकारी है.
डिवाइस का नाप या आकार
डिवाइस की वह क्लास जिसका इस्तेमाल असली उपयोगकर्ता ने पेज पर नेविगेट करने के लिए किया. यह डिवाइस का एक सामान्य क्लास है जो PHONE
, TABLET
, और DESKTOP
में बंटा है.
असरदार कनेक्शन टाइप
असरदार कनेक्शन टाइप, पेज पर नेविगेट करते समय, डिवाइस की कनेक्शन की अनुमानित क्वालिटी है. यह एक सामान्य क्लास है जो offline
, slow-2G
, 2G
, 3G
, और 4G
में बंटी है.
मेट्रिक
हम मेट्रिक को सांख्यिकीय एग्रीगेशन, हिस्टोग्राम, पर्सेंटाइल, और फ़्रैक्शन में एग्रीगेशन के तौर पर रिपोर्ट करते हैं.
फ़्लोटिंग पॉइंट वैल्यू को दशमलव के बाद चार अंकों तक पूरा किया जाता है. ध्यान दें कि cumulative_layout_shift
मेट्रिक को स्ट्रिंग के तौर पर एन्कोड किया जाता है. इसलिए, इन्हें फ़्लोट नहीं माना जाता. साथ ही, इन्हें स्ट्रिंग में दशमलव के बाद दो अंकों तक रिपोर्ट किया जाता है.
हिस्टोग्राम
जब मेट्रिक को हिस्टोग्राम में दिखाया जाता है, तो हम उस मेट्रिक के लिए खास रेंज में आने वाले पेज लोड का प्रतिशत दिखाते हैं.
उदाहरण मेट्रिक के लिए, तीन बिन वाला सामान्य हिस्टोग्राम ऐसा दिखता है:
{
"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 के साथ पर्सेंटाइल | एफ़सीपी |
first_input_delay (अब उपलब्ध नहीं हैं) |
int | मिलीसेकंड | तीन बिन वाला हिस्टोग्राम, p75 के साथ पर्सेंटाइल | फ़िड |
interaction_to_next_paint |
int | मिलीसेकंड | तीन बिन वाला हिस्टोग्राम, p75 के साथ पर्सेंटाइल | आईएनपी |
largest_contentful_paint |
int | मिलीसेकंड | तीन बिन वाला हिस्टोग्राम, p75 के साथ पर्सेंटाइल | एलसीपी |
experimental_time_to_first_byte |
int | मिलीसेकंड | तीन बिन वाला हिस्टोग्राम, p75 के साथ पर्सेंटाइल | ttfb |
form_factors |
4 दशमलव प्लेस डबल | प्रतिशत | डिवाइस के नाप या आकार से भिन्न में मैपिंग | डिवाइस का नाप या आकार |
navigation_types |
4 दशमलव प्लेस डबल | प्रतिशत | नेविगेशन टाइप से भिन्न में मैपिंग | नेविगेशन टाइप |
BigQuery मेट्रिक के नाम को मैप करना
CrUX API मेट्रिक का नाम | BigQuery मेट्रिक का नाम |
---|---|
cumulative_layout_shift |
layout_instability.cumulative_layout_shift |
first_contentful_paint |
first_contentful_paint |
first_input_delay |
first_input.delay |
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 |
लागू नहीं |
कलेक्शन की अवधि
अक्टूबर 2022 से, CrUX API में एक collectionPeriod
ऑब्जेक्ट शामिल किया गया है. इसमें firstDate
और endDate
फ़ील्ड मौजूद हैं, जो एग्रीगेशन विंडो के शुरू और खत्म होने की तारीख दिखाते हैं. उदाहरण के लिए:
"collectionPeriod": {
"firstDate": {
"year": 2022,
"month": 9,
"day": 12
},
"lastDate": {
"year": 2022,
"month": 10,
"day": 9
}
}
इससे डेटा को बेहतर तरीके से समझने में मदद मिलती है. साथ ही, यह भी पता चलता है कि क्या इसे उस दिन के लिए अभी तक अपडेट किया गया है या इसमें वही डेटा है जो कल मिला था.
ध्यान दें कि CrUX API, आज की तारीख से करीब दो दिन पीछे है. इसकी वजह यह है कि डेटा को प्रोसेस होने के लिए, दिन भर का इंतज़ार करना पड़ता है. साथ ही, एपीआई में डेटा उपलब्ध होने में थोड़ा समय लगता है. इस्तेमाल किया गया टाइमज़ोन पैसिफ़िक स्टैंडर्ड टाइम (पीएसटी) है. डेलाइट सेविंग में कोई बदलाव नहीं किया जाता.
क्वेरी के उदाहरण
https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=[YOUR_API_KEY]"
को POST अनुरोध का इस्तेमाल करके क्वेरी को JSON ऑब्जेक्ट के तौर पर सबमिट किया जाता है, जिसमें क्वेरी के डेटा को POST के मुख्य भाग में JSON ऑब्जेक्ट के तौर पर शामिल किया जाता है:
{
"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: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
first_input_delay
(अब सेवा में नहीं है)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
एचटीटीपी अनुरोधों को स्वीकार करता है. एपीआई, अनुरोध किए गए ऑरिजिन या पेज के परफ़ॉर्मेंस डेटा से जुड़े एक या ज़्यादा metrics
वाले record
दिखाता है.
एचटीटीपी अनुरोध
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 |
असरदार कनेक्शन टाइप एक क्वेरी डाइमेंशन होता है. इससे यह तय होता है कि रिकॉर्ड का डेटा, किस नेटवर्क क्लास से जुड़ा होना चाहिए. इस फ़ील्ड में ध्यान दें: अगर कोई असरदार कनेक्शन टाइप नहीं चुना गया है, तो सभी तरह के कनेक्शन के लिए एग्रीगेट किए गए डेटा वाला एक खास रिकॉर्ड दिखेगा. |
formFactor |
डिवाइस का नाप या आकार एक क्वेरी डाइमेंशन होता है. इससे यह तय होता है कि रिकॉर्ड का डेटा, डिवाइस की किस क्लास से जुड़ा होना चाहिए. इस फ़ील्ड में ध्यान दें: अगर डिवाइस के नाप या आकार के बारे में कोई जानकारी नहीं दी गई है, तो सभी डिवाइस के नाप या आकार के हिसाब से इकट्ठा किए गए डेटा वाला एक खास रिकॉर्ड दिखाया जाएगा. |
metrics[] |
जवाब में शामिल की जाने वाली मेट्रिक. अगर कोई मेट्रिक तय नहीं की गई है, तो नतीजे के तौर पर दिखने वाली सभी मेट्रिक दिखेंगी. मंज़ूर किए गए मान: |
यूनियन फ़ील्ड url_ . url_pattern , रिकॉर्ड लुकअप के लिए मुख्य आइडेंटिफ़ायर होता है. यह इनमें से सिर्फ़ एक हो सकता है: |
|
origin |
उदाहरण: |
url |
उदाहरण: |
उदाहरण के लिए, 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 |
डिवाइस का नाप या आकार, डिवाइस की उस क्लास को दिखाता है जिसका इस्तेमाल सभी उपयोगकर्ताओं ने इस रिकॉर्ड के लिए, साइट को ऐक्सेस करने के लिए किया था. अगर डिवाइस के नाप या आकार की जानकारी नहीं दी गई है, तो डिवाइस के सभी नाप या आकार के हिसाब से इकट्ठा किया गया डेटा दिखाया जाएगा. |
effectiveConnectionType |
असरदार कनेक्शन टाइप, वह सामान्य कनेक्शन क्लास होती है जिसका अनुभव सभी उपयोगकर्ताओं को इस रिकॉर्ड के लिए होता है. इस फ़ील्ड में, ["Offline", "slow-2G", "2G", "3G", "4G"] वैल्यू का इस्तेमाल किया जाता है, जैसा कि यहां बताया गया है: https://wicg.github.io/netinfo/#effective-connection-types अगर सही कनेक्शन टाइप की जानकारी नहीं दी गई है, तो सभी तरह के कनेक्शन का एग्रीगेट किया गया डेटा दिखाया जाएगा. |
यूनियन फ़ील्ड url_ . यूआरएल पैटर्न, वह यूआरएल होता है जिस पर रिकॉर्ड लागू होता है. url_ इनमें से सिर्फ़ एक हो सकती है: |
|
origin |
ध्यान दें: |
url |
ध्यान दें: |
मेट्रिक
metric
, वेब की परफ़ॉर्मेंस मेट्रिक के लिए उपयोगकर्ता अनुभव के इकट्ठा किए गए डेटा का सेट होता है, जैसे कि फ़र्स्ट कॉन्टेंटफ़ुल पेंट.
इसमें bins
की सीरीज़, खास पर्सेंटाइल डेटा
(जैसे कि p75) के तौर पर, असल दुनिया में Chrome के इस्तेमाल की खास जानकारी वाला हिस्टोग्राम शामिल हो सकता है. इसके अलावा, इसमें लेबल किए गए फ़्रैक्शन भी हो सकते हैं.
{
"histogram": [
{
object (Bin)
}
],
"percentiles": {
object (Percentiles)
}
}
या
{
"fractions": {
object (Fractions)
}
}
फ़ील्ड | |
---|---|
histogram[] |
किसी मेट्रिक के लिए उपयोगकर्ता अनुभव का हिस्टोग्राम. हिस्टोग्राम में कम से कम एक बिन होगा और सभी बिन की डेंसिटी, ~1 हो जाएगी. |
percentiles |
मेट्रिक के सामान्य उपयोगी पर्सेंटाइल. पर्सेंटाइल के लिए वैल्यू टाइप, हिस्टोग्राम बिन के लिए दिए गए वैल्यू टाइप के जैसा ही होगा. |
fractions |
इस ऑब्जेक्ट में लेबल किए गए फ़्रैक्शन हैं, जिनका योग ~1 होता है. भिन्नों को दशमलव के बाद चार अंकों तक पूरा किया जाता है. |
बिन
A bin
, शुरू से लेकर आखिर तक फैला डेटा का डिस्क्रीट (अलग-अलग वैल्यू) हिस्सा होता है. अगर शुरू से लेकर पॉज़िटिव इनफ़िनिटी तक कोई एंड न दिया गया हो.
बिन की शुरुआती और आखिरी वैल्यू, उस मेट्रिक के वैल्यू टाइप में दी जाती हैं जिसे वह दिखाता है. उदाहरण के लिए, फ़र्स्ट कॉन्टेंटफ़ुल पेंट, मिलीसेकंड में मापा जाता है और इंटरट के रूप में दिखाया जाता है. इसलिए, इसके मेट्रिक बिन, शुरू और खत्म होने के टाइप के लिए int32s का इस्तेमाल करेंगे. हालांकि, कुल लेआउट शिफ़्ट को यूनिटलेस दशमलव में मापा जाता है और इसे स्ट्रिंग के तौर पर एन्कोड किए गए दशमलव के रूप में दिखाया जाता है. इसलिए, इसके मेट्रिक बिन, वैल्यू टाइप के लिए स्ट्रिंग का इस्तेमाल करेंगे.
{
"start": value,
"end": value,
"density": number
}
फ़ील्ड | |
---|---|
start |
डेटा बिन की शुरुआत से शुरू होता है. |
end |
डेटा बिन का आखिरी हिस्सा एंड है. अगर आखिरी वैल्यू भरी हुई नहीं है, तो इसका मतलब है कि बिन का कोई आखिरी हिस्सा नहीं है और यह शुरू से +inf तक मान्य है. |
density |
ऐसे उपयोगकर्ताओं का अनुपात जिन्होंने दी गई मेट्रिक के लिए, इस बिन की वैल्यू को देखा है. सघनता को दशमलव के बाद चार अंकों तक पूरा किया जाता है. |
पर्सेंटाइल
Percentiles
में, दिए गए आंकड़ों के पर्सेंटाइल पर किसी मेट्रिक की एआई से जनरेट की गई वैल्यू शामिल होती है. इनका इस्तेमाल, किसी मेट्रिक की वैल्यू का अनुमान लगाने के लिए किया जाता है. यह आकलन, कुल उपयोगकर्ताओं में से कुछ उपयोगकर्ताओं के प्रतिशत के आधार पर किया जाता है.
{
"P75": value
}
फ़ील्ड | |
---|---|
p75 |
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 |
नॉर्मलाइज़ेशन की किसी भी कार्रवाई से पहले, अनुरोध किया गया ओरिजनल यूआरएल. |
normalizedUrl |
नॉर्मलाइज़ेशन की सभी कार्रवाइयों के बाद इस्तेमाल होने वाला यूआरएल. यह एक मान्य उपयोगकर्ता अनुभव यूआरएल है, जिसे सही तरीके से खोजा जा सकता है. |
दर की सीमाएं
हर Google Cloud प्रोजेक्ट के लिए, CrUX एपीआई को हर मिनट 150 क्वेरी की जा सकती है. यह सुविधा बिना किसी शुल्क के उपलब्ध कराई जाती है. इस सीमा और आपके मौजूदा इस्तेमाल की जानकारी को Google Cloud Console में देखा जा सकता है. इस्तेमाल के ज़्यादातर उदाहरणों के लिए, यह कोटा काफ़ी होना चाहिए. साथ ही, बढ़े हुए कोटा के लिए पैसे चुकाना संभव नहीं है.