ورود مخاطبان فعلی در لحظهٔ روشن‌شدن در برابر فقط مچ‌های آینده

ورود مخاطبان فعلی در لحظهٔ روشن‌شدن فلو، همهٔ رکوردهایی را که همین حالا فیلتر تریگر را پاس می‌کنند داخل مسیر می‌کشد؛ حالت فقط‌آینده صبر می‌کند تا بعد از go-live یک تغییر وضعیت تازه رخ دهد.

ورود موجود در فعال‌سازی و فقط‌آینده دقیقاً چه فرقی دارند؟

وقتی یک فلو یا جرنی فیلترمحور را روشن می‌کنی، معمولاً یک سؤال ظاهر می‌شود که خیلی‌ها سرسری رد می‌شوند: «مخاطبانی که الان شرط را دارند هم وارد شوند؟» یا «فقط کسانی که بعد از روشن‌شدن تازه مچ می‌شوند؟» جواب این سؤال همان تفاوت enroll-existing در برابر future-only است.

در حالت ورود موجود (enroll existing at activation)، سیستم در لحظهٔ publish یک کوئری روی store پروفایل/سگمنت می‌زند و هر رکوردی که فیلتر تریگر را همین حالا پاس کند وارد صف می‌کند. در حالت فقط‌آینده (future-only)، همان فیلتر فقط به گذارهای بعدی گوش می‌دهد: کسی که از دیروز VIP بوده و هنوز VIP است، تا وقتی وضعیتش دوباره تغییر نکند وارد نمی‌شود.

به زبان برنامه‌نویس: activation backfill یعنی SELECT * WHERE filters در t0؛ future-only یعنی subscribe به state transition بعد از t0. این همان تمایزی است که در مارکتینگ اتومیشن چیست هم زیر پوست تعریف اتومیشن دیده می‌شود — فقط اینجا تمرکز روی لحظهٔ روشن‌شدن است، نه کل مفهوم اتومیشن.

نکتهٔ مهم: تریگرهای مبتنی بر ایونت معمولاً ذاتاً future-only هستند. ایونت گذشته را دوباره «آتش» نمی‌کنند مگر اینکه جداگانه backfill دستی یا فیلتر معادل بسازی.

هر کدام چطور کار می‌کند؟

ورود موجود در فعال‌سازی

فرض کن فلو nurture برای کسانی که lifecycle = mql و هنوز دمو رزرو نکرده‌اند. اگر enroll-existing را بزنی، همهٔ MQLهای فعلی — حتی آن‌هایی که ماه‌هاست در این وضعیت مانده‌اند — یک‌جا وارد می‌شوند. مناسب وقتی است که می‌خواهی بدهی انباشته را جبران کنی: «همهٔ کسانی که باید پیام می‌گرفتند و نگرفتند.»

ریسک: انفجار صف. اگر ۱۲۰ هزار نفر مچ شوند و اولین قدم پیامک باشد، بودجه و deliverability یک‌شبه آسیب می‌بینند. قبل از publish همیشه dry-run count بگیر.

فقط مچ‌های آینده

همان فلو را future-only می‌گذاری. فقط کسی که بعد از go-live تازه MQL می‌شود (یا دوباره به MQL برمی‌گردد اگر re-enrollment روشن باشد) وارد می‌شود. مناسب وقتی مسیر را از صفر برای سیگنال‌های تازه طراحی کرده‌ای و نمی‌خواهی تاریخچهٔ کهنه را با منطق جدید بمباران کنی.

جدول مقایسه سریع

مثال واقعی از فروشگاه و SaaS ایرانی

فروشگاه مد: سری خوش‌آمد برای کسانی که عضو خبرنامه هستند ولی هنوز خرید نکرده‌اند. اگر enroll-existing بزنی، همهٔ مشترکین قدیمی یک‌جا ایمیل ۱ را می‌گیرند — حتی کسانی که دو سال پیش عضو شده‌اند. اغلب بهتر است future-only بگذاری و برای قدیمی‌ها یک کمپین یک‌بارهٔ جدا با سگمنت «عضو بدون خرید > ۹۰ روز» بسازی.

SaaS B2B: فلو onboarding وقتی plan = trial و setup_completed = false. روشن کردن با enroll-existing یعنی همهٔ trialهای باز فعلی وارد مسیر آموزش می‌شوند؛ عالی اگر محتوا تازه است. اگر محتوا تخفیف پایان trial دارد و خیلی از trialها همین هفته تمام می‌شوند، future-only + کمپین دستی امن‌تر است.

اپ فود: سگمنت «آدرس ثبت کرده ولی سفارش اول نزده». backfill می‌تواند هزاران پیامک اول‌سفارش بسازد؛ اینجا dry-run و سقف نرخ ارسال اجباری است.

چک‌لیست فعال‌سازی (شماره‌دار)

۱. تعداد مچ فعلی فیلتر را در استیجینگ یا preview بشمار.
۲. اگر عدد بزرگ است، اول future-only روشن کن یا backfill را به بچ‌های کوچک بشکن.
۳. suppression list و quiet hours را قبل از publish چک کن.
۴. اولین قدم را اگر پیامک است، با سقف روزانه تست کن.
۵. برای ایونت‌تریگرها انتظار backfill خودکار نداشته باش؛ فیلتر معادل بساز یا دستی enroll کن.
۶. بعد از روشن‌شدن، متریک ورود ساعت اول را نگاه کن — اگر غیرعادی بالاست، فلو را pause کن.

نگاشت به Leadara (events، segments، journeys، email/SMS)

• Segments: فیلتر enrollment معمولاً روی سگمنت زنده یا attribute پروفایل سوار است؛ backfill یعنی snapshot همان سگمنت در t0.
• Events: ورود با ایونت = future-only؛ برای بک‌فیل باید سگمنت/فیلتر معادل بسازی.
• Journeys: لحظهٔ activate جرنی همان جایی است که انتخاب backfill در برابر future-only معنا دارد.
• Email/SMS: هزینهٔ کانال تعیین می‌کند کدام حالت را انتخاب کنی؛ پیامک در ایران یعنی backfill بی‌گارد = سوخت بودجه.

این انتخاب را با مدل جرنی در برابر کمپین قاطی نکن: کمپین یک‌باره برای بک‌فیل قدیمی‌ها گاهی تمیزتر از enroll-existing روی یک جرنی بلند است.

اشتباه‌های رایج

• روشن کردن enroll-existing روی فلو پیامک‌محور بدون شمارش.
• انتظار backfill از تریگر ایونت خالص.
• ساختن منطق جدید و همزمان ریختن همهٔ مخاطبان کهنه داخلش.
• فراموش کردن اینکه scheduled workflow ممکن است در اجرای بعدی تقویم، مچ‌های قبلی را دوباره ببیند حتی اگر در activate بلافاصله enroll نشده باشند.

جمع‌بندی یک‌خطی برای تیم

Enroll-existing = صف را با مچ‌های فعلی پر کن. Future-only = فقط به گذار بعدی گوش بده. قبل از تیک زدن، عدد را ببین.

گام بعدی چیست؟

یک فلو nurture واقعی را باز کن. بنویس: اگر امروز روشن شود چند نفر وارد می‌شوند؟ اگر عدد را نمی‌دانی، هنوز آمادهٔ publish نیستی. بعد تصمیم بگیر backfill لازم است یا یک کمپین یک‌باره جدا.

سؤالات پرتکرار

آیا تریگر ایونت هم enroll-existing دارد؟

معمولاً نه. ایونت‌های گذشته دوباره fire نمی‌شوند. برای پوشش گذشته از فیلتر یا enroll دستی استفاده کن.

اگر کسی از قبل شرط را داشته و future-only باشد چه می‌شود؟

تا وقتی وضعیتش تغییر نکند (یا re-enrollment با گذار تازه فعال نشود) وارد نمی‌شود.

برای ورکفلوهای زمان‌بندی‌شده چطور؟

گاهی حتی اگر در activate بک‌فیل نکنی، در اجرای بعدی schedule اگر هنوز مچ باشند وارد می‌شوند. داک محصولت را چک کن.

چطور از blast جلوگیری کنم؟

Dry-run count، سقف نرخ، شروع با ایمیل به‌جای پیامک، یا بک‌فیل تدریجی با سگمنت‌های برش‌خورده.

آیا re-enrollment همان enroll-existing است؟

خیر. Enroll-existing دربارهٔ لحظهٔ روشن‌شدن است؛ re-enrollment دربارهٔ ورود دوباره بعد از خروج است.

این موضوع به اتومیشن event-centric چه ربطی دارد؟

در مدل event-centric وسوسه می‌شوی همه‌چیز را ایونت کنی و بعد بپرسی چرا قدیمی‌ها وارد نشدند؛ بدان که بک‌فیل معمولاً فیلتر/سگمنت می‌خواهد — همان تمایز event-centric در برابر contact-centric.

برای سری خوش‌آمد کدام را انتخاب کنم؟

معمولاً future-only برای اعضای جدید + کمپین جدا برای انباشتهٔ قدیمی. Enroll-existing فقط وقتی محتوا و بودجه برای همهٔ انباشته آماده‌اند.

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

فروشگاه لوازم خانگی، سگمنت «سبد رها شده در ۷ روز بدون خرید». می‌خواهند فلو بازیابی را امشب روشن کنند.

۱. Preview می‌گوید ۸۴۰۰ نفر مچ‌اند.
۲. اولین قدم پیامک است → تصمیم: future-only برای امشب.
۳. همزمان کمپین ایمیل یک‌باره برای همان ۸۴۰۰ با قالب نرم‌تر.
۴. فردا اگر نرخ باز شدن خوب بود، بچ ۲۰۰۰تایی از قدیمی‌ها را دستی به فلو enroll می‌کنند.
۵. quiet hours و لیست suppression چک شده.

این مسیر کنترل‌شده بهتر از یک تیک enroll-existing است که نیمه‌شب هزاران پیامک می‌سازد.

تفاوت با enroll دستی و کمپین یک‌باره

گاهی وسوسه می‌شوی به‌جای تصمیم‌گرفتن بین enroll-existing و future-only، همه را دستی به فلو add کنی. enroll دستی برای نمونه‌های کوچک و VIP خوب است، ولی برای ده‌ها هزار نفر نه مقیاس دارد نه audit trail تمیز. کمپین یک‌باره برای بک‌فیل قدیمی‌ها اغلب تمیزتر است چون:

• پیام و زمان‌بندی را جدا از منطق جرنی بلند نگه می‌دارد.
• اگر نتیجه بد بود، فلو زنده را آلوده نکرده‌ای.
• می‌توانی A/B روی قالب بک‌فیل بگیری بدون دست زدن به مسیر آینده.

قاعده عملی تیم رشد: آینده را با جرنی بساز، گذشته را با کمپین یا بچ کنترل‌شده جبران کن — مگر عدد بک‌فیل کوچک و محتوای مسیر برای کهنه‌کارها هم مناسب باشد.

متریک‌هایی که بعد از روشن‌شدن باید ببینی

در ساعت اول: تعداد enrollment، نرخ خطا، نرخ شکست ارسال. در روز اول: unsubscribe، شکایت اسپم، نرخ باز شدن غیرعادی پایین (نشانهٔ مخاطب کهنه). اگر enroll-existing زده‌ای و unsubscribe یک‌ساعته از میانگین ماهانه بالاتر است، فلو را pause کن و سگمنت را ببر.

همچنین صف wait را نگاه کن. بک‌فیل بزرگ همه را هم‌زمان به یک wait ۲۴ساعته می‌فرستد و روز بعد انفجار دوم می‌سازد. برای بک‌فیل، jitter تصادفی یا بچ‌بندی زمانی بگذار.

گفت‌وگوی محصول و داده

قبل از publish یک جدول سه ستونی در تیکت بنویس: فیلتر enrollment، تخمین مچ فعلی، کانال قدم اول. صاحب داده تخمین را تأیید کند؛ صاحب کانال سقف را. بدون این سه امضا، تیک enroll-existing نزن. این همان انضباطی است که جلوی «دیشب فلو را روشن کردیم و صبح بودجه پیامک تمام شد» را می‌گیرد.

اگر استیجینگ دیتای تولید ندارد، حداقل یک نمونهٔ anonymized از شمارش production بگیر. حدس زدن عدد مچ از روی حس، همان جایی است که حادثه می‌سازد.

مطالب مرتبط

• مارکتینگ اتومیشن چیست؟ از ایونت و سگمنت تا جرنی و پیام
• جرنی مارکتینگ در برابر کمپین: مسیر چندمرحله‌ای در برابر یک ارسال
• اتومیشن event-centric در برابر contact-centric: استریم رفتار در برابر رکورد شخص