Campaign Attribution و Measurement Labels

وقتی «+۳۵٪ رشد» هنوز یک نتیجه‌ی قابل‌مقایسه نیست

فرض کن گزارش کمپین می‌گوید نرخ تبدیل ماه دوم ۳۵٪ بهتر شده است. در ماه اول لینک‌ها با utm_source و utm_medium دستی برچسب خورده‌اند و conversion برابر «ارسال فرم» بوده؛ در ماه دوم بخشی از ورودی auto-tagged است، conversion به «lead واجدشرایط» تغییر کرده و reporting attribution model هم عوض شده است. اگر فقط ستون conversion rate را ببینی، یک عدد تمیز داری؛ اما یک measurement یکسان نداری.

خروجی این درس Campaign Attribution Measurement Label Registry v1 است: برای هر metric باید هویت کمپین، روش tagging، event/conversion definition، attribution model/scope/window، data origin، metric-definition version، محدودیت‌ها و evidence کنار خود عدد ثبت شوند. هدف پیش‌بینی بازاریابی یا اثبات causal lift نیست؛ هدف این است که reviewer بتواند بفهمد دو عدد واقعاً یک چیز را اندازه می‌گیرند یا نه.

مرز مالکیت COM-026

COM-026 مالک measurement semantics و comparability است. COM-025 حقوق/Disclosure/Brand Safety را مالک است و COM-027 اتصال Shopify را. این درس UTM generator، ad-platform automation یا مدل incrementality نمی‌سازد و هیچ dashboard خارجی را source of truth نمی‌کند.

ورودی prerequisite سخت COM-021 فقط در حد boundary موردنیاز carry می‌شود. خروجی این درس یک registry قابل‌ممیزی است که metric بدون label/version را برای تصمیم قطعی قبول نمی‌کند.

مدل ذهنی: عدد آخر زنجیره است، نه شروع آن

ترتیب درست این است:

campaign identity → traffic labels → tagging method → event/conversion definition → attribution model/scope/window → data origin → metric definition → limitations/evidence → comparability gate → interpretation

اگر هر حلقه‌ای عوض شود، نتیجه‌ی قبلی خودکار قابل‌مقایسه نیست. همان campaign_name یا metric_name نمی‌تواند تغییر conversion definition یا attribution setting را پنهان کند.

COMPARABLE یعنی دو measurement label در ابعاد تعیین‌کننده هم‌معنا هستند. PARTIAL_COMPARABLE یعنی بعضی comparisonها—مثلاً trend داخل یک label/version—معتبرند ولی cross-channel یا cross-period comparison کامل نیست. هر evidence تعیین‌کننده‌ی مفقود باید HOLD/UNKNOWN بسازد.

FACT، INFERENCE و DESIGN را جدا نگه دار

FACT: Google Analytics برای traffic source ابعادی مثل source، medium، campaign، campaign ID، source platform و default channel grouping دارد و data می‌تواند از manual tagging یا auto-tagging integration بیاید.

FACT: manual tagging شامل UTMهای رایج utm_source، utm_medium، utm_campaign، utm_term و utm_content است. وجود UTM فقط می‌گوید traffic چگونه label شده؛ causal effect را ثابت نمی‌کند.

FACT: در GA4 reporting attribution model، channels eligible for credit و key-event lookback window تنظیمات واقعی measurement هستند. تغییر reporting attribution model روی گزارش‌های event-scoped تاریخی و آینده اثر می‌گذارد؛ user/session-scoped dimensions semantics متفاوتی دارند.

INFERENCE: اگر model/scope/window و conversion definition همراه metric ذخیره نشوند، snapshotهای دو dashboard می‌توانند ظاهراً یک metric name داشته باشند ولی معنای متفاوتی بدهند.

DESIGN: MAKNOW هر تغییر معنایی تعیین‌کننده را label/version change یا HOLD می‌کند و cross-label comparison را باید دوباره محاسبه کرد.

قرارداد ۲۳بُعدی measurement

Gate 1 — measurement و campaign identity را جدا کن

measurement_id شناسه‌ی evidence bundle است؛ campaign_id هویت initiative و campaign_version نسخه‌ی تعریف/اجراست. تغییر audience/offer/creative taxonomy یا هدف measurement می‌تواند campaign version جدید بخواهد حتی اگر نام کمپین همان باشد.

Gate 2 — source/medium/campaign_name label هستند، نه حقیقت causal

source و medium مشخص می‌کنند traffic چگونه طبقه‌بندی شده است. این فیلدها برای audit ضروری‌اند، اما «facebook / paid_social» به‌تنهایی نمی‌گوید فروش به‌خاطر همان touchpoint اتفاق افتاده است.

Gate 3 — tagging method را صریح ثبت کن

tagging_method حداقل باید بین MANUAL_UTM، AUTO_TAGGED، MIXED و OFFLINE_IMPORT یا ترکیب کنترل‌شده‌ی آن‌ها فرق بگذارد. اگر دو دوره با روش‌های متفاوت مقایسه می‌شوند ولی این تفاوت ثبت نشده، HOLD_TAGGING_METHOD درست‌تر از interpretation مثبت است.

Gate 4 — event name با conversion definition یکی نیست

event_name=generate_lead کافی نیست. conversion_definition باید بگوید چه شرطی آن event را conversion محسوب می‌کند: submit خام، lead deduplicated، qualified lead یا purchase confirmed. تغییر این تعریف بدون label/version جدید، series را می‌شکند.

Gate 5 — attribution model و attribution scope را جدا ثبت کن

attribution_model می‌تواند data-driven یا last-click باشد، ولی attribution_scope هم باید معلوم کند credit روی چه channel universe/report semanticsی اعمال شده است. مدل یکسان با scope متفاوت هنوز comparison یکسان نمی‌سازد.

Gate 6 — reporting window بخشی از معناست

lookback/reporting window تعیین می‌کند چه touchpointهایی eligible هستند و چه بازه‌ای تحلیل شده است. «۳۰ روز» و «۹۰ روز» یک metric name را هم‌معنا نمی‌کنند.

Gate 7 — data_source را از channel جدا نگه دار

data_source می‌گوید عدد از کجا آمده: GA report، ad platform، CRM qualified-lead table، offline conversion import یا join داخلی. source=google با data_source=GA4_EXPORT دو چیز متفاوت‌اند.

Gate 8 — metric definition version را version کن

metric_name=ROAS یا conversion_rate کافی نیست. numerator/denominator، currency/time basis، dedupe rule و inclusion/exclusion باید در metric_definition_version قابل بازسازی باشند.

Gate 9 — known limitations اجباری است

اگر cross-device coverage ناقص، offline match rate نامعلوم، consent gap، modeled data، late-arriving conversions یا timezone mismatch وجود دارد، باید در known_limitations بماند. حذف limitation evidence را قوی‌تر نمی‌کند؛ فقط audit را ضعیف می‌کند.

Gate 10 — comparability یک decision مشتق‌شده است

comparability_state باید از label dimensions محاسبه شود. اگر conversion definition یا attribution scope تغییر کرده، metric name مشترک حق COMPARABLE صادر نمی‌کند.

Gate 11 — offline import lineage باید معلوم باشد

در transfer، channel جدید conversion offline وارد می‌کند. باید matching key boundary، import source، lag/dedupe semantics و coverage limitation ثبت شود. بدون آن، cross-channel comparison به HOLD_DATA_ORIGIN یا PARTIAL_COMPARABLE می‌رود.

Gate 12 — evidence_ref reviewer را به مبنا برگرداند

هر measurement row باید بتواند به campaign config، tagging spec، conversion definition، attribution settings snapshot و data extract/fixture مربوط trace شود. screenshot بدون version/context evidence کافی نیست.

مثال‌های کاری

۱. baseline هم‌معنا → COMPARABLE

دو هفته از یک campaign version، tagging method، conversion definition، attribution model/scope/window، data source و metric-definition version یکسان استفاده می‌کنند. known limitations نیز ثابت و evidence کامل است. trend comparison مجاز است.

۲. conversion عوض شده ولی metric label همان است → HOLD_CONVERSION_DEFINITION

ماه اول submit خام و ماه دوم qualified lead را conversion می‌گیرد. conversion_rate نام مشترک دارد اما denominator/numerator meaning عوض شده است.

۳. manual و auto-tagging قاطی شده و method ثبت نشده → HOLD_TAGGING_METHOD

source/medium ظاهراً پر هستند، ولی روش collection معلوم نیست. بدون tagging lineage، channel comparison قطعی صادر نکن.

۴. attribution scope عوض شده → HOLD_ATTRIBUTION_SCOPE

مدل «data-driven» در هر دو دوره ثبت شده، اما channels eligible for credit یا report scope تغییر کرده است. model name مشترک کافی نیست.

۵. limitation حذف شده → HOLD_LIMITATIONS

offline matching در یک دوره فقط بخشی از CRM را پوشش داده، اما این limitation از row حذف شده است. metric value وجود دارد ولی evidence bundle ناقص است.

۶. transfer با channel جدید → PARTIAL_COMPARABLE

channel جدید با tagging متفاوت و offline conversion import اضافه می‌شود. درون label/version جدید trend معتبر است، اما cross-channel comparison فقط در dimensionهای واقعاً هم‌تعریف‌شده مجاز است. baseline verdict کپی نمی‌شود.

failure modeهای رایج

• مقایسه‌ی دو dashboard فقط چون metric name یکی است؛
• فرض اینکه UTM مساوی causality است؛
• یکی گرفتن source با data_source؛
• تغییر conversion definition بدون bump کردن measurement label/version؛
• ثبت attribution model بدون scope/window؛
• قاطی‌کردن manual و auto-tagging بدون provenance؛
• استفاده از campaign name به‌عنوان campaign identity؛
• حذف known limitation برای «تمیزتر شدن» گزارش؛
• مقایسه‌ی offline-import channel با online-only channel بدون matching/coverage boundary؛
• reuse کردن نتیجه‌ی baseline بعد از تغییر attribution settings؛
• تفسیر metric وقتی evidence_ref یا definition version مفقود است.

گزینه‌ها و trade-offها

Dashboard-only interpretation: سریع است، اما semantics پنهان می‌ماند و change history قابل‌ممیزی نیست.

UTM taxonomy فقط: campaign labeling را منظم می‌کند، اما conversion/attribution/metric-definition drift را پوشش نمی‌دهد.

Measurement Label Registry: overhead بیشتری دارد، ولی هر metric را به definition/version/evidence متصل می‌کند و comparison invalid را زود متوقف می‌کند.

یک label سراسری cross-channel: ساده است، ولی اختلاف tracking/import/matching را پنهان می‌کند. labelهای channel-aware با comparability gate پیچیده‌ترند، اما evidence صادقانه‌تری می‌دهند.

پل برای فرد باتجربه: ۱۷ سؤال review

1. measurement_id چیست؟
2. campaign ID و version دقیق کدام‌اند؟
3. source و medium چگونه جمع شده‌اند؟
4. tagging method چیست؟
5. campaign/content/term/creative taxonomy چه نسخه‌ای دارد؟
6. landing reference چیست؟
7. event name چیست؟
8. conversion definition دقیقاً چیست و چه نسخه‌ای دارد؟
9. reporting attribution model چیست؟
10. attribution scope/channels eligible چیست؟
11. reporting/lookback window چیست؟
12. data source واقعی metric کجاست؟
13. metric definition version چگونه numerator/denominator را تعریف می‌کند؟
14. limitationهای known چیست؟
15. evidence_ref reviewer را به چه snapshot/config/data می‌برد؟
16. آیا دو row واقعاً در critical dimensions هم‌معنا هستند؟
17. اگر channel/tagging/offline import تغییر کند، چه چیزی باید recompute شود؟

تمرین هدایت‌شده و مستقل

Lab آفلاین ۸ fixture دارد: baseline comparable، conversion drift، tagging method نامعلوم، attribution-scope drift، limitation حذف‌شده، evidence ناقص، channel جدید با offline import ناقص و transfer صحیح با comparability محدود.

تمرین مستقل: یک channel جدید اضافه کن که tagging و offline conversion import متفاوتی دارد. measurement label جدید بساز؛ سپس مشخص کن comparison داخل همان label، comparison با baseline و aggregate cross-channel هرکدام COMPARABLE، PARTIAL_COMPARABLE یا HOLD هستند و چرا.

evidence قابل‌قبول

Artifact باید هر ۲۳ dimension را پر کند یا non-success state صریح بدهد. metric بدون campaign/version/tagging/conversion/attribution/data-origin/metric-definition/limitations/evidence قابل promotion نیست. comparability باید نتیجه‌ی deterministic diff روی critical dimensions باشد، نه نظر dashboard reader.

Lab کاملاً synthetic و offline است؛ credential، production account یا داده‌ی مشتری لازم ندارد.

Assessment و transfer

برای پایان درس باید بتوانی:

1. مرز COM-026 را در برابر COM-025 و COM-027 توضیح بدهی؛
2. Campaign Attribution Measurement Label Registry v1 را بسازی؛
3. UTM/traffic labels را از causality جدا کنی؛
4. conversion definition، attribution model/scope/window و metric definition را version کنی؛
5. semantic drift را به HOLD یا label-version جدید تبدیل کنی؛
6. known limitations و evidence lineage را حذف نکنی؛
7. transfer channel/offline import را بدون کپی baseline verdict بازسازی کنی.

منابع و freshness

• Google Analytics Traffic-source dimensions — rechecked در 15 سپتامبر 2026؛ source/medium/campaign/campaign ID/source platform/channel grouping و semantics گزارش را پشتیبانی می‌کند.
• Google Analytics Traffic-source dimensions, manual tagging, and auto-tagging — rechecked در 15 سپتامبر 2026؛ UTM manual tagging و auto-tagging integration را پشتیبانی می‌کند.
• Google Analytics Select attribution settings و Change the reporting attribution model for key events — rechecked در 15 سپتامبر 2026؛ reporting attribution model، eligible channels، lookback window و اثر مدل روی event-scoped historical/future reporting را پشتیبانی می‌کنند.
• measurement label versioning، comparability states و fail-closed promotion در این درس MAKNOW DESIGN هستند، نه الزام Google Analytics.