برنامه‌ریزی، تحلیل و عملیات پلتفرم · فصل ۲ — Planning Horizon، Content Gap، Audience، Crisis و Experiment · 207
Experiment Model و جداسازی Observation/Hypothesis/Change
داده و event دارد اما آن‌ها را به مدل تصمیم، attention، experiment یا platform policy قابل توضیح تبدیل نمی‌کند. موضوع جاری: «Experiment Model و جداسازی Observation/Hypothesis/Change». می‌تواند برای «Experiment Model و جداسازی Observation/Hypothesis/Change» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.
Experiment Model: Separate Observation, Hypothesis and Change — en-US
خلاصهٔ درس
داده و event دارد اما آن‌ها را به مدل تصمیم، attention، experiment یا platform policy قابل توضیح تبدیل نمی‌کند. موضوع جاری: «Experiment Model و جداسازی Observation/Hypothesis/Change».
می‌تواند برای «Experiment Model و جداسازی Observation/Hypothesis/Change» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.
خروجی این درس
می‌تواند برای «Experiment Model و جداسازی Observation/Hypothesis/Change» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.
1. مسئله واقعی: اول نتیجه را دیدیم، بعد داستان ساختیم
یک تیم می‌بیند نرخ تکمیل Landing Page در یک بازه مشخص از 48٪ به 39٪ رسیده است. بلافاصله پیشنهاد می‌شود Headline، Navigation و Signup Form هم‌زمان تغییر کنند. اگر بعد از این بسته تغییرات عدد بهتر شود، دیگر نمی‌توان فهمید کدام تغییر مؤثر بوده یا اصلاً تغییر مشاهده‌شده ناشی از Treatment بوده است. این درس Experiment را از «تغییر بده و بعد توضیح بساز» به یک قرارداد قابل ممیزی تبدیل می‌کند.
2. مرز این درس
خروجی این درس Experiment Hypothesis & Change-Isolation Card v1 است. Observation از درس قبل می‌تواند ورودی باشد، اما Pattern/Trend Discovery مالک این درس نیست. Event/Dimension/Metric-Regime نیز در درس بعدی عمیق‌تر می‌شود. اینجا سؤال محدود است: قبل از Exposure چه چیزی دیده‌ایم، چه فرضیه‌ای داریم، دقیقاً چه چیزی را تغییر می‌دهیم، و چه شواهدی اجازه یک تفسیر علّی محدود را می‌دهند؟
3. Observation را قبل از Hypothesis فریز کن
Observation باید یک گزاره توصیفی باشد: چه Metricی، برای چه Populationی، در چه Windowی و با کدام Query/Instrumentation تغییر کرده است. مثال: «در Fixture مصنوعی، Completion برای کاربران جدید در بازه W2 کمتر از W1 ثبت شده است.» Observation نباید حاوی علت پنهان باشد؛ جمله «Headline باعث افت شده» دیگر Observation نیست، Hypothesis است. Window، Query و Provenance را قبل از طراحی Treatment ثبت کن.
4. Hypothesis باید ابطال‌پذیر باشد
NIST طراحی آزمایش را برنامه‌ریزی از پیش برای تغییر کنترل‌شده Factorها و مشاهده Responseها توصیف می‌کند [NIST-DOE]. یک Hypothesis خوب باید بگوید چه مکانیزمی انتظار می‌رود و چه نتیجه‌ای آن را تضعیف می‌کند. نمونه: «اگر ابهام Headline یکی از علل افت Completion باشد، تغییر فقط Headline به پیام روشن‌تر باید تحت Form و Navigation ثابت، Completion را نسبت به Control بهبود دهد؛ در غیر این صورت این Hypothesis حمایت نمی‌شود.»
5. Treatment Change را ایزوله کن
برای یک سؤال علّی محدود، تغییر هم‌زمان چند متغیر هزینه شناختی بالایی دارد. اگر Headline و Form و Navigation با هم عوض شوند، نتیجه فقط درباره Bundle تغییرات حرف می‌زند. در این درس Treatment اصلی یک تغییر تصمیم‌ساز دارد؛ هر تغییر همراه باید یا ثابت بماند یا صریحاً بخشی از Treatment تعریف شود. اگر Treatment بیش از یک تغییر مستقل دارد، Decision به ISOLATE_TREATMENT برمی‌گردد.
6. Control و Experimental Unit را تعریف کن
Control نسخه‌ای است که Treatment را دریافت نمی‌کند و پایه مقایسه را حفظ می‌کند. Experimental Unit چیزی است که Assignment روی آن انجام می‌شود: User، Account، Session، Device یا Cluster. انتخاب اشتباه Unit می‌تواند همان فرد را از دو مسیر وارد Control و Treatment کند. Card باید Unit، دلیل انتخاب آن و هر محدودیت وابستگی را ثبت کند.
7. Assignment، Randomization و Interference
NIST در Completely Randomized Design تخصیص تصادفی Treatment Levelها به Experimental Unitها را توضیح می‌دهد [NIST-RAND]. در محصول دیجیتال، Assignment ممکن است Randomized یا با Hash پایدار انجام شود؛ مهم این است که Rule قبل از Exposure مشخص باشد و Unitها بین بازوها نشت نکنند. اگر یک User با Identityهای مختلف در هر دو بازو ظاهر شود، Assignment معتبر نیست تا Interference Control تعمیر شود.
8. Primary Metric و Guardrail را قبل از Exposure قفل کن
Primary Metric باید مستقیم به Hypothesis وصل باشد؛ Guardrailها جلوی «بردن» آزمایش با آسیب جانبی را می‌گیرند. برای مثال Primary Metric می‌تواند Completion Rate باشد و Guardrailها Error Rate و Time-to-complete. تغییر Primary Metric پس از دیدن Result، نتیجه را Post-hoc می‌کند. Card باید Metric، Direction، Denominator، Guardrail و نقش هرکدام را پیشاپیش مشخص کند.
9. Sample Plan، Exposure Window و Analysis Plan
این درس عدد جادویی برای Sample Size یا Significance ارائه نمی‌کند. به‌جای آن، Sample Plan باید Population، Unit، حداقل Window و محدودیت‌های عملی را روشن کند و Analysis Plan بگوید چه Comparisonی انجام می‌شود و Uncertainty چگونه گزارش می‌شود. هر Threshold آماری باید متناسب با زمینه طراحی شود؛ نبود آن را با یک عدد عمومی پنهان نکن.
10. Stopping Rule و خطر Peeking
اگر تیم هر چند ساعت Result را ببیند و فقط زمانی Stop کند که Metric مطلوب بالا است، Rule با Result آلوده می‌شود. Stopping Rule باید قبل از Exposure ثبت شود: پایان Window، رسیدن به Sample Plan یا یک Safety Trigger از پیش‌تعریف‌شده. Early Stop فقط وقتی معتبر است که Trigger قبلاً تعریف شده باشد؛ «وقتی عدد خوب شد» Rule نیست.
11. Result با Causal Interpretation یکی نیست
Microsoft Research Controlled/A-B Experiments را ابزار ارزیابی قابل‌اعتماد اثر Product Change معرفی می‌کند و بر طراحی و Randomization تأکید دارد [MS-EXP]. بااین‌حال، یک اختلاف Metric به‌تنهایی مجوز ادعای علّی نیست. Instrumentation، Assignment، Interference، Uncertainty و Ruleهای ازپیش‌تعریف‌شده باید سالم باشند. بنابراین Card دو فیلد جدا دارد: Result (چه دیده شد) و Causal Claim Boundary (حداکثر چه برداشتی مجاز است).
12. Gate تصمیم‌گیری
این جدول چند وضعیت اصلی را نشان می‌دهد. هدف Boolean Pass/Fail نیست؛ وضعیت باید بگوید دقیقاً کدام بخش طراحی سالم یا خراب است و اقدام بعدی چیست.
| case | observation | hypothesis | treatment | assignment | primary_metric | stop_rule | result | state | decision | causal_boundary |
|---|---|---|---|---|---|---|---|---|---|---|
| baseline_ready | FROZEN | PREDECLARED | ONE_CHANGE | VALID | LOCKED | LOCKED | NOT_YET | DESIGN_READY | RUN_BOUNDED_EXPERIMENT | NO_RESULT_YET |
| multiple_changes | FROZEN | PREDECLARED | HEADLINE+FORM | VALID | LOCKED | LOCKED | NOT_YET | DESIGN_REPAIR_REQUIRED | ISOLATE_TREATMENT | BLOCKED |
| peeking_rule | FROZEN | PREDECLARED | ONE_CHANGE | VALID | LOCKED | POSTHOC | PARTIAL | DESIGN_REPAIR_REQUIRED | LOCK_PREDECLARATIONS | BLOCKED |
| identity_interference | FROZEN | PREDECLARED | ONE_CHANGE | CROSS_ARM_LEAK | LOCKED | LOCKED | NOT_YET | DESIGN_REPAIR_REQUIRED | REPAIR_ASSIGNMENT | BLOCKED |
| posthoc_hypothesis | FROZEN | REWRITTEN_AFTER_RESULT | ONE_CHANGE | VALID | LOCKED | LOCKED | AVAILABLE | CAUSAL_CLAIM_BLOCKED | DO_NOT_CLAIM_CAUSALITY | DESCRIPTIVE_ONLY |
| missing_provenance | PARTIAL | PREDECLARED | ONE_CHANGE | UNKNOWN | LOCKED | LOCKED | NOT_YET | UNKNOWN | DEFER_MISSING_EVIDENCE | BLOCKED |
| stale_evidence | FROZEN | PREDECLARED | ONE_CHANGE | VALID | LOCKED | LOCKED | NOT_YET | STALE_EVIDENCE | REFRESH_EVIDENCE | BLOCKED |
| email_transfer_result | FROZEN | PREDECLARED | SUBJECT_ONLY | USER_CLUSTER_VALID | LOCKED | LOCKED | AVAILABLE | RESULT_INTERPRETABLE | REPORT_BOUNDED_EFFECT | BOUNDED_TO_DESIGN |
13. مثال کارشده: Landing Page
Observation فریز شده: Completion کاربران جدید در W2 نسبت به W1 افت کرده است. Hypothesis: ابهام Headline اصطکاک ایجاد می‌کند. Treatment: فقط Headline تغییر می‌کند؛ Form و Navigation ثابت‌اند. Unit: User پایدار. Assignment: Randomized 50/50. Primary Metric: Completion Rate. Guardrail: Form Error Rate. Stop Rule: پایان Window ازپیش‌تعریف‌شده و Safety Trigger. اگر Result همراه با Instrumentation معتبر و Uncertainty گزارش شود، خروجی می‌تواند یک اثر محدود را گزارش کند؛ نه اینکه «Headline همیشه علت افت Conversion است».
14. Negative Caseها
سه میان‌بر عمداً رد می‌شوند: 1) Headline و Form هم‌زمان عوض شوند؛ در این حالت Treatment ایزوله نیست. 2) تیم Result را مکرر ببیند و Stop Rule را بعد از بهبود Metric تنظیم کند؛ Predeclaration شکسته است. 3) همان User با Identityهای متفاوت وارد هر دو بازو شود؛ Assignment و Independence مخدوش است. یک حالت چهارم نیز مهم است: تغییر Hypothesis یا Primary Metric بعد از دیدن Result، که Causal Claim را Block می‌کند.
15. Transfer: تست Subject Line ایمیل
در Email Campaign یک User ممکن است در چند Campaign ظاهر شود. کپی‌کردن Unit صفحه وب کافی نیست. برای Transfer باید Unit و Interference Control دوباره طراحی شوند: مثلاً تخصیص پایدار در سطح User Cluster در Window مشخص، جلوگیری از Cross-arm Exposure، Subject Line به‌عنوان تنها Treatment، Open/Click یا Conversion به‌عنوان Metricهای ازپیش‌تعریف‌شده و Guardrailهایی مثل Unsubscribe. Contract ثابت می‌ماند، اما جزئیات Context از نو محاسبه می‌شوند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
PLN-016-AS1 application
Using the supplied landing-page fixture, build Experiment Hypothesis & Change-Isolation Card v1. Freeze the observation, state one falsifiable hypothesis, isolate the treatment, define control/unit/assignment, predeclare the primary metric, guardrails, exposure/stopping/analysis rules, and state the causal boundary.
PLN-016-AS2 diagnosis
A team changes headline and signup form together, then attributes a positive completion movement to the headline. Identify the exact failed experiment dimension and the bounded repair.
PLN-016-AS3 decision
A team checks the dashboard repeatedly and stops after the preferred metric rises. Issue a typed decision and state what must be locked before a new exposure.
PLN-016-AS4 transfer
Transfer the model to an email subject-line experiment where a user may appear in multiple campaigns. Rebuild the experimental unit, assignment, interference control, primary metric/guardrail, and stopping rule rather than copying the page-test design.
ملاک‌های ارزیابی (rubric)
A sufficient submission keeps five dimensions visible: identity/scope, exact evidence binding, isolation + assignment, predeclared rules + bounded causal interpretation, and changed-context transfer. A blocking failure occurs when observation is rewritten as a cause, more than one treatment variable is silently changed, cross-arm exposure is uncontrolled, a metric/hypothesis/stopping rule is changed after result inspection, or the final claim is stronger than the evidence.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
در همین پوشه python run_checks.py را اجرا کنید. برای هر Case مصنوعی توضیح دهید چرا جداسازی Observation/Hypothesis، ایزوله‌بودن Treatment، Assignment، Predeclaration و Causal Boundary به State خروجی منجر شده‌اند. سپس فقط یک فیلد تصمیم‌ساز را تغییر دهید و دوباره ارزیابی کنید. شبکه یا Credential واقعی لازم نیست.