فلو تاریخ پروفایل در برابر فلو رویداد رفتار: سالگرد روی تقویم در برابر سیگنال زنده

فلو تاریخ پروفایل افراد را از روی یک تاریخ ذخیره‌شده—تولد، تمدید، قرار ملاقات—روی همان روز یا قبلش با تکرار ماهانه/سالانه/یک‌بار صف می‌کند؛ فلو رویداد رفتار همان لحظه که ایونت زنده‌ای مثل سفارش یا مشاهده محصول شلیک شود شروع می‌شود.

فلو تاریخ پروفایل و فلو رویداد رفتار چه فرقی دارند؟

یکی از پرتکرارترین سؤال‌های تیم‌های eCRM این است: تولد و تمدید اشتراک را چطور اتومات کنیم، و سبد رها‌شده را چطور؟ جواب یک فلو نیست. یکی روی تقویم پروفایل سوار است، دیگری روی استریم رفتار.

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

فلو تاریخ پروفایل (date-property)

منبع تریگر یک فیلد تاریخ روی مخاطب است: birthday، renewal_at، appointment_at. معمولاً می‌توانی بگویی «همان روز»، «X روز قبل» یا گاهی «بعد». تکرار: سالانه (تولد)، ماهانه (اشتراک)، یک‌بار (رویداد تکی). موتور هر روز پروفایل‌ها را اسکن می‌کند و کسانی را که لنگر تاریخشان با قانون می‌خواند وارد صف می‌کند.

فلو رویداد / متریک (metric-triggered)

منبع تریگر یک ایونت رفتاری است: placed_order، viewed_product، cart_abandoned. ورود همان لحظه (یا با تأخیر کوتاه تشخیص) رخ می‌دهد. تکرار معمولاً «هر بار ایونت» یا «با کول‌داون» است—نه سالگرد تقویمی.

برای جزئیات لنگر قبل/روز/بعد، فلو replenishment چیست؟ یادآوری سفارش قبل از تمام‌شدن محصول را ببین. لایهٔ فلسفی‌تر رویداد در برابر زمان‌بندی هم در مارکتینگ اتومیشن در برابر زمان‌بندی ارسال: واکنش به رویداد در برابر ساعت تقویم آمده است.

مثال واقعی ایرانی

اشتراک ماهانه محتوای ویدیو

فیلد renewal_at روی پروفایل. فلو تاریخ: ۳ روز قبل ایمیل یادآوری، روز موعد پیامک، ۲ روز بعد اگر تمدید نشده ایمیل winback ملایم. تکرار ماهانه. این را با ایونت payment_failed قاطی نکن—آن یکی فلو رویداد جداست برای شکست پرداخت همان لحظه.

فروشگاه—سبد و تولد

سبد رها‌شده باید metric-triggered باشد (cart_updated + wait). تولد باید date-property باشد. اگر تولد را با «آخرین خرید در سالگرد» شبیه‌سازی کنی، کسانی که فیلد تولد دارند ولی امسال نخریده‌اند از دست می‌روند.

کلینیک—قرار ملاقات

appointment_at با تریگر «۲۴ ساعت قبل» پیامک یادآوری. اگر بیمار همان روز از اپ رزرو را لغو کند، بهتر است یک فلو رویداد appointment_cancelled خروج/توقف بسازد تا پیامک یادآوری بی‌معنی نرود.

کی کدام را انتخاب کنی؟

1. مناسبت تقویمی تکراری → تاریخ پروفایل.
2. واکنش به عمل کاربر → رویداد.
3. هر دو را برای یک نفر می‌توانی داشته باشی؛ با exit و فیلتر هم‌پوشانی را مدیریت کن.
4. قبل از روشن‌کردن فلو تاریخ، نمونهٔ فرمت تاریخ و تایم‌زون را در داده واقعی چک کن.
5. برای تغییر فیلد لنگر، معمولاً فلو را کلون کن نه اینکه وسط راه عوضش کنی.

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

• Events: برای شاخه رفتار؛ نام پایدار و پراپرتی لازم.
• Segments: کسانی که renewal_at پر است؛ یا خریداران ۳۰ روز اخیر برای سرکوب تولد اگر لازم است.
• Journeys: مسیرهای جدا برای تاریخ و برای ایونت؛ قاطی‌کردن در یک کانوس شلوغ دیباگ را سخت می‌کند.
• Email / SMS: یادآوری تمدید اغلب پیامک؛ داستان تولد اغلب ایمیل+کد.

اگر ورود باید از سیستم بیرونی همان لحظه هل شود (نه اسکن روزانه تاریخ)، الگوی جرنی چرخه عمر در برابر کمپین لحظه‌ای رویدادمحور را هم ببین.

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

• ساختن «تولد» با ایونت آخرین خرید
• نادیده‌گرفتن تایم‌زون (تهران در برابر UTC)
• یک فلو برای تمدید ماهانه و شکست پرداخت با هم
• فرمت تاریخ چندگانه در CRM بدون نرمال‌سازی
• انتظار اینکه فلو تاریخ مثل ایونت «همان میلی‌ثانیه» شلیک شود

جمع‌بندی یک‌خطی

تاریخ پروفایل = scheduler.scan(date_prop)؛ رویداد = subscribe(event_stream).

گام بعدی

یک فیلد تاریخ واقعی در CRM را باز کن. ۱۰ ردیف را از نظر فرمت و تایم‌زون بخوان. بعد تصمیم بگیر فلو تاریخ می‌سازی یا هنوز داده تمیز نیست.

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

می‌شود هم before و هم on را در یک فلو داشت؟

معمولاً با چند پیام در یک فلو تاریخ؛ یا دو فلو کلون‌شده. محدودیت ابزار را چک کن.

اگر فیلد تاریخ خالی باشد؟

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

تکرار yearly برای تمدید ماهانه؟

غلط است—monthly بگذار یا از ایونت billing استفاده کن.

تفاوت با کمپین زمان‌بندی‌شده یک‌باره؟

کمپین یک‌باره لیست را در ساعت ثابت می‌زند؛ فلو تاریخ هر روز لنگرها را چک می‌کند و فقط مچ‌ها را وارد می‌کند.

برای سالگرد اولین خرید چه؟

اگر first_order_at روی پروفایل است، تاریخ پروفایل؛ اگر فقط ایونت تاریخی داری، باید به پراپرتی تبدیلش کنی یا از گزارش cohort جدا استفاده کنی.

پیامک شبانه برای «روز تولد»؟

لنگر را با ساعت ارسال آرام (مثلاً ۱۰ صبح به وقت کاربر) ترکیب کن؛ فقط تاریخ کافی نیست.

تغییر renewal_at وسط ماه؟

رفتار اسکن را تست کن؛ بعضی موتورها همان دوره را دوباره صف می‌کنند.

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

1. فیلد لنگر را در دیکشنری داده قفل کن.
2. قانون before/on و تکرار را بنویس.
3. کانال هر پیام را مشخص کن.
4. فلو رویداد موازی (مثلاً payment_failed) را جدا بساز.
5. با پروفایل تست تاریخ را دستی جابه‌جا کن و ورود را ببین.
6. بعد از go-live نرخ ورود روزانه را با تعداد تاریخ‌های مچ‌شونده مقایسه کن.

متریک‌ها

• پوشش فیلد تاریخ (٪ پر بودن)
• ورود روزانه در برابر انتظار تقویم
• نرخ تبدیل تمدید بعد از پیام before
• نرخ لغو به‌خاطر پیام بی‌موقع

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

anchor=renewal_at; when=3d_before+on_day; repeat=monthly; channels=email,sms; separate flow for payment_failed event

طراحی گارد

• یک لنگر تاریخ در هر فلو
• کلون برای تغییر فیلد
• فیلتر سگمنت برای وضعیت اشتراک فعال
• خروج روی ایونت تمدید موفق تا پیام بعد از تمدید نرود

تفاوت ذهنی با تیم فروش

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

مدل ذهنی برنامه‌نویس

# date-property
daily:
  for profile in scan(date_prop, rule=before/on, tz=Asia/Tehran):
    enroll(flow_date)

# metric
on event_stream:
  if event.name in triggers and filters_pass(event):
    enroll(flow_metric)

گاردها: اعتبارسنجی فرمت تاریخ؛ یک لنگر در هر فلو؛ کلون برای عوض‌کردن فیلد؛ تایم‌زون تهران را صریح بنویس نه فرضی.

ماتریس انتخاب سریع

ویگنت بیمه و چند قرارداد

اگر برای هر پلاک بیمه یک تاریخ تمدید جدا داری، یک فیلد روی پروفایل شخص کافی نیست. یا باید به ازای هر قرارداد پراپرتی/رکورد جدا داشته باشی، یا فعلاً از ایونت policy_renewal_upcoming که از بک‌اند می‌آید استفاده کنی. این مرز همان‌جایی است که مدل داده eCRM جلوی «یک فلو تولد ساده» را می‌گیرد.

پذیرش قبل از انتشار

1. ۱۰ پروفایل با تاریخ‌های مرزی (۱ فروردین، ۲۹ اسفند، leap-ish edge اگر میلادی است).
2. تغییر دستی تاریخ تست و مشاهده ورود در ۲۴ ساعت اسکن.
3. اطمینان از نرفتن پیام بعد از تمدید موفق (exit یا فیلتر).
4. مقایسه تعداد ورود روز اول با تعداد ردیف‌های مچ در SQL/CRM.

اشتباه گزارش‌گیری

ورود کم در روز اول را «خراب بودن فلو» ندان؛ اول پوشش فیلد و تایم‌زون را بسنج. خیلی وقت‌ها نصف پروفایل‌ها تاریخ خالی یا UTC اشتباه دارند.

چک‌لیست نویسنده قبل از انتشار فلو تاریخ

• فرمت تاریخ در ۱۰ نمونه خام یکسان است
• تایم‌زون Asia/Tehran در تنظیم ارسال آمده
• تکرار (monthly/yearly/once) با بیزنس یکی است
• فلو رویداد موازی برای شکست/لغو جداست
• پیام بعد از موفقیت تمدید با exit یا فیلتر می‌میرد

## مطالب مرتبط

• فلو replenishment چیست؟ یادآوری سفارش قبل از تمام‌شدن محصول
• مارکتینگ اتومیشن در برابر زمان‌بندی ارسال: واکنش به رویداد در برابر ساعت تقویم
• جرنی چرخه عمر در برابر کمپین لحظه‌ای رویدادمحور

مطالب مرتبط

• فلو replenishment چیست؟ یادآوری سفارش قبل از تمام‌شدن محصول
• مارکتینگ اتومیشن در برابر زمان‌بندی ارسال: واکنش به رویداد در برابر ساعت تقویم
• فلو با تریگر کاتالوگ در برابر فلو با تریگر ایونت: تغییر محصول در برابر عمل کاربر