معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۵ — Editorial Cell، SEO، QA، Approval و Onboarding · 253
Social Format Playbooks
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Social Format Playbooks». می‌تواند «Social Format Playbooks» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خلاصهٔ درس
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Social Format Playbooks».
می‌تواند «Social Format Playbooks» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خروجی این درس
می‌تواند «Social Format Playbooks» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
1) یک ایده‌ی خوب، یک فایل واحد برای همه‌ی شبکه‌ها نیست
فرض کنید تیم یک ویدیوی آموزشی ۷۰ ثانیه‌ای و 16:9 ساخته و می‌خواهد همان export، همان hook، همان caption، همان CTA و حتی همان KPI را در همه‌ی social surfaceها منتشر کند. ممکن است متن در یک surface crop شود، asset در جای دیگر classification متفاوت بگیرد و dashboard هم viewsهایی را با معنای متفاوت کنار هم بگذارد.
در این درس Channel Format Playbook Matrix v1 را می‌سازیم. یک content_intent ثابت می‌ماند، اما هر channel/surface قرارداد مستقل برای geometry، duration، hook، caption، CTA، rights، publish state و metric semantics دارد.
قانون مرکزی: چیزی که بین کانال‌ها مشترک می‌ماند «intent» است؛ format و metric باید برای هر surface صریح و versioned باشند.
2) مرز COM-012: Playbook کانال، نه Human Anchor و نه Winner Repurposing
COM-012 مالک قرارداد channel/surface است. COM-011 مالک Human Anchor + AI Variants و COM-013 مالک Winner Repurposing بدون Copy است. این درس آن outcomeها را جذب نمی‌کند.
همچنین live publish، adjudication حقوقی یا اثبات universal best practice انجام نمی‌دهیم. Lab کاملاً synthetic و offline است.
3) مدل ذهنی: Intent → Channel/Surface → Format Contract → Rights/Publish Gate → Metric Contract
برای هر ردیف playbook پنج سؤال به‌ترتیب بپرسید: intent چیست؟ target surface کجاست؟ asset geometry/duration مجاز چیست؟ rights و publish state چه هستند؟ و success metric دقیقاً چه چیزی را با کدام semantic version می‌شمارد؟
| case | channel / surface | intent | asset / geometry | duration | rights / publish | metric definition | metric version | experiment | bounded state | repair / next action |
|---|---|---|---|---|---|---|---|---|---|---|
| baseline | YouTube / Shorts | teach feature value | video / vertical | <=3m | CLEARED / READY | engaged-view rate for declared window | 2026-08-24+ | EXP-012-A | PLAYBOOK_READY | run bounded experiment |
| generic metric | YouTube / Shorts | teach feature value | video / vertical | <=3m | CLEARED / READY | views | 2026-08-24+ | EXP-012-B | REVISE_GENERIC_METRIC | define exact counted behavior |
| format mismatch | short-form / vertical surface | teach feature value | 16:9 landscape master | 60s | CLEARED / DRAFT | qualified completion | current | EXP-012-C | BLOCKED_FORMAT_MISMATCH | rebuild geometry for target surface |
| stale rule | YouTube / Shorts | teach feature value | video / vertical | <=3m | CLEARED / READY | public views | pre-change semantics | EXP-012-D | STALE_PLATFORM_ASSUMPTION | refresh playbook evidence/version |
| transfer | two affected surfaces | same core intent | surface-native assets | changed on one surface | CLEARED / DRAFT | versioned channel metrics | new semantics | EXP-012-E | REBASELINE_COMPARABILITY | update only affected playbooks and rebaseline |
اگر فقط نام پلتفرم یا یک KPI عمومی داشته باشیم، Playbook قابل‌ممیزی نیست.
4) FACT: YouTube Shorts و محدودیت format/duration
راهنمای رسمی فعلی YouTube می‌گوید ویدئوهای مربعی یا عمودی تا ۳ دقیقه می‌توانند به‌عنوان Shorts دسته‌بندی شوند؛ جزئیات زمانی و نوع channel در همان راهنما قید شده‌اند. این یک FACT پلتفرمی است، نه استاندارد جهانی short-form.
در Matrix، aspect_ratio_class و duration_class باید به evidence جاری همان surface وصل شوند. یک landscape master که فقط resize شده، بدون بررسی surface معتبر نیست.
5) FACT: نام views ثابت مانده، اما semantics آن تغییر کرده است
YouTube از ۲۴ اوت ۲۰۲۶ public view را از لحظه‌ی شروع پخش در همه‌ی formatها می‌شمارد. در عین حال engaged views و qualified views برای analytics، earnings یا eligibility نقش‌های جدا دارند.
پس metric_definition فقط نباید بنویسد «views». باید روشن کند دقیقاً چه چیزی شمرده می‌شود و metric_version_date به کدام semantics اشاره دارد. نتیجه‌ی experiment قبل و بعد از تغییر تعریف، خودکار comparable نیست.
6) ساختار Playbook: ۱۸ فیلد برای یک تصمیم قابل بازسازی
هر ردیف playbook_id, channel, surface, content_intent, audience_context, asset_type, aspect_ratio_class, duration_class, hook_pattern, caption_contract, cta_contract, rights_state, publish_state, metric_definition, metric_version_date, experiment_ref, owner, evidence_ref دارد.
۱۲ فیلد critical هستند. نبود یکی از آن‌ها success مصنوعی تولید نمی‌کند؛ state باید HOLD_MISSING_EVIDENCE یا state محدودتر باشد.
7) Geometry و Duration: adaptation واقعی قبل از export
asset_type, aspect_ratio_class و duration_class باید قبل از production final مشخص شوند. اگر surface عمودی است و تیم همان 16:9 master را بدون contract reuse کند، state درست BLOCKED_FORMAT_MISMATCH است.
اگر خود platform rule درباره‌ی duration تغییر کند، playbook affected باید version جدید بگیرد؛ نه اینکه همه‌ی کانال‌ها بی‌دلیل بازنویسی شوند.
8) Hook، Caption و CTA می‌توانند تغییر کنند؛ Intent نباید گم شود
یک core intent می‌تواند در یک surface با hook سریع‌تر، در دیگری با context بیشتر و در سومی با CTA متفاوت بیان شود. این تغییرها failure نیستند؛ بخشی از channel-native expression هستند.
اما اگر adaptation آن‌قدر تغییر کند که intent جدیدی ایجاد شود، دیگر همان Playbook نیست و باید رابطه‌ی experiment و تصمیم دوباره تعریف شود.
9) Rights State و Publish State را یکی نکنید
publish_state=READY به معنی rights_state=CLEARED نیست. ممکن است asset از نظر format آماده باشد اما music، testimonial یا image ingredient هنوز rights روشن نداشته باشد.
در MAKNOW، rights نامعلوم BLOCKED_RIGHTS می‌دهد. prior publication یا تایید layout جایگزین rights evidence نیست.
10) Metric Contract: KPI هر کانال باید تعریف مستقل داشته باشد
یک bare views field برای cross-channel comparison کافی نیست. Playbook باید توضیح دهد metric چه event/behaviorی را می‌شمارد و semantic version آن چیست.
اگر تیم generic views را جایگزین metric definition کند، state REVISE_GENERIC_METRIC است. exposure، engaged behavior، qualified outcome و conversion را فقط وقتی مقایسه کنید که contract آن‌ها مشخص باشد.
11) Experiment Ref و comparability: نسخه‌ی Playbook بخشی از شواهد است
experiment_ref باید به playbook version مورد استفاده وصل باشد. اگر definition متریک یا accepted duration تغییر کند، نتایج قبلی ممکن است historical evidence باقی بمانند اما direct comparison دیگر معتبر نباشد.
در این حالت REBASELINE_COMPARABILITY به تیم می‌گوید affected playbook را update کند و experiment تازه یا baseline سازگار بسازد؛ core intent و playbookهای unaffected ثابت می‌مانند.
12) Failure Modeهای اصلی و typed state درست
- landscape master بدون surface check →
BLOCKED_FORMAT_MISMATCH - duration خارج از rule جاری →
REVISE_DURATION_CONSTRAINT - metric فقط با نام generic
views→REVISE_GENERIC_METRIC - rights نامعلوم →
BLOCKED_RIGHTS - rule پلتفرم قدیمی/بدون بازبینی →
STALE_PLATFORM_ASSUMPTION - metric/duration semantics عوض شده و baseline قبلی مقایسه‌پذیر نیست →
REBASELINE_COMPARABILITY - critical evidence واقعاً گم شده →
HOLD_MISSING_EVIDENCE
Typed state جلوی این را می‌گیرد که «تقریباً آماده» به publish-ready تبدیل شود.
13) Lab و Transfer: فقط playbookهای affected را update کنید
COM-012-LAB1 هشت fixture آفلاین دارد. baseline، generic metric، landscape mismatch، rights failure، stale rule، missing evidence، duration violation و changed-context transfer را بدون oracle پنهان بررسی می‌کند.
در transfer، definition view در یک platform و duration accepted در channel دیگر عوض می‌شود. learner باید فقط همان دو playbook را version کند، core intent را ثابت نگه دارد و توضیح دهد چرا experimentهای قبلی direct comparable نیستند.
14) تصمیم محدود، Freshness و چیزی که این درس ثابت نمی‌کند
این درس نمی‌گوید یک format یا KPI برای همه‌ی شبکه‌ها بهترین است و هیچ publish واقعی انجام نمی‌دهد. خروجی فقط مشخص می‌کند آیا evidence فعلی برای یک Channel Format Playbook قابل‌ممیزی کافی است یا باید HOLD/BLOCK/REVISE/REBASELINE شود.
YouTube یک vendor-current source است و باید تا 2026-10-18 یا زودتر پس از تغییر material بازبینی شود. schema playbook، stateها و release policy DESIGN خود MAKNOW هستند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 retrieval
What remains stable across channel playbooks, and which fields must remain surface-specific?
Q2 diagnosis
A team replaces every channel metric with a generic views field. What state should result and why?
Q3 transfer
One platform changes view semantics and another channel changes accepted duration. Which playbooks change, and why are previous experiment results not automatically directly comparable?
ملاک‌های ارزیابی (rubric)
A sufficient answer must: (1) preserve COM-012 scope and one bounded content intent; (2) bind each channel/surface to explicit asset, geometry and duration constraints; (3) keep rights and publish state separate; (4) define metric semantics with a version date; (5) preserve typed HOLD/BLOCK/REVISE/STALE states; and (6) update only affected playbooks and rebaseline comparability after a material platform-rule change.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
python run_checks.py را اجرا کنید. fixtureها synthetic و آفلاین‌اند. تصمیم هر playbook را از constraintهای surface، rights، metric semantics/version و comparability experiment بازسازی کنید؛ label قبلی oracle نیست.