Chrome UX रिपोर्ट (CrUX) का रॉ डेटा, BigQuery पर उपलब्ध है. यह Google Cloud का डेटाबेस है. BigQuery का इस्तेमाल करने के लिए, आपके पास GCP प्रोजेक्ट और एसक्यूएल की बुनियादी जानकारी होनी चाहिए.
इस गाइड में, CrUX डेटासेट के हिसाब से क्वेरी लिखने के लिए, BigQuery का इस्तेमाल करने का तरीका जानें. इससे वेब पर उपयोगकर्ता अनुभव की स्थिति के बारे में अहम जानकारी वाले नतीजे हासिल किए जा सकते हैं:
- समझें कि डेटा कैसे व्यवस्थित किया जाता है
- किसी ऑरिजिन की परफ़ॉर्मेंस का आकलन करने के लिए, एक बेसिक क्वेरी लिखें
- समय के साथ परफ़ॉर्मेंस को ट्रैक करने के लिए, ऐडवांस क्वेरी लिखें
डेटा संगठन
बुनियादी क्वेरी पर नज़र डालकर शुरुआत करें:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
क्वेरी चलाने के लिए, उसे क्वेरी एडिटर में डालें और "क्वेरी चलाएं" दबाएं बटन:
इस क्वेरी के दो हिस्से हैं:
SELECT COUNT(DISTINCT origin)
का मतलब है कि टेबल में ऑरिजिन की संख्या के लिए क्वेरी करना. मोटे तौर पर कहें, तो दो यूआरएल एक ही ऑरिजिन के हैं, अगर उनकी स्कीम, होस्ट, और पोर्ट एक जैसी हैं.FROM chrome-ux-report.all.202206
, सोर्स टेबल का पता बताता है. इस टेबल के तीन हिस्से होते हैं:- Cloud प्रोजेक्ट का नाम
chrome-ux-report
, जिसमें CrUX का पूरा डेटा व्यवस्थित किया जाता है all
डेटासेट, जो सभी देशों का डेटा दिखाता है- टेबल
202206
, YYYYMM फ़ॉर्मैट में डेटा का साल और महीना
- Cloud प्रोजेक्ट का नाम
यहां हर देश के लिए डेटासेट उपलब्ध हैं. उदाहरण के लिए, chrome-ux-report.country_ca.202206
सिर्फ़ कनाडा से मिले उपयोगकर्ता अनुभव का डेटा दिखाता है.
हर डेटासेट में, 201710 से लेकर अब तक, हर महीने के लिए टेबल दी गई हैं. पिछले महीने के लिए, नई टेबल नियमित तौर पर पब्लिश की जाती हैं.
डेटा टेबल के स्ट्रक्चर (जिसे स्कीमा भी कहा जाता है) में ये चीज़ें शामिल होती हैं:
- ऑरिजिन, जैसे कि
origin = 'https://www.example.com'
. यह उस वेबसाइट के सभी पेजों के लिए, उपयोगकर्ता अनुभव का पूरा डिस्ट्रिब्यूशन दिखाता है - पेज लोड के समय, कनेक्शन की स्पीड. उदाहरण के लिए,
effective_connection_type.name = '4G'
- डिवाइस किस तरह का है, जैसे कि
form_factor.name = 'desktop'
- उपयोगकर्ता अनुभव से जुड़ी मेट्रिक
- first_ Paint (FP)
- first_contentful_ Paint (एफ़सीपी)
- dom_content_loaded (डीसीएल)
- ऑनलोड (OL)
- Experiments.first_input_delay (एफ़आईडी)
हर मेट्रिक का डेटा, ऑब्जेक्ट के कलेक्शन के तौर पर दिखाया जाता है. JSON नोटेशन में, first_contentful_paint.histogram.bin
ऐसा दिखेगा:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
हर बिन में, शुरू और खत्म होने का समय मिलीसेकंड में होता है. साथ ही, इसमें दी गई समयावधि में उपयोगकर्ता के अनुभवों का प्रतिशत दिखाने वाली सघनता होती है. दूसरे शब्दों में कहें, तो इस काल्पनिक ऑरिजिन, कनेक्शन स्पीड, और डिवाइस टाइप के लिए 12.34% एफ़सीपी अनुभव 100 मि॰से॰ से कम है. सभी बिन डेंसिटी का कुल योग 100% है.
BigQuery में टेबल के स्ट्रक्चर को ब्राउज़ करें.
परफ़ॉर्मेंस का आकलन करें
हम टेबल स्कीमा के बारे में अपनी जानकारी का इस्तेमाल करके, एक ऐसी क्वेरी लिख सकते हैं जो इस परफ़ॉर्मेंस डेटा को एक्सट्रैक्ट करती है.
SELECT
fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
effective_connection_type.name = '4G' AND
form_factor.name = 'phone' AND
fcp.start = 0
नतीजा 0.01115
मिला. इसका मतलब है कि इस ऑरिजिन पर 1.115% उपयोगकर्ता अनुभव, 4G और फ़ोन पर 0 से 100 मि॰से॰ के बीच है. अगर हमें अपनी क्वेरी को किसी भी कनेक्शन और डिवाइस टाइप के लिए सामान्य बनाना है, तो उन्हें WHERE
क्लॉज़ से हटाया जा सकता है. साथ ही, उनसे जुड़ी सभी बिन डेंसिटी को जोड़ने के लिए, SUM
एग्रीगेटर फ़ंक्शन का इस्तेमाल किया जा सकता है:
SELECT
SUM(fcp.density)
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start = 0
इसकी वजह से नतीजा 0.05355
या सभी डिवाइसों और कनेक्शन टाइप से 5.355% मिला. हम क्वेरी में थोड़ा बदलाव कर सकते हैं. साथ ही, उन सभी बिन के लिए डेंसिटी जोड़ सकते हैं जो "तेज़" हैं 0–1000 मि॰से॰ की एफ़सीपी रेंज:
SELECT
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
इससे हमें 0.6977
मिलता है. दूसरे शब्दों में, web.dev पर एफ़सीपी उपयोगकर्ता अनुभव के 69.77% हिस्से को "तेज़" माना जाता है एफ़सीपी रेंज की परिभाषा के हिसाब से.
परफ़ॉर्मेंस ट्रैक करना
अब जब हमने किसी ऑरिजिन के बारे में परफ़ॉर्मेंस डेटा एक्सट्रैक्ट कर लिया है, तो हम इसकी तुलना पुरानी टेबल में मौजूद पुराने डेटा से कर सकते हैं. ऐसा करने के लिए, हम टेबल का पता पिछले महीने के हिसाब से दोबारा लिख सकते हैं या सभी महीनों की क्वेरी करने के लिए वाइल्डकार्ड सिंटैक्स का इस्तेमाल कर सकते हैं:
SELECT
_TABLE_SUFFIX AS yyyymm,
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.*`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
GROUP BY
yyyymm
ORDER BY
yyyymm DESC
यहां हमने देखा है कि तेज़ एफ़सीपी के अनुभवों का प्रतिशत, हर महीने कुछ प्रतिशत अंकों के हिसाब से अलग-अलग होता है.
yyyymm | fast_fcp |
---|---|
202206 | 69.77% |
202205 | 70.71% |
202204 | 69.04% |
202203 | 69.82% |
202202 | 67.75% |
202201 | 58.96% |
202112 | 41.69% |
... | ... |
इन तकनीकों का इस्तेमाल करके, किसी ऑरिजिन की परफ़ॉर्मेंस देखी जा सकती है. साथ ही, यह पता लगाया जा सकता है कि उसका प्रतिशत कितना तेज़ है और उसे समय-समय पर ट्रैक किया जा सकता है. अगले चरण के तौर पर, दो या दो से ज़्यादा ऑरिजिन के लिए क्वेरी करें और उनकी परफ़ॉर्मेंस की तुलना करें.
अक्सर पूछे जाने वाले सवाल
CrUX BigQuery डेटासेट के बारे में, अक्सर पूछे जाने वाले कुछ सवाल यहां दिए गए हैं:
मुझे दूसरे टूल की जगह BigQuery का इस्तेमाल कब करना चाहिए?
BigQuery की ज़रूरत सिर्फ़ तब होती है, जब आपको CrUX Dashboard और PageSpeed Insights जैसे दूसरे टूल से मिलती-जुलती जानकारी न मिल सकती हो. उदाहरण के लिए, BigQuery आपको डेटा को सही तरीके से बांटने की सुविधा देता है. यहां तक कि बेहतर डेटा माइनिंग करने के लिए, इसे एचटीटीपी संग्रह जैसे दूसरे सार्वजनिक डेटासेट के साथ भी जोड़ा जा सकता है.
क्या BigQuery का इस्तेमाल करने की कोई सीमा है?
हां, सबसे ज़रूरी सीमा यह है कि डिफ़ॉल्ट रूप से उपयोगकर्ता, हर महीने सिर्फ़ 1 टीबी के डेटा के लिए ही क्वेरी कर सकते हैं. इसके अलावा, 5 डॉलर/टीबी की सामान्य दर लागू होती है.
BigQuery के बारे में ज़्यादा जानकारी कहां मिल सकती है?
ज़्यादा जानकारी के लिए BigQuery दस्तावेज़ देखें.