في الجزء الأول، بدأنا بمقدمة عن ايش دور مدير المنتجات في الفرق التقنية، كيف نكتب الفرضيات بشكل صحيح، كيف الاختبارات تساعد في اتخاذ القرار، وبعض اطر العمل اللي تساعد في تحديد الاولويات.

وفي الجزء الثاني اتكلمنا عن كيف نشوف القمع او الـFunnel، نفمهم جمهورنا، وكيف نقيس سلوك المستخدمين ونقسهم بناء على الديموغرافية و/او السلوك.

في هذا الجزء، حندخل اعمق في عملية كيف نظهر للمستخدمين تجارب مختلفة وكيف نعمل لهم تعيين على واحدة (او أكثر) من المجموعات اللي قدرنا نحددها (اتكلمنا عن الموضوع بتفصيل اكبر في الجزء الثاني)

كيف وصلنا هنا؟ (مراجعة سريعة جدًا) 🤔

الفرضيات

ذكرنا إطار مهم جدًا يساعدنا في صياغة أي فرضية:

  • لو - If [الإجراء أو التغيير المقترح]: إيش الفعل اللي بنسويه؟
  • إذًا - Then [النتيجة المتوقعة]: إيش التغيير اللي راح نلاحظه بعد هذا الإجراء؟
  • عشان Because [السبب أو الافتراض الأساسي]: ليش نتوقع هذا التغيير؟

استخدام البيانات بشكل فعال

شفنا مع بعض كمان كيف ممكن نستخدم البيانات وكيف نسوي Benchmarking على منصات ومنتجات شبيهة عشان نطلع بأرقام واقعية صحيحة. أتكلمنا أيضا عن كيف ممكن نستخدم منتجاتنا الحالية عشان نطلع أرقام الاستخدام الحالية سواء كانت ديموغرافية او كانت سلوكية باستخدام ادوات مثل Metabase و Mixpanel.

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

بسم الله نبدأ…

أنواع المستخدمين وتقسيمهم 🍱

المستخدمين يختلفوا بحسب معايير كثيرة تطرقنا لها في مقالة سابقة. ولكن، من المهم اننا نعرف ان مين هم الناس اللي نبغاهم يشوفوا التجارب المختلفة؛ هل هم مستخدمين جدد دخلوا للموقع للمرة الأولى؟ ولا هم مستخدمين مشتركين معانا ونحتاج نعرف ايش نوع التجربة اللي حتعزز من استخدامهم للخدمة/التطبيق/المنصة اللي نقدمها؟

هذه الأهداف واختلافها هو محدد كبير لكيف تكون التجربة، فمثلا، لو كان الهدف كيف نزيد معدل التحول للتسجيل، بيكون فيه اختلافات جوهرية عن لو كان الهدف اننا نزيد الاستخدام الأسبوعي للمستخدم الواحد (Weekly Active Users - WAU).

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

عدد الأشخاص المطلوب الاختبار معهم 🧮

الهدف الرئيسي من القسم السابق هو معرفة عدد الأفراد (Sample Size) اللي من الممكن نستهدفه في التجربة اللي حنسويها، هذا بيساعدنا كثير على ادارة التوقعات بشكل صحيح ومعرفة الأعداد المنطقية وكيف نعرف نحسب حجم العينة المطلوبة حتى نقدر ناخذ قرار صحيح.

خلينا ناخذ مثال يوضح لنا الفكرة بشكل أكبر: لنفترض السيناريو الأول، الهدف من التجربة هو زيادة معدل التحول للمستخدمين الجدد على صفحة الهبوط؛ عشان نعرف عدد الأفراد المحتملين في هذا السيناريو، حنرجع للأداة اللي نستخدمها عشان نشوف عدد الأشخاص اللي يشوفوا صفحتنا كل أسبوع. لنفترض ان العدد هو 50,000 مستخدم.

العدد هذا ممكن يزيد او يقل بحسب نوع المستخدمين المراد استهدافهم. فمثلا لو كان المراد استهداف المستخدمين من جنس معين (ذكور او اناث)، من الممكن معرفة هذه المعلومة من منصة الاعلانات وحساب اعداد الزوار شهريا بنفس الطريقة.

والآن، خلينا نشوف السيناريو الثاني: لنفترض ان الهدف هو رؤية اذا كان التغيير للـhero section حيدفع الى مستخدمين مشتركين حاليين من الدخول الى المنصة بشكل أكبر. مما يغير من طريقة حساب عدد الأفراد المحتملين؛ الآن سيتم حساب هذا الرقم عن طريق رؤية عدد المستخدمين الحاليين في المنصة (كحد أعلى)، لنفترض ان منصتنا فيها 8,000 مشترك حالي. وكما نرى هنا، ممكن تتغير الحسبة بشكل جذري، وهذا ممكن يؤثر بشكل كبير جدا على عدة عوامل، منها:

  • نسبة التغيير الأدنى المراد كشفها من التجربة (Minimum Detectable Effect - MDE)
  • نسبة الثقة في النتائج (Statistical Significance)
  • مدة الانتظار بعد اطلاق التجربة (Wait Time)

💡 تعريف نسبة التغيير الأدنى المراد كشفها (Minimum Detectable Effect - MDE): النسبة هذه ترمز الى التغير (سواء ايجابي او سلبي) على نقطة المرجع (Baseline) المراد مننا تتبعها. على سبيل المثال، لو كان عندنا معدل تحول من الدخول الى الصفحة الرئيسية حتى التسجيل بنسبة 20%، هل يهمنا ان نستطيع نكشف عن تغيّر بمعدل 2%؟ أم بمعدل 10%؟ في الحالة الأولى (2%)، سيتطلب الاختبار عدد أكبر لاننا نريد اكتشاف حتى التغيرات البسيطة (دقة أعلى). أما في الحالة الثانية (10%) سيتطلب الاختبار عدد أصغر لاننا نريد اكتشاف فقط التغيرات الكبيرة نسبيا (دقة أقل).

وبعد معرفة الـPopulation Size، خلينا نشوف ايش حجم العينة المطلوب حتى نقدر نحكم على نتائج التجربة؛ لأن من غير الواقعي اننا نتوقع ان جميع المستخدمين المحتملين لازم يجربوا اختبارنا حتى نقدر نحدد نتائج الاختبار. ولهذا السبب، نحتاج اننا نحدد عدد المستخدمين الواقعي اللي من الضروري يجربوا الاختبار لنتمكن من رسم استنتاج صحيح؛ وهذا هو حجم العينة.

تحديد استراتيجية حساب العينة

حجم العينة او الـSample Size هو عدد المتسخدمين المطلوب انه يشوف/يجرب الاختبار اللي طلعناه حتى يمكننا نعمم النتائج على جميع المستخدمين والحكم على نتائج الاختبار.

طريقة أخرى لشرح ليش حجم العينة المطلوب هو:

“كم أقل عدد مستخدمين مطلوب ينهوا تجربتي الجديدة (مثال: رؤية صفحة هبوط) حتى أستطيع الحكم على انها أفضل او أسوأ من القديمة؟”.

تحديد حجم العينة يترتب على أولوياتنا في الاختبار، لأن هنا لازم يصير تنازل بين دقة نتائج الاختبار وبين سرعة التوصل الى نتيجة، خلينا نفهم بمثال متطرف لكل جهة من المعادلة. accuracy vs speed

سرعة النتائج

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

أولوياتنا هنا ستكون كالتالي:

  • تحديد أصغر حجم عينة مطلوب لتشغيل اختبار المنتج بشكل صحي
  • الوصول بشكل سريع لمستخدمين محتملين وعمل اختبارات معهم على أرض الواقع
  • تقليل الدقة المطلوب اكتشافها للتغير من نقطة المرجع (نسبة MDE كبيرة)

في هذا التوجه، الهدف هو الوصول لنتيجة بأسرع شكل ممكن، حتى لو ما كان عندنا يقين بصحة النتائج. قد يكون هذا الأسلوب صحيح في حال كان الرهان على تغيير جذري وسيتسبب بتغيير كبير في نقطة المرجع في نقطة التحول (ولا يهمنا ان كمان التغير بسيط)، فيمكننا بشكل سريع التوصل الى استنتاج يحدد ان كان هذا التغيير الجذري فعلا يحقق النتائج المرجوه او عدمها.

دقة النتائج

في الضفة الأخرى من المجال نجد دقة النتائج. لنتخيل ان من غير الضروري التوصل الى نتائج سريعة، ومن الممكن لنا ان نجري التجربة على أكبر عدد من المستخدمين، بغض النظر عن المدة الزمنية المطلوبة لتحقيق ذلك، والأهم بالنسبة لنا هو أخذ القرار ونحن على يقين تام ان هذا القرار هو فعلا الأفضل من جميع النواحي. بالاضافة الى ذلك، من المهم لنا ان نكون على معرفة بتفاصيل الاختبار والى أي حد غير في نقطة المرجع بشكل دقيق (الى الـ1%). في هذه الحالة، سيكون من المهم ان تكون أولوياتنا كالتالي:

  • تحديد حجم عينة يمكن ان يوصلنا الى نتائج دقيقة
  • عدم محاولة دفع المستخدمين الى تجربة التجربة الجديدة، حتى تكون طبيعية
  • زيادة الدقة المطلوبة (نسبة MDE صغيرة جدا) لاكتشاف كل تغيير في نقطة المرجع

كما نرى، التوجه هنا هو التأكد ان النتائج دقيقة جدا، مما سيتطلب حجم عينة كبير لزيادة الدلالة الاحصائية (Statistical Significance) وبسبب النسبة الصغيرة المراد كشفها في نقطة المرجع (نسبة MDE صغيرة). هذا النوع من التجارب ممتاز جدا لو كان الموضوع مجرد تحسين على نسبة تحول حالية، والنسبة هذه لا نتوقع ان تتغير بشكل كبير او سريع. فيمكننا ان نرسل اختبارنا الى المستخدمين وننساه لمدة شهر او اثنين والعودة اليه في حين وجود نتائج مرضية وليس المقصد هو أخذ قرارات سريعة.

تعريف 💡 الدلالة الاحصائية - Statistical Significance: هل النسبة المؤية للجواب على السؤال التالي: “ما هي فرصة ان الاستنتاج (مثلا: التحسن في معدل التحول) هو مجرد صدفة؟”. في البحوث العلمية، النسبة المقبولة في الغالب تكون 95% او 99% بحسب المجال. في الشركات الناشئة، نسبة أقل قد تكون مقبولة (خصوصا ان لم يكن المجال طبي او يمس حياة البشر بشكل مباشر). مثال الجواب: “نحن متأكدون أن نتائج اختبارنا ليست صدفة بنسبة 99%.”

مثال للتوضيح بين الاستراتيجية

لنعود الى واحد من الأمثلة ونرى الفرق في عدد المستخدمين المطلوبين لانهاء كل تجربة. لنفترض ان عدد المستخدمين الشهري الذي يعرض صفحة الهبوط هو 50,000 مستخدم ولنفترض أيضا ان نسبة التحول الحالية من مجرد عرض الى تسجيل هل حاليا 20%. لنرى الآن كيف تتغير الأعداد بحسب الاستراتيجية المختارة:

  • ما يهم هو سرعة اتخاذ القرار
    • نقطة المرجع: 20%
    • التغير المراد اكتشافه (MDE): 5%
    • الدلالة الاحصائية (Statistical Significance): 80% في هذه الحالة، حجم العينة المطلوب سيكون: 21,000 مستخدم، مما يمكن الحصول عليه في حوالي 10 أيام، بحسب عدد المستخدمين الذي يعرض صفحة الهبوط كل شهر حاليا.

لنرى اختلاف الأرقام في الاستراتيجية الثانية لنفس الاختبار بالضبط، لكن مع نتائج أدق:

  • ما يهم هو دقة الأرقام
    • نقطة المرجع: 20%
    • التغير المراد اكتشافه (MDE): 2%
    • الدلالة الاحصائية (Statistical Significance): 95% في هذه الحالة، حجم العينة المطلوب سيكون: 190,000 مستخدم، مما يمكن الحصول عليه في حوالي 4 شهور، بحسب عدد المستخدمين الذي يعرض صفحة الهبوط كل شهر حاليا.

اذا، حتى ومع تثبيت الاختبار والمنتج، من المهم جدا أن نحدد:

  • عدد المستخدمين الحالي (للتنبؤ بالمدة الزمنية المطلوبة)
  • نسبة الدلالة الاحصائية المريحة بالنسبة لنا لاتخاذ القرار (لا يوجد صح أو خطأ)
  • نسبة التغير المراد لنا اكتشافها (MDE)

ولكن يوجد سؤال غير مجاوب الى الآن… من أين لنا بالـ190,000 والـ21,000؟ كيف استطعنا أن نحسب هذه الأرقام؟ وماهي الدالة المستخدمة؟ وهل يوجد بدائل؟

أسئلة رائعة ومهمة وضروري الاجابة عنها؛ لنكتشف سوية.

البداية والنهاية 🚦

سؤال و جواب قبل التعمق في الموضوع

يوجد سؤال يجب الاجابة عنه قبل التعمق أكثر في موضوع حساب حجم العينة المطلوب لنا الاختبار معه، وهو “متى أبدأ اختبار المنتج اللي صممته؟”، والاجابة سهلة: لو كان عندك كل البيانات المطلوبة (او تعرف ان من الممكن استخراجها بشكل سهل)، ابدأ حالًا!. والمقصود بـ”البيانات المطلوبة” هو التالي:

  1. الفرضية موجودة بشكل واضح والهدف مكتوب فيها ومبني على أرقام واقعية
  2. تم تعريف نوعية المستخدمين المراد استهدافهم (cohorts)
  3. نعرف نقطة البداية (baseline)
  4. تم الاتفاق على استراتيجية السرعة vs. الدقة في اجراء الاختبارات (وتحديد MDE و Stat Sig) أول ما تكون هذه المتغيرات معرفة، وعندك بنية تحتية تدعم الاختبارات على منتجك (لاحقا في هذه القالة)، ابدأ!

حساب حجم العينة

والآن، لنعود الى طريقة حساب حجم العينة المطلوب. يوجد الكثير من الطرق اللي يمكن من خلالها حساب حجم العينة، وهذه الطرق تختلف في السهولة وتختلف في طلباتها بالنسبة للمتغيرات (بعضها يطلب أكثر من الـbaseline, MDE و Stat Sig). بالنسبة لي شخصيا، أكثر طريقة وجدتها مجدية وسهلة الحساب هي استخدام الـSample Size Calculator من Optimizely.

ستستطيع استخدام هذه الأدوات بثقة وسهولة لو تعلمت كيف تعمل (وهذا موضوع تكلمنا فيه انا وعبدالرحمن في احدى حلقات بيفابت، هنا)، ولكن من الممكن أن تبدأ بشكل سريع قبل ان تتعمق في طريقة حساب الأرقام الخام ومعرفة الدوال المتسخدمة (الا لو كنت عالم بيانات، أتخيل انك تدور وتفهم الموضوع جوّك 🧃).

روعة، الآن عندنا النسب معرفة، وعندنا حجم العينة المطلوب، ونعرف كم مدة الاختبار تقريبا. ولكن في بداية هذا القسم، كنا نقول ان من المهم أن تكون لديك “بنية تحتية تدعم الاختبارات على منتجك“، خلينا نشوف ايش معنى هذا الكلام.

اختبر منتجك بدون ما يكرهك مطورو المنتج :) 🔪

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

هل يمكن أن نحقق هذه الرؤية؟

طبعًا! تعرف ايش أكثر شيء يحبه المطور -اتكلم عن لسان مطور حالي في مشاريع جانبية وسابق بدوام كامل-؟

أن يتأكد أن كل سطر كود يكتبه ذو قيمة حقيقية.

لو ما كان هذا أكثر شيء يحبه أحد المطورين في فريقك، دوّر مطور يؤمن بالمنتج أكثر…

ولكن دائما ما يكون من الصعب جدا تطبيق هذا المبدأ، في نهاية اليوم، من المهم (وقد تكون الأولوية الأولى) أن نطلق خواص بشكل سريع. بالإضافة الى ذلك، النقطة الأساسية من انشاء الاختبارات هو اننا سنقتل الخاصية/التجربة الأسوأ أداء، فمن الطبيعي أن يكون هناك نوع من المقاومة من طرق مطوري التطبيق، لأننا حاليا نناقض المبدأ الذي بنيناه سوية للتو، مئات (او آلاف) الأسطر سيتكون دون قيمة أو فائدة، بل انها ضرر على كود المنتج لأنها الآن تعتبر أكواد تم اقالتها (Deprecated) وتكون يتم النظر اليها بشكل سلبي لأنها استلاف تقني يجب التخلص منه في أقرب فرصة ممكنة (Technical Debt).

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

البيئة التطويرية المرنة

يمكننا أن نعالج موضوع “قتل الخاصية/التجربة” الأسوأ اداء بسهولة عن طريق بناء توقعات صحيحة من بداية الرحلة. عند العمل على الاختبار، من المهم جدا ان يعلم المطور عن هذا الموضوع، بل ومن المهم أن يتم استشارته في طريقة بناء هذا الاختبار بشكل جيد حتى يمكننا التخلص من النسخة “الاضعف” بشكل سلس وسهل.

بناء هذه التوقعات يساعد جدا على خلق بيئة صحية للتطوير، وارى شخصيا ان هذا النوع من التعاون والوضوح هو دور مدير المنتج بشكل أول؛ اذا لم يكن بامكانك ان توائم توقعات ورؤية جميع افراد الفريق من مطورين، مصممين، وغيرهم من ذوي الصلاحية، داخل الفريق او خارجة، فلم تقم بعملك بشكل جيد!

متى تعرف أن البيئة صحية؟ عندما تسمع هذه المحادثة في المكتب:

  • المطور: “شفت الـexperiment reflection document، شكرا مره على التحليل! أتخيل اننا قررنا ان التجربة الجديدة ما حققت النتائج اللي نتمناها، فهمني صح؟”
  • مدير المنتج: “العفو! صحيح، للأسف التجربة الجديدة ما حققت النتائج اللي كنا كلنا نتمناها، ولكن تعلمنا منها وحاليا بنصمم تجربة جديدة بتكون أفضل.”
  • المطور: “بسيطة درس وتعلمناه، صراحة حتى انا جدا مستغرب تخيلت ان التجربة الجديدة أفضل بكثير… على كل حال، ايش رأيك نضيف Technical Story في الـsprint الجاي عشان انظف الكود وأخلي 100% من المتخدمين يشوفوا التجربة القديمة؟”
  • مدير المنتج: “أكيد! خليني اشرف كيف ممكن نضيف الـStory من دون ما نأثر في الـroadmap. وأكيد! ما نبغا نضحي بمستخدمين أكثر بسبب التجربة، كلامك في مكان 100%، خليني أكتبها وأرسلها لك نراجعها سوا قبل الـplanning الأسبوع الجاي”
  • المطور: “أكيد، شكرا!”

بمجرد ان المطور ومدير المنتج كلهم في نفس الصورة ان التجربة الجديدة أفضل، وبمجرد فشلها وتعلم الدرس منها، الكل سعيد ومتعاون، مافي مجال للملامة او اي احساس سلبي آخر. والكل واضحة معاه الأولويات والكل في نفس الصورة ويعمل لنفس الهدف: “نبني أفضل منتج كلنا نكون فخورين فيه.”

البينة التحتية الداعمة للاختبارات

المعادلة لسيت كلها تواصل و”بس حلينا المشكلة!”. الموضوع يحتوي جانب تقني لابد أن يكون قائم حتى يمكن للمطورين أن يبنوا الاختبارات بشكل سلس وتشغيلها/الغاءها (أو حتى اعطاء هذه الصلاحية لمدير المنتج) بكل يسر وسهولة.

للوصول الى تلك الرؤية، من الضروري وجود العوامل التالية:

  1. استخدام أداة/آلية للتعليم على الميزات (Feature Flagging)
  2. فصل كود النظام عن الكود المستخدم في التحكم بالاختبارات على المنتج
  3. طريقة سهلة للوصول الى بيانات الاختبار ورؤية النتائج (حتى اثناء التشغيل، بشكل حي)
  4. طريقة سهلة للتحكم بدورة حياة الاختبار، من دون التغيير في الكود
  5. آلية واضحة لتوثيق تفاصيل كل الاختبار يمكن الرجوع لها والاستدلال بها

لتحقيق كل من هذه العوامل، من الضروري أن نفهم كل واحدة منها بشكل أعمق

استخدام أداة/آلية للتعليم على الميزات (Feature Flagging)

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

تعريف 💡 أعلام الخواص - Feature Flags فكرة أعلام الخواص بسيطة: آلية تمكننا من التحكم في ظهور الخاصية من عدمه، من غير متطلب التغيير في كود. بالاضافة الى ذلك، تمكننا هذه الآلية من اطلاق الخاصية لعدد معين من المستخدمين، او مستخدمين يستوفون شروط معينة.

تطبيق Feature Flagging mechanism من الصفر عمل طويل ومرهق. فمن باب عدم اعادة اختراع العجلة، نقدر نستخدم أدوات تساعدنا جدا على الوصول الى هدفنا؛ اليك عزيزي القارئ بعض الأدوات المعروفة أو اللي جربتها خلال سنيني في العمل على حلول برمجية:

الأداة 1: Optimizely

قد تكون Optimizely أكثر اداة A/B testing و Feature Flagging معروفة ومتكاملة. بالاضافة الى ذلك، عندهم واحدة من أفضل الـdocumentation (مثال React) اللي ممكن تستخدمها في أي أداة. عندهم أيضا الكثير من التطبيقات والحلول اللي تتكلم بين بعضا البعض بشكل سهل ومريح، فتقدر تستخدم Optimizely echosystem لو كنت محتاج CMS، Feature Flags, A/B tests, Campaign marketing وغيرها من الحلول اللي تساعدك في التسويق أو تتبع أشياء مخلفة من حملاتك الاعلانية أو منتجاتك أو صفحات الهبوط الخاصة بك.

نرجع لموضوعنا الأساسي، الأداة هذه لسيت أفضل أداة لو كانت ميزانيتك محدودة لأن الخواص الموجودة في Optimizely ممتازة ولكنها غالية؛ ولكن ممكن تكون القيمة مبررة مقابل الفائدة، لانهم يوفروا SDKs لأشهر التقنيات وأطر العمل المعروفة (Frameworks)، فتفوز في المقارنة ضد الحلول الأخرى لأنها تختصر الكثير من الوقت.

الأداة 2: GrowthBook

لو كنت من محبين الحلول مفتوحة المصدر (Open source) فستعشق GrowthBook (الكود). الحل ممتاز ويضم العديد من الميزات اللي نحتاجها مثل امكانية تشغيل Feature Flags، A/B tests, وغيرها. اضافة على ذلك، لو كنت لا تفضل ان تقوم باستضافة الحل (host)، فمن الممكن لك أن تقوم باستخدام خدماتهم السحابية والتي توفر لك ميزات تنافس الأدوات والحلول الأخرى.

في سكيلرز نستخدم GrowthBook لتشغيل الاختبارات على المنتج، وكانت من احدى الخيارات التي نرى انها صحيحة. ✅

من أكبر العيوب التي قد تواجهها عند استخدامك GrowthBook هو الدعم الفني، الشركة ليست كبيرة مثل Optimizely فاذا كنت شركة كبيرة وتبحث عن دعم فني احترافي وسريع فمن الأفضل لك أن تختار حل مختلف.

فصل كود النظام عن الكود المستخدم في التحكم بالاختبارات على المنتج

نصيحة مجرب، قم بفصل الكود الأساسي المستخدم في البزنس (Business logic) من الكود المستخدم في تتبع سلوك المستخدم او تشغيل الاختبارات في المنتج. حتشكر نفسك في المستقبل لما ربنا يفتح عليك وتكبر الشركة والـcodebase كثييييير. 🫠

الهدف الأساسي من هذه النقطة هو ان تستطيع أن تحذف الكود الخاص بأي تجربة بعد تحديد “الفائز”. بالاضافة الى ذلك، في حال تريد التغيير في أي تجربة في نصف دورة حياتها، يمكنك الوصول الى الكود بشكل سريع وسهل من دون ترك مجال للخطأ في التغييرات الحاصلة او تغيير كود في مكان غير مقصود (تحصل كثير في حال الفريق يعيد استخدام الكود في اماكن مختلفة -كما يجب 💯-).

لتسهيل هذه العملية، ابدأ بشكل بسيط. ممكن يكون لديك في كل repository مجلد يحتوي على ملفات لكل تجربة منتج. المجلد هذا يحتوي على ملفات JSON او YAML يقوم المطور بكتابة التغييرات على الـUI component او يحدد أي components يعرض على الشاشة من الأساس؛ ويمكن لنا أيضا أن نعرف أي هذه التجارب يعمل الآن وأيها لا يعمل من هذه الملفات.

تكاملا مع النقطة السابقة، يمكن للكود أن يقرأ رقم يصلنا من GrowthBook على سبيل المثال، ويحدد اذا كان من اللازم عرض variant a او variant b للمستخدم

{
  "experiment_name": "best_button_color",
  "variant_a": {
    "description": "Default blue button",
    "color": "#0000FF"
  },
  "variant_b": {
    "description": "Test red button",
    "color": "#FF0000"
  },
  "active": true
}

في المثال السابق، الاخبار يقوم بتجربة تغيير لون الزر لنرى ان كان يؤدي الى معدل تحول أفضل. كل ما يجب فعله الآن هو تحديد التالي:

  • س. هل أعرض للمستخدم الحالي الزر الأحمر أو الأزرق؟
    • ج. يمكن معرفة ذلك برقم معين من GrowthBook (او اي اداة) والتحديد من هناك
  • س. كيف أربط اللون مع اعدادات الزر؟
    • ج. تربط اللون عن طريق كتابة الكود، مافي طريقة سحرية. يجب أن يكون متغير في الـcomponent ويتغير بدلالة القيمة الراجعة من الأداة المستخدمة، ومن ثم تمرير هذه القيمة (اللون) الى اعدادات الزر

⚠️ نقطة مهمة عند عمل تسطيب (setup) للاختبار على الاداة المختارة (Growth, Optimizely, او غيرها)، من المهم أن تكون الاختبارات كلها تتطابق مع الاختبارات الموجودة في الكود. وهذا جزء أساسي من المنطق الذي سيتم عرض الاختبارات بناء عليه.

في حال كثرت الاختبارات وصار المجلد كبير والتحكم فيه صعب، ويريد فريق المنتج أن يقوم بتغيير اللون و/أو زيادة متغيرات أخرى، من الأسهل أن تكون هناك أداة تساعدنا على التحكم والتتبع بشكل أفضل من دون تغيير الكود بشكل كبير. أدوات مثل ConfigCat تساعد في ذلك، ولكن لا أنصح أن يكون هذا هو الخيار الأول (الا لو كنت بمعرفة تامة بما تعمل).

بالاضافة الى ذلك، الكثير من الأدوات الموجودة تدعم أن تحتفظ بالبيانات التعريفية والمتغيرات للاختبار في الأداة نفسها. فاذا كنت تحتاج، تستطيع أن تقوم باضافة المطلوب في بيانات الاختبار نفسه في GrowthBook او Optimizely وتمرير هذه المعلومات من الأداة نفسها، مما يمحي الحاجة لأداة اضافية.

طريقة سهلة للوصول الى بيانات الاختبار (بشكل حي)

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

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

لعمل ذلك، لابد ان نتتبع سلوك المستخدم في المنتج؛ وهذا موضوع قد يكون سلسلة مستقبلية بذاته. ولكن لغرض التوضيح، من الممكن لنا ان نعتبر ان المنتج الحالي يحتوي على تكامل وربط بين جميع الضغطات والتحركات على المنتج مع Mixpanel.

في هذه الحالة، يوجد لدينا خيارين:

  1. اضافة حقل في جميع الـevents الصادرة من المنتج نفسه تحتوي على معلومات الاختبار (القادمة من أداة الاختبار نفسها)
  2. اذا كانت الأداة تدعم، يمكن لنا عمل اختبار (Experiment) مما يسهل لنا الكثير من الحسابات المستقبلية -مثال: الخطوات لعمل اختبار في Mixpanel-

تدعيم فريق المنتج بهذا النوع من البيانات يسرع ويزيد من مصداقية البيانات لدى الفريق. العمل الأولي لهذا النوع من الدعم في الكود الحالي ليس سهل، ولكن بعد ما تكون البنية التحتية موجودة، تسهل الكثير من الأمور بعد ذلك ودائما تكون تستاهل الاستثمار فيها.

طريقة سهلة للتحكم بدورة حياة الاختبار، من دون التغيير في الكود

فالغالب هذه خاصية تكون ضمنية في الأداة التي تقوم بتعريف الاختبارات فيها (Optimizely, GrowthBook، او غيرها). ولكن للتأكيد، من المهم جدا أن يكون بامكان الفريق تشغيل و/او ايقاف الاختبارات في أي وقت من دون الحاجة الى عمل تغييرات في الكود واطلاقه.

قد يكون الدعم لهذه الخواص غير مباشر، ولكن في حال كان يمكن تغيير نسبة العرض بين المتغيرات (variants)، فيمكن أن “تنهي” التجربة بحيث انك تغير التوزيعة بين المتغيرات الى 0% // 100%، مما ينهي احتمالية عرض أي مستخدم جديد للمتغير الأول في اختبارنا (لأن النسبة 0%).

آلية واضحة لتوثيق تفاصيل كل الاختبار يمكن الرجوع لها والاستدلال بها

سواء كنت تستخدم Notion، Confluence, Word, Google Docs، أو حتى تكتب تفاصيل الاختبارات في Github، لازم يكون عندكم نموذج توثيق وتشغيل الاختبارات اللي تطلق على المنتج.

بس للتأكيد: لازم يكون موجود.

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

  • النظرية
  • المراجع التي تم الاستناد عليها
  • المتغيرات المؤثرة على النظرية بأنواعها (dependent / independent / confonuding)
  • أنواع المستخدمين
  • نسبة الثقة المختارة
  • الصفحات المتأثرة بالاختبار
  • تاريخ اطلاق الاختبار
  • دليل بأي تغييرات طرأت على الاختبار أثناء التشغيل
  • …الخ

الموضوع مو صعب، ويفرق بشكل كبير في طريقة التواصل بين أعضاء الفريق. اجعل الكتابة عادة عندك في منتجك، ستعود عليك بأضعاف الفائدة. 🧠

الجزء الرابع للسلسلة: كيف أوصل اختباراتي للناس؟ 🚚

في الجزء القادم، أريد ان اتحدث أكثر عن طريقة توصيل الاختبارات للمستخدمين سواء كانت بطرق معروفة مثل الـA/B tests او الـFeature flags. أو طرق أسرع واسهل مثل الـFake doors، عمل خواص ضحلة لا يبدو للمستخدم انها غير متهية، أو حتى عمل اختبارات عن طريق الاتصال على المستخدمين بالهاتف او عمل اجتماع معهم وطريق تتبع البيانات منها واقصاء أي ضوضاء قد تؤثر على نتائج الاختبار (مثال: شخصية المستخدم قوية مما يجعلني أريد تنفيذ طلبه).

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

حاكون ممتن لو ساعدتني على نشر العمل هذا عن طريق ارسال المدونة لاحد ممكن يستفيد منها، فالاخير الهدف هو نشر محتوى عربي تقني بجودة عالية مجانا؛ مساعدتك لي في هذا الهدف يعني لي الكثير. 🐳🍉

//غوني

اترك تعليق

قد يعجبك أيضا