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