بدءًا من مجموعة بيانات شباط (فبراير) 2021، سنضيف مقياسًا تجريبيًا إلى تقرير تجربة المستخدم على Chrome في BigQuery للتمييز بين مدى رواج مصادر البيانات حسب الكمية: أبرز 1,000 أصل، وأعلى 10 آلاف أصل، وأعلى 100 ألف، وأعلى مليون،...
لنرى كيف يبدو ذلك عمليًا:
SELECT
experimental.popularity.rank AS rank_magnitude,
COUNT(DISTINCT origin) AS num_origins
FROM
`chrome-ux-report.all.202102`
GROUP BY
rank_magnitude
ORDER BY
rank_magnitude
| الصف | rank_magnitude | num_origins |
|---|---|---|
| 1 | 1,000 | 1,000 |
| 2 | 10,000 | 9,000 |
| 3 | 100,000 | 90,000 |
| 4 | 1,000,000 | 900000 |
| 15 | 10,000,000 | 7,264,371 |
بالنسبة إلى مجموعة البيانات العالمية لشهر شباط (فبراير) 2021، نحصل على 5 مجموعات. كما هو متوقع، في الصف 1، نرى أنّ هناك 1,000 أصل مع قيمة الترتيب 1000، وهو الترتيب الأكثر والأصول الشائعة من خلال مقياسنا. قد يبدو الصف 2 مفاجئًا، مشيرًا إلى وجود هي 9 آلاف أصل فقط من بين أبرز 10 آلاف نقطة؛ وذلك لأن الأصول في الصف 1 هو أيضًا جزء من مجموعة الـ 10 آلاف الأولى. لاختيار أهم 10 آلاف مصدر، على المرء ما يلي: حدد Testing.popularity.rank <= 10000 عند الاستعلام.
تحتوي مجموعة البيانات أيضًا على قيمة التصنيف الخاصة بالبلد. على سبيل المثال، يدرج 10 آلاف أصول الأكثر شيوعًا في ألمانيا.
SELECT DISTINCT origin
FROM `chrome-ux-report.country_de.202102`
WHERE experimental.popularity.rank <= 10000
للتطرق إلى إمكانات مقياس الشعبية الجديد، دعونا نرى مدى رواج تختلف شرائح الجمهور على الويب في ما يتعلق بمقياس أول سرعة لعرض المحتوى على الصفحة (FCP). لغرض هذا الاستعلام، فإننا نعتبر ثانية واحدة بمثابة تجربة مستخدم سريعة.
SELECT
SUM(fcp.density)/count(distinct origin)
FROM
`chrome-ux-report.all.202102`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
fcp.start < 1000 AND experimental.popularity.rank <= 1000
بالنسبة إلى الأصول التي تحتوي على experimental.popularity.rank <= 1000، يجمع طلب البحث كل
كثافات مجموعة المدرّج التكراري لقيم مقياس FCP التي تقلّ عن 1000 ملي ثانية، وتقسم
على عدد المصادر، أي أنه يحسب متوسط النسبة المئوية
يتم تحميل البيانات بسرعة FCP لألف من المصادر الأكثر رواجًا. في هذا الطلب، تحتوي جميع الأصول على
بالتساوي، لذا يمكن القول إن هذا ليس مثاليًا. لكن لنرى ما إذا كانت النتيجة
حساسة لتغيير حجم الترتيب، عن طريق تغيير عبارة where
حدد test.popularity.rank <= 10000. ونفعل ذلك لـ 10 آلاف و100 ألف،
عَلَى:
| حجم الترتيب للأصول | نسبة سرعة عرض المحتوى على الصفحة < ثانية واحدة، تم حساب متوسطها على المصادر |
|---|---|
| 1,000 | 53.6% |
| 10,000 | 49.6% |
| 100,000 | 45.9% |
| 1,000,000 | 43.2% |
| 10,000,000 | 39.9% |
ويشير ذلك إلى أنّ زيادة سرعة تجربة المستخدم على الويب مرتبطة بكونه أكثر رواجًا.
في مجموعة بيانات تشرين الأول (أكتوبر) 2022، تم تقسيمها أكثر بخطوات بنصف الترتيب. تؤدي إعادة تشغيل الاستعلام الأول لمجموعة البيانات هذه إلى إظهار نصف الخطوات وعدد الأصول في كل حجم ترتيب:
SELECT
experimental.popularity.rank AS rank_magnitude,
COUNT(DISTINCT origin) AS num_origins
FROM
`chrome-ux-report.all.202210`
GROUP BY
rank_magnitude
ORDER BY
rank_magnitude
| الصف | rank_magnitude | num_origins |
|---|---|---|
| 1 | 1,000 | 1,000 |
| 2 | 5000 | 4000 |
| 3 | 10,000 | 5000 |
| 4 | 50000 | 40,000 |
| 5 | 100,000 | 50000 |
| 6 | 500000 | 400000 |
| 7 | 1,000,000 | 500000 |
| 8 | 5,000,000 | 4,000,000 |
| 9 | 10,000,000 | 5,000,000 |
| 10 | 50,000,000 | 7,637,195 |
اطّلِع على مزيد من المعلومات حول استخدام CrUX على BigQuery وتصفّح CrUX Cookbook للحصول على مزيد من الأمثلة على طلبات البحث. يمكنك مشاركة استفساراتك إذا أردت، وإعلامنا بما تعثر عليه.