قم بتشخيص عدم تطابق نسبة العينة في خمسة فروع قبل التخلص من الاختبار.

تُظهر حوالي 6% من التجارب في مايكروسوفت عدم تطابق في نسبة العينة، وهو ما يعادل تقريبًا اكتشافًا واحدًا يوميًا في منتج يُجري 10,000 تجربة سنويًا (فابيان وآخرون، KDD 2019الفرق التي تُجري عددًا أقل بكثير من الاختبارات نادرًا ما ترى هذا الرقم، لأن الفحص الذي تُجريه منصتها لا يُمكن أن يصل إلى مستوى الدلالة الإحصائية مع حجم حركة المرور لديها. يبدو الاختبار سليمًا ظاهريًا، ويُشير إلى زيادة بنسبة 4%، ولكنه خاطئ على أي حال.

هذا الدليل مُخصّص للشخص الذي يقرأ نتائج التجربة ويُقرر ما إذا كان سيتم شحنها أم لا. بنهاية هذا الدليل، ستتمكن من تحديد ما إذا كان حجم اختبارك كافيًا لكي يكون لفحص عدم التطابق أي دلالة، وإجراء خمسة مسارات تشخيصية بالترتيب الذي يُحدد السبب بأسرع وقت، وفصل أي خلل يُبطل النتائج عن خلل يُمكنك تجاهله والاحتفاظ به.

ما الذي يخبرك به جهاز إنذار SRM بالفعل؟

عدم تطابق نسبة العينة هو فجوة بين التقسيم الذي قمت بتكوينه والتقسيم الذي لاحظته: فقد قمت بتعيين 50/50 وحصلت على 50.8/49.2. ويتمثل الفحص القياسي في اختبار مربع كاي لبيرسون لجودة المطابقة على عدد مرات التعرض، بدرجة حرية واحدة لاختبار ذي مجموعتين.

هذا الأمر مهم لأن آلية فقدان المستخدمين نادراً ما تكون محايدة فيما يتعلق بمقياسك. فإذا أدى إعادة التوجيه إلى قطع الاتصالات البطيئة من الموقع البديل، فإن المستخدمين المتبقين هم من يملكون اتصالات أفضل، وبالتالي يحققون معدلات تحويل أعلى. هذا التحسن ظاهر في البيانات ولكنه غائب في الواقع.

أول خطأ ترتكبه معظم الفرق هو عدم وجود عتبة صناعية محددة. تختلف المنصات في هذا الشأن بأكثر من عشرة أضعاف.

هناك نتيجتان. أولاً، إذا تم الإبلاغ عن اختبار على منصة ما، فإنه ينجح على منصة أخرى بنفس البيانات، لذا فإن عبارة "لم ينبهنا برنامجنا" لا تُعد دليلاً على وجود انقسام واضح. ثانياً، يشير عتبة 0.01 إلى اختبار واحد من بين كل مئة اختبار سليم. إذا قمت بتقييم قيمة p يومياً على مدار اختبار مدته ثلاثة أسابيع، فإن الحد الأدنى المُبسط للإنذار الخاطئ هو 19%؛ الرقم الحقيقي أقل لأن الأيام المتتالية مترابطة بقوة، ولكنه ليس 1%. لهذا السبب، تُجري AB Tasty إجراءً تسلسلياً. إذا كانت منصتك تُجري اختبار مربع كاي ذي أفق زمني ثابت، فانظر مرة واحدة، في النهاية، إلى الإحصاءات التراكمية.

تحقق مما إذا كان اختبارك قادرًا على اكتشاف أي خلل على الإطلاق

في حالة التوزيع المتساوي (50/50)، تُبسط إحصائية مربع كاي إلى 4n(p̂−0.5)²، حيث n هو إجمالي عدد مرات التعرض. بعكس هذه المعادلة، نحصل على أصغر اختلال يمكن أن يكشفه الفحص.

اقرأها كقيد، لا كترخيص. عند 10,000 عملية تعريض، فإن أي اختلال أقل من 1.3 نقطة يكون غير مرئي للفحص، وتأثير اختيار 1.3 نقطة أكثر من كافٍ لإحداث زيادة طفيفة في معدل التحويل. هذه هي المشكلة الهيكلية في معظم أنحاء المنطقة. سجلت تركيا حوالي 6 مليارات معاملة تجارة إلكترونية عبر ما يقرب من 634,000 شركة في عام 2025 (وزارة التجارة، 12 مايو 2026يبلغ متوسط ​​عدد مرات ظهور الإعلانات في المتاجر الإلكترونية حوالي 9,500 مرة سنويًا، ويرتفع هذا المتوسط ​​بشكل ملحوظ بسبب عدد قليل من منصات البيع. فعلى سبيل المثال، يتعامل متجر متوسط ​​الحجم يختبر خطوة الدفع مع عشرات الآلاف من مرات الظهور، وليس الملايين، لذا فإن فحص إدارة علاقات الموردين (SRM) لديه لا يكشف إلا عن الأخطاء الجسيمة ولا يرصد أي أخطاء أخرى.

عند هذا الحجم، لا تعتمد على الإنذار. استخرج بنفسك عدد مرات التعرض الخام حسب اليوم وحسب الشريحة، وتعامل مع أي انحراف مستمر في نفس الاتجاه على أنه مثير للريبة حتى لو كانت قيمة p طبيعية. إذا لم تكن متأكدًا من مصدر تعرض منصتك لهذه الأرقام، وثائق مدقق إدارة علاقات الموردين يتم تحديدها حسب الأداة.

الفروع الخمسة، بالترتيب الذي يحدد السبب بأسرع وقت

يُصنّف تصنيف KDD أسباب SRM حسب مرحلة دورة الحياة: التخصيص، والتنفيذ، ومعالجة السجلات، والتحليل، والتداخل. يتم تشخيصها بترتيب مختلف، بدءًا بالأقل تكلفة والأكثر شيوعًا.

1. التحليل والتفعيل. العرض: يظهر التقسيم واضحًا في سجل التعرض الخام، ولكنه غير مكتمل في بطاقة النتائج. التحقق: أعد حساب النسبة بدون شرط التشغيل، وفلتر التاريخ، والوصلات على مستوى المقياس. تأكد من ذلك إذا عادت النسبة إلى القيمة المتوقعة. الحل: قيّم التشغيل بشكل متطابق في كلا المجموعتين، قبل أن يؤثر أي سلوك خاص بالمتغير على الأهلية. هذا هو الإنذار الكاذب الأكثر شيوعًا، ويستغرق استبعاده عشر دقائق.
2. معالجة السجلات. العرض: تختلف أعداد مرات التعرض بين مسارين، أو تظهر الفجوة بعد خطوة ETL. التحقق: قارن عدد مرات التعرض من جانب SDK، وعدد مرات التعرض من جانب المستودع، وعدد مرات التعرض من جانب التقارير لنفس الفترة الزمنية، ثم قارن معدلات استبعاد مرشح الروبوتات لكل مسار. يؤكد ذلك ما إذا كانت المسارات متساوية في المنبع وغير متساوية في المصب. الحل: قم بالتصفية بشكل حتمي ومتطابق. وصلت حركة المرور الآلية إلى 53% من حركة مرور الويب في عام 2026، ارتفاعًا من 51% في عام 2024.تقرير عن برنامج Imperva Bad Bot، 29 أبريل 2026لذا، يمكن لمرشح استدلالي يعتمد على توقيت التحميل أو سلوك وكيل المستخدم أن يستبعد بمعدلات مختلفة لكل متغير. وينطبق هنا أيضًا فقدان البيانات الناتج عن الموافقة: عندما ad_storage في حال الرفض، تتوقف منصة علامات جوجل عن وضع ملفات تعريف الارتباط الإعلانية (مستندات الموافقة على منصة علامات جوجللذلك، إذا اختلفت معدلات الرفض عبر المناطق الجغرافية في اختبار واحد، فإن أي مهمة تعتمد على تلك المعرفات ستفقد المستخدمين بشكل غير متساوٍ.
3. إعدام. العرض: يزداد عدم التوازن مع زيادة حجم الصفحة، ويتفاقم على الأجهزة المحمولة، أو يبدأ عند النشر. التحقق: قسّم النسبة حسب الجهاز والمتصفح ونوع الاتصال واليوم؛ قارن وقت الوصول بين المجموعتين. تأكد مما إذا كان النقص يتركز في الأجزاء البطيئة أو في متصفح واحد. الحل: هنا تفشل اختبارات إعادة التوجيه. تضيف إعادة التوجيه مسار تنقل كاملًا إلى مجموعة واحدة فقط، وكل من يغادر أثناءها يُعتبر خسارة انتقائية. اعرض كلا المتغيرين من جانب الخادم على عنوان URL واحد، أو تقبّل أن المجموعتين غير قابلتين للمقارنة.
4. الاحالة. العرض: النسبة غير متوازنة منذ الساعة الأولى، ويستمر هذا الاختلاف بنسبة ثابتة. التحقق: قم بتشغيل اختبار A/A على نفس التخصيص، وتأكد من عدم إعادة استخدام قيمة التجزئة (salt) من تجربة سابقة على هذه المجموعة. يؤكد ذلك ما إذا أظهر اختبار A/A عدم التوازن أيضًا. الحل: أعد التخصيص باستخدام قيمة تجزئة جديدة، ثم أعد التشغيل. يُعدّ الترحيل من اختبار سابق هو النسخة غير الظاهرة من هذه المشكلة، ولا يكشف عنها إلا اختبار A/A.
5. التشوش. العرض: يتركز عدم التوازن في عدد قليل من المعرّفات ذات النشاط العالي، أو في نطاقات عناوين IP الداخلية. التحقق: توزيع عدد مرات التعرض لكل مستخدم، وأعلى 1% من المعرّفات حسب حجم الأحداث. التأكد من أن إزالتها تُعيد النسبة إلى وضعها الطبيعي. الحل: استبعاد حركة المرور الداخلية والمبرمجة باستخدام قاعدة موثقة، وليس يدويًا، لضمان تطابق الاستبعاد في المرة القادمة.

شرح تفصيلي مفصل

الأرقام أدناه توضيحية وليست بيانات عميل. يُظهر اختبار التحقق 61,480 حالة تعرض للتحكم و58,520 حالة تعرض للمتغير: 51.2/48.8 على 120,000 مستخدم، وقيمة مربع كاي أقل من 0.001. الفرع 1: يؤدي حذف شرط التشغيل إلى 60,020 / 59,980، لذا فإن التخصيص صحيح ويحدث الفقد بعد التعرض. الفرع 2: تتفق أعداد خط الأنابيب، ونسبة استبعاد الروبوتات 0.9% في كلا الفرعين. الفرع 3: على أجهزة سطح المكتب 50.1/49.9، وعلى الأجهزة المحمولة 52.4/47.6، ومتوسط ​​وقت التعرض للمتغير أعلى بمقدار 900 مللي ثانية على الأجهزة المحمولة. التشخيص: يُرسل المتغير طلبًا إضافيًا يعيق العرض، ويتخلى مستخدمو الأجهزة المحمولة عنه أثناء ذلك، بينما يتمتع المستخدمون المتبقون باتصالات أفضل. القراءة غير صالحة. الإصلاح هو إصلاح للأداء، ويُعاد تشغيل الاختبار، وليس إعادة تفسيره.

ما يمكنك إنقاذه وما لا يمكنك إنقاذه

• أبطل القراءة عندما يكون من الممكن أن ترتبط آلية الخسارة بالمقياس بشكل معقول. كل سبب للتنفيذ والتخصيص مؤهل افتراضياً.
• الإنقاذ حسب القطاع لا يتحقق ذلك إلا عندما يقتصر عدم التوازن على شريحة يمكنك استبعادها بشكل واضح، وتكون هذه الشريحة قد حُددت قبل النظر إلى المقياس، ويجتاز الباقي فحص إدارة علاقات الموردين الخاص به. اثنان من ثلاثة لا يكفيان.
• احتفظ بالاختبار عندما يكون السبب متعلقًا بالتحليل فقط، وتجتاز بطاقة الأداء المصححة الاختبار. أنت تعيد قراءة البيانات نفسها باستخدام فلتر ثابت، وليس عن طريق البحث العشوائي.
• سجلها بأي طريقة كانت. سجّل فئة السبب في التجربة. يُؤتي التصنيف ثماره تراكميًا: إذا فشلت ثلاث من آخر عشر تجارب في الفرع 3، فالمشكلة ليست في التجريب، بل في تسليم واجهة المستخدم. [بيانات داخلية مطلوبة: نسبة التجارب التي أجرتها Switas خلال الـ 24 شهرًا الماضية والتي فشلت في فحص SRM، مُصنّفة حسب فرع التصنيف، لاستبدال معيار مايكروسوفت البالغ 6% برقم من هذا السوق]

أين يكمن الخلل؟

يفترض هذا النموذج اختبارًا ثنائي الأذرع بتخصيص ثابت ومعروف، وعشوائية على مستوى المستخدم. ولا يشمل الاختبارات متعددة الأذرع، التي تتطلب قيمة مربع كاي الكاملة لجميع الأذرع، بالإضافة إلى متابعة لتحديد الزوج غير المناسب، أو التخصيصات المتدرجة، حيث تتغير النسبة المتوقعة أثناء الاختبار، ويكون مربع كاي التراكمي اختبارًا خاطئًا بشكل قاطع. كما لا ينطبق على التصاميم العنقودية أو العشوائية جغرافيًا، حيث لا تكون الوحدة هي المستخدم، ويكون عدم التوازن المهم في خصائص المجموعة. ولا يُشير هذا النموذج إلى صحة تعريف المقياس. ولا يُمكنه المساعدة عندما لا يتم تسجيل حالات التعرض، وعندما تستنتج التخصيص من حدث المقياس، وهو ليس فحصًا للتقسيم، بل مجرد تخمين.

الأسئلة الشائعة

هل يُعدّ تقسيم الأرباح بنسبة 51/49 مشكلة دائماً؟ يعتمد الأمر كلياً على عدد مرات التعريض (n). عند 5,000 مرة، يُعتبر ضوضاءً عادية؛ أما عند 500,000 مرة، فيُصبح عيباً شبه مؤكد. قيّم النسبة بناءً على جدول قابلية الكشف، وليس بناءً على قاعدة نسبة مئوية ثابتة.

هل يمكنني ببساطة إعادة ترجيح الأذرع إحصائياً بدلاً من إعادة التشغيل؟ لا. إعادة الترجيح تُصحح الإحصاءات وتحافظ على الاختيار كما هو. المستخدمون الذين فقدتهم قد اختفوا، ولم يكونوا عينة عشوائية من المجموعة.

كم مرة يجب أن أنظر إلى قيمة p الخاصة بـ SRM؟ مرة واحدة، في النهاية، على الإحصاءات التراكمية، إلا إذا كانت منصتك تُشغّل إجراءً تسلسليًا. يؤدي النظر يوميًا إلى مربع كاي ذي أفق زمني ثابت إلى تضخيم الإنذارات الكاذبة بشكل كبير.

هل يؤدي نظام إدارة علاقات الموردين (SRM) إلى إبطال مقاييس الضوابط أيضًا؟ نعم، وللسبب نفسه. إذا كانت الأذرع تضم فئات سكانية مختلفة، فإن الحاجز المسطح ليس أكثر موثوقية من المقياس الأساسي المتحرك.

ماذا لو أظهر اختبار A/A أيضًا عدم تطابق؟ إذن، يكمن الخلل في عملية التخصيص أو في مسار تسجيل البيانات، وليس في معالجتك. أصلحه قبل تشغيل أي شيء آخر، لأنه يؤثر سلبًا على جميع الاختبارات على تلك المنصة.

هل تؤدي اختبارات إعادة التوجيه دائمًا إلى حدوث SRM؟ ليس دائمًا، لكنها تنطوي على مخاطر هيكلية لا توجد في أي تصميم آخر، لأن نظام الملاحة الإضافي موجود في ذراع واحد فقط. إذا كنت مضطرًا لاستخدامها، فتحقق من النسبة حسب سرعة الاتصال والجهاز قبل قراءة أي بيانات.

حركة المرور على موقعي منخفضة للغاية لدرجة أن الفحص لا يُجدي نفعاً. ماذا أفعل إذن؟ راقب عدد مرات التعرض اليومية الخام بحثًا عن أي انحراف مستمر، وقم بإجراء فحص دوري للطبقة المخصصة، وسجل مسبقًا قائمة أطول من فحوصات التحقق. أنت بذلك تستبدل قوة المعالجة بالقوة الإحصائية.

هل ينبغي تطبيق فلترة البرامج الآلية قبل أو بعد التعيين؟ بعد تسجيل التعرض، وقبل التحليل، يتم تطبيق قواعد حتمية بشكل متطابق على كلا المجموعتين. أما الترشيح الاستدلالي داخل حزمة تطوير البرامج (SDK) فهو ما يجعل المرشح نفسه هو سبب عدم التطابق.

قم بإجراء الفحص على برنامج التجربة الخاص بك

إذا كنت ترغب في الحصول على رأي ثانٍ حول سلامة الاختبارات التي تجريها حاليًا، أو مراجعة طبقة التعيين والتسجيل التي تعتمد عليها جميعها، فهذا ما نقدمه. خدمات البحث التعاقدي والتجريب لا.

مصادر

• فابيان، غوبتشوب، غوبتا، أوم هوفر، فيرمير، ديميترييف، "تشخيص عدم تطابق نسبة العينة في التجارب المضبوطة عبر الإنترنت: تصنيف وقواعد عامة للممارسين"، KDD 2019
• وثائق AB Tasty، عدم تطابق نسبة العينة (S-SRM المتسلسل، العتبة 0.01)
• Statsig، "دليل سريع لعدم تطابق نسبة العينة"، 31 أغسطس 2023 (اختبار مربع كاي، العتبة 0.01)
• وثائق GrowthBook، التجربة (اختبار مربع كاي، تحذير أقل من 0.001)
• إمبيرفا، "تقرير الروبوتات السيئة 2026: الروبوتات في عصر الوكلاء"، 29 أبريل 2026
• وزارة التجارة بجمهورية تركيا، أرقام التجارة الإلكترونية لعام 2025، 12 مايو 2026
• منصة علامات جوجل، ووضع الموافقة، وسلوك التخزين
• وثائق وأسئلة وأجوبة حول مدقق إدارة علاقات الموردين (SRM Checker)، لوكاس فيرمير