Content Gap Detection

1. مسئله واقعی: Query پربازدید مساوی Gap نیست

فرض کنید Search Console برای یک Query هزاران Impression و CTR پایین نشان می‌دهد. این مشاهده می‌تواند مهم باشد، اما هنوز ثابت نمی‌کند که باید صفحه تازه بسازیم. شاید همان Intent در یک صفحه موجود پوشش داده شده باشد، شاید صفحه موجود ضعیف باشد، شاید چند صفحه با هم رقابت کنند، یا بخشی از Queryها به‌دلیل privacy و محدودیت جدول اصلاً دیده نشوند. این درس Demand-to-Coverage Gap Matrix v1 را می‌سازد تا Demand Evidence به Content Inventory متصل شود و تصمیم از روی شواهد قابل‌ردیابی صادر شود.

2. مرز درس و Artifact مالک

PLN-010 مالک Content Gap Detection است. Artifact نهایی برای هر intent_cluster حداقل query_evidence، page_candidate، coverage_strength، data_visibility، duplicate_risk، gap_confidence، action، evidence_window، unknown_state و review_trigger را ثبت می‌کند. Rolling Planning Horizons متعلق به PLN-009 و Cadence Envelope متعلق به PLN-011 است؛ این درس برنامه زمانی یا cadence انتشار را تعیین نمی‌کند.

3. Demand Evidence را قبل از تصمیم Normalized کن

Raw Queryها را مستقیماً به Topic List تبدیل نکن. Queryهای نزدیک را در یک Intent Cluster معنادار جمع کن و Window، Region، Search Type و Device Scope را ثبت کن. impressions، clicks، ctr و position فقط Signalهای عملکرد Search هستند؛ آن‌ها به‌تنهایی نیاز کسب‌وکار یا مجوز ساخت Content جدید را اثبات نمی‌کنند. اگر Normalization ناقص باشد، gap_confidence باید کاهش یابد یا State به REVIEW_REQUIRED برود.

4. Search Console چه چیزی واقعاً می‌دهد؟

راهنمای فعلی Search Console در Performance Report ابعاد Query و Page و Metricsهایی مثل Clicks، Impressions، CTR و Average Position را ارائه می‌کند [GSC-PERF]. همچنین می‌توان یک Query را فیلتر کرد و Pages نمایش‌داده‌شده برای همان Query را دید [GSC-USE]. این Fact به ما Demand/Coverage Evidence می‌دهد؛ اما Classification نهایی Gap یک Design Rule در MAKNOW است، نه Claim مستقیم Google.

5. Data Visibility کامل نیست

Search Console صریحاً می‌گوید بعضی Queryها برای حفظ Privacy anonymized می‌شوند و Table می‌تواند به‌دلیل محدودیت‌های داخلی همه Rowها را نمایش ندهد [GSC-DIMS]. بنابراین «Query در Table نیست» مساوی «Demand صفر است» نیست. data_visibility باید مستقل ثبت شود. وقتی Visibility ناقص است، سیستم نباید absence را به certainty تبدیل کند.

6. Inventory را قبل از CREATE جست‌وجو کن

Content Inventory باید URL/ID، Intent اصلی، زبان، Status، Canonical Relationship و Coverage Notes داشته باشد. برای هر Intent Cluster اول Candidateهای موجود را پیدا کن. اگر یک صفحه مرتبط از Inventory پنهان شده باشد، مدل ممکن است به‌اشتباه CREATE بدهد؛ Failure Probe این درس دقیقاً همین shortcut را می‌شکند. CREATE قبل از Inventory Match ممنوع است.

7. Coverage Strength با Ranking یکی نیست

coverage_strength می‌پرسد صفحه موجود تا چه حد همان Intent را مفید و مستقیم پاسخ می‌دهد. Position پایین می‌تواند نشانه‌ای برای بررسی باشد، اما Coverage را فقط از Position استنتاج نکن. صفحه‌ای ممکن است Intent را خوب پوشش دهد ولی Distribution یا Competition ضعیف باشد. در این حالت ساخت صفحه دوم می‌تواند Duplicate Risk را زیاد کند؛ تصمیم مناسب می‌تواند OBSERVE یا بهبود غیرساختاری باشد.

8. چهار Action اصلی: CREATE / IMPROVE / CONSOLIDATE / OBSERVE

CREATE وقتی مجاز است که Demand معتبر، Coverage مؤثر غایب، Visibility به‌اندازه کافی قابل‌اعتماد و Duplicate Risk پایین باشد. IMPROVE برای Intentی است که صفحه موجود دارد ولی Coverage آن ضعیف است. CONSOLIDATE وقتی چند صفحه عملاً یک Intent را با wording متفاوت پوشش می‌دهند و Fragmentation/duplication ایجاد می‌کنند. OBSERVE برای Coverage کافی، Demand ضعیف، یا وضعیتی است که اقدام جدید هنوز ارزش اثبات‌شده ندارد.

9. UNKNOWN و REVIEW_REQUIRED را حفظ کن

اگر data_visibility ناقص است، Demand Estimate مبهم است، Evidence Window منقضی شده یا Provenance وجود ندارد، سیستم نباید با عددسازی تصمیم قطعی بسازد. Stateهای UNKNOWN، INSUFFICIENT_DATA، REVIEW_REQUIRED، REJECTED و DO_NOT_USE بخشی از Contract هستند. REVIEW_REQUIRED شکست نیست؛ یعنی Evidence فعلی اجازه Action قوی‌تر نمی‌دهد.

10. Duplicate Risk قبل از ساخت URL جدید

دو Page Candidate ممکن است Title و wording متفاوت داشته باشند اما Intent یکسان را جواب دهند. اگر فقط String Similarity بررسی شود، سیستم این هم‌پوشانی را نمی‌بیند. Duplicate Risk باید بر Intent/coverage سنجیده شود. وقتی دو صفحه پوشش متداخل قوی دارند، Action مناسب می‌تواند CONSOLIDATE باشد؛ ساخت صفحه سوم برای همان Intent به‌دلیل Impressions بالا پذیرفته نیست.

11. Evidence Window و Provenance را اجباری کن

هر Row باید Window مشخص، Source/Export Reference، Scope و تاریخ Recheck داشته باشد. Evidence قدیمی می‌تواند Reality فعلی Search و Inventory را نمایندگی نکند. Missing Provenance به REJECTED می‌رسد و Stale Window باید REVIEW_REQUIRED ایجاد کند. UI تمیز نباید age یا source uncertainty را مخفی کند.

12. Confidence عدد تزئینی نیست

gap_confidence خلاصه‌ای از Demand Strength، کیفیت Visibility، وضعیت Coverage و Duplicate Risk است؛ اما Threshold دقیق Portfolio-specific است. در این درس Confidence برای Audit و مقایسه Caseها استفاده می‌شود، نه برای وانمودکردن به قطعیت. اگر Visibility ناقص باشد، Confidence باید محدود شود حتی اگر Impressions ظاهراً بالا باشند.

13. مثال کارشده: سه Intent، سه تصمیم متفاوت

Intent A Demand قوی دارد، Inventory کامل بررسی شده و هیچ Page Candidate معناداری ندارد؛ Duplicate Risk پایین است، پس CREATE. Intent B Demand قوی دارد اما Page موجود فقط بخشی از سؤال را پاسخ می‌دهد؛ IMPROVE. Intent C دو صفحه با wording متفاوت ولی Intent مشترک دارد؛ CONSOLIDATE. Intent D Impressions بالا دارد ولی Page فعلی Coverage قوی دارد؛ OBSERVE. یک Metric واحد چهار تصمیم متفاوت می‌سازد چون Evidence Matrix متفاوت است.

14. Failure Probeهای قطعی

چهار shortcut باید رد شوند: 1) یک Page مرتبط را از Inventory مخفی کن → CREATE نباید قطعی بماند و Visibility/Inventory Review لازم است؛ 2) low-volume anonymized rows را حذف کن → absence نباید zero-demand تلقی شود؛ 3) دو Page را با wording متفاوت ولی Intent یکسان بساز → CONSOLIDATE، نه CREATE؛ 4) Impressions را برای Queryای که صفحه فعلی خوب پوشش می‌دهد زیاد کن → Coverage کافی هنوز OBSERVE است. Missing Provenance نیز REJECTED و Stale Evidence REVIEW_REQUIRED است.

15. Transfer: زبان دوم با Inventory کوچک‌تر و Queryهای anonymized

همین مدل را روی زبان دوم اجرا کنید؛ Inventory کوچک‌تر است و بخشی از Queryها anonymized شده‌اند. Contract عوض نمی‌شود، اما data_visibility و Gap Confidence باید دوباره محاسبه شوند. نبودن Rowهای Query به معنای Demand صفر نیست و کوچک‌بودن Inventory به‌تنهایی مجوز CREATE نمی‌دهد. Transfer وقتی موفق است که Evidence جدید Decision تازه بسازد و عدم قطعیت به‌صورت صریح باقی بماند.