حذف از لیست سرکوب، ورود خودکار نمی‌سازد: رفع بلاک در برابر لبهٔ تریگر تازه
حذف از suppression فقط eligibility را برمی‌گرداند. جدول حقیقت، مثال پیامک ایرانی، و نگاشت به جرنی Leadara.
امیر حسینی
اجرای کمپین‌های ایمیل، پیامک و پوش برای جذب، نگهداشت و بازگشت کاربر.
۹ مهر ۱۴۰۵ · 6 دقیقه مطالعه
نسخه دیگر English
حذف از لیست سرکوب (یا جدا کردن suppression از جرنی) فقط بلاک را برمی‌دارد؛ مخاطب به‌خاطر اینکه هنوز با معیار ورود جور است، خودکار وارد جرنی نمی‌شود—تا وقتی یک لبهٔ ورود/ورود-مجدد تازه بخورد یا شما دستی enroll کنید.
حذف از لیست سرکوب یعنی چه؟
در خیلی از پلتفرم‌های اتومیشن، لیست یا سگمنت سرکوب یک قفل سخت روی فلو است: حتی اگر مخاطب با تریگر ورود جور باشد، تا وقتی روی suppress است وارد نمی‌شود (یا اگر داخل است، از مسیر خارج می‌شود). تیم ops گاهی فکر می‌کند «از بلک‌لیست برداشتم = باید الان داخل جرنی باشد.» این دو تا یکی نیستند.
- رفع بلاک (eligibility): شرط منفی برداشته شد؛ مخاطب می‌تواند دوباره وارد شود.
- ورود واقعی (enrollment edge): یک رخداد تازه مثل ورود به سگمنت، رویداد خرید، وب‌هوک، یا enroll دستی.
اگر فقط suppress را پاک کنید و هیچ لبهٔ تازه‌ای نباشد، مخاطب روی پروفایل می‌ماند—نه داخل سفر.
این را با هدف ورک‌فلو در برابر لیست suppress قاطی نکنید: آنجا تفاوت goal و suppress است؛ اینجا سؤال این است که بعد از برداشتن suppress چه اتفاقی برای ورود می‌افتد.
جدول حقیقت: suppress × معیار ورود × بعد از حذف
| وضعیت | هنوز با معیار ورود جور است؟ | روی suppress است؟ | بعد از حذف از suppress چه می‌شود؟ |
|---|---|---|---|
| A | بله | بله | هنوز خارج؛ بعد از حذف فقط eligible می‌شود—ورود خودکار نه |
| B | بله | نه (هرگز suppress نبود) | طبق تریگر ورود عادی (مثلاً segment enters / event) |
| C | خیر | بله | بعد از حذف هم وارد نمی‌شود تا معیار برقرار شود |
| D | بله | suppress از جرنی جدا شد (لیست detach) | معمولاً مثل A: eligibility برمی‌گردد، نه ورود دسته‌ای همهٔ مچ‌ها |
| E | بله | حذف شد + enroll دستی | وارد می‌شود (اگر پلتفرم اجازه دهد و هنوز suppress دیگری نباشد) |
نکتهٔ عملی: «حذف لیست از تنظیمات جرنی» ≠ «همهٔ کسانی که معیار دارند همین الان enroll شوند.» برای ورود دسته‌ای مخاطبان فعلی معمولاً تنظیم جداگانه‌ای مثل enroll-existing-at-activation لازم است—ببینید ورود مخاطبان فعلی در فعال‌سازی در برابر فقط آینده.
مثال ایرانی: بلک‌لیست پیامک بعد از کمپین
فرض کنید فروشگاه لوازم خانگی تهران برای کمپین بلک‌فرایدی یک سگمنت «شکایت از پیامک / opt-out موقت ops» ساخته و آن را به‌عنوان suppress روی جرنی سبد رهاشده گذاشته. بعد از حل تیکت‌ها، تیم رشد همه را از آن سگمنت خارج می‌کند و انتظار دارد همان شب SMS سبد دوباره برود.
واقعیت رایج:
- مخاطب از suppress خارج شد → قفل برداشته شد.
- اگر تریگر جرنی «ورود تازه به سگمنت سبد» یا «رویداد cart_updated» باشد و آن رویداد بعد از حذف suppress رخ ندهد، پیامک نمی‌رود.
- کسی که دیروز سبد را رها کرده و از آن وقت رویداد تازه‌ای نداشته، منتظر لبهٔ تازه یا enroll دستی می‌ماند.
راه‌حل عملی ops: بعد از پاک‌سازی suppress، یا یک رویداد/سگمنت‌ورود تازه طراحی کنید، یا لیست کوتاه را دستی enroll کنید و Quiet hours + رضایت پیامک (کاوه‌نگار/نیکالاین) را چک کنید.
اشتباه‌های رایج
- فرض «حذف suppress = ورود فوری همهٔ مچ‌ها»؛
- detach کردن لیست suppress از جرنی و انتظار backfill خودکار؛
- پاک کردن suppress ولی نگه‌داشتن exit/goal که همان مخاطب را دوباره بیرون می‌اندازد—مرتبط با هدف بدون ارسال در برابر تبدیل بعد از ایمیل؛
- enroll دستی کسی که هنوز روی سگمنت سرکوب دیگری است؛
- قاطی کردن suppress با هدف تبدیل (goal): goal خروج/ثبت موفقیت است، suppress قفل ورود/ادامه است.
نگاشت صادقانه به Leadara
در Leadara با journeys، segments و events:
- سگمنت‌های exclusion/suppress را مثل قفل سخت در نظر بگیرید؛
- بعد از خارج شدن مخاطب از سگمنت سرکوب، منتظر لبهٔ تازه بمانید: segment enters، رویداد رفتار، یا enroll دستی—نه «چون هنوز معیار دارد پس داخل است»؛
- برای پیامک از کانکتور کاربر (کاوه‌نگار/نیکالاین) و رضایت استفاده کنید؛
- Live Chat پشتیبانی انسانی است؛ AI Chat فقط دستیار داخلی تیم داخل داشبورد است—نه ربات پاسخ‌گوی مشتری.
ادعای رفتار دقیق نام‌های لیست HubSpot را روی Leadara کپی نکنید؛ اصل محصولی یکی است: رفع بلاک ≠ ورود.
کی ممکن است «به‌نظر برسد» خودکار وارد شده؟
| سناریو | چرا گمراه‌کننده است |
|---|---|
| تریگر «already in segment» یا ارزیابی دوره‌ای state | ممکن است بعد از برداشتن suppress در چرخهٔ بعد مچ شود—این لبهٔ سیستم است نه جادوی حذف suppress |
| مخاطب همان لحظه رویداد تازه می‌فرستد | ورود به‌خاطر رویداد است |
| فلو روی enroll-existing-at-activation دوباره publish شده | backfill جداست؛ ربطی به «حذف از لیست» ندارد |
| وب‌هوک خارجی همان روز هل می‌کند | ورود از هل خارجی است |
گام‌های عملی
- قبل از پاک‌سازی suppress، بنویسید تریگر ورود جرنی چیست (event / segment enters / webhook).
- جدول حقیقت بالا را با ۳ پروفایل QA پر کنید: روی suppress، بعد از حذف بدون رویداد تازه، بعد از حذف + رویداد تازه.
- اگر نیاز به ورود فوری دارید: لیست کوتاه را دستی enroll کنید یا رویداد/سگمنت‌ورود عمدی بسازید.
- چک کنید suppress دومی (مثلاً شکایت کل حساب) هنوز قفل نکرده باشد.
- Quiet hours و رضایت کانال را قبل از موج enroll دستی مرور کنید.
- در ران‌بوک ops بنویسید: «clear suppress ≠ auto-enroll».
- متریک موفقیت: زمان تا اولین پیام بعد از clear، و تعداد enroll دستی ضروری.
سؤالات پرتکرار
آیا حذف مخاطب از لیست سرکوب او را وارد ورک‌فلو می‌کند؟
خیر—فقط eligibility برمی‌گردد. ورود نیاز به لبهٔ تازه یا enroll دستی دارد.
اگر suppression list را از جرنی حذف کنم، آیا همهٔ مچ‌ها وارد می‌شوند؟
معمولاً نه. جدا کردن لیست قفل را برمی‌دارد؛ backfill همهٔ مخاطبان فعلی تنظیم جداگانه‌ای است.
می‌توانم کسی را که هنوز روی سگمنت سرکوب است دستی enroll کنم؟
اغلب پلتفرم اجازه نمی‌دهد یا فوراً unenroll می‌کند. اول از suppress خارجش کنید، بعد enroll.
فرقش با goal ورک‌فلو چیست؟
Goal معمولاً موفقیت/خروج بر اساس تبدیل است؛ suppress قفل منفی روی ورود یا ادامه است. جزئیات را در مطلب goal در برابر suppress بخوانید.
بعد از clear، سبد رهاشده کی SMS می‌گیرد؟
وقتی رویداد/ورود سگمنت تازه بعد از clear رخ دهد، یا وقتی دستی enroll کنید—نه صرفاً به‌خاطر clear.
آیا Leadara Live Chat این را برای مشتری توضیح می‌دهد؟
Live Chat پشتیبانی انسانی است. طراحی suppress و enroll کار تیم شماست؛ AI Chat فقط دستیار داخلی است.
برای مخاطبان فعلی در لحظهٔ فعال‌سازی چه کنم؟
اگر هدف backfill است، از منطق enroll-existing-at-activation استفاده کنید—نه از حذف suppress.
معیار موفقیت ops چیست؟
صفر غافلگیری «چرا وارد نشد؟»، QA سه‌پروفایلی سبز، و مستند یک‌خطی در ران‌بوک.
گام بعدی چیست؟
جرنی حساس (سبد، winback، VIP) را باز کنید. تریگر ورود را بنویسید، یک پروفایل را از suppress خارج کنید بدون رویداد تازه و ببینید وارد نمی‌شود، بعد همان پروفایل را با رویداد تازه یا enroll دستی وارد کنید. این تست را در چک‌لیست لانچ بگذارید.
