معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۵ — Editorial Cell، SEO، QA، Approval و Onboarding · 255
Performance Feedback Loop
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Performance Feedback Loop». می‌تواند «Performance Feedback Loop» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خلاصهٔ درس
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Performance Feedback Loop».
می‌تواند «Performance Feedback Loop» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خروجی این درس
می‌تواند «Performance Feedback Loop» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
1) داشبورد بالا رفته؛ آیا واقعاً محتوا بهتر شده است؟
فرض کنید بعد از redesign یک کمپین، نمودار views جهش کرده است. همان هفته tracking هم تغییر کرده، یک page_view دستی روی page_view خودکار اضافه شده و پلتفرم تعریف view را عوض کرده است. اگر فقط عدد dashboard را بخوانیم، ممکن است به «برنده شدن محتوا» برسیم؛ در حالی که بخشی از افزایش، حاصل instrumentation یا تغییر semantics متریک است.
در این درس Content Performance Feedback Loop Contract v1 را می‌سازیم: هر فرضیه‌ی محتوایی به تعریف متریک، نسخه‌ی instrumentation، کیفیت collection، window، segment، baseline، decision rule و next action متصل می‌شود.
قانون مرکزی: metric یک مشاهده است؛ بدون تعریف، نسخه‌ی instrumentation و context تصمیم، «حقیقت editorial» نیست.
2) مرز COM-014: Feedback Loop، نه repurposing و نه content model
COM-014 مالک feedback loop عملکرد است. COM-013 درباره‌ی Winner Repurposing بدون Copy و COM-015 درباره‌ی Single-source Content Model است؛ آن outcomeها را اینجا جذب نمی‌کنیم.
همچنین live analytics configuration، publish واقعی یا causal attribution قطعی انجام نمی‌دهیم. Lab کاملاً synthetic و offline است.
3) مدل ذهنی: Hypothesis → Instrumentation → Observation → Decision → Next Action
یک loop بسته پنج سؤال دارد: چه فرضیه‌ای را می‌سنجیم؟ با چه event/metric و کدام نسخه‌ی instrumentation؟ observation دقیقاً در چه window/segment جمع شده؟ decision rule از قبل چه بوده؟ و نتیجه چه action بعدی را ایجاد می‌کند؟
| case | hypothesis | metric definition | instrumentation | collection | window / segment | baseline | observed signal | decision rule | bounded state | next action |
|---|---|---|---|---|---|---|---|---|---|---|
| baseline | new hero improves qualified completion | qualified completion rate | web-v12 | VALID | 14d / organic-new | BL-014-A | +8% qualified completion | promote if >= +5% and collection valid | LOOP_ACTIONABLE | KEEP_TESTING |
| duplicate page_view | redesign increases views | public page views | web-v13 manual+auto | DUPLICATE | 7d / all | BL-014-B | +31% views | no winner if duplicate collection | BLOCKED_DUPLICATE_COLLECTION | REMEASURE |
| semantic change | video redesign lifts views | YouTube public views | yt-sem-v2026-08-24 | VALID | before/after / all | BL-014-C | view count up | definition must be stable/versioned | STALE_METRIC_SEMANTICS | REBASELINE |
| window mismatch | CTA improves leads | qualified completion | web-v12 | VALID | promo week / non-promo baseline | BL-014-D | +11% leads | windows must be comparable | DISPUTED_WINDOW | MATCH_WINDOW |
| transfer | variant expands reach | views + qualified lead completion | web-v12 | VALID | 14d / paid-search | BL-014-E | views +40%; qualified leads -12% | qualified metric dominates broad exposure | REVISE_OR_SEGMENT | SEGMENT_OR_REVISE |
اگر یکی از این پیوندها شکسته باشد، loop بسته نیست؛ فقط یک dashboard خوانده‌ایم.
4) GA4 چه چیزی را درباره‌ی event و parameter ثابت می‌کند؟
مستندات فعلی Google Analytics برای Measurement Protocol، eventها را با name و params در payload ساختاریافته تعریف می‌کند و هم eventهای recommended و هم custom eventها را پشتیبانی می‌کند. این FACT به ما می‌گوید collection باید هویت و پارامترهای روشن داشته باشد.
اما GA4 به‌تنهایی ثابت نمی‌کند که یک تغییر محتوا علت افزایش conversion بوده است. causation و business value خارج از این fact هستند.
5) Duplicate page_view: وقتی instrumentation خودش performance می‌سازد
Google می‌گوید page_view به‌طور پیش‌فرض می‌تواند خودکار ارسال شود و اگر بخواهیم manual page_view بفرستیم باید automatic behavior را غیرفعال کنیم؛ وگرنه duplicate pageviews ممکن است ایجاد شود.
در قرارداد ما collection_state باید این وضعیت را آشکار کند. وقتی duplicate محتمل یا ثابت‌شده است، state درست BLOCKED_DUPLICATE_COLLECTION یا REMEASURE_COLLECTION_SUSPECT است، نه «winner».
6) Metric Definition و semantic version: اسم متریک کافی نیست
دو dashboard می‌توانند هر دو ستون views داشته باشند ولی معنای آن‌ها یکسان نباشد. metric_definition باید توضیح دهد چه چیزی count می‌شود، و اگر semantics عوض شد آن تغییر باید به decision context وصل شود.
نمونه‌ی زنده: YouTube از 24 August 2026 public views را در همه‌ی formatها از لحظه‌ی شروع playback می‌شمارد، در حالی که engaged views و qualified views برای بعضی analytics، درآمد یا eligibility همچنان نقش جدا دارند. مقایسه‌ی قبل/بعد بدون ثبت این semantic boundary می‌تواند STALE_METRIC_SEMANTICS باشد.
7) Instrumentation Version: dashboard بدون نسخه‌ی جمع‌آوری قابل audit نیست
instrumentation_version مشخص می‌کند observation با کدام tag/config/schema تولید شده است. اگر redesign محتوا هم‌زمان با تغییر tracking اجرا شده، performance delta را نمی‌توان مستقیم به محتوا نسبت داد.
نسخه فقط یک رشته نیست؛ باید بتوانیم از event_name، event_params و collection state بفهمیم چه چیزی واقعاً اندازه‌گیری شده است.
8) Window، Segment و Baseline: مقایسه‌ی ظاهراً مشابه می‌تواند نابرابر باشد
یک هفته‌ی promotion سنگین را با هفته‌ی بدون promotion مقایسه نکنید و بعد نتیجه را صرفاً «اثر محتوا» بنامید. observation_window، segment و baseline_ref باید context مقایسه را ثابت کنند.
اگر window یا segment قابل‌مقایسه نیست، DISPUTED_WINDOW یا BLOCKED_BASELINE از یک decision مثبت سالم‌تر است.
9) Decision Rule و metric hierarchy: قبل از دیدن نتیجه تعیینش کن
اگر ابتدا dashboard را ببینیم و بعد threshold را انتخاب کنیم، feedback loop به rationalization تبدیل می‌شود. decision_rule باید قبل از تفسیر observation معلوم باشد.
مثلاً اگر هدف business، qualified lead completion است، افزایش view نمی‌تواند افت شدید lead completion را به‌تنهایی خنثی کند. در signal conflict، rule می‌تواند نتیجه را به REVISE_OR_SEGMENT ببرد، نه promotion عمومی.
10) از Observation تا Action: loop فقط وقتی بسته است که next action ثبت شود
observed_value و uncertainty_note evidence هستند. decision_state نتیجه‌ی bounded آن evidence است و next_action حلقه را می‌بندد: keep testing، segment، revise، stop یا remeasure.
اگر action ثبت نشود، تیم ممکن است همان dashboard را ماه بعد دوباره تفسیر کند بدون اینکه چیزی در production contract تغییر کرده باشد.
11) Failure modeهای اصلی و state درست
Baseline با metric definition روشن، instrumentation معتبر، collection سالم، window/segment قابل‌مقایسه، baseline مشخص و rule از پیش‌تعریف‌شده می‌تواند LOOP_ACTIONABLE باشد.
- manual و automatic
page_viewبا هم →BLOCKED_DUPLICATE_COLLECTION - collection مشکوک یا gapدار →
REMEASURE_COLLECTION_SUSPECT - metric semantics عوض شده ولی version نشده →
STALE_METRIC_SEMANTICS - window/segment نابرابر →
DISPUTED_WINDOW - baseline نامعتبر →
BLOCKED_BASELINE - exposure بالا ولی qualified metric پایین →
REVISE_OR_SEGMENT
12) Lab و transfer: views بالا، qualified lead پایین
در COM-014-LAB1 هشت fixture آفلاین داریم. learner باید از evidence visible state بسازد، نه اینکه label baseline را کپی کند.
Transfer اصلی Bible: variant جدید top-of-funnel views را بالا می‌برد اما qualified lead completion را پایین می‌آورد. باید metric hierarchy را صریح کنیم، instrumentation و window را دوباره کنترل کنیم و بعد بین keep، segment، revise یا stop تصمیم بگیریم. افزایش یک metric سطح بالا به‌تنهایی کافی نیست.
13) تصمیم bounded، freshness و چیزی که این درس اثبات نمی‌کند
این درس causation را اثبات نمی‌کند، vendor خاصی را بهترین analytics stack اعلام نمی‌کند و هیچ data collection زنده‌ای تغییر نمی‌دهد. خروجی فقط می‌گوید آیا evidence package فعلی برای یک next action محدود کافی است یا باید HOLD/REMEASURE/DISPUTED بماند.
GA4 و YouTube منابع vendor-current هستند و به‌دلیل تغییرپذیری semantics تا 2026-10-18 یا زودتر در صورت تغییر material دوباره بررسی می‌شوند. metric hierarchy، decision thresholds و state vocabulary DESIGN خود MAKNOW هستند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 retrieval
Why can a dashboard increase fail to prove content improvement?
Q2 diagnosis
A page sends both automatic and manual page_view events. What state should result and what is the minimum repair?
Q3 transfer
Views rise 40% while qualified lead completion falls 12%. Recompute the decision using an explicit metric hierarchy instead of copying the baseline answer.
ملاک‌های ارزیابی (rubric)
A sufficient answer must: (1) preserve COM-014 scope; (2) bind a hypothesis to explicit metric semantics and instrumentation version; (3) expose collection quality, window, segment and baseline; (4) predeclare a decision rule/metric hierarchy; (5) preserve typed HOLD/REMEASURE/DISPUTED/BLOCKED states; and (6) document a changed-context next action without claiming causation from dashboard movement alone.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
python run_checks.py را اجرا کنید. داده‌ها synthetic و آفلاین‌اند. هر تصمیم را از تعریف متریک، instrumentation، کیفیت collection، window/segment، baseline و decision rule بازسازی کنید؛ label قبلی را oracle نگیرید.