اختبار A/B في C#: كيف تتوقف عن التخمين وتبدأ في جني الأرباح

لماذا يعمل كود C# الخاص بك دون جدوى (وكيفية إصلاح ذلك)

لقد أمضيت أسابيع في إعادة هيكلة خوارزمية التوصيات. الإصدار الجديد من RecommendationService يبدو لا تشوبه شائبة، الكود أنظف، استعلامات LINQ أسرع. تقوم بنشر التحديث إلى الإنتاج، و... ينخفض معدل التحويل بنسبة 15%. هل يبدو هذا مألوفًا؟ إذا لم يكن كذلك، فأنت محظوظ. إذا كان كذلك، فقد فقدت المال والوقت للتو لأنك اعتمدت على الحدس، وليس على البيانات.

في عالم تطوير C#، هناك قاعدة ذهبية: "لا تثق أبدًا برأيك، ثق بالإحصائيات". ولهذا السبب تحديدًا يوجد اختبار A/B (أو اختبار الانقسام). إنها ليست حيلة تسويقية - بل هي نهج هندسي لاتخاذ القرارات. في هذه المقالة، سنشرح كيفية تطبيق اختبار A/B كامل في تطبيق C# الخاص بك: من البنية التحتية إلى حساب الدلالة الإحصائية. ونعم، سيكون هناك الكثير من الكود.

ما هو اختبار A/B في سياق C#؟

تخيل أن لديك نسختين من نفس المنطق - المجموعة الضابطة A (النسخة القديمة) والمجموعة التجريبية B (النسخة الجديدة). تقوم بتوزيع المستخدمين عشوائيًا بينهما، وتجمع المقاييس، وباستخدام الرياضيات تحدد أي نسخة هي الأفضل حقًا.

في C#، يمكن أن يتعلق هذا بأي شيء:

\n
• تغيير خوارزمية البحث
\n
• تصميم جديد لنموذج الدفع
\n
• خيارات مختلفة لترتيب المنتجات
\n
• تجارب مع وقت التخزين المؤقت
\n
• اختبار نماذج التعلم الآلي
\n

النقطة الأساسية: اختبار A/B في C# لا يتعلق بـ "وضع علامة في ملف التكوين". إنه يتعلق بـ بنية نظيفة، العشوائية، وجمع المقاييس بدون أخطاء.

بنية اختبار A/B: طبقات الكيك في C#

دعنا ننتقل مباشرة إلى التطبيق العملي. سأعرض لك بنية بسيطة ولكنها عملية. تتكون من ثلاث طبقات:

\n
1. المُعيّن (Assigner) - يقرر المجموعة التي ينتمي إليها المستخدم.
\n
2. قرار الميزة (Feature Decision) - أي نسخة من الكود سيتم تنفيذها.
\n
3. المُتعقّب (Tracker) - يسجل الحدث والنتيجة.
\n

الخطوة 1: المُعيّن - من أنت أيها المستخدم؟

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

public interface IExperimentAssigner\n{\n    string GetVariant(string userId, string experimentName);\n}\n\npublic class ConsistentExperimentAssigner : IExperimentAssigner\n{\n    public string GetVariant(string userId, string experimentName)\n    {\n        // إنشاء تجزئة مستقرة من userId + experimentName\n        var hash = HashCode.Combine(userId, experimentName);\n        // أخذ باقي القسمة من 100 - نحصل على النسبة المئوية\n        var bucket = Math.Abs(hash) % 100;\n        \n        // لنفترض، 50% في A، 50% في B\n        return bucket < 50 ? "A" : "B";\n    }\n}\n

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

الخطوة 2: قرار الميزة - معركة الخوارزميات

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

public interface IPricingStrategy\n{\n    decimal CalculatePrice(decimal basePrice);\n}\n\npublic class OldPricingStrategy : IPricingStrategy\n{\n    public decimal CalculatePrice(decimal basePrice) \n        => basePrice; // بدون خصم\n}\n\npublic class NewPricingStrategy : IPricingStrategy\n{\n    public decimal CalculatePrice(decimal basePrice) \n        => basePrice * 0.9m; // خصم 10%\n}\n\npublic class PricingStrategyFactory\n{\n    private readonly IExperimentAssigner _assigner;\n\n    public PricingStrategyFactory(IExperimentAssigner assi