CrUX इतिहास API की मदद से, पेज और ऑरिजिन की जानकारी के स्तर पर, असल उपयोगकर्ता के अनुभव से जुड़े छह महीनों के डेटा का ऐक्सेस, इंतज़ार का समय कम करने की सुविधा मिलती है.
सामान्य इस्तेमाल का उदाहरण
CrUX इतिहास API की मदद से, किसी खास यूआरआई के लिए उपयोगकर्ता अनुभव से जुड़ी पुरानी मेट्रिक की क्वेरी की जा सकती है. जैसे, "https://example.com
के ऑरिजिन के लिए, उपयोगकर्ता अनुभव के पुराने रुझान पाएं."
इतिहास एपीआई और हर दिन के CrUX API का स्ट्रक्चर. हालांकि, किसी कलेक्शन में वैल्यू दी गई होती हैं और कुंजियों को बहुवचन नामों से लेबल किया जाता है. जैसे, histogram
के बजाय histogramTimeseries
या p75
की जगह p75s
.
CrUX API कुंजी
रोज़ के एपीआई की तरह, CrUX History 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
का नाप या आकार बताता है कि रिकॉर्ड में मोबाइल डिवाइस पर हुए लोड के बारे में जानकारी है.
CrUX History API, सिर्फ़ डिवाइस के नाप या आकार के हिसाब से एग्रीगेट किया गया है. यह डिवाइस की एक सामान्य क्लास है जो PHONE
, TABLET
, और DESKTOP
में बंटी है.
मेट्रिक
हम आंकड़ों को एग्रीगेशन की टाइम सीरीज़ में रिपोर्ट करते हैं. इसमें हिस्टोग्राम, पर्सेंटाइल, और भिन्न.
हिस्टोग्राम
जब मेट्रिक को हिस्टोग्राम श्रेणी में दिखाया जाता है, तो हर टाइम सीरीज़ एंट्री वह पेज लोड जिसके लिए मेट्रिक, सभी के अनुपात में किसी इंटरवल में आई. डेटा पॉइंट, डेटा इकट्ठा करने की अवधि के क्रम में दिखाए जाते हैं. इसमें एपीआई भी वह तारीख दिखाता है जिसमें पहला पॉइंट, सबसे पुरानी अवधि का होता है और आखिरी पॉइंट, डेटा इकट्ठा करने की सबसे हाल की अवधि होती है.
उदाहरण के तौर पर दी गई मेट्रिक के लिए, 3 बिन हिस्टोग्राम ऐसा दिखता है:
{
"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 |
डिवाइस का नाप या आकार, डिवाइस की वह क्लास है जिसका इस्तेमाल सभी उपयोगकर्ताओं ने इस रिकॉर्ड के लिए साइट ऐक्सेस करने के लिए किया था. अगर डिवाइस के नाप या आकार की जानकारी नहीं दी गई है, तो सभी डिवाइस टाइप के हिसाब से इकट्ठा किया गया डेटा दिखाया जाएगा. |
यूनियन फ़ील्ड url_ . यूआरएल पैटर्न, वह यूआरएल होता है जिस पर रिकॉर्ड लागू होता है. url_ इनमें से सिर्फ़ एक हो सकता है: |
|
origin |
ऑरिजिन से उस ऑरिजिन के बारे में पता चलता है जिसके लिए यह रिकॉर्ड है. ध्यान दें: ऑरिजिन के बारे में बताते समय, इस ऑरिजिन में सभी पेजों के लिए लोड किए गए डेटा को ऑरिजिन लेवल के उपयोगकर्ता अनुभव से जुड़े डेटा में शामिल किया जाता है. |
url |
ध्यान दें: |
मेट्रिक
metric
, किसी एक वेब परफ़ॉर्मेंस मेट्रिक के लिए उपयोगकर्ता अनुभव से जुड़े डेटा का सेट है, जैसे कि फ़र्स्ट कॉन्टेंटफ़ुल पेंट. इसमें bins
की सीरीज़ के तौर पर, असल दुनिया में Chrome के इस्तेमाल के बारे में खास जानकारी वाला हिस्टोग्राम मौजूद है.
{
"histogramTimeseries": [
{
object (Bin)
}
],
"percentilesTimeseries": {
object (Percentiles)
}
}
या
"fractionTimeseries": {
object (Fractions)
}
फ़ील्ड | |
---|---|
histogramTimeseries[] |
किसी मेट्रिक के लिए, उपयोगकर्ता अनुभव का टाइम सीरीज़ हिस्टोग्राम. टाइम सीरीज़ हिस्टोग्राम में कम से कम एक बिन होगा और सभी बिन की डेंसिटी का जोड़ ~1 होगा. कलेक्शन की उस अवधि के लिए वैल्यू मौजूद न होने पर, उसे |
percentilesTimeseries |
मेट्रिक के सामान्य उपयोगी पर्सेंटाइल. पर्सेंटाइल के लिए वैल्यू का टाइप, हिस्टोग्राम बिन के लिए दी गई वैल्यू टाइप से मेल खाता है. कलेक्शन की उस अवधि के लिए वैल्यू मौजूद न होने पर, उसे |
fractionTimeseries |
इस ऑब्जेक्ट में लेबल किए गए भिन्नों की टाइम सीरीज़ होती हैं, जिनका प्रति प्रविष्टि ~1 होता है. फ़्रैक्शन को दशमलव के बाद चार अंकों में बदल दिया जाता है. सभी भिन्नों में ऐसी एंट्री को `"NaN"` के तौर पर दिखाया जाता है जो मौजूद नहीं हैं. |
बिन
bin
, डेटा का ऐसा हिस्सा होता है जो शुरू से आखिर तक फैला होता है या शुरुआत से पॉज़िटिव इनफ़िनिटी तक कोई आखिरी हिस्सा नहीं होता.
बिन की शुरुआती और आखिरी वैल्यू, उस मेट्रिक के वैल्यू टाइप में दी जाती है जिसे वह दिखाती है. उदाहरण के लिए, पहले कॉन्टेंटफ़ुल पेंट को मिलीसेकंड में मापा जाता है और इसे पूर्णांक के तौर पर दिखाया जाता है. इसलिए, इसके मेट्रिक बिन, शुरू और खत्म होने के टाइप के लिए int32s का इस्तेमाल करेंगे. हालांकि, कुल लेआउट शिफ़्ट को यूनिटलेस डेसिमल में मेज़र किया जाता है और इसे स्ट्रिंग के तौर पर कोड में बदले गए दशमलव के तौर पर दिखाया जाता है. इसलिए, इसके मेट्रिक बिन, वैल्यू टाइप के लिए स्ट्रिंग का इस्तेमाल करेंगे.
{
"start": value,
"end": value,
"densities": [number, number, number...etc.]
}
फ़ील्ड | |
---|---|
start |
शुरुआत, डेटा बिन की शुरुआत होती है. |
end |
आखिर में डेटा बिन खत्म हो जाता है. अगर खत्म होने की जानकारी अपने-आप नहीं भरी जाती, तो इसका मतलब है कि बिन का कोई अंत नहीं है और यह शुरू से +inf तक मान्य है. |
densities |
दी गई मेट्रिक के लिए, इस बिन की वैल्यू का अनुभव करने वाले उपयोगकर्ताओं के अनुपात की टाइम सीरीज़. डेंसिटी को दशमलव के बाद चार अंकों तक कर दिया जाता है. |
पर्सेंटाइल
Percentiles
में, दिए गए आंकड़ों के पर्सेंटाइल में किसी मेट्रिक की सिंथेटिक वैल्यू शामिल होती हैं. इनका इस्तेमाल, किसी मेट्रिक की वैल्यू का अनुमान लगाने के लिए किया जाता है. यह अनुमान, उपयोगकर्ताओं की कुल संख्या में से कुछ उपयोगकर्ताओं को मिलता है.
{
"P75": value
}
फ़ील्ड | |
---|---|
p75s |
जिन वैल्यू के लिए 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 है. मेट्रिक उपलब्ध न होने पर
तो उससे जुड़ी एंट्री
"नाएन" भिन्नों की सभी सरणियों में.
फ़ील्ड | |
---|---|
p75s |
75% पेज लोड होने वाली वैल्यू की टाइम सीरीज़ में, दी गई मेट्रिक को इस वैल्यू से कम या उससे कम दिखाया गया. |
UrlNormalization
यूआरएल को नॉर्मलाइज़ करने के लिए की गई नॉर्मलाइज़ेशन कार्रवाइयों को दिखाने वाला ऑब्जेक्ट, ताकि लुकअप की प्रोसेस को पूरा किया जा सके. ये आसान अपने-आप होने वाले बदलाव हैं, जिन्हें दिए गए url_pattern
को खोजते समय लागू किया जाता है. ऐसा हो सकता है कि इन बदलावों को लागू न किया जा सके. रीडायरेक्ट जैसी जटिल कार्रवाइयां हैंडल नहीं की जाती हैं.
{
"originalUrl": string,
"normalizedUrl": string
}
फ़ील्ड | |
---|---|
originalUrl |
नॉर्मलाइज़ेशन के लिए की जाने वाली किसी भी कार्रवाई से पहले, अनुरोध किया गया ओरिजनल यूआरएल. |
normalizedUrl |
नॉर्मलाइज़ेशन की किसी भी कार्रवाई के बाद मौजूद यूआरएल. यह उपयोगकर्ता अनुभव वाला एक मान्य यूआरएल है, जिसे खोजा जा सकता है. |
रेट लिमिट
किसी भी एपीआई के लिए, हर Google Cloud प्रोजेक्ट के लिए, CrUX API के साथ हर मिनट 150 क्वेरी करने पर, CrUX History API की एक जैसी सीमा ही लागू होती है. यह एपीआई बिना किसी शुल्क के उपलब्ध होता है. इस सीमा और आपके मौजूदा इस्तेमाल को Google Cloud Console में देखा जा सकता है. यह कोटा, इस्तेमाल के ज़्यादातर मामलों में काफ़ी काम का होना चाहिए. साथ ही, बढ़े हुए कोटा के लिए कोई पेमेंट नहीं किया जा सकता.