ورود با رویداد در برابر ورود با فیلتر حالت: «اتفاقی افتاد» در برابر «الان این‌طور است»
Event در برابر filter enrollment: جدول مقایسه، has-not، مثال فروشگاه ایرانی، نگاشت به رویداد و سگمنت Leadara.
رضا احمدی
بهینه‌سازی سایت و محتوا برای گوگل؛ افزایش ترافیک ارگانیک و دیده‌شدن برند در نتایج جستجو.
۹ مهر ۱۴۰۵ · 6 دقیقه مطالعه
نسخه دیگر English
ورود با رویداد روی یک رخداد گسسته شروع می‌شود («اتفاقی افتاد»—فرم ارسال شد، سفارش ثبت شد)؛ ورود با فیلتر/حالت وقتی شروع می‌شود که یک وضعیت پایدار درست باشد («الان این‌طور است»—شهر تهران، lifecycle=customer). فقط منطق فیلتر/سگمنت «انجام‌نداده» را تمیز بیان می‌کند؛ تریگر رویداد برای نبودن رفتار معمولاً به شاخهٔ بعدی نیاز دارد.
تعریف یک‌خطی: event enrollment در برابر filter enrollment
- Event enrollment: لبهٔ زمانی. چیزی اتفاق افتاد. بسته به تنظیم، یک‌بار یا هر بار که رویداد تکرار شود.
- Filter / state enrollment: ارزیابی وضعیت. چیزی الان برقرار است. اغلب با ورود به سگمنت، already-in، یا تغییر property مدل می‌شود.
سؤال محصولی این نیست که «کدام مدرن‌تر است»؛ سؤال این است که سیگنال شما لحظه‌ای است یا وضعیتی—و آیا باید «کسانی که X را نکرده‌اند» را در نقطهٔ ورود بگیرید.
برای جزئیات «انجام‌نداده» ببینید تریگر فیلتر has-not در برابر تریگر ایونت. برای هل سیستم خارجی در برابر سیگنال کاربر: ورود با وب‌هوک در برابر ورود با رویداد.
جدول مقایسه
| بعد | ورود با رویداد (Event) | ورود با فیلتر/حالت (Filter / Segment state) |
|---|---|---|
| سیگنال | رخداد گسسته با timestamp | وضعیت یا عضویت سگمنت |
| مثال | order_completed, form_submitted, cart_updated | شهر=تهران، RFM=خفته، has_purchased=false |
| «انجام‌نداده» در تریگر ورود | ضعیف/غیرطبیعی؛ معمولاً بعد از ورود با if/else | طبیعی روی سگمنت یا فیلتر منفی |
| ورود مجدد | اغلب هر بار رویداد (اگر allow re-entry) | با enters دوباره، یا already-in در فعال‌سازی |
| زمان‌بندی | فوری بعد از رخداد | وقتی وضعیت برقرار/کشف شود (ممکن است تأخیر ارزیابی باشد) |
| ریسک رایج | گرفتن «همهٔ غیرخریداران» با رویداد خرید | ماندن طولانی روی state بدون لبهٔ تازه |
| کانال بعدی | عالی برای پیام تراکنشی/سبد | عالی برای nurture و winback وضعیتی |
تریگر سگمنت را با فیلتر اشتباه نگیرید
سگمنت خودش می‌تواند سه لبه داشته باشد—Enters در برابر Already-in در برابر Exits:
- Enters: شبیه رویداد عضویت—لبهٔ تازه.
- Already-in: بیشتر شبیه فیلتر در لحظهٔ فعال‌سازی یا ارزیابی.
- Exits: خروج از وضعیت—برای suppress/exit مفید، نه برای «شروع فروش».
پس «ورود با سگمنت» همیشه filter enrollment خالص نیست؛ بستگی دارد کدام لبه را انتخاب کنید.
مثال ایرانی: فروشگاه مد
سناریو A — رویداد: مشتری دکمهٔ «پرداخت» را می‌زند → checkout_started. جرنی در ۵ دقیقه SMS یادآوری ارسال/کد تخفیف محدود می‌فرستد. اینجا رویداد درست است چون لحظه مهم است.
سناریو B — فیلتر: می‌خواهید همهٔ کسانی که در ۳۰ روز خرید نکرده‌اند وارد winback شوند. اگر بگویید «رویداد خرید رخ نداد» به‌عنوان تریگر ورود، سیستم چیزی برای fire شدن ندارد. درستش سگمنت last_order_at > 30d یا has_not purchased in 30d است.
سناریو C — ترکیب: ورود با رویداد browse_category=shoes، بعد شاخه: اگر در سگمنت «خریدار کفش» بود → مسیر مراقبت؛ وگرنه → مسیر تبدیل اول. رویداد برای ورود، فیلتر برای مسیر.
چه وقت کدام را انتخاب کنیم؟
| نیاز | انتخاب | دلیل |
|---|---|---|
| سبد رهاشده، فرم، پرداخت ناموفق | Event | لبهٔ زمانی واضح |
| Winback خفته، VIP شهر، RFM | Filter / segment state | وضعیت پایدار |
| «هرگز خرید نکرده» در نقطهٔ ورود | Filter / has-not segment | رویداد نبودن را fire نمی‌کند |
| همگام با سیستم انبار/CRM خارجی | Webhook یا event سفارشی | منبع حقیقت بیرون است |
| پیامک تراکنشی OTP/ارسال | معمولاً بیرون promo journey یا event جدا | FC و رضایت جدا |
ورود مجدد و سقف اسپم
- رویداد با re-entry آزاد می‌تواند با هر
cart_updatedدوباره enroll کند → با frequency cap و Quiet hours جفت کنید. - فیلتر already-in فقط وقتی خطرناک است که هر publish دوباره همه را بک‌فیل کند؛ تنظیم activation را آگاهانه انتخاب کنید.
- برای پیامک ایرانی (کاوه‌نگار/نیکالاین) رضایت و ساعت ارسال را روی هر دو مدل جدی بگیرید.
نگاشت صادقانه به Leadara
در Leadara:
- Events را به تریگرهای لحظه‌ای map کنید؛
- Segments را به حالت و has-not / RFM؛
- برای نبود رفتار: ترجیح با سگمنت منفی یا شاخهٔ بعد از ورود، نه «رویداد منفی» جعلی؛
- ایمیل و پیامک؛ Live Chat = پشتیبانی انسانی؛ AI Chat = دستیار داخلی تیم—نه ربات مشتری.
کانکتور فروشگاه‌سازی که در docs عمومی نیست ادعا نکنید؛ اگر خرید از وب‌هوک می‌آید، در بریف بنویسید.
گام‌های عملی
- برای هر جرنی یک جمله بنویسید: «این سفر با اتفاق شروع می‌شود یا با وضعیت؟»
- اگر جمله «کسانی که X نکرده‌اند» بود، تریگر ورود را رویداد نگذارید.
- جدول بالا را در داکیومنت جرنی کپی کنید و ستون «انتخاب ما» را پر کنید.
- QA: پروفایل با رویداد تازه؛ پروفایل فقط state؛ پروفایل has-not.
- Re-entry و FC را قبل از لانچ پیامک چک کنید.
- Already-in در برابر Enters را عمدی انتخاب کنید—پیش‌فرض حدس نزنید.
- بعد از لانچ، نرخ enroll اشتباه (مثلاً خریدار داخل مسیر «هنوز نخریده») را مانیتور کنید.
اشتباه‌های رایج
- ساختن «رویداد خرید نکرد»؛
- استفاده از event برای winback ۳۰روزه بدون سگمنت؛
- already-in روی هر republish بدون آگاهی؛
- قاطی کردن webhook سیستم با event رفتار کاربر؛
- فراموش کردن که filter enrollment ممکن است با تأخیر ارزیابی state وارد کند.
سؤالات پرتکرار
فرق ورود مبتنی بر رویداد و ورود مبتنی بر فیلتر چیست؟
رویداد = رخداد گسسته؛ فیلتر = وضعیت برقرار. بازورود، has-not و زمان‌بندی فرق می‌کند.
آیا تریگر رویداد می‌تواند «خرید نکرده‌ها» را وارد کند؟
به‌صورت تمیز خیر. برای نبود خرید از سگمنت/فیلتر یا شاخه بعد از ورود استفاده کنید.
آیا هر بار رویداد رخ دهد دوباره وارد می‌شوند؟
اگر re-entry مجاز باشد، بله—مگر محدودیت‌های فلو/FC جلویش را بگیرد.
سگمنت enters رویداد است یا فیلتر؟
Enters لبه است (شبیه رویداد عضویت)؛ already-in بیشتر شبیه فیلتر state است.
برای سبد رهاشده کدام بهتر است؟
معمولاً event روی به‌روزرسانی/رها کردن سبد؛ فیلتر مکمل برای «هنوز خرید نکرده بعد از ورود».
وب‌هوک کجای این جدول است؟
هل خارجی است—نه دقیقاً رفتار کاربر. مطلب webhook در برابر event را ببینید.
Live Chat لیدارا این انتخاب را برای مشتری انجام می‌دهد؟
خیر. Live Chat انسانی است؛ طراحی تریگر با تیم شماست. AI Chat فقط داخلی است.
معیار موفقیت چیست؟
کاهش enrollهای بی‌معنی، وضوح has-not، و پیام درست در ساعت درست بدون اسپم رویداد تکراری.
گام بعدی چیست؟
یک جرنی winback و یک جرنی سبد را کنار هم باز کنید. برای اولی جملهٔ «وضعیت» و برای دومی جملهٔ «اتفاق» بنویسید. اگر جابه‌جا بودند، تریگر را قبل از نوشتن کپی اصلاح کنید.
