اذهب إلى المحتوى

البحث في الموقع

المحتوى عن 'الاختبار a/b'.

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • لغة Rust
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • مقالات DevOps عامة
  • خوادم
    • الويب HTTP
    • البريد الإلكتروني
    • قواعد البيانات
    • DNS
    • Samba
  • الحوسبة السحابية
    • Docker
  • إدارة الإعدادات والنشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • مقالات عمل حر عامة
  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • العمل الحر المهني
    • العمل بالترجمة
    • العمل كمساعد افتراضي
    • العمل بكتابة المحتوى

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

  • الأقسام
    • أسئلة البرمجة
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات

التصنيفات

  • كتب ريادة الأعمال
  • كتب العمل الحر
  • كتب تسويق ومبيعات
  • كتب برمجة
  • كتب تصميم
  • كتب DevOps

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

تم العثور على 1 نتيجة

  1. توفر اختبارات A / B أكثر من مجرد التحقق الإحصائي بين إجراء وآخر. ويمكن - بل يجب - أن تؤثر على كيفية منح فريقك الأولوية للمشاريع. في كثير من الأحيان، تستخدم فرق العمل اختبار A / B للتثبت من صحة الأفكار السيئة. تقوم بإجراء تغييرات طفيفة وتأمل بأن يُنتج الاختبار نتائج عظيمة. ولكن يمكن لهذه الاختبارات أن تأتي بنتائج عكسية. فالنتائج التي تأتي نتيجة للتغييرات العشوائية (على سبيل المثال: غير ذات أهمية إحصائية) تعطي رؤى غير مفيدة، وحتى النتائج الجيدة ليس من المضمون أن تبقى صحيحة عندما يتم تطبيق المتغيّر الفائز على كامل جمهورك. إذا كنت تلتزم بأفضل ممارسات اختبار A / B وتطرح الأسئلة الصحيحة قبل إجراء الاختبار، فستتعرف على أنواع التغييرات التي تستحق وقتك بالفعل وبالتالي تركز على المشاريع التي ينتج عنها رؤى مفيدة. تأثير القوة الإحصائية هناك الكثير مما كُتب عن أخطاء اختبار A / B المتكررة. الخطأ الأكثر شيوعًا هو إجراء اختبارات ضمن نطاق زمني صغير استنادًا إلى الدلالة الإحصائية. في بعض الأحيان تكون نتيجة الاختبار مهمة نظرًا لوجود تأثير حقيقي، في أحيان أخرى بسبب الزخم الشديد. في النهاية، لا يمكن لعينة عشوائية أن تكون خير تمثيل للشريحة بأكملها. لتتمكن من التفريق بين التأثير و الزخم، لا تحتاج فقط لأهمية إحصائية ولكن أيضًا لقوة إحصائية. إذا كنت تمتلك قوة إحصائية أكبر ستزداد يقينًا بأن التأثير كان حقيقيًا. للحصول على قوة كافية وإجراء الاختبار بشكل صحيح، اسأل نفسك: إلى أي مدى تعتقد أن التغيير سيزيد من مؤشر الأداء الرئيسي (KPI) المصاحب له؟ وقياسًا للتأثير المطلوب، كم من الوقت سيحتاج الاختبار ليمنحك نتائج دقيقة؟ هل النتيجة تستحق الانتظار؟ 1. كم تعتقد أن التغيير سيزيد من مؤشرات الأداء الرئيسية؟ لنفترض أنك تريد تحسين سير عملية الاشتراك. ولديك قائمة من الأفكار وتحاول أن تقرر أي منها ستعمل عليه. أنت لست راضيًا عن واجهة المستخدم، ولكن الصيانة الكاملة لها ستستغرق شهرًا ما بين تصميم و هيكلة. من ناحية أخرى، يمكنك تجربة تغيير نظام الألوان، وهو ما لن تستغرق تجربته وقتًا طويلًا. يعتقد فريق العمل لديك أن إعادة التصميم بالكامل يمكن أن تعزز التحويل ما بين 10٪ إلى 15٪ في حين أن تغيير نظام الألوان قد يعزز ما بين 10٪ إلى 11٪. 2. قياسًا للتأثير المطلوب، كم من الوقت سيحتاج الاختبار ليمنحك نتائج دقيقة؟ خذ إجابتك على السؤال السابق وضعّها ضمن هذا الموقع البسيط، نظريًا ستتكون لديك إحصائيات مهمة، ولكن المنطق الأساسي يقول أنه كلما صغرت النتائج، استغرقت وقتًا أطول لاكتشافها في حين أن النتائج الكبيرة سرعان ما تظهر للعيان. هذه نتيجة مهمة: يُعدّ اكتشاف مفعول التغييرات الصغيرة مكلفًا. ففي مثالنا، يستغرق تغيير نظام الألوان يومين فقط لإنشاءه، ولكننا سنحتاج إلى 24 ضعف البيانات إن أردنا اختبار 1% بالقياس إلى اختبار 5%. 3. هل النتيجة تستحق الانتظار؟ مع أخذ أحجام العينات بعين الاعتبار، يجب أن تنظر في حجم الوقت الذي تحتاجه لإجراء الاختبار لتحقيق نتائج موثوقة. لنفترض أن عدد مرات الاشتراك يصل إلى 600 زيارة في اليوم. وتتطلب إعادة التصميم بشكل كامل يومين لجمع بيانات كافية في حين أن تغيير نظام الألوان سيستغرق وقتًا أطول. وبالتالي، فإن المشروع الأكبر يستغرق 32 يومًا للتطوير والاختبار، في حين أن المشروع الأصغر سيستغرق49 يومًا. كلاهما يأخذ الكثير من الوقت، ولكن لإعادة التصميم إمكانيات أكبر. ركّز على المشاريع ذات الإمكانيات الأكبر في أواخر العام الماضي، كنا نظن أننا قادرون على تحسين سير عمليات الاشتراك. لم يكن شكل صفحة الاشتراك السابقة منظمًا كما يجب (كما هو موضح في خانة "تدفق التسجيل للإدارة" أدناه). لم يتم عرض طرق الإدراج بترتيب يكون ذا صلة بالمستخدمين الجدد. وبما أن تدفق الاشتراك لدينا لا يشهد مئات الآلاف من الزوار، كنا نعلم أن علينا اختبار شيء نظنه أفضل بكثير. أردنا رفع معدلات التسجيل بنسبة 10%. و بعد الحصول على بيانات كافية، نظرنا إلى معدلات الاشتراك بين الإصدارين. وكانت النتيجة مخيبة للآمال، فالفرق بسيط وليس ذو دلالة إحصائية. كان الاختبار سيئًا، ولكن لا بأس. فما زلنا مصممين على استخدام النسخة الجديدة، لأن تجربة الاشتراك كانت ألطف ووضعتنا في وضع أفضل للتكرار والتطوير في المستقبل. ماذا يعني هذا النهج للشركات الناشئة بالنسبة للشركات الصغيرة، فمشاريع التحسين البسيط لا فائدة منها. تستغرق الاختبارات زمنًا طويلًا لإجراءها وتُلهيك عن العمل على المشاريع المهمة. قد ترى تحسنًا طفيفًا، ولكن من المرجح أن ذاك سيدفعك للعمل للوصول إلى الذروة العالمية. و للوصول إليها، تحتاج الشركات الناشئة إلى إجراء تغييرات كبيرة. تقضي الشركات الكبرى الكثير من الوقت في العمل على التدفقات وفهم عملائها. وهي أكثر ملاءمة للتحسينات الصغيرة لأن لديهم عدد الزيارات الكافي لإنهاء الاختبارات بشكل أسرع. بالإضافة إلى ذلك، تحسن بنسبة 1٪ يعني الكثير عندما يكون لديك مئات الآلاف من الزوار يوميًا. بمجرد إجراءك للعديد من الاختبارات الكبيرة، وتمتعك بفهم جيد لعملائك إضافة لحجم زيارات كبير، ستتمكن من العمل على التطويرات الصغيرة. تذكر، لن يُسفر كل اختبار A / B عن النتيجة التي ترجوها. المهم هو أن تحدد هدفك في التحسين وتُدرك كم من الوقت تحتاج إلى إجراء الاختبارات للحصول على النوع المناسب من النتائج. وإلا فإنك تخاطر بإنفاق الكثير من الموارد فقط للحصول على عائد استثماري سيء. ترجمة -وبتصرّف- للمقال The golden rule of A/B testing: look beyond validation لصاحبه Scott Kamino
×
×
  • أضف...