ورود با خروج از فلو در برابر ورود با ایونت: هندآف مسیر تمامشده در برابر سیگنال رفتار تازه
فرق on-flow-exit و event entry: تعریف، جدول، توالی، FAQ و نگاشت Leadara.
رضا احمدی
بهینهسازی سایت و محتوا برای گوگل؛ افزایش ترافیک ارگانیک و دیدهشدن برند در نتایج جستجو.
۱ مهر ۱۴۰۵ · 7 دقیقه مطالعه
نسخه دیگر English
ورود با خروج از فلو وقتی تریپ قبلی تمام میشود (اختیاری با فیلتر مرحلهٔ خروج) فرد را وارد مسیر بعدی میکند؛ ورود با ایونت وقتی یک رفتار محصول/اپ آتش بگیرد — یکی برای زنجیر کردن جرنیهاست، دیگری برای واکنش به سیگنال زنده.
ورود با خروج از فلو و ورود با ایونت چه فرقی دارند؟
بعد از اینکه onboarding تمام شد، تیم میخواهد upsell را شروع کند. دو راه رایج است: «وقتی فلو A تمام شد وارد B شو» یا «وقتی ایونت Feature Used آمد وارد B شو.» اولی هندآف مسیر است؛ دومی واکنش به رفتار تازه.
ورود on-flow-exit به ایونت تکمیل تریپ فلو مبدأ گوش میدهد — گاهی با فیلتر روی اینکه از کدام مرحله/وضعیت خارج شده (هدف خورده، لغو، انقضا). ورود event entry به دامنهٔ محصول گوش میدهد: خرید، بازدید، کلیک، نصب.
به زبان برنامهنویس: on-flow-exit = subscribe به trip-complete فلو A بهعنوان enrollment فلو B؛ event entry = subscribe به domain event. اگر identity merge ممکن است با تأخیر باشد، بعد از exit کمی delay بگذار. این الگو مکمل جرنی در برابر کمپین است: کمپین یکباره هندآف ظریف ندارد؛ جرنی زنجیرهای دارد.
هر کدام چطور کار میکند؟
ورود با خروج از فلو
فلو onboarding تمام میشود → فلو «فعالسازی ویژگی پیشرفته» شروع میشود. میتوانی بگویی فقط اگر با موفقیت (goal) خارج شده، نه اگر unsubscribe کرده. مناسب وقتی مرحلهٔ بعدی به اتمام قرارداد مرحلهٔ قبل وابسته است، نه به یک کلیک تازه.
ریسک: اگر فلو A را عوض کنی و exitهایش شلوغ شوند، B ناگهان پر یا خالی میشود. قرارداد exit را مثل API بدان.
ورود با ایونت
همان upsell را با PowerFeature Clicked شروع میکنی. کسانی که onboarding را تمام نکردهاند ولی همان ویژگی را زدهاند هم ممکن است وارد شوند — مگر فیلتر بگذاری. مناسب وقتی سیگنال ارزش از رفتار محصول میآید، نه از تقویم اتمام فلو.
جدول مقایسه
| معیار | ورود با خروج فلو | ورود با ایونت |
|---|---|---|
| سیگنال | اتمام تریپ قبلی | رفتار دامنه |
| وابستگی | به طراحی فلو مبدأ | به schema ایونت |
| مناسب برای | هندآف مرحلهای لایفسایکل | واکنش لحظهای |
| ریسک | شکنندگی به تغییر exitهای A | ورود کسانی که مرحلهٔ قبل را ندیدهاند |
| فیلتر رایج | نوع/مرحلهٔ خروج | پراپرتی ایونت + پروفایل |
توالی پیشنهادی (قدمبهقدم)
۱. مرز مرحله را بنویس: onboarding چه وقت «تمام» است؟
۲. اگر تمامشدن همان سیگنال ارزش است → on-flow-exit.
۳. اگر ارزش با رفتار جداگانه معلوم میشود → event entry (+ فیلتر «onboarding complete» در صورت نیاز).
۴. برای race هویت، ۱–۳۰ دقیقه صبر بعد از exit.
۵. re-entry و سقف ورود را روی B جدا تنظیم کن.
۶. یک نمودار ساده در ویکی: A exits → B؛ و موازی event X → B.
مثالها
SaaS: خروج موفق از welcome → فلو آموزش ویژگی پولی. موازی: ایونت Limit Hit هم میتواند همان فلو را باز کند برای کسانی که زودتر به سقف رسیدند.
فروشگاه: خروج از سری خوشآمد → فلو دستهبندی محبوب. یا ایونت Category Viewed برای کسانی که خوشآمد را تمام نکردهاند ولی مرور میکنند — الگوی نزدیک به جرنی در برابر کمپین realtime ایونت.
بازگشت کاربر: گاهی بهتر است بهجای زنجیر سخت، از re-engagement در برابر winback استفاده کنی و ورود را روی ایونت/سگمنت غیرفعالی بگذاری نه روی exit یک فلو قدیمی.
نگاشت به Leadara
- Journeys: زنجیر A→B با on-flow-exit؛ یا B مستقل با ایونت.
- Events: هم trip-complete (اگر سیستم emit کند) هم domain events.
- Segments: فیلتر «مرحله را تمام کرده» وقتی exit خام نداری.
- Email/SMS: در هندآف، لحن را عوض کن؛ تکرار همان سه پیام onboarding در upsell = خستگی.
اشتباههای رایج
- زنجیر کردن همهٔ فلوها فقط چون کانوس زیبا میشود.
- فیلتر نکردن نوع خروج (موفق در برابر unsubscribe).
- فراموش کردن کسانی که از وسط با ایونت ارزش وارد میشوند.
- دو فلو موازی که بعد از exit و ایونت همزمان دو پیام میفرستند بدون اولویت.
جمعبندی
On-flow-exit = باتون را بعد از خط پایان بده. Event entry = با سیگنال تازه شروع کن. قرارداد مرحله را قبل از سیمکشی بنویس.
گام بعدی
یک جفت فلو که «باید پشت سر هم باشند» پیدا کن. بنویس سیگنال واقعی اتمام است یا رفتار؟ همان را enrollment کن؛ بقیه را فیلتر.
سؤالات پرتکرار
اگر فلو A را duplicate کنم B میشکند؟
اگر B به id فلو قدیم وصل است بله. مثل وابستگی API مدیریت کن.
میشود هم exit و هم ایونت؟
بله؛ موازی با اولویت/سقف ورود تا دوبار پیام نرود.
خروج ناموفق هم باید هندآف شود؟
گاهی به فلو جبران؛ نه لزوماً به همان upsell.
تأخیر بعد از exit لازم است؟
وقتی merge هویت یا بهروز سگمنت با تأخیر است، بله.
این همان journey orchestration است؟
نزدیک است به لایهٔ عملیاتی orchestration؛ ولی اینجا فقط نوع enrollment مطرح است.
برای win-back کدام؟
معمولاً ایونت/سگمنت غیرفعالی، نه exit یک فلو قدیمی سال پیش.
پیامک در هندآف؟
فقط اگر مرحلهٔ جدید ارزش واضح دارد؛ وگرنه ایمیل نرمتر است.
عمیقتر: قرارداد exit مثل API
تیم محصول فلو A را «رفاکتور» میکند و سه exit جدید اضافه میکند. ناگهان B سه برابر ورودی میگیرد چون «هر خروجی» را میشنود. جلسهای بگذارید و بگویید: B فقط به exit_reason = completed گوش میدهد. این را در نامگذاری و تست رگرسیون مثل endpoint نسخهدار نگه دارید.
اگر سیستم trip-complete emit نمیکند، سگمنت «پروفایلهایی که آخرین قدم A را دیدهاند و N روز گذشته» بساز — نه اینکه وانمود کنی on-flow-exit داری.
vignette ایران
اپ آموزش آنلاین: فلو خوشآمد ۷روزه. بعد از اتمام موفق، فلو «دوره پیشنهادی» شروع میشود (on-flow-exit با فیلتر completed). موازی، ایونت Lesson Completed برای کسانی که خوشآمد را skip کردهاند ولی درس تمام کردهاند همان فلو پیشنهاد را باز میکند با فیلتر has-not welcome_completed. دو درِ ورود، یک محتوا، سقف یکبار ورود.
اولویت وقتی دو درِ ورود همزمان بازند
اگر هم on-flow-exit و هم ایونت به یک فلو B میرسند، قبل از روشنشدن سیاست اولویت بنویس:
- اولین ورود برنده است و دومی در کولداون بلاک میشود؛ یا
- ایونت بر exit اولویت دارد چون سیگنال ارزش قویتر است؛ یا
- دو وریانت محتوا با تگ منبع enrollment.
بدون این سیاست، کاربر یک روز دو پیام مشابه میگیرد و روز بعد unsubscribe. در گزارشها هم entry_source را لاگ کن تا بدانی کدام در مؤثرتر است.
نسخه و تست رگرسیون
هر بار فلو A تغییر میکند، یک چکلیست رگرسیون برای B اجرا کن: exit موفق، exit انصراف، exit انقضا، و ایونت موازی. مثل smoke test API. اگر تیم جرنی کوچک است، حداقل یک پروفایل تست برای هر شاخه در استیجینگ نگه دار.
محتوای هندآف
پیام اول B نباید «دوباره خوش آمدید» باشد. باید فرض کند مرحلهٔ قبل را دیدهاند (اگر از exit موفق آمدهاند) و پلهٔ بعدی را بگوید. برای ورودیهای ایونتی که welcome را ندیدهاند، یک شاخهٔ کوتاه همترازسازی بگذار — سه خط کافی است، نه تکرار کل سری.
ماتریس تصمیم سریع برای مدیر محصول
| وضعیت | انتخاب enrollment | دلیل کوتاه |
|---|---|---|
| مرحله بعدی فقط بعد از اتمام قرارداد قبلی معنا دارد | on-flow-exit (فیلتر completed) | سیگنال اتمام همان درِ ورود است |
| ارزش با رفتار محصول معلوم میشود | event entry | رفتار از تقویم فلو جلوتر است |
| هر دو منبع مشتری میآورند | موازی + سقف یکبار | پوشش کامل بدون دوبار پیام |
| فلو مبدأ ناپایدار و زیاد تغییر میکند | سگمنت پروکسی بهجای exit خام | وابستگی شکننده کاهش مییابد |
| هدف بازیابی غیرفعالهاست | ایونت/سگمنت inactivity | exit قدیمی سیگنال ضعیف است |
این جدول را در کانال تیم پین کن. نصف بحثهای بیپایان enrollment با یک ردیف ماتریس جمع میشود.
هزینه پنهان زنجیر بیشازحد
هر لینک on-flow-exit یک وابستگی عملیاتی است: مالک فلو A عوض میشود، B بدون خبر میشکند. اگر بیش از دو هندآف پشت سر هم داری، احتمال دارد لایفسایکل را بیشازحد در کانوس کد کرده باشی. گاهی یک سگمنت مرحلهای (stage = onboarded) و ورود فیلترمحور پایدارتر از زنجیر سهتایی است.
قبل از افزودن حلقهٔ چهارم از خودت بپرس: اگر A را فردا حذف کنیم، چند مسیر میمیرد؟ اگر جواب بیشتر از یکی است، معماری enrollment را ساده کن.
