في تجربة التبديل الزمني تتغير النسخة لمجموعة كاملة عبر فترات، وتُقارن وحدات زمنية بدل تقسيم المستخدمين إلى مجموعتين ثابتتين. قد يناسب ذلك الخدمات التي يتداخل فيها أثر المستخدمين. [1]
الخلاصة السريعة
اختر الوحدة بحسب موضع انتقال الأثر، ثم وثق تخصيص النسخ للوقت وحدود الانتقال والإسناد وطريقة تلخيص النتائج؛ التبديل وحده لا يثبت صلاحية المقارنة.
- تفيد الفكرة عندما يؤثر تغيير تجربة شخص في الآخرين عبر مورد مشترك؛ ليست بديلًا تلقائيًا لكل اختبار A/B. [4]
- عرّف وحدة المنطقة والفترة، ولا تعتبر كل طلب فيها تعيينًا مستقلًا للنسخة. [1]
- وثق آلية تخصيص النسخ للوقت؛ يصف مثال DoorDash التاريخي اختيارًا عشوائيًا لكل وحدة زمن ومنطقة. [2]
- قد يستمر أثر النسخة السابقة؛ طول هذا الأثر من افتراضات التصميم، ولا توجد مدة انتقال واحدة مناسبة للجميع. [3]
- سجل وقت التعرض ووقت النتيجة معًا، وحدد قاعدة إسناد الأحداث قبل تشغيل المقارنة.
- متوسط الفترات ومتوسط الطلبات سؤالان مختلفان؛ مثالنا المؤلف يعطيهما اتجاهين وصفيين مختلفين دون إعلان فائز.
- راجع التنفيذ والاستبعادات وطريقة التحليل وعدم اليقين؛ جدول متوازن شكليًا لا يثبت نتيجة سببية.
لماذا قد يتداخل تأثير مجموعتي الاختبار؟
يعرض شرح DoorDash المنشور في 2018 مشكلة اشتراك مجموعتي العملاء في أسطول توصيل واحد: تغيير الطلب في جانب قد يغير ما يتاح للجانب الآخر. لذلك لا يظل أثر التعديل محصورًا في الأشخاص الذين تلقوه، وتحتاج المقارنة إلى تصميم يناسب هذا التداخل. [2]
ولتقريب الفكرة، افترض سوقًا تعليميًا له طلبات ومقدمون للخدمة. إذا غيرت قاعدة تخصيص الموارد لبعض الطلبات، فقد يتغير زمن انتظار طلبات أخرى تشارك المورد نفسه. لا يكفي أن تسمي أصحاب الطلبات مجموعتين منفصلتين إذا كانت أعمالهم تتزاحم على المورد ذاته. هذا وصف لموقف افتراضي يساعد على صياغة السؤال، لا قياس لأثر قاعدة حقيقية.
وتؤكد إرشادات Microsoft أن وحدة التوزيع تحتاج مراعاة تأثيرات الشبكة، وأن تصميم البنية المشتركة قد يمنح مجموعة أفضلية أو يسمح بانتقال أثر التغيير. نأخذ منها أهمية فحص العلاقة بين الوحدات، لا وصفة واحدة لتجميع كل سوق أو منصة أو جمهور إعلاني. [4]
قبل اختيار التبديل الزمني، اكتب أين تتوقع انتقال الأثر: هل يشترك المستخدمون في طابور، أم مورد، أم نموذج يتعلم من نشاطهم؟ ثم حدد ما يمكن تغييره على مستوى المجموعة كلها لفترة. إذا لم تعرف قناة التداخل، فابدأ بفهمها بدل اختيار تصميم معقد لمجرد أن اسمه يبدو أكثر تقدمًا من توزيع الأشخاص على نسختين.
عرّف الوحدة: منطقة في فترة محددة
يعرض دليل Statsig V2 تخصيص النسخ لمجموعات عبر نوافذ زمنية، وتجميع البيانات بحسب هذه النوافذ وتحليلها مع عوامل الزمن وخصائص المجموعة. لا يجعل عدد الطلبات وحده كل طلب وحدة توزيع مستقلة. [1]
نبني من الآن مثالًا مؤلفًا، لا تجربة نفذناها: منطقتان نسميهما شمال وجنوب، وأربع فترات، طول كل منها ساعة، من الثامنة صباحًا إلى الثانية عشرة. نعطي لكل منطقة وفترة مفتاحًا مستقلًا، مثل شمال مع الفترة الأولى. يصبح لدينا ثماني وحدات منطقة وفترة، بينما عدد الطلبات داخل كل وحدة معلومة أخرى لم نحددها في جدول التخصيص.
سنتعامل مع حدود الفترات في هذا المثال على أنها تشمل وقت البداية ولا تشمل وقت النهاية. فالطلب عند التاسعة تمامًا يبدأ في الفترة الثانية، لا الأولى. نستخدم توقيتًا افتراضيًا واحدًا للجدول كله؛ وإذا أردت تحويل الفكرة إلى خطة عمل، فسم المنطقة الزمنية وتاريخ التشغيل في سجلك بدل الاعتماد على ساعة تظهر في جهاز شخص واحد.
هذا التعريف يغير معنى الثبات. في تجربة تحفظ النسخة لكل معرف طوال مدتها، انتقاله بين النسخ قد يخالف الخطة. أما هنا فالنسخة تخص المنطقة والفترة وفق تصميم معلن. رؤية المعرف نفسه في نسختين لا تكفي للحكم بوجود خطأ؛ يلزم أن تعرف أي تصميم تفحص، وما المنطقة والفترة اللتان تخصهما كل مشاهدة قبل مقارنة الصفوف.
فرق بين جدول مكتوب وآلية تخصيص موثقة
في تطبيق DoorDash التاريخي، يختار النظام النسخة عشوائيًا لكل نافذة، ويجري الاختيار للمناطق بصورة مستقلة، بدل الاكتفاء بتناوب حتمي يبدأ بقرعة واحدة. نذكر ذلك مثالًا على آلية التخصيص المعلنة، ولا نزعم أن كل منتج يحمل اسم Switchback ينفذ الجدول بالطريقة نفسها. [2]
جدولنا التالي مكتوب يدويًا للتعليم: للشمال أ ثم ب ثم ب ثم أ، وللجنوب ب ثم أ ثم ب ثم أ. تتساوى أ وب في عدد وحدات الجدول، لكننا لم نجر قرعة أو نحاك آلية توزيع. التوازن العددي هنا خاصية للأسماء التي كتبناها، وليس إثباتًا أن التخصيص عشوائي أو أن ظروف التشغيل متوازنة في واقع لم نقسه.
ومن المفيد ملاحظة أن تكرار ب في فترتين متجاورتين للشمال لا يخالف جدولنا. لا تعني كلمة التبديل أن الحروف يجب أن تكون أ ثم ب بلا أي تكرار في كل تصميم. ابدأ بالآلية المعتمدة قبل تشغيلك، ثم افحص توافق السجل معها؛ لا تصلح الأسماء لاحقًا حتى تبدو متناوبة فتطمس ما كان مخططًا وما حدث فعلًا.
وعند تخطيط تجربة فعلية، افصل جدول التخصيص عن سجل التنفيذ. قد تحدد الخطة نسخة عند وقت معين ثم يتأخر نشر الإعداد أو يقع انقطاع. اكتب الوقت المخطط والوقت الذي بدأ فيه التنفيذ، مع سبب أي اختلاف. هذه التفرقة تحفظ إمكانية مراجعة ما تعرض له المستخدمون، بدل إسناد كل ما وقع في الساعة إلى حرف مكتوب في خطة لم تتحقق منها.
| الفترة | شمال | جنوب |
|---|---|---|
| 08–09 | أ | ب |
| 09–10 | ب | أ |
| 10–11 | ب | ب |
| 11–12 | أ | أ |
احسب زمن التحليل وافحص الأثر المتبقي
يعرّف ملخص بحث بوجينوف وزملائه الأثر الممتد بأنه استمرار تأثير المعالجة في النتيجة عبر الزمن، ويربط التصميم والاستدلال بافتراض مدة هذا الأثر. قرأنا الملخص وبيانات النسخة، لا براهين الورقة؛ لذلك نستعمل التعريف وحدود المسألة دون ادعاء تنفيذ التصميم الأمثل الذي يدرسه البحث. [3]
يتيح Statsig V2 استبعاد بداية النافذة ونهايتها، بخيارات منفصلة للتعرض والمؤشرات. هذه إعدادات، لا تقدير لمدة الأثر المتبقي؛ يجب أن يبرر تصميمك مددها. [1]
في تمريننا فقط، نفترض استبعاد أول عشر دقائق وآخر خمس دقائق من كل نافذة ساعة، فيبقى خمس وأربعون دقيقة. للفترة من الثامنة إلى التاسعة نحتفظ بالمجال من الثامنة وعشر دقائق إلى الثامنة وخمس وخمسين، مع استبعاد لحظة النهاية وفق اتفاقنا. هذا حساب زمني معلن، لا تقدير تجريبي لطول أثر متبقٍ في سوق حقيقي.
لدينا ثماني وحدات، فتبلغ مدتها الأصلية أربعمئة وثمانين دقيقة منطقة؛ نستبعد مئة وعشرين دقيقة منطقة، وتبقى ثلاثمئة وستون. نضيف كلمة منطقة لأن المنطقتين تعملان في الوقت نفسه: الجدول يغطي أربع ساعات تقويمية، لا ثماني ساعات متتابعة. ونطبق الاستبعاد المفترض على كل نافذة في المثال حتى عندما تكرر الحرف؛ لا نقدمه قاعدة واجبة لكل خطة.
احتفظ بوقت التعرض ووقت اكتمال الطلب
أضف إلى بطاقتك هوية المنطقة، وبداية النافذة ونهايتها، والنسخة المخططة والمنفذة، ثم هوية الطلب ووقت تعرضه ووقت نتيجته. السؤال ليس جمع أكبر عدد ممكن من الأعمدة، بل حفظ المعلومات التي تحتاجها لربط الحدث بوحدة معلومة. لا تستبدل وقت اكتمال الطلب بوقت بدايته وتترك اسم العمود كما هو، لأن ذلك يغير السؤال الذي يمكن للسجل الإجابة عنه.
افترض طلبًا في الشمال تعرض للنسخة ب عند العاشرة وخمسين دقيقة، ثم اكتمل عند الحادية عشرة وعشر دقائق بعد بدء نافذة أ في الجدول. لم نكتشف تعارضًا بمجرد اختلاف الحرفين عند هذين الوقتين. نحتاج قاعدة تبين هل يُنسب مؤشرنا إلى وقت التعرض أم إلى وقت الاكتمال، وما حدود متابعة النتيجة التي اختارتها الخطة قبل رؤية هذا الطلب.
وفي هذا المثال، يقع وقت التعرض داخل مجال التحليل الزمني المفترض للفترة الثالثة، بينما يقع الاكتمال في الفترة الرابعة. احتفظ بالوقتين حتى لو كان تقريرك النهائي يحتاج واحدًا منهما. إذا حذفت أحدهما مبكرًا، قد تفقد ما يلزم لتفسير عبور الحدود أو مراجعة سياسة الإسناد. لا نحسم السياسة نيابة عن المحلل، لأن المؤشرات المختلفة قد تحتاج تعريفات مختلفة.
يفصل Statsig V2 إعداد حساب التعرض عن حساب المؤشرات. لذلك راجع مصير النتيجة اللاحقة لتعرض مستبعد، واكتب سياسة الإسناد التي طبقتها؛ لا يكفي نقل مدة الاستبعاد إلى التقرير. [1]
ميز بين متوسط الفترات ومتوسط الطلبات
يشرح مقال DoorDash التاريخي تحليل متوسطات وحدات المنطقة والوقت، وينبه إلى أن الوحدات المتجاورة قد ترتبط، فلا تُعامل كلها كمشاهدات مستقلة تلقائيًا. نأخذ منه ضرورة توافق التحليل مع التصميم؛ لا ننقل طريقته التاريخية بوصفها الاختبار الإحصائي الوحيد، ولا نحسب فاصل ثقة من جدولنا التعليمي الصغير. [2]
ننشئ مثالًا وصفيًا آخر للشمال وحده، مستقلًا عن افتراض الاستبعاد السابق: عدد الطلبات في الفترات الأربع هو مئة، ثم عشرون، ثم مئة، ثم عشرون. ومتوسط زمن الطلب في كل فترة هو عشر، ثم اثنتا عشرة، ثم ست عشرة، ثم عشرون دقيقة. نفترض أن جميع الطلبات المذكورة داخلة في هذا المثال، وأن المتوسطات معطاة كما هي دون تقريب.
للنسخة أ في الفترتين الأولى والرابعة، متوسط متوسطي الفترتين خمس عشرة دقيقة؛ وللنسخة ب في الثانية والثالثة أربع عشرة. لكن جمع دقائق الطلبات ثم قسمتها على عددها يعطي للنسخة أ ألفًا وأربعمئة على مئة وعشرين، أي نحو 11.67 دقيقة، وللنسخة ب ألفًا وثمانمئة وأربعين على مئة وعشرين، أي نحو 15.33. اختلاف الوزن غيّر اتجاه المقارنة الوصفية.
إذن الفرق ب ناقص أ هو ناقص دقيقة عند إعطاء الفترتين وزنًا متساويًا، ونحو زائد 3.67 دقائق عند وزن كل طلب بالتساوي. ليست إحداهما عملية حساب فاشلة؛ إنهما تلخصان البيانات بطريقة مختلفة. اختر المقدار الذي يستهدفه تصميمك قبل مشاهدة الاتجاه، ولا تنتق المتوسط الذي يعلن نتيجة مرغوبة. الأعداد مؤلفة، ولا تثبت أن النسخة ب تحسن الخدمة أو تضرها سببيًا.
| الفترة والنسخة | عدد الطلبات | متوسط الدقائق |
|---|---|---|
| الأولى: أ | 100 | 10 |
| الثانية: ب | 20 | 12 |
| الثالثة: ب | 100 | 16 |
| الرابعة: أ | 20 | 20 |
ما الذي تراجعه قبل إعلان النتيجة؟
ابدأ بتطابق التنفيذ مع الخطة، واكتمال السجلات، وتعريف وحدة المنطقة والفترة، وسياسة الانتقال والإسناد. ثم اسأل عن طريقة التحليل التي تراعي التصميم والزمن وعدم اليقين. كثرة الطلبات لا تعوض غياب هذه التعريفات، كما أن تساوي عدد حروف أ وب لا يثبت أن التعطل أو الطلب أو ظروف اليوم توزعت بطريقة تسمح باستنتاجك المقصود.
تلفت إرشادات Microsoft إلى أن الموارد المشتركة، مثل الذاكرة المؤقتة أو مكونات النموذج، قد تنقل أثر نسخة إلى أخرى أو تمنحها أفضلية غير مقصودة. لذلك راجع حدود التغيير نفسها، لا حدود الخريطة والساعة فقط. إذا تشاركت المناطق موردًا مؤثرًا، فمجرد تسميتها شمالًا وجنوبًا لا يثبت عزلها في الخدمة الفعلية. [4]
واحفظ أي نافذة غير معتادة مع توقيتها وسببها قبل تقرير كيفية التعامل معها. لا تحذف فترة ضعيفة الأداء لأن وجودها يزعج النتيجة، ولا تخلط تغيير قاعدة الاستبعاد بتحديث عادي لاسم التقرير. يمكن للمراجعة أن تنتهي بالحاجة إلى تصميم أو بيانات أفضل؛ هذه نتيجة مفيدة حين تظل مرتبطة بما تعرفه، بدل إعلان فائز من جدول لم يثبت صلاحية المقارنة.
النتيجة المطلوبة هنا فهم الاختيار: إذا كان التغيير يتجاوز الفرد عبر مورد مشترك، فقد يناسبك تخصيصه لوحدات زمن ومنطقة ضمن تصميم مدروس. حدد الآلية والأثر المتبقي والإسناد والمقدار المطلوب تقديره، ثم حلل وفقها. لم نشغل تجربة أو نقدم تصميمًا أمثل أو دلالة إحصائية؛ الجداول والأعداد المعروضة أدوات لفهم القرارات التي يجب توثيقها قبل العمل.
المصادر ومتابعة القراءة
- Statsig: تصميم Switchback V2 (يفتح في نافذة جديدة)docs.statsig.com
- DoorDash: التجارب تحت تأثيرات الشبكة (يفتح في نافذة جديدة)careersatdoordash.com
- بوجينوف وزملاؤه: تصميم تجارب Switchback وتحليلها (يفتح في نافذة جديدة)arxiv.org
- Microsoft Research: تصميم التجربة قبل تشغيلها (يفتح في نافذة جديدة)microsoft.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.