Performance Lens و Provenance-linked Results

1. مسئله واقعی: یک عدد، چند محاسبه متفاوت

اسلاید مدیریتی می‌گوید «ثبت‌نام ۱۴٪ بهتر شده»، اما Export جدید با Reporting Identity متفاوت و یک Country Filter اضافه ساخته شده و Query قبلی هم نگه‌داری نشده است. اگر فقط دو عدد را کنار هم بگذاریم، یک مقایسه تمیز ولی غیرقابل ممیزی ساخته‌ایم. هدف این درس بازسازی هویت هر Result قبل از هر تفسیر است.

2. مرز این درس

مالک این درس Provenance-Linked Performance Result Packet v1 است. Event taxonomy و Metric Regime درس قبل را دوباره طراحی نمی‌کنیم و Capacity Advisor درس بعد را هم جذب نمی‌کنیم. این درس علت اثر را ثابت نمی‌کند و هیچ اقدام Production را مجاز نمی‌کند؛ فقط می‌گوید Result قابل بازتولید و قابل‌مقایسه هست یا نه.

3. Performance Lens یعنی چه؟

Lens مشخص می‌کند سؤال Performance دقیقاً چیست: conversion، acquisition efficiency، search visibility یا هر Lens محدود دیگر. یک Metric نامشابه در Lens مشابه، یا همان Metric در Lens متفاوت، الزاماً Comparator معتبر نمی‌سازد. performance_lens باید پیش از مشاهده‌ی Result ثبت شود تا تفسیر پس از دیدن عدد عوض نشود.

4. Metric Regime را از Label جدا کن

Label مثل «Users» کافی نیست. metric_regime_id باید تعریف Metric، نسخه semantics و قواعد aggregation را مشخص کند. اگر Regime بین دو Result تغییر کرده باشد، مقایسه مستقیم فقط با Bridge صریح و قابل ممیزی مجاز است؛ وگرنه NOT_COMPARABLE است.

5. Query Identity باید کامل باشد

query_spec فقط نام Report نیست. Date Window، Dimensions، Metrics، Filters و Segment بخشی از هویت محاسبه‌اند. حذف یک Filter از Result قبلی یعنی نمی‌توانیم ادعا کنیم دو Query برابر بوده‌اند. در این حالت «حدس» جایگزین Evidence نمی‌شود و State به UNVERIFIED می‌رود.

6. Reporting Identity یک Detail تزئینی نیست

Google Analytics توضیح می‌دهد که Reporting Identity می‌تواند User Deduplication و User Count را برای همان Date Range تغییر دهد. بنابراین Blended/Observed/Device-based یا هر identity معادل باید در Packet ذخیره شود. تغییر Identity با Label ثابت، Comparator را بی‌اعتبار می‌کند مگر Bridge معتبر داشته باشیم.

7. Source Snapshot و Freshness

Result باید به source_snapshot و زمان extraction متصل باشد. داده‌ی خیلی تازه ممکن است هنوز در حال processing و aggregation باشد؛ اگر Result دوباره Query شود ولی Timestamp قدیمی را reuse کنیم، Lineage دروغین ساخته‌ایم. چنین Evidenceی STALE_EVIDENCE یا UNVERIFIED می‌شود، نه «تقریباً همان».

8. Transformation Lineage

هر تبدیل بین Source و Result باید قابل ردیابی باشد: normalization، join، exclusion، derived metric یا aggregation. derived_from باید Entityهای ورودی را مشخص کند و transformation_steps Activityها را. اگر فقط Value نهایی بماند و زنجیره حذف شود، Result قابل بازتولید نیست.

9. Entity، Activity و Agent در Provenance

از الگوی W3C PROV استفاده می‌کنیم: Snapshot یا dataset یک Entity است؛ Query/Transform یک Activity؛ و سیستم، analyst یا pipeline مسئول یک Agent. این Vocabulary جای Policy MAKNOW را نمی‌گیرد، ولی کمک می‌کند بگوییم چه چیزی از چه چیزی مشتق شده و چه کسی/چه سیستمی آن را تولید کرده است.

10. Uncertainty را حذف نکن

Result بدون uncertainty بیش از حد قطعی به‌نظر می‌رسد. Sampling، thresholding، processing lag یا gapهای provenance می‌توانند uncertainty ایجاد کنند. این درس اجازه نمی‌دهد uncertainty ناشناخته با صفر جایگزین شود. اگر uncertainty تصمیم‌ساز است ولی Evidence نداریم، State INSUFFICIENT_DATA یا DEFERRED می‌ماند.

11. Comparability Gate

برای VERIFIED شدن، Lens، Regime، Query identity، Reporting Identity، Snapshot/Freshness و Derivation باید هم‌ارز باشند. اگر تفاوت شناخته‌شده با Mapping و Evidence صریح bridge شده باشد، BRIDGED مجاز است. اختلاف semantics یا filter بدون Bridge → NOT_COMPARABLE؛ Evidence ناقص → UNVERIFIED.

12. Decision از Comparability قوی‌تر نیست

VERIFIED یعنی «این دو Result با قرارداد فعلی قابل مقایسه‌اند»، نه اینکه تغییر causal است یا اقدام خاصی باید اجرا شود. Decisionهای این درس محدودند: SUPPORT_BOUNDED_PLANNING، SUPPORT_WITH_BRIDGE، DO_NOT_COMPARE یا مسیرهای Rebuild/Refresh. Authorization بیرون این درس است.

13. مثال کارشده: ادعای رشد ۱۴٪

Result فعلی مقدار 114 و Result قبلی 100 نشان می‌دهد، اما قبلی Query Spec کامل ندارد و فعلی Country Filter اضافه دارد. با وجود +14٪ ظاهری، Comparability Gate رد می‌شود: Query identity برابر نیست و Result قبلی قابل بازتولید نیست. خروجی UNVERIFIED/DO_NOT_COMPARE است تا Query قبلی بازسازی شود.

14. Negative Caseها

چهار Shortcut باید شکست بخورند: تغییر Reporting Identity با Chart Label ثابت؛ حذف Filter Set از Result قبلی؛ re-query داده‌ی تازه با reuse کردن Snapshot Timestamp قبلی؛ و نگه‌داشتن Value در حالی که Derivation Chain حذف شده است. هیچ‌کدام نباید با best guess به VERIFIED تبدیل شوند.

15. Transfer: Search Performance

در Transfer، Source همان Search Performance dataset است اما extraction time و page filter تغییر کرده‌اند. Packet باید از صفر rebuild شود. چون Filter scope عوض شده، apparent improvement تا زمانی که Comparator هم با همان Scope ساخته نشود NOT_COMPARABLE است؛ تصمیم برنامه‌ریزی باید DO_NOT_COMPARE بماند، نه اینکه نتیجه baseline کپی شود.