برنامه‌ریزی، تحلیل و عملیات پلتفرم · فصل ۲ — Planning Horizon، Content Gap، Audience، Crisis و Experiment · 206

Trend Observatory: Observation→Hypothesis→Pattern

داده و event دارد اما آن‌ها را به مدل تصمیم، attention، experiment یا platform policy قابل توضیح تبدیل نمی‌کند. موضوع جاری: «Trend Observatory: Observation→Hypothesis→Pattern». می‌تواند برای «Trend Observatory: Observation→Hypothesis→Pattern» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.

خلاصهٔ درس

می‌تواند برای «Trend Observatory: Observation→Hypothesis→Pattern» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.

خروجی این درس

می‌تواند برای «Trend Observatory: Observation→Hypothesis→Pattern» model، signal و guardrail لازم را در یک workflow محدود تعریف و ارزیابی کند.

پیش‌نیازها

PLN-009 PLN-014

1. مسئله واقعی: یک Spike را «Trend» صدا نزن

یک داشبورد در هفت روز اخیر برای یک Topic جهش نشان می‌دهد و در دو ماه قبلی هم دو افزایش کوچک‌تر دیده می‌شود. وسوسه این است که همان لحظه برچسب «روند پایدار» بزنیم و برنامه محتوا یا محصول را تغییر دهیم. مشکل اینجاست که Observation، توضیح احتمالی و Pattern سه لایه متفاوت‌اند. این درس یک Trend Observatory می‌سازد که اجازه نمی‌دهد یک نمودار جذاب مستقیماً به تصمیم تبدیل شود.

2. مرز این درس

خروجی درس Trend Observatory Evidence Ladder v1 است. ما Observation را از منبع و Window مشخص ثبت می‌کنیم، Context و Baseline را می‌سنجیم، Hypothesis و Alternative Hypothesis را جدا می‌نویسیم، سپس Replication، Corroboration و Counter-signal را بررسی می‌کنیم. Anti-newsjacking و Ethical Context Use مالک PLN-014 است؛ طراحی Experiment و Change Isolation مالک PLN-016. این درس هیچ‌کدام را جذب نمی‌کند.

3. Observation فقط چیزی است که واقعاً دیده‌ای

Observation باید قابل اشاره و قابل بازتولید باشد: Query/Topic چیست، در چه Region و Windowی بررسی شده، مقدار Normalized Interest چه بوده و چه زمانی ثبت شده است. جمله «علاقه مردم واقعاً زیاد شده» Observation نیست؛ آن یک Interpretation است. جمله بهتر: «برای Topic X در Region R و Window W، مقدار نرمال‌شده نسبت به Baseline بالاتر ثبت شده است.»

4. Google Trends چه چیزی را نشان می‌دهد و چه چیزی را نه

Google توضیح می‌دهد Trends از نمونه‌ای از جست‌وجوها استفاده می‌کند و نتایج را نسبت به زمان و مکان Query نرمال می‌کند؛ مقادیر مقیاس‌شده‌اند، نه حجم مطلق تقاضا [GT-FAQ]. پس عدد 100 به معنی «100 جست‌وجو» یا «تقاضای مطلق بیشینه در بازار» نیست. این داده یک Observation معتبر برای Interest نسبی است، نه اثبات Intent، Market Size یا Trend پایدار.

5. Baseline و Comparison Window را قبل از داستان‌سازی ثابت کن

یک Spike بدون Baseline فقط یک نقطه برجسته است. همان سیگنال را با دوره قبل، دوره مشابه سال قبل، یا Window مناسب دیگری مقایسه کن. Quick Comparisons در Google Trends همین مقایسه با دوره‌های مرجع را پشتیبانی می‌کند [GT-COMPARE]. اگر نتیجه با تغییر Window ناپدید شود، باید Confidence کاهش یابد؛ نه اینکه Window نامطلوب حذف شود.

6. Region، Query/Topic و Sampling Note جزو Evidence هستند

Signal می‌تواند در یک Region قوی و در Region دیگر صفر باشد. Search Term و Topic نیز معنای یکسان ندارند. بنابراین Region، نوع Query/Topic، Sampling Note و زمان Retrieval باید کنار Observation بمانند. اگر Context عوض شود، Observation جدید است و نباید بی‌صدا با قبلی ادغام شود.

7. از Observation به Hypothesis بپر، نه به Pattern

Hypothesis یک توضیح آزمون‌پذیر برای Observation است؛ برای مثال «افزایش Interest ناشی از ورود یک نیاز آموزشی پایدار است». در همان لحظه Alternative Hypothesis هم بنویس: «افزایش ناشی از یک رویداد خبری یا Seasonality کوتاه‌مدت است». اگر فقط Hypothesis مطلوب را ثبت کنی، Observatory عملاً Confirmation Machine می‌شود.

8. Replication یعنی Signal دوباره دیده شود

برای ارتقا از ONE_OFF، Evidence باید در بیش از یک مشاهده مستقل یا Window مناسب تکرار شود. یک Spike بسیار بزرگ جای چند Observation سازگار را نمی‌گیرد. در این درس عدد جهانی برای تعداد Replication تعیین نمی‌کنیم؛ Rule باید در Context مشخص شود. Fixture آموزشی از تکرارهای صریح استفاده می‌کند تا تفاوت ONE_OFF و EMERGING_PATTERN قابل تست باشد.

9. Corroboration و Counter-signal را هم‌زمان نگه دار

Corroborating Signal می‌تواند یک منبع مستقل یا Measure مکمل باشد که با Hypothesis سازگار است. Counter-signal شواهدی است که با آن ناسازگار یا محدودکننده است. Pattern فقط با جمع‌کردن شواهد مثبت ساخته نمی‌شود؛ شواهد مخالف باید در همان Artifact دیده شوند. حذف Counter-signal یک Failure مستقل است.

10. Seasonality و Trending Now

Trending Now روی Queryهایی تمرکز دارد که اخیراً surge داشته‌اند و Windowهای بسیار تازه تا چند روزه را ارائه می‌کند [GT-NOW]. این برای کشف Observation تازه مفید است، اما ماهیت «recent surge» دقیقاً دلیل آن است که نباید آن را خودکار معادل Pattern پایدار بدانیم. Seasonality، Event-driven spikes و News cycle باید به‌عنوان Alternative یا Counter-evidence بررسی شوند.

11. State machine: ONE_OFF تا STABLE_PATTERN

Observatory پنج State اصلی دارد: ONE_OFF برای مشاهده منفرد، HYPOTHESIS وقتی توضیح ثبت شده اما Evidence تکرار کافی ندارد، EMERGING_PATTERN وقتی Replication/Corroboration ظاهر شده اما هنوز محدودیت مهم باقی است، STABLE_PATTERN وقتی Rule ازپیش‌اعلام‌شده برای تکرار و Context پاس می‌شود، و REJECTED وقتی Evidence مخالف یا تغییر Context توضیح را فرو می‌ریزد. برای Evidence ناقص نیز UNKNOWN، INSUFFICIENT_DATA و STALE_EVIDENCE را حفظ می‌کنیم.

12. Gate تصمیم: قدرت تصمیم از قدرت Evidence بیشتر نشود

STABLE_PATTERN به معنی «حقیقت علّی» نیست. حتی Pattern پایدار فقط اجازه یک Planning Use محدود می‌دهد: مثلاً «این Topic را برای بررسی برنامه‌ای در Horizon بعدی نگه دار». اگر Provenance ناقص، Source stale، Region نامشخص یا Counter-signal حل‌نشده باشد، Decision باید Refresh، Review یا Defer باشد. تمیزی Dashboard مجوز حذف عدم‌قطعیت نیست.

13. مثال کارشده: Topic آموزشی

فرض کن سه Window غیرهم‌پوشان افزایش سازگار نشان می‌دهند، Region ثابت است، Baseline مناسب انتخاب شده، یک Signal مکمل همسو وجود دارد، Seasonality بررسی شده و Counter-signal مهمی دیده نمی‌شود. این Fixture می‌تواند به STABLE_PATTERN برسد، اما Claim محدود است: «Evidence فعلی یک Pattern تکرارشونده Interest را در این Context پشتیبانی می‌کند.» هنوز ادعای User Need، Revenue Impact یا Causality نداریم.

14. Negative Caseها

چهار میان‌بر عمداً رد می‌شوند: 1) یک Spike شدید بدون Replication → ONE_OFF; 2) تغییر Region و ناپدیدشدن Signal → REJECTED; 3) ظهور توضیح Seasonal بدون بازنویسی Hypothesis → HYPOTHESIS و Review؛ 4) حذف Corroboration در حالی که State همچنان STABLE نگه داشته شده → Downgrade. Evidence stale یا Provenance ناقص نیز اجازه Promotion نمی‌دهد.

15. Transfer: وقتی Growth با تغییر Window ناپدید می‌شود

در Transfer همان Topic را با Comparison Window جدید بررسی کن. اگر Growth ظاهری ناپدید شد، Conclusion قبلی را کپی نکن. Baseline، Normalized Signal، Alternative Hypothesis و Pattern State را دوباره محاسبه کن. Contract ثابت می‌ماند؛ Context-specific Evidence عوض می‌شود. این همان نقطه‌ای است که یک Observatory قابل اعتماد از یک Dashboard داستان‌گو جدا می‌شود.

ارزیابی

پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.

PLN-015-AS1 application

Build Trend Observatory Evidence Ladder v1 from the supplied synthetic topic observations. Keep observation, hypothesis, alternative hypothesis, replication, corroboration, counter-signals, seasonality, provenance and pattern state explicit.

lesson ✗AI ✗notes ✗

PLN-015-AS2 diagnosis

A team labels one extreme seven-day spike a stable trend. Identify the failed evidence dimension and the bounded state.

lesson ✗AI ✗notes ✗

PLN-015-AS3 decision

A seasonal counter-explanation appears after two increases. Issue a typed state and finite review action without inventing certainty.

lesson ✗AI ✗notes ✗

PLN-015-AS4 transfer

Change the comparison window so apparent growth disappears. Rebuild baseline, hypothesis/alternative and pattern state rather than copying the baseline conclusion.

lesson ✗AI ✗notes ✗

ملاک‌های ارزیابی (rubric)

A sufficient submission keeps five critical dimensions visible: identity/scope, exact evidence binding, negative/unknown states, bounded pattern decision, and changed-context transfer. Blocking failures include calling a single spike stable, dropping counter-signals, ignoring changed region/window, missing provenance, or making a decision stronger than the evidence.