Audience Fit و Drift Detection

1. مسئله واقعی: اسم Audience ثابت است، آدم‌های داخلش نه

فرض کن محصولی Audienceای به نام «یادگیرندگان بازگشتی» دارد. نام Segment و Dashboard عوض نشده، اما کمپین جدید کاربران متفاوتی وارد کرده و Completion درس‌های پیشرفته پایین آمده است. اگر فقط Label را ثابت فرض کنیم، Planning بر شواهد تاریخی نامعتبر سوار می‌شود. این درس یک Audience Fit & Drift Evidence Monitor v1 می‌سازد که تعریف Audience، نسخه، Baseline، Observed Window، Composition و Behavior را جدا ثبت می‌کند.

2. مرز درس و Artifact نهایی

خروجی مالک این درس Audience Fit & Drift Evidence Monitor v1 است. Monitor یکی از حالت‌های FIT، DRIFT_SUSPECTED، DRIFT_CONFIRMED یا INSUFFICIENT_DATA را صادر می‌کند و در حالت‌های مبهم UNKNOWN، DEFERRED، REVIEW_REQUIRED یا REJECTED را حفظ می‌کند. Cadence متعلق به PLN-011 و Context Radar متعلق به PLN-013 است؛ این درس نه Frequency Recommendation می‌دهد و نه Crisis Action.

3. Audience Definition را Version کن

هر مقایسه باید حداقل audience_version، segment_condition و membership_rule را ثبت کند. اگر Membership Rule وسط Observed Window از static به dynamic تغییر کند ولی Version بالا نرود، داده قبل و بعد نماینده یک Population واحد نیست. در این حالت نتیجه Drift نباید محاسبه شود؛ تصمیم باید به REVIEW_REQUIRED یا DEFERRED برود تا Window سازگار دوباره ساخته شود.

4. GA4 Audience چه چیزی را واقعاً نشان می‌دهد

مستندات فعلی Google Analytics می‌گویند Audience condition می‌تواند static یا dynamic ارزیابی شود و metricهای time-windowed نیز پشتیبانی می‌شوند [GA4-AUDIENCE]. در ارزیابی dynamic، کاربر وقتی شرط را دارد وارد Audience می‌شود و وقتی دیگر شرط برقرار نیست خارج می‌شود. این رفتار یک Vendor Implementation است؛ MAKNOW آن را «حقیقت Audience» یا معیار جهانی Drift اعلام نمی‌کند.

5. Cohort برای مقایسه رفتار در طول زمان

راهنمای رسمی Cohort Exploration می‌گوید Cohort گروهی از کاربران با characteristic مشترک است؛ Inclusion Criterion ورود را تعیین می‌کند و Return Criterion رفتار بعدی را در Windowهای روزانه، هفتگی یا ماهانه می‌سنجد [GA4-COHORT]. این برای دیدن تغییر رفتار Cohortها مفید است، اما تغییر Cohort به‌تنهایی اثبات Drift نیست؛ Composition، Window و Confounder هم باید بررسی شوند.

6. Baseline و Observed Window باید Comparable باشند

baseline_window و observed_window فقط دو بازه تاریخ نیستند. باید Definition Version، Seasonality، Acquisition Mix و Coverage آن‌ها قابل مقایسه باشد. اگر Baseline 28 روز و Observed فقط 7 روزِ کمپین ویژه باشد، تفاوت Metric ممکن است از Window Design بیاید. Monitor باید window_compatible را قبل از Drift State ببندد.

7. Composition Change را از Behavior Change جدا کن

composition_signal می‌گوید چه کسانی وارد Segment شده‌اند؛ مثل تغییر Channel Mix، Device Mix یا Entry Cohort. behavior_signal می‌گوید همان Population بعد از ورود چه کرده است؛ مثل Completion یا Return. اگر فقط Composition تغییر کند، فرضیه Drift مطرح می‌شود ولی هنوز Behavior Change تأیید نشده است. این تفکیک جلوی نتیجه‌گیری عجولانه را می‌گیرد.

8. Sample Size: Signal کوچک را certainty نکن

هر Window باید sample_size و حداقل Sample موردنیاز Fixture را داشته باشد. در Lab، نصف‌کردن Sample بدون تغییر Metric عمداً آزمایش می‌شود. همان Delta با Evidence نصفه نباید همان State قبلی را حفظ کند؛ نتیجه باید INSUFFICIENT_DATA شود. Threshold واقعی محصول باید در Context خودش تعیین شود و این درس Threshold جهانی اختراع نمی‌کند.

9. Confounder را Evidence درجه‌دو ندان

Campaign، Seasonality، Pricing Change یا Tracking Gap می‌توانند Metric را جابه‌جا کنند بدون اینکه Audience Definition واقعاً Drift کرده باشد. confounder باید explicit باشد. اگر یک Spike یک‌هفته‌ای هم‌زمان با Campaign دیده شود، Monitor نباید آن را مستقیم DRIFT_CONFIRMED کند؛ State محدود DRIFT_SUSPECTED و Review Trigger مناسب‌تر است.

10. Drift Metric باید Composite Evidence باشد

در این درس، Drift Metric از دو Signal مستقل ساخته می‌شود: تغییر Composition و تغییر Behavior. برای Fixture مصنوعی، Deltaهای بالاتر از Gateهای تعریف‌شده فقط زمانی می‌توانند DRIFT_CONFIRMED شوند که Version/Window/Sample/Provenance سالم و Confounder کنترل‌شده باشد. Metric یک Evidence خلاصه است، نه جایگزین Gateها.

11. چهار State اصلی Monitor

FIT یعنی Evidence فعلی با Baseline سازگار است. DRIFT_SUSPECTED یعنی یک یا چند Signal معنادار دیده شده اما برای تأیید کامل کافی نیست یا Confounder باز است. DRIFT_CONFIRMED یعنی Composition و Behavior هر دو با Evidence کافی و قابل‌مقایسه از Baseline فاصله گرفته‌اند. INSUFFICIENT_DATA یعنی Sample یا Data Coverage اجازه Judgment معتبر نمی‌دهد.

12. Provenance و Review Trigger تصمیم را قابل Audit می‌کنند

هر ردیف باید provenance_ref و review_trigger داشته باشد. اگر Source/Window/Version trace نشود، حتی Metric جذاب هم قابل دفاع نیست و می‌تواند REJECTED شود. Review Trigger باید finite باشد؛ مثلاً «پس از جمع‌شدن 200 observation جدید»، «بعد از پایان Campaign» یا «پس از ساخت Baseline برای Version 2».

13. مثال کارشده: Returning Learners بعد از Campaign جدید

Baseline Version 1 با Membership Rule ثابت، 28 روز و Sample کافی است. Observed Window هم 28 روز است، اما Acquisition Mix تغییر کرده و Completion پیشرفته افت کرده است. اگر Composition Delta و Behavior Delta هر دو از Gate Fixture عبور کنند و Campaign اثر مستقیم توضیح‌دهنده باقی نماند، Monitor DRIFT_CONFIRMED می‌دهد. اگر Campaign هنوز Confounder فعال باشد، فقط DRIFT_SUSPECTED مجاز است.

14. Negative Caseها و Failure Probeهای قطعی

چهار Shortcut رد می‌شوند: 1) تغییر Membership Rule وسط Window بدون Versioning → REVIEW_REQUIRED; 2) نصف‌کردن Sample و نگه‌داشتن Drift قبلی → INSUFFICIENT_DATA; 3) Spike یک‌هفته‌ای Campaign → DRIFT_SUSPECTED, نه Confirmed؛ 4) Missing Provenance → REJECTED. همچنین Composition-only یا Behavior-only به‌تنهایی Confirmed نیست.

15. Transfer: static به dynamic، بدون مقایسه Window ناسازگار

اکنون Audience از Membership Rule ثابت به Dynamic Rule می‌رود. Contract تغییر نمی‌کند، اما audience_version باید به Version جدید برود و Baseline تازه برای همان Rule ساخته شود. Windowهای Version 1 و Version 2 نباید مثل یک Segment ثابت مقایسه شوند. Transfer زمانی موفق است که Learner Definition را version کند، Window را re-baseline کند و State را از Evidence جدید محاسبه کند، نه از Label قبلی.