CrUX BigQuery डेटासेट को इस्तेमाल करने का तरीका

Rick Viscomi

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 फ़ॉर्मैट में

यहां हर देश के लिए डेटासेट भी हैं. उदाहरण के लिए, 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 दस्तावेज़ देखें.