Chrome UX রিপোর্টের ( CrUX ) কাঁচা ডেটা BigQuery- এ উপলব্ধ, Google ক্লাউডের একটি ডাটাবেস৷ BigQuery ব্যবহার করার জন্য একটি GCP প্রকল্প এবং SQL এর প্রাথমিক জ্ঞান প্রয়োজন।
এই নির্দেশিকাটিতে, ওয়েবে ব্যবহারকারীর অভিজ্ঞতার অবস্থা সম্পর্কে অন্তর্দৃষ্টিপূর্ণ ফলাফল বের করতে CrUX ডেটাসেটের বিরুদ্ধে প্রশ্ন লিখতে BigQuery ব্যবহার করতে শিখুন:
- ডেটা কীভাবে সংগঠিত হয় তা বুঝুন
- একটি মূলের কর্মক্ষমতা মূল্যায়ন করার জন্য একটি মৌলিক প্রশ্ন লিখুন
- সময়ের সাথে পারফরম্যান্স ট্র্যাক করতে একটি উন্নত ক্যোয়ারী লিখুন
তথ্য সংস্থা
একটি মৌলিক ক্যোয়ারী দেখে শুরু করুন:
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
ক্যোয়ারী চালানোর জন্য, এটি ক্যোয়ারী এডিটরে প্রবেশ করান এবং "ক্যোয়ারী চালান" বোতাম টিপুন:
এই প্রশ্নের দুটি অংশ আছে:
- SELECT COUNT(DISTINCT origin)মানে সারণিতে উৎপত্তির সংখ্যার জন্য অনুসন্ধান করা। মোটামুটিভাবে বলতে গেলে, দুটি URL একই মূলের অংশ যদি তাদের একই স্কিম, হোস্ট এবং পোর্ট থাকে।
- FROM chrome-ux-report.all.202206উৎস টেবিলের ঠিকানা উল্লেখ করে, যার তিনটি অংশ রয়েছে:-  ক্লাউড প্রকল্পের নাম chrome-ux-reportযার মধ্যে সমস্ত CrUX ডেটা সংগঠিত হয়৷
-  allডেটাসেট, সমস্ত দেশে ডেটা উপস্থাপন করে৷
-  টেবিল 202206, YYYYMM ফর্ম্যাটে ডেটার বছর এবং মাস৷
 
-  ক্লাউড প্রকল্পের নাম 
 এছাড়াও প্রতিটি দেশের জন্য ডেটাসেট রয়েছে। উদাহরণস্বরূপ, chrome-ux-report.country_ca.202206 শুধুমাত্র কানাডা থেকে উদ্ভূত ব্যবহারকারীর অভিজ্ঞতার ডেটা উপস্থাপন করে।
প্রতিটি ডেটাসেটের মধ্যে 201710 সাল থেকে প্রতি মাসের জন্য টেবিল রয়েছে৷ আগের ক্যালেন্ডার মাসের জন্য নতুন টেবিলগুলি নিয়মিত প্রকাশিত হয়৷
ডেটা টেবিলের গঠন ( স্কিমা নামেও পরিচিত) এর মধ্যে রয়েছে:
-  উত্স, উদাহরণস্বরূপ origin = 'https://www.example.com', যা সেই ওয়েবসাইটের সমস্ত পৃষ্ঠাগুলির জন্য সামগ্রিক ব্যবহারকারীর অভিজ্ঞতা বিতরণকে প্রতিনিধিত্ব করে
-  পৃষ্ঠা লোডের সময় সংযোগের গতি, উদাহরণস্বরূপ, effective_connection_type.name = '4G'( ফেব্রুয়ারি 2025 থেকে সরানো হয়েছে )
-  ডিভাইসের ধরন, উদাহরণস্বরূপ form_factor.name = 'desktop'
- ইউএক্স মেট্রিক্স নিজেই
 প্রতিটি মেট্রিকের ডেটা অবজেক্টের অ্যারে হিসাবে সংগঠিত হয়। JSON স্বরলিপিতে, first_contentful_paint.histogram.bin এর মতো দেখাবে:
[
    {"start": 0, "end": 100, "density": 0.1234},
    {"start": 100, "end": 200, "density": 0.0123},
    ...
]
প্রতিটি বিনে মিলিসেকেন্ডে একটি শুরু এবং শেষ সময় থাকে এবং সেই সময়সীমার মধ্যে ব্যবহারকারীর অভিজ্ঞতার শতাংশের প্রতিনিধিত্ব করে একটি ঘনত্ব। অন্য কথায়, এই কাল্পনিক উৎপত্তি, সংযোগের গতি এবং ডিভাইসের প্রকারের জন্য 12.34% FCP অভিজ্ঞতা 100ms এর কম। সমস্ত বিন ঘনত্বের যোগফল 100%।
BigQuery-এ টেবিলের গঠন ব্রাউজ করুন।
কর্মক্ষমতা মূল্যায়ন
আমরা টেবিল স্কিমা সম্পর্কে আমাদের জ্ঞান ব্যবহার করে একটি প্রশ্ন লিখতে পারি যা এই কর্মক্ষমতা ডেটা বের করে।
SELECT
  fcp
FROM
  `chrome-ux-report.all.202502`,
  UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
  origin = 'https://web.dev' AND
  form_factor.name = 'phone' AND
  fcp.start = 0
 ফলাফল হল 0.01115 , অর্থাৎ 4G এবং একটি ফোনে এই উৎপত্তিতে ব্যবহারকারীর অভিজ্ঞতার 1.115% 0 থেকে 100ms এর মধ্যে। যদি আমরা আমাদের ক্যোয়ারীকে যেকোনো সংযোগ এবং যেকোনো ডিভাইসের ধরণে সাধারণীকরণ করতে চাই, তাহলে আমরা সেগুলিকে 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-1000ms এর "দ্রুত" FCP পরিসরে থাকা সমস্ত বিনের জন্য ঘনত্ব যোগ করতে পারি:
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-এ FCP ব্যবহারকারীর অভিজ্ঞতার 69.77% FCP পরিসরের সংজ্ঞা অনুসারে "দ্রুত" বলে বিবেচিত হয়।
ট্র্যাক কর্মক্ষমতা
এখন যেহেতু আমরা একটি উত্স সম্পর্কে পারফরম্যান্স ডেটা বের করেছি, আমরা এটিকে পুরানো টেবিলে উপলব্ধ ঐতিহাসিক ডেটার সাথে তুলনা করতে পারি। এটি করার জন্য, আমরা পূর্ববর্তী মাসে টেবিলের ঠিকানাটি পুনরায় লিখতে পারি, অথবা আমরা সমস্ত মাস জিজ্ঞাসা করার জন্য ওয়াইল্ডকার্ড সিনট্যাক্স ব্যবহার করতে পারি:
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
এখানে, আমরা দেখি যে দ্রুত FCP অভিজ্ঞতার শতাংশ প্রতি মাসে কয়েক শতাংশ পয়েন্ট দ্বারা পরিবর্তিত হয়।
| yyyymm | দ্রুত_এফসিপি | 
|---|---|
| 202206 | 69.77% | 
| 202205 | 70.71% | 
| 202204 | 69.04% | 
| 202203 | 69.82% | 
| 202202 | 67.75% | 
| 202201 | 58.96% | 
| 202112 | 41.69% | 
| ... | ... | 
এই কৌশলগুলির সাহায্যে, আপনি একটি উত্সের জন্য কার্যক্ষমতা সন্ধান করতে, দ্রুত অভিজ্ঞতার শতাংশ গণনা করতে এবং সময়ের সাথে সাথে এটি ট্র্যাক করতে সক্ষম হন৷ পরবর্তী ধাপ হিসেবে, দুই বা তার বেশি উৎসের জন্য অনুসন্ধান করার চেষ্টা করুন এবং তাদের কর্মক্ষমতা তুলনা করুন।
FAQ
এইগুলি CrUX BigQuery ডেটাসেট সম্পর্কে প্রায়শই জিজ্ঞাসিত কিছু প্রশ্ন:
কখন আমি অন্যান্য টুলের বিপরীতে BigQuery ব্যবহার করব?
BigQuery শুধুমাত্র তখনই প্রয়োজন যখন আপনি CrUX ড্যাশবোর্ড এবং PageSpeed ইনসাইটের মতো অন্যান্য টুল থেকে একই তথ্য পেতে পারেন না। উদাহরণস্বরূপ, BigQuery আপনাকে অর্থপূর্ণ উপায়ে ডেটা টুকরো টুকরো করতে দেয় এবং এমনকি কিছু উন্নত ডেটা মাইনিং করতে HTTP আর্কাইভের মতো অন্যান্য পাবলিক ডেটাসেটের সাথে যোগ দিতে দেয়।
BigQuery ব্যবহার করার কোন সীমাবদ্ধতা আছে কি?
হ্যাঁ, সবচেয়ে গুরুত্বপূর্ণ সীমাবদ্ধতা হল যে ডিফল্টভাবে ব্যবহারকারীরা প্রতি মাসে শুধুমাত্র 1TB মূল্যের ডেটা জিজ্ঞাসা করতে পারে। এর বাইরে, $5/TB-এর আদর্শ হার প্রযোজ্য।
আমি কোথায় BigQuery সম্পর্কে আরও জানতে পারি?
আরও তথ্যের জন্য BigQuery ডকুমেন্টেশন দেখুন।