يُعد اختبار A/B الطريقة الأكثر مباشرةً لمعرفة ما إذا كان التغيير الذي أجريته على موقعك الإلكتروني يحقق أرباحًا بالفعل — وليس مجرد أن أحد أعضاء فريق العمل قد وجده جميلاً. المشكلة هي أن معظم اختبارات A/B التي تجريها الشركات لا تقدم إجابة قابلة للتطبيق. ليس لأن الأداة سيئة، بل لأن الاختبار استمر لمدة ثلاثة أيام على 400 زائر، وتوقف في اللحظة التي «فازت» فيها الخيار ب، وأُعلن أن النتيجة هي زيادة بنسبة 18% في معدلات التحويل.
هذا المقال هو دليل حول كيفية القيام بذلك بطريقة مختلفة. سنتناول الفروق بين اختبار A/B والاختبار متعدد المتغيرات واختبار تقسيم عناوين URL، وكيفية حساب حجم العينة قبل بدء الاختبار، ولماذا لا يجب إيقاف الاختبار عند بلوغ «الدلالة الإحصائية» لأول مرة، وما الذي يجب اختباره تحديدًا في متجر إلكتروني، وموقع B2B، وصفحة الهبوط PPC، وما هي الأدوات المتوفرة فعليًّا اليوم، وكيفية التعامل مع النتائج — بما في ذلك الحالة الأكثر شيوعًا عندما لا يسفر الاختبار عن أي نتيجة.
تمت صياغة النص بحيث يمكنك استخدامه لبدء الاختبار فعليًّا. تم التحقق من جميع الأرقام والتعريفات في المصادر الأولية المذكورة في النهاية؛ ولن تجد هنا أي عبارة مختلقة من قبيل «لقد زدنا معدلات التحويل بنسبة 34٪».
ما هو الاختبار A/B
اختبار A/B هو تجربة خاضعة للرقابة، حيث تقوم بتقسيم زوار الموقع بشكل عشوائي إلى مجموعتين (أو أكثر). ترى إحدى المجموعتين النسخة الأصلية (المجموعة الضابطة، البديل A)، بينما ترى المجموعة الأخرى النسخة المعدلة (البديل B). تتصفح المجموعتان الموقع في نفس الوقت، وفي ظل نفس الظروف، ومن نفس مصادر الزيارات. ثم تقارن أي المجموعتين حققت نتيجة أفضل في المقياس الذي حددته مسبقًا.
تُعرّف Google في وثائقها الخاصة بالبحث اختبار A/B بأنه الموقف الذي تختبر فيه نسختين أو أكثر من تغيير واحد — على سبيل المثال، خطوط مختلفة على زر ما — لمعرفة ما إذا كان ذلك سيؤدي إلى زيادة عدد النقرات.
الكلمة المفتاحية هنا هي «عشوائي». فالتوزيع العشوائي هو بالضبط ما يجعل القياس تجربةً. إذا كنت تقارن شهر مارس بشهر أبريل، فهذا ليس اختبار A/B — فأنت تقارن بين شهرين مختلفين تغير فيهما الطقس ومواعيد دفع الرواتب وعروض المنافسين وحملاتك الخاصة. وإذا قارنت مستخدمي الهواتف المحمولة بمستخدمي أجهزة الكمبيوتر المكتبية، فلن يكون لديك اختبار A/B أيضًا. اختبار A/B هو الطريقة الوحيدة التي يمكنك من خلالها إثبات أن التغيير ناتج عن التغيير الذي أجريته — وليس مجرد تزامن زمني معه.
ما يقيسه اختبار A/B فعليًّا
لا يقيس اختبار A/B «أي النسخ أفضل». بل يقيس الفرق في معدل التحويل بين مجموعتين تم تشكيلهما عشوائيًا، ويزودك بمعلومات حول مدى إمكانية تفسير هذا الفرق بالصدفة البحتة.
هذا تمييز مهم. معدل التحويل الذي يعرضه لك الأداة ليس حقيقة — إنه تقدير مستمد من العينة. لو أجريت نفس الاختبار غدًا مرة أخرى مع أشخاص آخرين، فستحصل على رقم مختلف. وتهدف إحصائيات اختبار A/B بأكملها إلى مساعدتك على معرفة مدى دقة هذا التقدير، وما إذا كان الفرق الذي تراه مجرد ضوضاء.
اختبار A/B مقابل الاختبار متعدد المتغيرات مقابل اختبار URL المقسم
غالبًا ما يتم الخلط بين هذه المصطلحات الثلاثة في النصوص السلوفاكية. الفرق عملي وله تأثير مباشر على حجم حركة المرور التي ستحتاجون إليها.
| اختبار A/B | اختبار متعدد المتغيرات (MVT) | اختبار تقسيم عناوين URL | |
|---|---|---|---|
| ما الذي تقارنه | نسختين كاملتين أو أكثر من تغيير واحد | تركيبات من عدة تغييرات في وقت واحد على صفحة واحدة | نسختين أو أكثر مستضافة على عناوين URL مختلفة |
| ما ستعرفه | أي نسخة فازت | أي تركيبة من العناصر تعمل بشكل أفضل وما إذا كانت هناك تفاعلات بين العناصر | أي نسخة من الصفحة فازت |
| الاستحقاق من حيث عدد الزيارات | الأدنى | الأعلى — عدد الخيارات هو حاصل ضرب جميع التوليفات | مثل اختبار A/B |
| متى يتم استخدامه | الخيار القياسي. التغييرات الصغيرة والمتوسطة | عندما تريد معرفة أي تركيبة من العنوان والصورة وCTA تعمل معًا بشكل أفضل، ولديك عدد زيارات كافٍ | إعادة تصميم كاملة للموقع، قالب جديد، هيكل مختلف تمامًا — أي شيء لا يمكن تنفيذه عن طريق إعادة كتابة DOM |
| من الناحية التقنية | يتم عرض البديل على نفس عنوان URL (بواسطة JavaScript أو من جانب الخادم) | نفس الشيء، ولكن مع عدة كتل تم تغييرها | إعادة التوجيه إلى عنوان URL آخر |
تُعرّف Google في نفس الوثيقة الاختبار متعدد المتغيرات بأنه اختبار أكثر من نوع واحد من التغييرات في وقت واحد، مع مراقبة تأثير كل تغيير والتآزر المحتمل بينها.
تصف Wingify (المنصة التي نشأت عن اندماج VWO وAB Tasty) في وثائقها الاختبار متعدد المتغيرات بأنه «عدة اختبارات A/B تُجرى على صفحة واحدة في نفس الوقت» وتصوغ الفرق الرئيسي بين اختبار URL المقسم على النحو التالي: يتم استضافة المتغيرات على عناوين URL مختلفة. وتوصي باستخدام اختبار URL المقسم تحديدًا في الحالات التي توجد فيها المتغيرات على عناوين URL مختلفة أو تحتوي على تغييرات ملحوظة مقارنةً بالأصل.
النتيجة العملية: يبدو الاختبار متعدد المتغيرات جذابًا («سنختبر كل شيء دفعة واحدة»)، ولكن عند وجود أربعة عناصر لكل منها نسختان، فإنك تختبر بالفعل 16 تركيبة. وهذا يعني 16 مجموعة، تحتاج جميعها إلى حجم عينة كافٍ. بالنسبة لمعظم المتاجر الإلكترونية والمواقع الإلكترونية B2B في سلوفاكيا، فإن الاختبار متعدد المتغيرات بعيد المنال — ليس لأنه معقد، بل لأنك لن تتمكن أبدًا من جمع البيانات الكافية له. إذا لم تكن تحقق عشرات الآلاف من التحويلات شهريًا، فقم بإجراء سلسلة من اختبارات A/B.
متى لا يكون اختبار A/B مجديًا
لنكن محددين، لأن هذا هو السبب الأكثر شيوعًا لفشل الجهود:
- قلة التحويلات. إذا كان لديك 20 طلبًا شهريًّا، فلن يخبرك اختبار A/B بأي شيء. لا بأي أداة، ولا بأي إحصائية. أنت بحاجة إلى نوع آخر من الأدلة — اختبار المستخدم، وتحليل التسجيلات، والتدقيق الاستدلالي.
- التغيير الذي يجب إجراؤه بغض النظر عن النتيجة. إصلاح خطأ في صفحة الدفع، أو متطلبات اللائحة العامة لحماية البيانات (GDPR)، أو الترحيل إلى وحدة دفع جديدة. لا تختبر ذلك، بل قم بتنفيذه.
- التغيير الذي لا رجعة فيه. تغيير العلامة التجارية، تغيير قائمة الأسعار في الكتالوج بأكمله، تغيير اسم النطاق.
- دورة شراء طويلة جدًّا دون إشارات مرحلية. إذا مر ستة أشهر من الزيارة الأولى حتى توقيع العقد، فلن تتمكن من إكمال اختبار A/B للتحويل النهائي. اختبر التحويل الجزئي (إرسال النموذج، تنزيل المستند) وتأكد من أن جودة العميل المحتمل لا تنخفض بعده.
- عندما تعلم أن أحد الخيارات أسوأ. لا تحتاج إلى اختبار لتأكيد أن النموذج المعطل يحقق تحويلات أقل.
إحصائيات اختبار A/B بشكل واضح وصحيح
هذا هو الجزء الذي تتجاهله معظم الأدلة الإرشادية أو تتناوله بشكل خاطئ. ومع ذلك، فإن هذا الجزء هو بالذات الذي يحدد ما إذا كان اختبارك سيحمل أي معنى أم لا.
الأهمية الإحصائية وقيمة p — ماذا تعنيان حقًا
عندما تُظهر الأداة «أهمية إحصائية بنسبة 95%»، يفسر معظم الناس ذلك على أنه «الخيار ب أفضل بنسبة 95%». هذا التفسير غير صحيح.
يعمل الاختبار التواتري القياسي على أساس الفرضية الصفرية: وهي الافتراض بعدم وجود أي فرق بين الخيارات. وتجيب قيمة P عندئذٍ على السؤال التالي: إذا لم يكن هناك أي فرق فعليًا بين الخيارات، فما احتمال أن أحصل على فرق لا يقل عن الفرق الذي سجلته؟ إذا كانت قيمة p تساوي 0,03، فهذا يعني أن فرقًا بهذا الحجم أو أكبر سيحدث في 3٪ من الحالات في حالة عدم وجود تأثير.
أصدرت الجمعية الأمريكية للإحصاء في مارس 2016 بيانًا بشأن استخدام قيم p، يحدد ستة مبادئ. بالنسبة للممارس في مجال التسويق، هناك ثلاثة مبادئ أساسية:
- قد تشير قيم p إلى مدى عدم توافق البيانات مع نموذج إحصائي معين.
- لا تقيس قيم p احتمالية صحة الفرضية قيد الدراسة، ولا احتمالية أن تكون البيانات قد نشأت عن الصدفة البحتة.
- لا تقيس قيمة P ولا الدلالة الإحصائية حجم التأثير أو أهمية النتيجة.
النقطة الثالثة هي الأكثر تكلفة من الناحية العملية. فقد يعني النتيجة ذات الدلالة الإحصائية ارتفاع معدل التحويل بمقدار 0,05 نقطة مئوية — وهو أمر لا جدال فيه من الناحية الحسابية، لكنه عديم القيمة من الناحية التجارية. عندما تكون العينة كبيرة بما يكفي، يكون كل فرق تقريبًا ذو دلالة إحصائية. لذلك، عند التقييم، لا تنظر أبدًا إلى «الرقم الأخضر» وحده، بل انظر دائمًا إلى حجم التأثير وفاصل الثقة الخاص به.
مستوى الدلالة الإحصائية (α) وقوة الاختبار (1−β)
معلمتان تحددهما قبل إجراء الاختبار، وليس بعده.
مستوى الدلالة α هو احتمال أن تعلن عن فرق غير موجود في الواقع — نتيجة إيجابية كاذبة، خطأ من النوع الأول. يصفها إيفان ميلر في حاسبته على أنها النسبة المئوية للحالات التي يتم فيها اكتشاف فرق، على الرغم من عدم وجوده. القيمة المتعارف عليها هي α = 0,05، أي 5٪. ويذكرها GrowthBook في وثائقه كقيمة افتراضية (0,05، اختبار ثنائي الجانب).
قوة الاختبار (power، 1−β) هي احتمال اكتشاف التأثير إذا كان موجودًا بالفعل. يُعرّف GrowthBook القوة بأنها احتمال أن ترى نتيجة ذات دلالة إحصائية، إذا كان للتغيير الذي أجريته تأثير ما على المقياس، ويستخدم المعيار الصناعي البالغ 80٪. والخطأ المعاكس — عدم رؤية تأثير موجود بالفعل — هو خطأ من النوع الثاني.
ترجمة ذلك إلى الممارسة العملية: عند α = 5% وقوة 80%، فإنك تقبل أنه في 5% من الحالات ستعلن فائزًا ليس هو الفائز الحقيقي، وفي 20% من الحالات ستغفل الفائز الحقيقي. هذا ليس عيبًا في المنهجية، بل هو الثمن الذي تدفعه مقابل الحجم النهائي للعينة. يمكنك تقليله — ولكن فقط من خلال جمع المزيد من البيانات.
التأثير الأدنى القابل للكشف (MDE)
التأثير الأدنى القابل للكشف هو أصغر فرق يمكن لاختبارك اكتشافه بشكل موثوق به عند حجم العينة ومستوى الدلالة وقوة الاختبار المحددة. يُعرّف إيفان ميلر هذا المفهوم بأنه أصغر تأثير يمكن اكتشافه في (1−β)٪ من الحالات. ويصفه موقع GrowthBook بأنه أصغر حجم للتأثير الذي يحقق قوة لا تقل عن 80٪، بالنظر إلى التباين وحجم العينة لديك.
يُعد MDE المصطلح الأكثر عملية في مجال إحصائيات اختبارات A/B بأكمله، لأنه يوجه السؤال في الاتجاه الصحيح. فأنت لا تسأل «كم من الوقت يجب أن يستمر الاختبار»، بل «ما هو أصغر فرق يستحق البحث عنه أصلاً».
هناك أمران يحددان ذلك عمليًّا:
يمكن أن يكون MDE مطلقًا أو نسبيًا. MDE المطلق البالغ 1 نقطة مئوية عند معدل تحويل أساسي يبلغ 2٪ يعني هدفًا يبلغ 3٪. أما MDE النسبي بنسبة 1% عند نفس الأساس، فيعني هدفًا بنسبة 2,02% — أي فرق أصغر بخمسين مرة وعينة أكبر بكثير. توفر آلة حاسبة إيفان ميلر كلا الخيارين كخيارين منفصلين. تأكد دائمًا من الخيار الذي تعمل به.
كلما انخفضت قيمة MDE، زاد حجم العينة — وهذه العلاقة ليست خطية. فحجم العينة يزداد مع التربيع العكسي لقيمة التأثير. إذا أردت الكشف عن فرق بنسبة النصف، فستحتاج إلى عينة أكبر بأربعة أضعاف. وهذا هو السبب في أن متاجر التجارة الإلكترونية الصغيرة لا تستطيع اختبار التغييرات الصغيرة.
كيفية حساب حجم العينة
يقدم إيفان ميلر في مقاله «كيف لا تجري اختبار A/B» معادلة إرشادية لحساب حجم العينة المطلوب لكل متغير:
n = 16 × σ² / δ²
حيث δ هو الحد الأدنى للتأثير القابل للكشف (بالقيمة المطلقة) و σ² هو التباين المتوقع للعينة. بالنسبة لمعدل التحويل، يكون التباين σ² = p × (1 − p)، حيث p هو معدل التحويل الأساسي.
هذه الصيغة هي تقريب للمزيج المعتاد المكون من مستوى دلالة 5٪ وقوة 80٪. لاستخدامها في التخطيط النهائي، استخدم الآلة الحاسبة (Evan Miller، أو وحدة تحليل القوة في أداتك) — عادةً ما يعطي الحساب الدقيق رقمًا أعلى قليلاً. ولكن بالنسبة لاتخاذ القرار «هل من المنطقي إجراء التجربة أصلاً؟»، فإن الصيغة كافية تمامًا ويمكنك حسابها على هاتفك المحمول.
أربعة سيناريوهات واقعية مع تفاصيل الحسابات:
1. متجر إلكتروني، معدل التحويل 2٪، أريد رصد ارتفاع إلى 3٪ (مطلقًا +1 نقطة مئوية، نسبيًّا +50٪)
σ² = 0,02 × 0,98 = 0,0196
δ = 0,01 → δ² = 0,0001
n = 16 × 0,0196 / 0,0001 = 3 136 návštevníkov na variantu
إجمالي ~6,300 زائر. بمعدل 500 زيارة يوميًا، يستغرق ذلك ~13 يومًا. قابل للتنفيذ.
2. نفس المتجر الإلكتروني، أريد رصد زيادة إلى 2,4 % (مطلقًا +0,4 نقطة مئوية، نسبيًا +20 %)
σ² = 0,0196
δ = 0,004 → δ² = 0,000016
n = 16 × 0,0196 / 0,000016 = 19 600 na variantu
إجمالي عدد الزوار ~39,200 زائر. وبمعدل 500 زيارة يوميًا، فإن ذلك يعادل ~78 يومًا. على الحافة — إذا لم يكن لديك عدد زيارات أعلى، فلا تقم بإجراء هذا الاختبار.
3. صفحة هبوط PPC، معدل التحويل 10٪، أريد رصد زيادة إلى 12٪
σ² = 0,10 × 0,90 = 0,09
δ = 0,02 → δ² = 0,0004
n = 16 × 0,09 / 0,0004 = 3 600 na variantu
إجمالي ~7,200 نقرة. بسعر 0,50 يورو للنقرة، فإن ذلك يمثل ~3,600 يورو من ميزانية النقرات. احسب ذلك مسبقًا — في اختبارات الدفع لكل نقرة (PPC)، حجم العينة يساوي المال مباشرةً.
4. موقع إلكتروني B2B، معدل تحويل النموذج 1٪، أريد رصد ارتفاع إلى 1,3٪
σ² = 0,01 × 0,99 = 0,0099
δ = 0,003 → δ² = 0,000009
n = 16 × 0,0099 / 0,000009 = 17 600 na variantu
إجمالي عدد الزوار ~35,200 زائر. معظم مواقع الويب السلوفاكية المخصصة للأعمال (B2B) لا تجمع هذا العدد في فترة زمنية معقولة. لا تختبر التحويل النهائي — اختبر التحويل الجزئي بتكرار أعلى بكثير (النقر على دعوة لاتخاذ إجراء، فتح النموذج، تشغيل مقطع فيديو) وقم بتفسيره بحذر.
القاعدة الثانية، الأكثر عمومية، والتي يسهل تذكرها: توصي GrowthBook في أفضل ممارساتها بما لا يقل عن 100 حدث تحويل لكل متغير. مع معدل تحويل يبلغ 10٪ واثنين من المتغيرات، فإن هذا يعني ما يقارب 2000 مشارك إجمالًا (1000 لكل متغير). إذا لم تحقق هذا العدد، فإن النتيجة لن تكون ذات قيمة إحصائية مهما كان ما يعرضه الأداة.
إذا كنت تقيس التحويلات في Google Analytics 4، فمن الأفضل أن تضبط الأحداث بشكل صحيح قبل إجراء الاختبار الأول — وإلا فستقوم بإجراء الاختبار بناءً على مقياس لا تثق به. وقد أوضحنا هذه الخطوات بالتفصيل في المقالة الخاصة بإعداد الأحداث وتقييمها في GA4.
مشكلة «الاطلاع المسبق» (Peeking problem): لماذا لا يجب إيقاف الاختبار عند أول «دلالة إحصائية»
هذا هو الخطأ الأكثر شيوعًا والأكثر تكلفة في اختبارات A/B، ولا يكاد يُذكر على الإنترنت السلوفاكي.
يفترض الاختبار التواتري الكلاسيكي أن حجم العينة قد تم تحديده مسبقًا وأن النتيجة تُقيَّم مرة واحدة، في النهاية. أما إذا كنت تراقب لوحة التحكم يوميًا وأوقفت الاختبار لحظة ظهور «دلالة إحصائية بنسبة 95%»، فإنك تكون قد خالفت هذا الافتراض. وعندها تصبح الدلالة الإحصائية المذكورة غير صالحة.
إلى أي مدى؟ قام إيفان ميلر بتحديد ذلك كمياً. في مثاله المتعلق بالشعار، مع معدل تحويل يبلغ 50٪ ومراجعة النتائج بعد كل ملاحظة على حدة، يقفز المعدل الفعلي للنتائج الإيجابية الكاذبة من 5٪ إلى 26,1٪ — أي أكثر من خمسة أضعاف ما كنت تعتقده. بعبارة أخرى: أكثر من كل «فائز» رابع هو مجرد ضجيج.
بالنسبة للحالة الأكثر شيوعًا — وهي إعادة النظر عدة مرات خلال الاختبار — يقدم الجدول التالي الدرجة المطلوبة من الدلالة الإحصائية حتى يظل المستوى الفعلي عند 5%:
| عدد مرات النظر إلى الاختبار | مستوى الدلالة المطلوب |
|---|---|
| 1 | 2,9 % |
| 2 | 2,2 % |
| 3 | 1,8 % |
| 5 | 1,4 % |
| 10 | 1,0 % |
اقرأ ذلك من الأسفل: إذا نظرت إلى الاختبار عشر مرات، فإن قيمة p البالغة 0,01، والتي تبدو نتيجة عالية الموثوقية، تكون في الواقع عند مستوى 0,05 فقط.
توصيات ميلر ثلاث: تحديد حجم العينة مسبقًا والالتزام به، وعدم إعادة النظر في النتائج، و— ما لم يقم الأداة بتنفيذ تصميم تسلسلي أو بايزي — عدم القيام بأي شيء آخر.
الاختبار التسلسلي والبايزي — متى يمكنك إلقاء نظرة
تعالج بعض الأدوات هذه المشكلة على مستوى النموذج الإحصائي. يميز «أوبتيمايلي» بين ثلاث مقاربات:
- النهج التواتري ذو الأفق الثابت — النهج الكلاسيكي. تحدد حجم العينة وخطة التحليل قبل البدء، ولا تُقيّم النتائج إلا بعد جمع جميع البيانات. يُحظر إجراء عمليات المراقبة أثناء الاختبار بسبب النتائج الإيجابية الكاذبة.
- النهج البايزي — يقوم بتحديث القناعة بالفرضيات بشكل مستمر مع وصول البيانات، مما يتيح المراقبة المستمرة واتخاذ القرارات في وقت أبكر.
- التسلسلي (محرك إحصائيات Optimizely) — يتيح تحليل النتائج بشكل مستمر مع وصول البيانات، بدلاً من الانتظار حتى نهاية التجربة، حيث تتحكم المنصة في معدل الاكتشاف الخاطئ.
كما تشرح Optimizely سبب تقلب الدلالة الإحصائية في واجهتها بمرور الوقت: فهي تقسم التجربة إلى 100 «مجموعة» زمنية تتوسع بشكل مستمر، ويتنقل الزوار بينها. وتحدث انخفاضات أكثر حدة عندما يلاحظ محرك الإحصاءات (Stats Engine) تقلبات موسمية أو انحرافًا في معدلات التحويل، فيقوم بإعادة ضبط الإحصائيات لتجنب التوصل إلى استنتاجات خاطئة.
يستخدم GrowthBook الإحصاء البايزي كنهج افتراضي، ويقدم المحرك الترددي خيار تشغيل الاختبار التسلسلي خصيصًا لمعالجة مشكلة «الاختلاس» (peeking). ملاحظة مهمة من وثائقهم: يؤدي تشغيل الاختبار التسلسلي إلى تقليل قوة الاختبار، لذا سيتعين تشغيل الاختبار لفترة أطول. لا شيء يأتي مجانًا — فأنت تدفع ثمن إمكانية «التلصص» بمدة أطول.
استنتاج عملي: اكتشف النموذج الإحصائي الذي تستخدمه أداتك. إذا كان الأفق ثابتًا، فحدد العينة مسبقًا ولا تنظر إلى النتائج (إلا للتحقق الفني، وليس لمعرفة الفائز). إذا كان النموذج تسلسليًّا أو بايزيًّا، فيمكنك الاطلاع على النتائج — لكن عليك مع ذلك الالتزام بالمدة الدنيا، لأن ذلك يحل مشكلة أخرى.
كم من الوقت يجب ترك الاختبار يعمل
حجم العينة هو الشرط الأول. المدة هي الشرط الثاني المستقل — ويجب استيفاء كلا الشرطين.
والسبب بسيط: يتصرف الناس يوم الاثنين بشكل مختلف عن يوم السبت، وفي الصباح بشكل مختلف عن الليل، وقبل يوم الدفع بشكل مختلف عنه بعده. إذا استمر الاختبار لمدة ثلاثة أيام، فستكون قد قمت بالتحسين بناءً على ثلاثة أيام محددة.
ما توصي به المصادر الأساسية:
- Optimizely: «يجب إجراء جميع الاختبارات لمدة لا تقل عن دورة عمل واحدة (سبعة أيام) لمراعاة جميع أنواع سلوك المستخدمين.» دورة عمل واحدة على الأقل، أي سبعة أيام.
- GrowthBook: اترك التجربة تعمل لمدة أسبوع إلى أسبوعين على الأقل لالتقاط التباينات في عدد الزيارات؛ كما تنصح بتوخي الحذر خلال أيام العطلات.
- Google Ads (للتجارب المتعلقة بالحملات الإعلانية): يوصي بإبقاء التجربة قيد التشغيل لمدة 4 إلى 6 أسابيع على الأقل، لجمع بيانات كافية للتقييم؛ وإذا لم تكن البيانات كافية حتى بعد ذلك، فيجب تعديل الميزانية أو تمديد المدة.
وينبثق عن ذلك ثلاث قواعد عملية:
- دائمًا أسابيع كاملة، وليس «10 أيام». أنهي الاختبار في نفس اليوم من الأسبوع الذي بدأ فيه — وإلا فستكون قد أعطيت وزنًا زائدًا ليوم واحد في الأسبوع.
- الحد الأدنى هو أسبوع إلى أسبوعين حتى في حالة ارتفاع عدد الزيارات. حتى لو جمعت العينة في غضون يومين، دع الاختبار يستمر لمدة أسبوع كامل.
- إذا تجاوزت مدة الاختبار ~6 أسابيع، فلا تبدأ الاختبار بهذه الصيغة. فالاختبارات الطويلة تتأثر بالانحرافات الموسمية، وانتهاء صلاحية ملفات تعريف الارتباط، والتغييرات في الحملات التسويقية، وإعادة تصميم مواقع المنافسين. بدلاً من ذلك، قم بزيادة MDE (اختبر تغييرًا أكثر جرأة)، أو انقل الاختبار إلى صفحة ذات عدد زيارات أعلى، أو غيّر المقياس المستهدف إلى التحويل الجزئي.
تأثير الحداثة وتأثير الريادة
ظاهرتان تشوهان النتيجة في بداية الاختبار بالذات — أي بالضبط في الوقت الذي تكون فيه رغبتك في إعلان فوزه في ذروتها.
تأثير الحداثة (novelty effect) هو ميل الناس إلى الاستجابة بشكل إيجابي تجاه أي شيء جديد. قد تعمل النسخة الجديدة بشكل أفضل في البداية لمجرد أنها جديدة؛ ومع مرور الوقت، يتلاشى هذا التأثير وينخفض الأداء. توصي GrowthBook كإجراء وقائي بإبقاء الاختبار قيد التشغيل لفترة أطول، أو تطبيق التغيير تدريجيًا (staggered rollout)، وتتيح في أداةها إمكانية تأجيل قياس المقاييس لعدة ساعات أو أيام بعد التعرض.
أما «تأثير الأسبقية» (primacy effect) فهو عكس ذلك: لدى المستخدمين الحاليين أنماط استخدام راسخة، وتؤدي النسخة الجديدة في البداية إلى إبطاء أدائهم، مما يجعل الخيار يبدو أسوأ مما هو عليه في الواقع. الحل وفقًا لـ GrowthBook: توجيه التجربة أو تقسيمها لتقتصر على المستخدمين الجدد الذين لم تتأثر تجربتهم بالإصدار السابق.
كلا التأثيرين يشيران إلى نفس النقطة — لا تستخلص استنتاجات من الأيام الأولى.
كيف تكتب فرضية
الاختبار بدون فرضية ليس تجربة، بل مجرد تخمين باستخدام لوحة المعلومات. الفرضية هي ما يحدد ما إذا كنت ستتعلم شيئًا من الاختبار حتى لو فشل.
يذكر موقع GrowthBook أن الفرضية الجيدة يجب أن تكون محددة وقابلة للقياس وذات صلة وواضحة وبسيطة وقابلة للتفنيد — أي يجب أن يكون هناك نتيجة تدحضها.
القالب
نظرًا لـ [ملاحظة مستمدة من البيانات أو من أبحاث المستخدمين]،
نفترض أن [تغييرًا معينًا]
سيؤدي إلى [اتجاه التغيير وحجمه التقريبي] في [المقياس الأساسي]
لدى [الشريحة / الصفحة]،
وذلك بسبب [الآلية — سبب نجاح ذلك].
إذا لم يتأكد ذلك، فسنستنتج أن [ما الذي ينبثق عن ذلك بشأن عملائك].
السطر الأخير هو الذي تتجاهله معظم الشركات، وهو بالذات ما يجعل الاختبار الفاشل اختبارًا فاشلًا مفيدًا.
أمثلة
فرضية خاطئة:
«سنغير لون الزر إلى البرتقالي، فهو يبرز بشكل أفضل.»
لماذا هي فرضية خاطئة: لا تستند إلى أي ملاحظة، ولا تحدد مقياسًا، ولا تحدد حجم التأثير، ولا يمكن تعلم أي شيء منها. إذا نجحت، فلن تعرف السبب. وإذا فشلت، فلن تعرف السبب.
فرضية خاطئة (نسخة خادعة):
"سنعيد تصميم صفحة المنتج لتكون أكثر حداثة وموثوقية، مما سيؤدي إلى زيادة معدلات التحويل."
لماذا هي فرضية سيئة: إنها تغير عشرة أشياء دفعة واحدة. إذا نجحت، فلن تعرف أي منها كان السبب — ولن تتمكن من تطبيق ذلك في أي مكان آخر. (هذا لا يعني عدم اختبار إعادة التصميم؛ بل يعني أن تختبرها كاختبار URL مقسم بهدف «عدم التسبب في تدهور الأداء»، وليس كتجربة تعليمية.)
فرضية جيدة:
نظرًا لأن 41% من زوار صفحة المنتج في تسجيلات الجلسات يقومون بالتمرير إلى قسم الشحن ثم يعودون إلى الأعلى،
نفترض أن عرض موعد التسليم وتكلفة الشحن مباشرةً أسفل زر «إضافة إلى سلة التسوق»
سيزيد معدل الإضافة إلى سلة التسوق بنسبة 1 نقطة مئوية على الأقل (من 8,2 % إلى 9,2 %)
لدى زوار صفحات المنتجات على الأجهزة المحمولة،
لأن معلومات الشحن هي عامل حاسم يضطرون إلى البحث عنه حاليًا، مما يؤدي إلى فقدان جزء منهم في هذه المرحلة.
وإذا لم يتأكد ذلك، فسنستنتج أن الشحن ليس العائق الرئيسي في هذه الخطوة وسنبحث عن العائق في مكان آخر (السعر، التوافر، المصداقية).
لاحظوا: الملاحظة، التغيير المحدد، المقياس المحدد، MDE القابل للقياس الكمي (الذي يمكن من خلاله حساب العينة)، الشريحة، الآلية، والدروس المستفادة من الفشل.
من أين نستمد الفرضيات
لا تُبتكر الفرضيات في اجتماعات العمل. المصادر التي تثبت فعاليتها في الممارسة العملية:
- تسجيلات الجلسات وخرائط الحرارة. أين يتوقف المستخدمون، وأين ينقرون على عناصر غير قابلة للنقر، وأين يعودون. Microsoft Clarity هي خدمة مجانية بشكل دائم وفقًا لوثائق Microsoft، وتقدم تسجيلات الجلسات، وخرائط الحرارة، وتتبع الأحداث والمسارات. أصبح Hotjar اليوم جزءًا من Contentsquare.
- مسارات التحويل في GA4. أين يتسرب بالضبط أكبر نسبة من المستخدمين.
- البحث الداخلي على الموقع. ما الذي يبحث عنه المستخدمون ولا يجدونه.
- دعم العملاء والمبيعات. الأسئلة المتكررة تمثل ثغرات في محتوى الموقع.
- Search Console. الاستعلامات التي تصل إلى الموقع، لكن الموقع لا يقدم إجابات لها — هناك تداخل كبير هنا مع تحسين محركات البحث (SEO).
- استعلامات البحث ونصوص الإعلانات في PPC. إذا نجح شيء ما في إعلانات PPC، فهو مرشح لعنوان الصفحة المقصودة.
لا تجري كل من Clarity وContentsquare وGA4 اختبارات A/B — فهي أدوات لاكتشاف الفرضيات. الفرق جوهري، وغالبًا ما يتم التبسيط بينهما في النصوص السلوفاكية.
ما الذي يجب اختباره حسب نوع الموقع
دعونا نتوقف عن قول «اختبروا الأزرار». فيما يلي فرضيات محددة مرتبة حسب المكان الذي يحدث فيه أكبر قدر من فقدان القيمة في نوع الموقع المعني.
المتجر الإلكتروني
يتمتع المتجر الإلكتروني بأكبر عدد من الزيارات وأقصر وقت استجابة، لذا يمكن إجراء أكبر عدد من الاختبارات فيه. مرتبة حسب التأثير الأكبر:
صفحة الدفع وسلة التسوق (أعلى أولوية، وأقل ما يتم اختباره)
- عدد خطوات عملية الدفع: صفحة واحدة مقابل عدة خطوات مع مؤشر للتقدم.
- الطلب بدون تسجيل كخيار افتراضي مقابل عرض التسجيل.
- عرض جميع التكاليف (الشحن، الدفع عند الاستلام) في سلة التسوق مقابل عرضها في الخطوة الأخيرة فقط.
- موضع حقل القسيمة — ظاهر مقابل مخفي تحت الرابط (الحقل الظاهر يدفع بعض الأشخاص للبحث عن القسيمة على جوجل وقد لا يعودون).
- عدد الحقول الإلزامية في نموذج العنوان.
- ترتيب طرق الدفع والتسليم.
صفحة المنتج
- موعد التسليم وتكلفة الشحن بجانب الزر مقابل أسفل الصفحة.
- تعبير عن التوافر بالعدد («3 قطع متوفرة في المخزون») مقابل الحالة («متوفر في المخزون»).
- شريط ثابت يظهر السعر ودعوة لاتخاذ إجراء (CTA) على الهاتف المحمول مقابل عدم وجوده.
- التعليقات فوق الوصف مقابل أسفل الوصف.
- معرض الصور: عدد الصور، الترتيب، الصورة الأولى على خلفية بيضاء مقابل الصورة أثناء الاستخدام.
- البيع التكميلي أسفل الزر مقابل في نهاية الصفحة (راقب أيضًا تأثير ذلك على معدل التحويل، وليس فقط على متوسط قيمة الطلب).
الفئة والقائمة
- الترتيب الافتراضي (الموصى به مقابل الأكثر مبيعًا مقابل أقل سعر).
- الفلاتر المفتوحة مقابل الفلاتر المطوية على الهاتف المحمول.
- عدد المنتجات المعروضة على الشاشة.
- عرض التوفر مباشرةً في مربع المنتج.
الشحن والقواعد
- حد الشحن المجاني: قيمتان مختلفتان (هذا اختبار للهامش، وليس لمعدل التحويل — قم بقياس الربح لكل زائر، وليس التحويلات).
في المتجر الإلكتروني، راقب دائمًا مقياسين على الأقل: المقياس الأساسي (مثل الطلبات المكتملة) ومقياس المراقبة/الحماية (مثل متوسط قيمة الطلب أو الهامش الربحي). الاختبار الذي يزيد عدد الطلبات ويخفض متوسط القيمة بشكل أكبر هو اختبار فاشل يبدو وكأنه ناجح. لذلك، يعرض GrowthBook المقاييس الوقائية بشكل منفصل ولا يدرجها في تصحيحات قيم p، حتى تظل حساسة تجاه الاتجاهات السلبية.
إذا كنت لا تزال في مرحلة إنشاء متجرك الإلكتروني، فمن المفيد التفكير في قابلية الاختبار منذ البداية — وقد تناولنا هذا الموضوع بالتفصيل في مقالنا حول تكاليف إنشاء المتاجر الإلكترونية.
موقع B2B يقدم خدمات
القيد الرئيسي هنا هو قلة التحويلات. لذلك: اختبر التحويلات الصغيرة والتغييرات الكبيرة، ويفضل إجراء عدد أقل من الاختبارات.
- النموذج: 3 حقول مقابل 7 حقول. طريقة كلاسيكية ناجحة، لكن احذر من «حاجز الأمان» — إذا أدى النموذج القصير إلى جذب ضعف عدد العملاء المحتملين بنصف الجودة، فلن تكون قد حققت أي مكسب. قم بقياس العملاء المحتملين المؤهلين، وليس عدد عمليات الإرسال.
- نوع دعوة العمل (CTA): «استشارة غير ملزمة» مقابل «عرض أسعار خلال 24 ساعة» مقابل «أريد إعادة حساب».
- شفافية الأسعار: صفحة تتضمن نطاق الأسعار («من – إلى»، أمثلة نموذجية) مقابل عدم ذكر الأسعار. هذا هو أحد أكبر الاختلافات القابلة للاختبار على مواقع B2B السلوفاكية.
- طول الصفحة: صفحة قصيرة مع CTA في مكان بارز مقابل صفحة طويلة تتضمن العملية، وحالات، وأسئلة وأجوبة، وCTA متكررة.
- الدليل الاجتماعي: شعارات العملاء مقابل النتائج المحددة مقابل التوصيات المذكورة بالاسم. (استخدم التوصيات الحقيقية فقط؛ فالتوصيات المختلقة تشكل مشكلة قانونية وتضر بالسمعة.)
- طريقة الاتصال: نموذج مقابل نموذج + رقم هاتف مباشر + تقويم لحجز موعد.
- المحتوى مقابل الدخول المباشر: عرض مادة قابلة للتنزيل (تقرير تدقيق، قائمة مراجعة) كطريقة تحويل بديلة للأشخاص الذين ليسوا مستعدين بعد للتواصل.
إذا كنت تعمل بدورة طويلة، فقم بربط الاختبار بنظام إدارة علاقات العملاء (CRM). بدون ذلك، فإنك تختبر إرسال النموذج، وليس العمل التجاري. وقد قمنا بتفصيل الآليات ذات الصلة بالقنوات والميزانية في مقالنا حول التسويق عبر الإنترنت للشركات.
الصفحة المقصودة (Landing page) لـ PPC
تعد الصفحة المقصودة أفضل بيئة اختبار متاحة لديك: فأنت تشتري عدد الزيارات، وبالتالي يمكنك توجيهها وتوزيعها.
- توافق العنوان مع استعلام البحث (message match). العنوان الذي يتطابق كلمة بكلمة مع استعلام البحث ونص الإعلان، مقابل العنوان العام للعلامة التجارية. الاختبار الفائز الأكثر شيوعًا على صفحات الدفع لكل نقرة (PPC).
- نموذج التسجيل أعلى الصفحة مقابل نموذج التسجيل بعد عرض الحجج.
- دعوة واحدة للعمل مقابل مسارات متعددة. الصفحة المقصودة ذات الهدف الواحد مقابل الصفحة التي تتيح التنقل إلى الموقع بأكمله (عادةً ما يؤدي التنقل إلى تشتيت الانتباه — لكن تحقق من ذلك).
- طول النموذج مقابل جودة العميل المحتمل.
- عناصر بناء الثقة في دعوة العمل (شهادات الاعتماد، عدد العملاء، الضمان) مقابل عدم وجودها.
- الفيديو مقابل الرسومات الثابتة في قسم «hero».
- السعر المذكور على الصفحة مقابل السعر الذي يظهر بعد الاتصال.
ميزتان خاصتان باختبارات الدفع لكل نقرة (PPC):
- العينة = المال. احسب العدد المطلوب من النقرات واضربه في تكلفة النقرة (CPC). إذا بلغت تكلفة الاختبار 4,000 يورو، ففكر فيما إذا كان من الأفضل اختبار تغيير أكثر جرأة مع تأثير أكبر (MDE).
- لا تخلط بين اختبار الصفحة واختبار الإعلان. إذا كنت تختبر صفحة الهبوط في الوقت نفسه الذي يقوم فيه النظام بتدوير النصوص الإعلانية أو تغيير المزايدة، فلن يكون لديك تجربة نقية. اختبار واحد، تغيير واحد.
- يتمتع Google Ads بآلية خاصة به. تتيح صفحة «التجارب» في Google Ads توزيع الميزانية أو عدد الزيارات بين الحملة الأصلية والتجربة، ومقارنة النتائج خلال فترة محددة. وهي تدعم، من بين أمور أخرى، تنويعات الإعلانات (ad variations)، والتجارب المخصصة (custom experiments — Smart Bidding، وأنواع مطابقة الكلمات المفتاحية، وصفحات الهبوط، والجمهور)، والتجارب الخاصة بـ Performance Max و Demand Gen والفيديو. إذا كنت تختبر شيئًا موجودًا في الحملة (المزايدة، المطابقة، الجمهور)، فقم بذلك في الحملة نفسها، وليس في أداة تحسين معدل التحويل (CRO).
الجانب التقني: ما يجب تجنبه
الوميض (Flicker) (وميض النسخة الأصلية)
تعمل اختبارات A/B على جانب العميل بحيث يتم تحميل الصفحة في حالتها الأصلية ثم يقوم جافا سكريبت بإعادة كتابتها. إذا تم تحميل البرنامج النصي ببطء، فسيرى الزائر النسخة الأصلية لبرهة ثم التغيير. هذا «الوميض» يشوه النتيجة (بعض الأشخاص يغادرون قبل أن يلاحظوا التغيير، والبعض الآخر يلاحظ أن شيئًا ما قد حدث) ويؤدي إلى تدهور السرعة المتصورة.
الحلول: مقتطف مضاد للوميض يتم تحميله بشكل متزامن في <head>، أو الاختبار من جانب الخادم، أو التنفيذ عبر شبكة الحافة/شبكة توزيع المحتوى (CDN). إذا قمت بنشر الأداة عبر مدير العلامات (tag manager) بعد تحميل المحتوى، فمن شبه المؤكد أنك ستواجه الوميض.
عدم تطابق نسبة العينات (SRM)
يحدث SRM عندما تتوقع توزيعًا معينًا لحركة الزوار (مثل 50/50)، لكنك ترى توزيعًا مختلفًا بشكل ملحوظ (مثل 46/54). يقوم GrowthBook بإجراء هذا الفحص تلقائيًا وينبهك عندما تنخفض قيمة p إلى أقل من 0.001 — أي عندما يكون الاختلاف غير محتمل للغاية أن يكون مصادفة؛ من الناحية الفنية، يستخدم اختبار كاي-مربع القياسي الذي يقارن بين توزيع الوحدات المرصودة والوحدات المتوقعة.
يُعد SRM علامة تحذير، وليس مجرد مشكلة شكلية. وهذا يعني أن هناك خللاً ما في التنفيذ (حركة مرور الروبوتات، خطأ في التوزيع العشوائي، إعادة توجيه تفشل على بعض الأجهزة، أو نص برمجي محظور). في مثل هذه الحالة، يوصي GrowthBook مباشرةً بعدم الوثوق بالنتائج، والبحث عن الخطأ وإصلاحه، ثم إعادة تشغيل التجربة من جديد.
تحقق من توزيع الزيارات قبل أن تنظر إلى الفائز. هذه هي «النظرة» الوحيدة التي تعتبر مشروعة دائمًا.
اختبار A/A
قبل إجراء أول اختبار حقيقي، قم بإجراء اختبار A/A — نسختان متطابقتان. يذكر GrowthBook ذلك كنقطة انطلاق موصى بها: فهو يتحقق من أن تطبيقك يقسم حركة الزوار بشكل صحيح ويُنتج نتائج سليمة إحصائيًا.
ما ستكتشفه من اختبار A/A: ما إذا كان التوزيع صحيحًا، وما إذا كانت التحويلات تُقاس بنفس الطريقة في كلا المتغيرين، وما إذا كان هناك أي احتساب مزدوج في أي مكان. وفي الوقت نفسه، ستلاحظ بنفسك مدى تقلب «الفائز» حتى في حالة عدم وجود أي فرق على الإطلاق بين المتغيرات. وهذا هو أفضل «لقاح» ممكن ضد «التلصص».
اختبار A/B وتحسين محركات البحث (SEO): ماذا تقول Google عن ذلك
لدى جوجل وثائق منفصلة حول الاختبار في «Search Central»، ومحتواها محدد بشكل مدهش بالنسبة لتحسين معدل التحويل (CRO).
يُحظر «التخفي» (Cloaking). تُعرّف جوجل «التخفي» في سياسات البريد العشوائي بأنه «عرض محتوى مختلف للمستخدمين ومحركات البحث بهدف التلاعب بترتيب نتائج البحث وتضليل المستخدمين». في سياق الاختبار، يعني ذلك: لا تستبعد Googlebot من الاختبار ولا تعرض له نسخة مختلفة عن تلك المعروضة للمستخدمين. يجب أن يحصل Googlebot على نفس المحتوى الذي يحصل عليه الزائر العادي المندرج ضمن تلك النسخة. وبالمثل، لا يمكن معالجة الإخفاء (cloaking) عبر robots.txt.
استخدموا rel="canonical". توصي Google باستخدام السمة rel="canonical" في جميع عناوين URL البديلة مع الإشارة إلى عنوان URL الأصلي، حتى يكون واضحًا أن النسخة الأصلية هي النسخة المفضلة. وينطبق هذا بشكل خاص على اختبارات عناوين URL المقسمة.
عند إعادة التوجيه، استخدم الرمز 302، وليس 301. إذا كان الاختبار يعيد توجيه المستخدمين من الرابط الأصلي إلى نسخة بديلة، فاستخدم إعادة التوجيه المؤقتة 302، وليس الدائمة 301 — فهذا يشير إلى أن إعادة التوجيه مؤقتة وأن الرابط الأصلي يجب أن يبقى في الفهرس.
لا تستمر في الاختبار إلا للمدة اللازمة. توصي Google بتحديث الموقع إلى النسخة المختارة بعد انتهاء الاختبار وإزالة جميع عناصر الاختبار في أسرع وقت ممكن. فـ«الاختبار» الذي يستمر إلى ما لا نهاية يُعتبر أمرًا مريبًا بالنسبة لمحرك البحث.
Googlebot وملفات تعريف الارتباط. تشير Google إلى أن Googlebot لا يدعم ملفات تعريف الارتباط بشكل عام — وبالتالي، فإنه سيرى فقط نسخة المحتوى المتاحة للمستخدمين الذين يستخدمون متصفحًا لا يقبل ملفات تعريف الارتباط. ضع ذلك في اعتبارك عند التخطيط للاختبار: إذا كانت نسختك تعتمد على ملفات تعريف الارتباط، فلن يراها Googlebot.
من الناحية العملية: لا يمثل الاختبار A/B القياسي على عنوان URL واحد لمدة معقولة مشكلة بالنسبة لتحسين محركات البحث (SEO). تنشأ المشاكل عند إجراء اختبارات URL المقسمة طويلة الأمد بدون تحديد الرابط الأساسي (canonicalization)، وعند استخدام 301 بدلاً من 302، وعند محاولات «استبعاد محركات البحث من الاختبار».
السرعة ومؤشرات Core Web Vitals
كل أداة A/B هي نص برمجي إضافي. إذا قمت بتنفيذها بشكل متزامن (وهو أمر ضروري عند استخدام أداة منع الوميض)، فستؤثر على سرعة التحميل. قم بقياس السرعة قبل وبعد نشر الأداة، وإذا كنت تجري اختبارًا طويل الأمد، ففكر في التنفيذ من جانب الخادم أو على الحافة. ولا تنسَ إزالة البرنامج النصي عندما تتوقف عن الاختبار — فهناك العديد من المواقع التي لا تزال تشغل أداة تحسين معدل التحويل (CRO) من عام 2019، والتي لم يعد أحد يستخدمها.
أدوات اختبار A/B في عام 2026
هذا مجال تتسم فيه معظم المقالات السلوفاكية بأنها قديمة. فيما يلي الوضع الذي تم التحقق منه في 2 أكتوبر 2026.
ماذا حدث لـ Google Optimize
لم تعد Google Optimize و Optimize 360 متاحتين اعتبارًا من 30 سبتمبر 2023. هذه هي الصيغة الدقيقة المأخوذة من دليل Google: «لم تعد Google Optimize و Optimize 360 متاحتين اعتبارًا من 30 سبتمبر 2023.»
ما توصي به Google بدلاً من ذلك: الانتقال إلى تكامل أدوات اختبار A/B من جهات خارجية. ويذكر دليل المساعدة مزودي الخدمة المتعاونين — AB Tasty وOptimizely وVWO — ويضيف أن Google قد أتاحت واجهة برمجة التطبيقات (API) الخاصة بها للجمهور، لذا يمكن دمج أي أداة اختبار A/B مع Google Analytics.
النتيجة بالنسبة للقارئ: إذا قرأت في أي مكان دليلًا يوصيك باستخدام Google Optimize، فهذا الدليل أقدم من ثلاث سنوات ولا يمكن الوثوق به حتى في النقاط الأخرى. لا يمتلك Google Analytics 4 أداة خاصة به لإجراء اختبارات A/B للمواقع الإلكترونية — فهو يُستخدم للقياس، وليس لتقسيم حركة الزوار.
Wingify (نشأت عن اندماج VWO وAB Tasty)
أكبر تغيير في السوق منذ إيقاف Optimize. اندمجت VWO و AB Tasty وأصبحتا تعملان تحت علامة تجارية واحدة هي Wingify. تم الإعلان عن الاندماج في يناير 2026 على مدونة الشركة؛ وفي سبتمبر 2026، تم تقديم المنصة الموحدة والهوية الجديدة والموقع الإلكتروني. كما تم تغيير vwo.com وكذلك النطاق abtasty.com اليوم يعيد التوجيه بشكل دائم (301) إلى wingify.com.
ما تقدمه المنصة وفقًا لموقعها الإلكتروني: ستة مجالات منتجات — التجريب (اختبار A/B، واختبار URL المقسم، والاختبار متعدد المتغيرات)، والتخصيص، والتحليلات، وإدارة الميزات، والتجارة، وتفاعل العملاء. تتوفر نسخة تجريبية مجانية لمدة 30 يومًا دون الحاجة إلى بطاقة ائتمان.
في الإعلان عن الاندماج، ذكرت الشركة أن العلاقات الحالية مع العملاء، والعقود، وقوائم الأسعار، ومستويات الخدمة، والدعم ستبقى دون تغيير. إذا كنت عميلاً حاليًا لإحدى المنصتين، فتأكد من الوضع الحالي مباشرةً معهما — فقد تتغير تفاصيل عملية الترحيل بمرور الوقت.
Optimizely
رائد في هذه الفئة، ويُعرف اليوم باسم Optimizely Agentic Experimentation. من بين أنواع الاختبارات المذكورة صراحةً على صفحة المنتج، ستجد الاختبارات متعددة المتغيرات واختبارات البانديت، كما يتوفر محرر مرئي للويب وحلول من جانب الخادم. تعتمد المنصة على محرك Stats Engine الخاص بها الذي يوفر الاختبار التسلسلي والتحكم في معدل الاكتشاف الخاطئ (false discovery rate)، وهو أكبر ميزة تقنية لها فيما يتعلق بمشكلة «الاطلاع المسبق» (peeking).
لم يتم نشر قائمة الأسعار — لا توجد على صفحة المنتج أي إشارة إلى السعر أو خطة مجانية، بل يوجد فقط نموذج طلب نسخة تجريبية. لن تعرف السعر الفعلي إلا بعد التحدث مع فريق المبيعات؛ توقع أن تكون التكلفة على مستوى المؤسسات.
بغض النظر عما إذا كنت ستستخدم الأداة أم لا، فإن وثائقها تعد واحدة من أفضل المصادر المتاحة للجمهور حول إحصائيات اختبارات A/B، ونوصي بقراءتها حتى لمن يجرون اختباراتهم في أماكن أخرى.
Kameleoon
منصة فرنسية. وفقًا لموقعها الإلكتروني، تدعم الاختبارات A/B، ووضع العلامات على الميزات (feature flagging)، واختبارات البانديت السياقية (التخصيص الديناميكي لحركة الزوار)، وتجارب تجربة المستخدم (UX) لكل من الويب والتطبيقات المحمولة، وتقدم تجارب قائمة على المطالبات (prompt-based) عبر وكيل الذكاء الاصطناعي، وتكتشف تلقائيًا عدم تطابق نسبة العينة (Sample Ratio Mismatch). في مجال الامتثال، تذكر المنصة الامتثال لقوانين GDPR وCCPA وHIPAA، وشهادات ISO 27001 وSOC 2، بالإضافة إلى أداة لإدارة الموافقات. تتوفر نسخة تجريبية مجانية.
بالنسبة للشركات التي تولي أهمية كبيرة لبقاء معالجة البيانات داخل الاتحاد الأوروبي، يُعد الأصل الأوروبي حجة ذات صلة — ولكن تأكد من الشروط الحالية للمعالجة مباشرةً في اتفاقية معالجة البيانات (DPA)، وليس من خلال الصفحة التسويقية.
Convert Experiences
منصة أصغر حجمًا، تضع الخصوصية في المقام الأول عن قصد. وفقًا لموقعها الإلكتروني، تدعم الاختبارات A/B، واختبارات URL المقسمة (إعادة التوجيه)، واختبارات متعددة الصفحات (مسار التحويل الكامل)، والاختبارات متعددة المتغيرات، واختبارات الأسعار، واختبارات «اللص متعدد الأذرع»، والتجارب الكاملة من جانب الخادم باستخدام ستة SDK. وتشير إلى توافقها مع لوائح GDPR وTTDSG وBDSG، واستخدام ملفات تعريف الارتباط الخاصة بالطرف الأول حصريًّا، وخوادمها الموجودة في فرانكفورت، وحصولها على شهادات ISO 27001 وSOC 2 Type 2 وHIPAA وCCPA. تتوفر نسخة تجريبية مجانية لمدة 15 يومًا دون الحاجة إلى بطاقة ائتمان.
يُذكر على الموقع الإلكتروني، اعتبارًا من 2 أكتوبر 2026، أن الباقة الأساسية تبدأ من 399 دولارًا أمريكيًا شهريًّا. الأسعار قابلة للتغيير — يرجى التحقق منها مباشرةً على convert.com قبل اتخاذ القرار.
GrowthBook
منصة مفتوحة المصدر للتجريب وعلامات الميزات وتحليلات المنتجات، تعمل بشكل أصلي على مستودع البيانات (تعمل فوق مستودع البيانات الخاص بك). تتوفر نسخة سحابية مجانية وكذلك نسخة ذاتية الاستضافة بنفس الميزات، 100% ضمن البنية التحتية الخاصة بك.
من الناحية الإحصائية، تُعد هذه الأداة الأكثر شفافية من بين الأدوات المتاحة للجمهور: تستخدم نهج بايز بشكل افتراضي (مع إمكانية تعيين الأولويات الخاصة)، مع محرك تكراري يعتمد على اختبارات t ثنائية العينة، ودعم CUPED لتقليل التباين، واختبارات متسلسلة لمكافحة التلفيق. القيم الافتراضية: قوة 80٪، α = 0,05، اختبار ثنائي الجانب.
لمن: الشركات التي لديها فريق تطوير وترغب في التحكم في البيانات والتتبع الكامل للحسابات. بالنسبة لفريق التسويق الذي لا يضم مطورين، فإن هذه الأداة ليست الخيار الأول — فهي لا تحتوي على محرر مرئي «يعمل بالنقر» كلاسيكي كطريقة عمل أساسية.
PostHog
تحليلات المنتج مع تجارب مبنية على علامات الميزات (feature flags). وفقًا للوثائق، تقوم بتعريف المتغيرات واختيار المقاييس، ويتولى PostHog عملية التوزيع العشوائي وتتبع المستخدمين والتحليل الإحصائي (يدعم كل من النهج البايزي والنهج الترددي). تستفيد التجارب من الأحداث وعلامات الميزات الموجودة لديك بالفعل في PostHog، لذا لن تحتاج إلى تنفيذ جديد لقياس الأداء، وتربط النتائج تسجيلات الجلسات بكل متغير على حدة.
لمن: فرق المنتجات وفرق SaaS التي تستخدم PostHog بالفعل في القياس. لا يُعد هذا الخيار مناسبًا لمتجر إلكتروني يعمل على منصة جاهزة دون مطور.
الاختبار في أنظمة الإعلانات
لا يتم اختبار كل شيء في أداة تحسين معدل التحويل (CRO). إذا كنت تختبر شيئًا موجودًا في حملة إعلانية، فاختبره هناك:
- Google Ads – صفحة «التجارب». حيث يتم توزيع الميزانية أو عدد الزيارات بين الحملة الأصلية والحملة التجريبية، ومقارنة النتائج خلال فترة محددة. تشمل الأنواع: تنويعات الإعلانات (الإعلانات النصية والإعلانات التفاعلية في «Search»)، والتجارب المخصصة (Smart Bidding، وأنواع مطابقة الكلمات المفتاحية، وصفحات الهبوط، والجمهور)، وتجارب «Performance Max»، و«Demand Gen»، وتجارب التطبيقات والفيديو (2–4 أذرع). المدة الموصى بها: من 4 إلى 6 أسابيع.
عند ربط الاختبارات الإعلانية واختبارات الموقع الإلكتروني، هناك قاعدة واحدة: تغيير واحد في مستوى واحد في كل مرة. إذا قمت في الوقت نفسه بتغيير المزايدة في الحملة وتصميم الصفحة المقصودة، فلن تتعلم شيئًا عن أي منهما.
اختبارات A/B في البريد الإلكتروني
للبريد الإلكتروني آليته الخاصة — فأنت تعرف العينة مسبقًا (حجم قاعدة البيانات)، لذا يمكن التخطيط بشكل أكثر دقة مقارنةً بالموقع الإلكتروني.
تتيح Mailchimp، وفقًا لدليلها، في اختبارات A/B عبر البريد الإلكتروني مقارنة العنوان، واسم المرسل (from name)، والمحتوى، ووقت الإرسال، وذلك بما يصل إلى 3 متغيّبات لكل متغير قيد الاختبار. ويمكن اختيار الخيار الفائز تلقائيًا (بناءً على معدل الفتح أو معدل النقر أو الإيرادات الإجمالية) أو يدويًّا استنادًا إلى التقرير. أما في حملات الرسائل القصيرة (SMS)، فيتم اختبار المحتوى فقط.
تنبيه هام: يُعد معدل الفتح (open rate) اليوم مقياسًا غير موثوق به بسبب «حماية الخصوصية في بريد Apple» (Apple Mail Privacy Protection) والآليات المماثلة. اتخذ قرارك بناءً على النقرات، وبشكل أساسي بناءً على التحويلات الناتجة عن البريد الإلكتروني — مما يعني أنه يجب ربط الاختبار بتحليلات الموقع الإلكتروني. وقد تناولنا السياق الأوسع في الدليل الشامل للتسويق عبر البريد الإلكتروني.
الأدوات التي لا تجري اختبارات A/B (ولكن لا تجرِ الاختبارات بدونها)
- Microsoft Clarity — تسجيلات الجلسات، وخرائط الحرارة، وتتبع الأحداث والمسارات التحويلية، وCopilot على البيانات. وفقًا لوثائق Microsoft، فهي مجانية بشكل دائم، دون أي التزام بالانتقال إلى الإصدار المدفوع. أفضل نسبة بين القيمة والسعر لاكتشاف الفرضيات.
- Contentsquare (المعروفة سابقًا باسم Hotjar) — أصبح Hotjar اليوم جزءًا من Contentsquare؛ حيث اندمجت المنصتان في منصة واحدة. تقدم Contentsquare خطة مجانية تشمل 200,000 جلسة شهريًا، وخرائط الحرارة، وإعادة تشغيل الجلسات، والاستبيانات، ومراقبة الأخطاء والأداء، ومسارات التحويل، والتكاملات.
- Google Analytics 4 — القياس، والتجزئة، ومسارات التحويل. لا تحتوي على أداة مدمجة لاختبار A/B للموقع.
لن تعطيك هذه الأدوات إجابة سببية. بل ستقدم لك فرضية يمكنك التحقق منها لاحقًا من خلال الاختبار.
كيف تختار
عملية اتخاذ القرار التي تنجح:
- كم عدد التحويلات التي تحققها شهريًّا؟ إذا كان العدد أقل من ~200 تحويل شهريًّا، فلا فائدة من شراء أداة. استثمر في تسجيلات التفاعلات (Clarity، مجانًا)، واختبار المستخدمين، وإصلاح الأخطاء الواضحة.
- هل لديك مطور؟ إذا لم يكن لديك، فأنت بحاجة إلى أداة مزودة بمحرر مرئي (Wingify، Convert، Kameleoon، Optimizely). أما إذا كان لديك مطور وتريد التحكم في البيانات، فابحث عن GrowthBook أو PostHog.
- ما الذي تختبره في الغالب؟ الصفحات التسويقية والمتجر الإلكتروني → أداة عملاء مزودة بمحرر مرئي. المنتج، الأسعار، الخوارزميات، التطبيق → جانب الخادم / علامات الميزات.
- هل تعالج أداتكم مشكلة «الاطلاع المبكر» (peeking)؟ إذا كانت تستخدم أفقًا ثابتًا، فيجب عليكم ضمان الالتزام بالانضباط بأنفسكم. أما إذا كانت تعتمد نهجًا تسلسليًا أو بايزيًا، فهذا أكثر أمانًا.
- ما هي متطلبات معالجة البيانات؟ إذا كنت بحاجة إلى استضافة في الاتحاد الأوروبي وملفات تعريف الارتباط الخاصة بالطرف الأول، فقم بتضييق نطاق اختيارك وتحقق من اتفاقية معالجة البيانات (DPA).
- جرب الإصدار التجريبي في اختبار حقيقي واحد. ليس على صفحة تجريبية — بل على موقعك، مع عدد زوارك الفعلي.
كيفية تقييم الاختبار وماذا تفعل بالنتيجة
قائمة مراجعة قبل تحديد الفائز
راجعها بالترتيب التالي. إذا فشل أي بند، فلا تقرأ النتيجة.
- هل حققت حجم العينة المخطط له؟ ليس «تقريبًا»، بل نعم/لا.
- هل استمر الاختبار لمدة أسبوع كامل على الأقل، وهل أنهيته في نفس اليوم من الأسبوع الذي بدأ فيه؟
- هل توزيع الزيارات سليم (بدون SRM)؟
- ألم يتم تغيير أي شيء خلال الاختبار — لا المتغير، ولا الهدف، ولا التخصيص، ولا الاستهداف؟ تشير Optimizely في هذا الصدد إلى أن تغيير التجربة أثناء إجرائها قد يؤدي إلى استنتاجات خاطئة.
- هل تزامن الاختبار مع حملة أخرى، أو تخفيضات، أو نشاط علاقات عامة، أو حادث تقني؟ إذا كان الأمر كذلك، فقم بتدوين ذلك وفكر في استبعاد الأيام المتأثرة (ثم قم بتمديد الاختبار لتكملة العينة).
- هل قمت بقياس المقياس الأساسي الذي حددته مسبقًا؟ وليس المقياس الذي حقق أفضل النتائج في النهاية.
- هل تراقب أيضًا المقاييس الوقائية؟
فازت المتغيرات
«فازت» تعني: أنها بلغت عتبة الدلالة المحددة مسبقًا، وحجم التأثير ذو صلة بالأعمال، ولم تتدهور المقاييس الوقائية.
ماذا بعد ذلك:
- قم بتطبيق المتغير بشكل دائم — في الكود، وليس في أداة A/B. إن ترك المتغير الفائز يعمل في أداة الاختبار يمثل دينًا تقنيًا، وتوصي Google صراحةً بإزالة عناصر الاختبار في أقرب وقت ممكن.
- لا ترتكب خطأ الوعد بتحقيق الزيادة المقاسة كنتيجة مستقبلية. فالأثر المقاس هو تقدير مع نطاق ثقة، وعادةً ما يكون الفائدة الحقيقية على المدى الطويل أقل (الانحدار إلى المتوسط، وتلاشي تأثير الحداثة). أبلغوا عن نطاق الثقة، لا عن القيمة النقطية.
- دوّن الآلية، لا النتيجة فحسب. «ساعد عرض موعد التسليم بجوار زر الدعوة إلى اتخاذ إجراء» هو درس عملي — يمكن تطبيقه على الفئات، وسلة التسوق، والبريد الإلكتروني، والإعلانات.
- خططوا للتكرار: إذا كان عرض تكلفة الشحن هو العامل الفائز، فاختبروا صياغته.
خيار خسر
الاختبار الذي خسر ليس اختبارًا فاشلًا — إنه تجنب لتطبيق تغيير كان سيضر بكم. المهم هو استخلاص الدرس منه:
- دوّن ما تم دحضه من خلال هذا الاختبار. وهذا بالضبط الغرض من السطر الأخير في نموذج الفرضية.
- راجع تسجيلات الجلسات الخاصة بالخيار الخاسر. غالبًا ما تكشف هذه التسجيلات أن التغيير لم يكن سيئًا، بل كان معطلاً (زر لا يعمل على iPhone، أو تخطيط متغير عند الأسماء الطويلة).
- انظروا إلى المقاطع — فقد يعني الفشل بشكل عام نجاحًا على الهاتف المحمول وفشلًا كبيرًا على جهاز الكمبيوتر المكتبي.
انتهى الاختبار بالتعادل (الحالة الأكثر شيوعًا)
هذه هي النتيجة التي لا تعرف معظم الشركات كيف تتعامل معها، ولذلك تعلن عنها خطأً على أنها فوز أو خسارة.
النتيجة المتعادلة لا تعني أنه لا يوجد فرق بين المتغيرات. بل تعني أن اختبارك لم يكن دقيقًا بما يكفي للكشف عن الفرق — أو أن الفرق أصغر من الحد الأدنى الملموس (MDE). يصف «GrowthBook» ذلك بدقة: ينتج الخطأ من النوع الثاني بيانات غير حاسمة عندما تبدو البيانات غير حاسمة، ولكن في الواقع يوجد فائز.
إجراء اتخاذ القرار:
- انظر إلى نطاق الثقة للتأثير، لا إلى قيمة p. إذا كان النطاق يمتد، على سبيل المثال، من −3٪ إلى +5٪، فإن الاختبار لا يخبرك بأي شيء — فقد يكون الفرق ضارًا أو مفيدًا. وإذا امتد من −0,5 % إلى +0,8 %، فقد تعلمت شيئًا قيّمًا: لا يوجد تأثير كبير. هذه نتيجة مشروعة وسبب للتوقف عن النظر في هذه الفرضية.
- هل كان MDE الخاص بك واقعيًا؟ إذا كنت تبحث عن +0,2 نقطة مئوية في معدل التحويل البالغ 2٪ مع 5 000 زائر، فإن الاختبار لم يكن له أي فرصة للنجاح. لقد وقعت الخطأ في مرحلة التخطيط، وليس في مرحلة التقييم.
- هل تمدد الاختبار أم لا؟ لا تمدده إلا إذا كنت قد خططت للعينة الإضافية والمدة الجديدة كقرار مستقل — وليس على أساس «سنتركه يعمل حتى يتغير الوضع». هذا هو «التلصص» في أبسط صوره.
- قم بتطبيق البديل الأرخص أو الأفضل من نواحٍ أخرى. إذا كان التأثير على التحويلات صفريًا، لكن البديل الجديد أسرع أو أكثر سهولة أو أسهل في الإدارة، فقم بتطبيقه. الاختبار غير الحاسم هو إذن لاتخاذ القرار بناءً على معايير أخرى.
- سجل ذلك في قاعدة المعرفة. النتائج السلبية والصفرية لها نفس قيمة النتائج الإيجابية — فهي توفر عليك تكرار نفس الاختبار بعد عام.
- اختبروا بجرأة أكبر. إن تكرار سلسلة من الاختبارات غير الحاسمة هو في الغالب إشارة إلى أنكم تختبرون تغييرات صغيرة جدًّا. توقفوا عن التركيز على الفروق الدقيقة في ألوان الأزرار واختبروا نهجًا مختلفًا للصفحة بأكملها.
الشرائح: أين تكمن النتائج الحقيقية
النتيجة الإجمالية هي متوسط مرجح لمجموعات مختلفة. من الضروري النظر إلى ما وراء هذه النتيجة — ولكن مع مراعاة قاعدتين.
ركز على الشرائح التي حددتها مسبقًا (عادةً: الجوال/الكمبيوتر المكتبي، الزائر الجديد/الزائر العائد، مصدر الزيارات، أو فئة المنتج). كل شريحة إضافية تضيفها لاحقًا تمثل اختبارًا إحصائيًا آخر، وكلما أجريت المزيد من الاختبارات، زادت احتمالية العثور على نتيجة عشوائية «ذات دلالة» فيها.
لذلك، لا تعتبر الشريحة أبدًا استنتاجًا نهائيًا، بل اعتبرها فرضية جديدة لاختبار مستقل. إذا فازت إحدى المتغيرات على الهاتف المحمول فقط، فلا تطبقها على الهاتف المحمول بحجة أن «الاختبار أثبت ذلك» — بل قم بإجراء اختبار جديد يستهدف الهاتف المحمول.
التوثيق
احتفظ بوثيقة واحدة مشتركة تحتوي على سجل لكل اختبار: التاريخ من–إلى، عنوان URL، الفرضية (كاملةً، بما في ذلك السطر الأخير)، المقياس الأساسي ومقياس الحماية، حجم العينة المخطط له، حجم العينة الذي تم الوصول إليه، النتيجة مع الفاصل الزمني، القرار والدروس المستفادة. بعد إجراء اثني عشر اختبارًا، سيصبح هذا المستند الوثيقة التسويقية الأكثر قيمة في شركتكم، لأنه يحتوي على الشيء الوحيد الذي يمكن إثباته عن عملائكم.
الأخطاء الأكثر شيوعًا في اختبارات A/B
- حجم العينة صغير جدًّا. هذا هو الخطأ الأكثر شيوعًا على الإطلاق. احسبوه مسبقًا باستخدام الصيغة
n = 16 × p(1−p) / δ²وإذا كانت النتيجة خارج النطاق المطلوب، فلا تبدأوا الاختبار بهذه الصيغة. - مدة قصيرة جدًّا. ثلاثة أيام ليست أسبوعًا. الحد الأدنى هو دورة عمل واحدة (7 أيام) ودائمًا أسابيع كاملة.
- إيقاف الاختبار عند أول «دلالة إحصائية». عند إعادة النظر في النتائج بعد كل ملاحظة، ترتفع نسبة النتائج الإيجابية الكاذبة من 5% إلى 26,1%. إذا كانت الأداة لا تستخدم نموذجًا تسلسليًا أو نموذج بايز، فلا تعيد النظر في النتائج.
- اختبار عدة عناصر في وقت واحد دون خطة. إذا قمت بتغيير العنوان والصورة ودعوة العمل (CTA)، فستكتشف أن «الصفحة الجديدة أفضل»، لكنك لن تعرف السبب — ولن تتمكن من تكرار ذلك في أي مكان آخر.
- تجاهل العوامل الموسمية والحملات التسويقية. مثل «الجمعة السوداء»، والتخفيضات، والحملات الإعلامية الكبيرة، وانقطاع خدمة بوابة الدفع، وموسم العطلات. كل ذلك يشوه النتائج. قم بتسجيل كل ما حدث أثناء الاختبار في سجل الاختبار.
- تجاهل الشرائح — أو العكس، البحث فيها حتى يتم العثور على شيء ما. كلا الطرفين خطأ. حددوا الشرائح مسبقًا واعتبروا الباقي فرضيات.
- تغيير الاختبار أثناء إجرائه. إن تغيير المتغير أو الهدف أو التوزيع أو الاستهداف يؤدي إلى إعادة تعيين صلاحية الاختبار بأكمله.
- مقياس واحد بدون ضوابط. الاختبار الذي يزيد الطلبات ويقلل الهامش هو خسارة متنكرة في ثوب الفوز.
- عدم التحكم في SRM والتذبذب. يمكن لخطأ تقني في التنفيذ أن يولد «فائزًا» بشكل موثوق تمامًا. تحقق دائمًا من توزيع الزيارات قبل قراءة النتيجة.
- الاختبار بدون فرضية. بدون فرضية، لن تستخلص درسًا من النتيجة، بل مجرد رقم.
- تقديم الزيادة المسجلة على أنها ضمان. الزيادة المسجلة بنسبة +12٪ مع نطاق يتراوح بين +1٪ و+23٪ لا تعني «+12٪ إلى الأبد».
- الأرقام المختلقة في التقارير. إذا لم تكن العينة كافية، فاكتب «لا نعرف» — وليس «على الأرجح +8٪». تعتمد مصداقية برنامج تحسين معدل التحويل (CRO) بأكمله على صحة أرقامك.
كيف تبدأ إذا لم تكن تجري اختبارات بعد
خطة واقعية لأول 90 يومًا:
الأسبوعان 1–2 — التحضير للقياس. تحقق من أن التحويلات وأحداث التجارة الإلكترونية قد تم إعدادها بشكل صحيح في GA4. قم بتثبيت Clarity (مجانًا). احصل على الأرقام الأساسية: عدد زيارات الصفحات الرئيسية، ومعدل التحويل، وعدد التحويلات شهريًا. بدون هذه الأرقام، لن تتمكن من حساب العينة.
الأسابيع 3–4 — الفرضيات وتحديد الأولويات. اجمع 15–25 فرضية من التسجيلات ومسارات التحويل والدعم والمبيعات. اكتبها وفقًا للنموذج. احسب العينة المطلوبة لكل فرضية واستبعد تلك التي لا يمكن اختبارها على عدد زياراتك في غضون 6 أسابيع. رتب الباقي حسب التأثير المتوقع وصعوبة التنفيذ.
الأسبوع 5 — الأداة واختبار A/A. اختر الأداة، وقم بتنفيذها، وتحقق من تأثيرها على السرعة، ثم قم بإجراء اختبار A/A. اتركه يعمل لمدة أسبوع وتأكد من أن التوزيع والقياس يعملان بشكل صحيح.
الأسابيع 6–12 — أول اختبارين إلى ثلاثة اختبارات. ليس خمسة. قم بإجراء الاختبار الأول على الصفحة التي تحظى بأكبر عدد من الزيارات والتي تتضمن التغيير الأكثر جرأة من القائمة — فهذا يزيد من فرصتك في جمع عينة ورؤية التأثير. قم بتوثيق كل اختبار.
بعد 90 يومًا، سيكون لديكم عملية فعالة، ونتائج حقيقية تتراوح بين واحدة وثلاث نتائج، والأهم من ذلك — فكرة واقعية عما يمكن وما لا يمكن اختباره على عدد زيارات موقعكم.
إذا لم تكن متأكدًا مما إذا كان حجم حركة المرور على موقعك كافيًا لإجراء الاختبارات، أو إذا كنت ترغب في إعداد عملية تحسين معدل التحويل (CRO) بالكامل بما في ذلك القياس، فاتصل بنا — وسنخبرك بصراحة ما إذا كان إجراء الاختبارات مجديًا أم أنه من الأفضل توجيه أموالك إلى مكان آخر.
الأسئلة الشائعة
ما هو اختبار A/B ببساطة؟ اختبار A/B هو تجربة يتم فيها تقسيم زوار الموقع بشكل عشوائي إلى مجموعتين. ترى إحدى المجموعتين النسخة الأصلية من الصفحة، بينما ترى المجموعة الأخرى النسخة المعدلة. تتصفح المجموعتان الموقع في نفس الوقت، لذا يمكن أن يُعزى الاختلاف في النتيجة إلى التغيير، وليس إلى الظروف المحيطة. إنها الطريقة الوحيدة التي يمكنها إثبات أن التغيير هو الذي تسبب في النتيجة بالفعل.
ما الفرق بين اختبار A/B والاختبار متعدد المتغيرات واختبار URL المقسم؟ يقارن اختبار A/B بين نسختين أو أكثر من تغيير واحد على نفس عنوان URL. أما الاختبار متعدد المتغيرات فيقوم بتغيير عدة عناصر في آن واحد ويختبر جميع تركيباتها لتحديد التركيبة الأفضل وما إذا كانت هناك تفاعلات بين العناصر — ولذلك فهو يحتاج إلى عدد أكبر بكثير من الزيارات. أما اختبار URL المقسم فيقارن بين إصدارات مستضافة على عناوين URL مختلفة، ويُستخدم عند إعادة تصميم الموقع بالكامل.
كم عدد الزوار الذين أحتاجهم لإجراء اختبار A/B؟ يعتمد ذلك على معدل التحويل الخاص بك وعلى مدى صغر الفرق الذي ترغب في اكتشافه. كإرشاد عام n = 16 × p(1−p) / δ² لكل متغير، حيث p معدل التحويل الأساسي و δ التأثير الأدنى المطلق القابل للكشف. عند معدل تحويل يبلغ 2% والهدف هو الكشف عن زيادة إلى 3%، فإن العدد يبلغ حوالي 3,100 زائر لكل متغير. أما إذا كان الهدف هو اكتشاف زيادة تصل إلى 2,4 % فقط، فسيكون العدد حوالي 19 600 لكل متغير. توصي GrowthBook، كقاعدة عامة، بوجود ما لا يقل عن 100 حدث تحويل لكل متغير.
ما هي المدة التي يجب أن يستمر فيها اختبار A/B؟ يجب استيفاء شرطين في آن واحد: جمع الحجم المخطط للعينة والحد الأدنى للمدة. توصي Optimizely بفترة لا تقل عن دورة عمل واحدة، أي سبعة أيام، لالتقاط جميع أنواع سلوكيات المستخدمين. توصي GrowthBook بفترة تتراوح بين أسبوع واحد وأسبوعين. احرص دائمًا على إنهاء الاختبار في نفس اليوم من الأسبوع الذي بدأ فيه. إذا أظهر حسابك أن المدة ستتجاوز ستة أسابيع، فلا تقم بتشغيل الاختبار بهذه الصيغة.
هل يمكنني إيقاف الاختبار عندما يظهر أن الخيار ب هو الفائز؟ لا، إذا كنت تستخدم أداة كلاسيكية (ترددية) ذات أفق زمني ثابت. وقد قدر إيفان ميلر أن معدل النتائج الإيجابية الكاذبة الحقيقي يرتفع من 5% إلى 26,1% عند إلقاء نظرة سريعة بعد كل ملاحظة. فعند إلقاء عشر نظرات سريعة، تكون الدلالة الإحصائية المعروضة بنسبة 1% هي في الواقع 5% فقط. إذا كانت أداتك تستخدم تصميمًا متسلسلاً (مثل Optimizely Stats Engine) أو نهجًا بايزيًا، فلا بأس بالمراقبة المستمرة — ولكن عليك الالتزام بالمدة الدنيا على أي حال.
ما هو الحد الأدنى للتأثير القابل للكشف (MDE)؟ هو أصغر فرق يمكن لاختبارك اكتشافه بشكل موثوق به عند حجم العينة المحدد، ومستوى الدلالة الإحصائية، وقوة الاختبار. كلما كان MDE أصغر، زادت العينة المطلوبة — والعلاقة بينهما تربيعية، لذا فإن التأثير النصف يعني عينة أكبر بأربعة أضعاف. تأكد دائمًا مما إذا كانت الأداة تعمل باستخدام MDE مطلق أم نسبي؛ ففي حالة معدلات التحويل المنخفضة، يكون الفرق هائلاً.
ماذا لو انتهى اختبار A/B بنتيجة غير حاسمة؟ هذه هي النتيجة الأكثر شيوعًا، ولا تعني عدم وجود فرق — بل تعني أن اختبارك لم يتمكن من الكشف عنه. انظر إلى نطاق الثقة للتأثير: إذا كان ضيقًا وقريبًا من الصفر، فهذا يعني أنك توصلت إلى عدم وجود تأثير كبير، ويمكنك استبعاد الفرضية. إذا كان واسعًا، فهذا يعني أن الاختبار لم يكن كافيًا. لا تمدد الاختبار إلا كقرار منفصل مخطط له، ولا تفعل ذلك أبدًا «حتى تتغير النتائج». إذا كان التأثير صفريًّا، فاتخذ قرارك بناءً على معايير أخرى — مثل السرعة، وسهولة الوصول، وصعوبة الصيانة.
ما هي أداة اختبار A/B التي يجب استخدامها بعد انتهاء خدمة Google Optimize؟ لن تكون خدمات Google Optimize و Optimize 360 متاحة اعتبارًا من 30 سبتمبر 2023. توصي Google بالانتقال إلى أدوات طرف ثالث متكاملة، وتذكر في دليل المساعدة كلًا من AB Tasty وOptimizely وVWO؛ وقد أتاحت واجهة برمجة التطبيقات (API) الخاصة بها للجمهور، لذا يمكن دمج أي أداة مع Google Analytics. ملاحظة: اندمجت VWO وAB Tasty في غضون ذلك تحت العلامة التجارية Wingify. ومن الخيارات الأخرى Kameleoon وConvert Experiences، ومن الحلول مفتوحة المصدر GrowthBook أو PostHog. لا تتضمن Google Analytics 4 أداة خاصة بها لإجراء اختبارات A/B للمواقع الإلكترونية.
هل يضر اختبار A/B بتحسين محركات البحث (SEO)؟ لا، إذا تم تنفيذه بشكل صحيح. لدى Google وثائق منفصلة خاصة بالاختبار، وتشترط أربعة أمور: عدم استخدام تقنية الإخفاء (يجب أن يرى Googlebot نفس ما يراه المستخدمون)، واستخدام rel="canonical" التي تشير إلى الرابط الأصلي، واستخدام إعادة التوجيه المؤقتة 302 بدلاً من الدائمة 301، وإزالة جميع عناصر الاختبار في أقرب وقت ممكن بعد انتهائه. تشير Google أيضًا إلى أن Googlebot لا يدعم ملفات تعريف الارتباط بشكل عام، لذا سيرى النسخة المتاحة للمستخدمين بدون ملفات تعريف الارتباط.
ما الذي يجب اختباره أولًا في المتجر الإلكتروني؟ صفحة الدفع وسلة التسوق. فهذه هي المنطقة التي تضم أكبر عدد من العملاء الذين اتخذوا قرار الشراء، وفي الوقت نفسه هي الأقل اختبارًا. على وجه التحديد: عدد خطوات عملية الدفع، وإتاحة الطلب دون تسجيل كخيار افتراضي، وعرض جميع التكاليف في سلة التسوق، ووضوح حقل إدخال القسيمة، وعدد الحقول الإلزامية في نموذج العنوان. أضف دائمًا مقياسًا ثانويًّا إلى المقياس الأساسي — على سبيل المثال، متوسط قيمة الطلب أو الهامش الربحي.
المصادر
- Google Search Central — أفضل الممارسات في اختبار A/B للبحث (اختبار المواقع الإلكترونية) — https://developers.google.com/search/docs/crawling-indexing/website-testing
- Google Search Central — سياسات مكافحة البريد العشوائي في بحث الويب من Google (التخفي) — https://developers.google.com/search/docs/essentials/spam-policies
- مساعدة Google Optimize — لم يعد كل من Google Optimize و Optimize 360 متاحين اعتبارًا من 30 سبتمبر 2023 — https://support.google.com/optimize/answer/12979939
- مساعدة Google Ads — حول صفحة "التجارب" — https://support.google.com/google-ads/answer/10682377
- إيفان ميلر — كيف لا تجري اختبار A/B — https://www.evanmiller.org/how-not-to-run-an-ab-test.html
- إيفان ميلر — حاسبة حجم العينة — https://www.evanmiller.org/ab-testing/sample-size.html
- رونالد ل. واسرشتاين، نيكول أ. لازار — بيان الجمعية الأمريكية للإحصاء (ASA) بشأن قيم p: السياق، العملية، والغرض (الجمعية الأمريكية للإحصاء، 2016) — https://www.amstat.org/asa/files/pdfs/p-valuestatement.pdf
- دعم Optimizely — نظرة عامة على طرق التحليل الإحصائي — https://support.optimizely.com/hc/en-us/articles/39714777161229-Statistical-analysis-methods-overview
- دعم Optimizely — كيف ولماذا تتغير الدلالة الإحصائية بمرور الوقت في تجارب Optimizely — https://support.optimizely.com/hc/en-us/articles/4410289544589-كيف-ولماذا-تتغير-الدلالة-الإحصائية-بمرور-الوقت-في-تجارب-Optimizely
- Optimizely — التجارب على الويب / التجارب القائمة على الوكلاء — https://www.optimizely.com/products/experiment/web-experimentation/
- Wingify — الموقع الرسمي (نتج عن اندماج VWO و AB Tasty) — https://wingify.com/
- مدونة Wingify — VWO و AB Tasty: فصل جديد في تحسين التجربة الرقمية — https://wingify.com/blog/vwo-and-ab-tasty-join-forces/
- Wingify Help — أنواع الاختبارات في Wingify — https://help.wingify.com/hc/en-us/articles/58790466788377-Types-of-Tests-in-Wingify
- Kameleoon — الموقع الرسمي — https://www.kameleoon.com/
- Convert — الموقع الرسمي (Convert Experiences) — https://www.convert.com/
- وثائق GrowthBook — القوة والتأثير الأدنى القابل للكشف — https://docs.growthbook.io/statistics/power
- وثائق GrowthBook — نظرة عامة على الإحصائيات — https://docs.growthbook.io/statistics/overview
- وثائق GrowthBook — أفضل ممارسات التجريب — https://docs.growthbook.io/using/experimentation-best-practices
- وثائق GrowthBook — أساسيات اختبار A/B (تأثير الحداثة والأسبقية، الفرضيات) — https://docs.growthbook.io/using/fundamentals
- وثائق GrowthBook — نتائج التجارب (عدم تطابق نسبة العينات، ومقاييس الحماية) — https://docs.growthbook.io/app/experiment-results
- وثائق PostHog — التجارب — https://posthog.com/docs/experiments
- Microsoft Learn — نظرة عامة على Clarity — https://learn.microsoft.com/en-us/clarity/about-clarity
- Contentsquare — أصبح Hotjar الآن جزءًا من Contentsquare — https://contentsquare.com/hotjar/
- Mailchimp — حول حملات الاختبار A/B — https://mailchimp.com/help/about-ab-testing-campaigns/