تعمل أدوات اختبار A/B التقليدية (Optimize، VWO) عن طريق حقن JavaScript.

يقوم المتصفح بتحميل الصفحة أ.
يعمل JS ويفحص ملف تعريف الارتباط.
يعيد JS كتابة DOM إلى “الصفحة ب”. يؤدي هذا إلى FOOC (فلاش المحتوى الأصلي). يرى المستخدم العنوان القديم لمدة 0.5 ثانية، ثم ينتقل إلى العنوان الجديد. فهو يدمر مؤشرات الويب الأساسية (CLS) ويقلل الثقة. الحل؟ ** حافة الوسيطة **.

لماذا تتحدث Maison Code عن هذا

في Maison Code Paris، نعمل كضمير معمari لعملائنا. غالبًا ما نرث حزمًا “حديثة” تم بناؤها دون فهم أساسي للحجم.

نناقش هذا الموضوع لأنه يمثل نقطة تحول حاسمة في النضج الهندسي. التنفيذ الصحيح يميز MVP الهش عن منصة مؤسسية مرنة يمكنها التعامل مع حركة مرور الجمعة السوداء.

لماذا يتم إجراء اختبارات Maison Code على الحافة؟

نحن نرفض التنازل عن أداء البيانات. التسويق يريد التجارب. الهندسة تريد السرعة. اختبار الحافة يعطي كليهما. نقوم بتنفيذ المنطق على خوادم Cloudflare/Vercel (The Edge)، على بعد 5 مللي ثانية من المستخدم. يصل HTML معروضًا مسبقًا. لا يرى المستخدم المفتاح مطلقًا. هذه هي الطريقة الوحيدة للاختبار على موقع فاخر.

1. الهندسة المعمارية

نقوم بنقل المنطق إلى CDN (Vercel Edge / Cloudflare Workers). يتم اتخاذ القرار قبل إنشاء HTML.

الطلب: يضغط المستخدم على /.
الحافة: للتحقق من ملف تعريف الارتباط “معرف التجربة”.
الحافة: إذا كانت مفقودة، يتم رمي النرد (50/50). مجموعات ملفات تعريف الارتباط.
الحافة: إعادة كتابة الاستجابة (جانب الخادم).
المتصفح: يتلقى HTML المحدد للمتغير B فقط. صفر CLS. صفر وميض.

2. التنفيذ في Next.js / البرامج الوسيطة

نستخدم ملف “middleware.ts” لاعتراض الطلب.

// الوسيطة.ts
استيراد { NextResponse } من "الخادم/التالي"؛
استيراد { getBucket } من '@lib/ab-testing'؛

وظيفة التصدير الوسيطة (طلب: طلب) {
  const COOKIE_NAME = 'ab-hero-test';
  دع الجرة = request.cookies.get(COOKIE_NAME)?.value;

  // إذا لم يكن هناك دلو، قم بتعيين واحد
  إذا (!دلو) {
    دلو = Math.random () <0.5؟ "التحكم" : "البديل"؛
  }

  // أعد كتابة عنوان URL داخليًا (غير مرئي للمستخدم)
  const url = request.nextUrl.clone();
  إذا (دلو === "متغير") {
    url.pathname = '/variants/b';
  } آخر {
    url.pathname = '/variants/a';
  }

  استجابة ثابتة = NextResponse.rewrite(url);
  
  // قم بتعيين ملف تعريف الارتباط اللزج
  Response.cookies.set(COOKIE_NAME, Bucket);
  استجابة العودة؛
}

3. الدلالة الإحصائية (الرياضيات)

لا تقم فقط بإجراء اختبار لمدة يومين. أنت بحاجة إلى القوة الإحصائية. إذا كان لديك 100 زائر و5 تحويلات (5%) مقابل 7 تحويلات (7%)، فهذا يعد ضجيجًا. استخدم الآلة الحاسبة بايزي. نحن عادة نطلب:

الحد الأدنى للعينة: 1000 زائر لكل متغير.
المدة: دورتان عمل كاملتان (أسبوعان). ** مشكلة النظر **: لا توقف الاختبار في اللحظة التي يبدو فيها اللون أخضر. هذا هو “P-القرصنة”. الالتزام بالمدة قبل البدء.

4. تأثير تحسين محركات البحث (سلامة Google)

جوجل يكره المحتوى المكرر. إذا كان لديك / و/variant-b، فاستخدم العلامات canonical. قم بتوجيه كلا الإصدارين الصالحين إلى عنوان URL الأساسي /. أو، نظرًا لأننا نقوم بإعادة كتابة Edge، يظل عنوان URL هو / للمستخدم. عادةً ما يرى GoogleBot عنصر التحكم (ما لم يحتفظ بملفات تعريف الارتباط). تحذير: لا تقم “بالإخفاء” (أظهر لـ Google شيئًا وللمستخدمين شيئًا آخر). يتحقق Google من JS المقدم. يعد اختبار الحافة أكثر أمانًا لأنه يخدم استجابات مختلفة للخادم.

5. علامات الميزات مقابل اختبارات A/B

علامة الميزة: “قم بتشغيل الخروج الجديد لـ 10% من المستخدمين لاختبار الأخطاء.” (أمان).
اختبار A/B: “إظهار الزر الأحمر مقابل الزر الأزرق لاختبار التحويل.” (نمو). نحن نستخدم أدوات مثل LaunchDarkly أو Statsig لإدارة كليهما. إنهما يشتركان في نفس المنطق الأساسي (العرض الشرطي)، لكن القصد مختلف. أعلام الميزات مخصصة للهندسة. اختبارات A/B مخصصة للمنتج.

6. تحليل الوميض (تكلفة تجربة المستخدم)

إذا كنت تستخدم اختبار A/B من جانب العميل… وميضك هو 500 مللي ثانية … ستفقد 10% من المستخدمين حتى قبل أن يروا المتغير. بياناتك تالفة. أنت تختبر “التحكم مقابل (المتغير + التأخير)”. أنت لا تختبر “التحكم مقابل المتغير”. يقوم اختبار الحافة بإزالة متغير التأخير. إنها الطريقة العلمية الوحيدة للاختبار.

7. مجموعة الصامدين

إذا قمت بإجراء 10 تجارب مرة واحدة… فكيف تعرف التأثير الإجمالي؟ أنشئ مجموعة تعليق عالمية. 5% من المستخدمين لم يشاهدوا أي تجربة أبدًا. قارن بين مجموعة “جميع التجارب” ومجموعة “الرفض” بعد 6 أشهر. وهذا يثبت القيمة طويلة المدى لبرنامج CRO الخاص بك.

9. المقاييس المهمة (بما يتجاوز معدل النقر)

لا تقيس “النقرات” فقط. هذا هو مقياس الغرور. قياس العائد لكل زائر (RPV). قد يحصل البديل أ على نقرات أقل، ولكن AOV (متوسط قيمة الطلب) أعلى. إذا قمت بتحسين النقرات، فربما تقوم فقط بإنشاء “Clickbait”. نحن نتتبع:

معدل التحويل: هل اشتروا؟
AOV: كم أنفقوا؟
RPV: القيمة المجمعة.
الاحتفاظ: هل عادوا؟

10. الاختبار المجزأ (التخصيص)

يعد اختبار A/B على “جميع المستخدمين” أمرًا صريحًا. اختبار على الشرائح.

الاختبار أ: عرض “الشحن المجاني” للأشخاص المهمين العائدين.
الاختبار ب: عرض “خصم 10%” للزائرين الجدد. مجموعات مختلفة تتصرف بشكل مختلف. استخدم Edge Middleware لاكتشاف المقطع (عبر ملف تعريف الارتباط أو Geo) وتقديم الاختبار المناسب. لقد مات مبدأ “مقاس واحد يناسب الجميع”.

11. اختبار A/B/n (متعدد المتغيرات)

لماذا اختبار فقط A مقابل B؟ اختبار أ مقابل ب مقابل ج مقابل د. خوارزمية اللصوص: بدلاً من التقسيم الثابت بنسبة 50/50… تقوم الخوارزمية بتوجيه حركة المرور ديناميكيًا إلى المتغير الفائز أثناء تشغيل الاختبار. إذا فاز الإصدار C، أرسل 80% من حركة المرور إلى C. يؤدي هذا إلى زيادة الإيرادات أثناء الاختبار. هذا هو التعلم الآلي على الحافة.

“هل يمكننا اختبار ما إذا كانوا يرفضون ملفات تعريف الارتباط؟” لا. إذا رفض المستخدم التتبع، فلا يمكنك تعيين معرف ثابت له. الاستراتيجية:

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

13. تكامل التحليلات (GA4 / Mixpanel)

الحافة تقرر البديل. لكن GA4 يحتاج إلى معرفة. نقوم بإدخال القرار في كائن “النافذة”.

window.ab_test = {
  معرف_التجربة: 'اختبار_البطل'،
  البديل: "ب"
};

وبعد ذلك، يلتقطه GTM (Google Tag Manager) ويرسله باعتباره “خاصية مستخدم”. ويتيح لك ذلك تقسيم تقارير “إحصاءات Google”‏ 4 إلى شرائح حسب المتغير. “إظهار معدل الاحتفاظ بالصيغة ب.” وبدون هذا الرابط، تصبح بياناتك عمياء.

14. استراتيجية اختبار التسعير (الإيرادات الخطيرة)

اختبار التسعير أمر خطير. إذا اكتشف المستخدمون ذلك، فسيغضبون. اختبار “الخصم”: الاختبار أ: السعر القياسي ($100). الاختبار ب: “عرض لفترة محدودة: \90 دولارًا”. هذا آمن. اختبار “المتميز”: الاختبار أ: السعر القياسي ($100). الاختبار ب: التغليف المتميز متضمن ($120). اختبار مقترحات القيمة، وليس فقط نقاط السعر. إذا قمت باختبار السعر الخام ($100 مقابل $110) لنفس العنصر بالضبط، فإنك تخاطر بكابوس العلاقات العامة.

15. الاختبار الأول للهاتف المحمول (منطقة الإبهام)

تفشل معظم اختبارات A/B على الهاتف المحمول لأنها مصممة لسطح المكتب. “منطقة الإبهام”: على الهاتف المحمول، يجب أن يكون من الممكن الوصول إلى CTA بإبهام واحد. الاختبار أ: الزر الثابت القياسي. الاختبار ب: “زر الإجراء العائم” (FAB) في أسفل اليمين. غالبًا ما نرى تحويلاً بنسبة +15% فقط عن طريق تحريك الزر بمقدار 50 بكسل لأسفل. اختبار بيئة العمل المادية، وليس فقط الألوان.

16. الاستنتاج

اختبار A/B هو الأسلوب العلمي المطبق على الإيرادات. ولكن إذا كان “العلم” الخاص بك يعطل تجربة المستخدم (Flicker)، فإنك تبطل النتائج. اختبار على الحافة. حافظ على السرعة. احترم الرياضيات. النمو هو لعبة البوصات، وليس الأميال.

17. التحذير الأخير من الوميض

إذا أخذت شيئًا واحدًا من هذه المقالة: لا تقبل الوميض. وميض ليس مجرد “قبيح”. إنه تلف البيانات. إنه يتحيز اختبارك نحو المستخدمين ذوي الإنترنت السريع (الذين يرون وميضًا أقل). إنه متحيز ضد مستخدمي الهاتف المحمول. إنه يبطل فرضيتك بأكملها. الانتقال إلى الحافة. أو لا تختبر على الإطلاق.

تخمين ما الذي ينجح؟

نحن ننفذ خطوط أنابيب تجريبية خالية من الوميض.

مجموعة نمو الإعداد. قم بتوظيف مهندسينا.