Chrome UX रिपोर्ट (CrUX) का रॉ डेटा, BigQuery पर उपलब्ध है. यह Google Cloud का डेटाबेस है. BigQuery का इस्तेमाल करने के लिए, GCP प्रोजेक्ट और SQL की बुनियादी जानकारी होनी ज़रूरी है.
इस गाइड में, 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_पेंट (FP)
- first_contentfull_picture (एफ़सीपी)
- dom_content_loaded (डीसीएल)
- ऑनलोड (ओएल)
- 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 से 1,000 मि॰से॰ की "तेज़" एफ़सीपी रेंज वाले सभी बिन के लिए डेंसिटी जोड़ सकते हैं:
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 डैशबोर्ड और PageSpeed Insights जैसे दूसरे टूल से वह जानकारी नहीं मिल पाती. उदाहरण के लिए, BigQuery की मदद से डेटा को बेहतर तरीके से अलग-अलग किया जा सकता है. साथ ही, डेटा को बेहतर तरीके से माइन करने के लिए, इसे एचटीटीपी संग्रह जैसे अन्य सार्वजनिक डेटासेट के साथ भी जोड़ा जा सकता है.
क्या BigQuery का इस्तेमाल करने की कोई सीमा है?
हां, सबसे ज़रूरी सीमा यह है कि डिफ़ॉल्ट रूप से उपयोगकर्ता, हर महीने सिर्फ़ 1 टीबी डेटा की क्वेरी कर सकते हैं. इसके अलावा, $5/TB की मानक दर लागू होती है.
मुझे BigQuery के बारे में ज़्यादा जानकारी कहां मिल सकती है?
ज़्यादा जानकारी के लिए, BigQuery दस्तावेज़ देखें.