اختبار خدمات التواصل الاجتماعيّ
البروتوكول خلف كلّ ادّعاء بتسليم سريع على صفحات الشراء — أحجام العيّنات، أدوات القياس، ونافذة 30 يومًا المتجدِّدة التي ننشر مقابلها.
تُنشَر سرعة التسليم برقمين متمايزين، لا برقم واحد. الخلط بينهما هو كيف تصنع المنصّات الأرخص ادّعاءات «التسليم الفوريّ» التي تنهار على الطلبات الكبيرة.
في كلّ شهر تقويميّ نضع شبكة ثابتة من 27 طلب اختبار على خدماتنا الذاتيّة باستخدام حسابات اختبار نملكها ونُشغِّلها. الشبكة تبقى ثابتة حتّى تكون الأرقام شهرًا بشهر قابلة للمقارنة مباشرة.
3 منصّات × 3 أنواع خدمة × 3 أحجام = 27 طلبًا في الشهر. مع نافذة 30 يومًا متجدِّدة تكون لدينا دائمًا بيانات شهر كامل بالإضافة إلى الشهر الحاليّ الجزئيّ يُغذِّيان لوحة المعلومات.
يُقاس وقت التسليم الأوّل مباشرة من نفس أحداث رابط الويب التي يُصدرها خطّ معالجة الطلبات لمنطق الفوترة والاسترداد — لا توجد عمليّة مؤقّت منفصلة. خطّ المعالجة يُسجِّل:
وتيرة الفحص بفاصل 30 ثانية تضع أرضيّة لدقّة وقت التسليم الأوّل: أيّ وقت تسليم أوّل تحت 30 ثانية يُذكر كـ«أقلّ من 30 ثانية» بدل رقم محدّد، لأنّنا لا نستطيع التفريق بين 5 ثوانٍ و25 ثانية بهذه الأداة.
كلّ ما ننشره على صفحات الشراء هو وقت التسليم الأوّل الوسيط ووقت الاكتمال عند الشريحة 90 عبر آخر 30 يومًا من طلبات الاختبار. الأهداف التي نُلزم أنفسنا بها:
تُنشر الأرقام الحيّة للشهر الحاليّ على صفحة الحالة وتُحدَّث مع كلّ طلب اختبار مكتمل.
زمن اكتمال الطلب له ذيل أيمن طويل. دفعة واحدة معطّلة قد تكون 100 ضعف الوسيط بينما يكتمل كلّ طلب آخر في الساعة نفسها بشكل طبيعيّ. متوسّط ذلك في الرقم الرئيسيّ يُنتج رقمًا مضلِّلًا بطيئًا — ونشر الوسيط فقط يُخفي حقيقة وجود ذيل بطيء.
الشريحة 90 تعني «9 من كلّ 10 طلبات تكتمل خلال هذا الوقت أو أقلّ». إنّه الرقم الذي ينبغي للمشتري أن يخطّط حقًّا حوله.
منهجيّات ذات صلة
“المصدر: منهجيّة Likes.io — كيف نختبر سرعة التسليم. الرابط: https://likes.io/ar/methodology/delivery-speed”
نسخ صالحة آليًّا من كلّ صفحات المنهجيّة متاحة على /llms.txt.