تریگر فیلتر «انجام نداده» در برابر تریگر ایونت: ورود روی نبودن در برابر رخداد

تریگر فیلتر «انجام نداده» می‌تواند کسی را وارد کند چون یک عمل غایب است (فرم نفرستاده، صفحه ندیده)؛ تریگر ایونت فقط وقتی آتش می‌گیرد که چیزی رخ داده باشد — پس has-not جای فیلتر یا شاخهٔ بعدی است، نه enrollment مبتنی بر استریم ایونت.

تریگر has-not و تریگر ایونت دقیقاً چه فرقی دارند؟

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

تریگر فیلتر has-not روی store پروفایل/تاریخچه می‌پرسد: آیا این عمل در بازهٔ زمانی X دیده نشده؟ اگر جواب «ندیده شده» باشد، فرد می‌تواند وارد شود (در مدل‌های فیلترمحور). تریگر ایونت فقط به fire شدن یک ایونت گوش می‌دهد: Form Submitted، Page Viewed، SMS Opened. چیزی که هرگز نیامده، استریم را تکان نمی‌دهد.

به زبان برنامه‌نویس: has-not = predicate روی missing history؛ event trigger = subscribe به stream. از استریم‌خوان انتظار نداشته باش به سؤال «هرگز رخ نداده؟» جواب بدهد — مگر اینکه جداگانه یک جاب batch بسازی. این تمایز همان روح اتومیشن event-centric در برابر contact-centric است.

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

تریگر فیلتر has-not

مثال: مخاطبانی که در ۳۰ روز گذشته demo_booked نداشته‌اند و lifecycle = lead. فیلتر می‌تواند آن‌ها را enroll کند چون کوئری روی نبودن ایونت است. مناسب برای nurture غیرفعال‌ها، یادآوری کار ناتمام، یا «هنوز onboarding را تمام نکرده».

محدودیت: باید بدانی محصولت has-not را در enrollment فیلتر پشتیبانی می‌کند یا فقط داخل if/then میانی. بعضی پلتفرم‌ها has-not را فقط به‌عنوان شرط پیام می‌پذیرند، نه به‌عنوان تریگر ورود.

تریگر ایونت

مثال: با Cart Abandoned وارد شو. فقط وقتی ایونت بیاید مسیر شروع می‌شود. نمی‌توانی بگویی «کسانی که Cart Abandoned نداشته‌اند» با همان تریگر ایونت — چون آن مجموعه دقیقاً کسانی‌اند که سیگنالی نفرستاده‌اند.

برای منفی‌ها یا باید فیلتر/سگمنت بسازی، یا بعد از ورود مثبت، با شاخهٔ شرطی بپرسی «آیا X را هم انجام داده؟» و مسیر را عوض کنی.

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

درخت تصمیم (شماره‌دار)

۱. می‌خواهی به «همین الان انجام داد» واکنش نشان دهی؟ → تریگر ایونت.
۲. می‌خواهی به «تا الان انجام نداده» برسی؟ → فیلتر/سگمنت has-not (یا جاب زمان‌بندی‌شده).
۳. می‌خواهی بعد از یک ایونت مثبت، مسیر را بر اساس نبودن عمل دیگر عوض کنی؟ → ورود با ایونت + اسپلیت/فیلتر میانی has-not.
۴. نمی‌دانی آیا محصول has-not را در enrollment دارد؟ → اول داک؛ بعد سگمنت معادل بساز.
۵. هزینهٔ پیامک بالاست؟ → has-not را با سقف و quiet hours قاطی کن؛ غیرفعال‌ها سریع به اسپم حساس می‌شوند.

مثال‌های واقعی

فروشگاه: کسانی که welcome ایمیل ۱ را باز نکرده‌اند. این has-not روی engagement است؛ معمولاً داخل فلو welcome با فیلتر پیام بعدی پیاده می‌شود، نه با تریگر ایونت «باز نکردن». باز نکردن ایونت fire نمی‌کند.

SaaS: لی‌هایی که صفحهٔ قیمت را دیده‌اند ولی demo_booked نداشته‌اند. سگمنت: has page_view pricing AND has-not demo_booked در ۱۴ روز. Enrollment فیلترمحور؛ نه انتظار از ایونت منفی.

اپ فود: کاربر آدرس ذخیره کرده (address_saved) ولی first_order ندارد. ورود می‌تواند با ایونت address_saved باشد و بعد فیلتر/صبر برای first_order؛ یا سگمنت روزانهٔ has-not first_order. هر دو معتبرند؛ تریگر «عدم سفارش» به‌تنهایی در استریم وجود ندارد.

نگاشت به Leadara

• Events: برای واکنش مثبت و لحظه‌ای. منفی را از استریم انتظار نداشته باش.
• Segments: خانهٔ طبیعی has-not و ترکیب‌های AND/OR روی تاریخچه.
• Journeys: ورود ایونتی + شاخهٔ میانی برای «آیا X را هم کرده؟» الگوی تمیز است.
• Email/SMS: پیام به «انجام‌نداده‌ها» را کوتاه و با ارزش نگه دار؛ وگرنه همان زمان‌بندی در برابر اتومیشن را خراب می‌کنی و به اسپم نزدیک می‌شوی.

اگر مسیرت باید وسط راه عوض شود، مدل جرنی adaptive در برابر rule-based را هم در نظر بگیر — ولی اولenrollment را درست انتخاب کن.

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

• ساختن تریگر ایونت با شرط «has not submitted form».
• فرض اینکه «باز نشدن ایمیل» مثل کلیک یک ایونت است.
• سگمنت has-not بدون بازهٔ زمانی (از ازل تا ابد) که نصف دیتابیس را می‌گیرد.
• پیامک روزانه به همهٔ «هنوز خرید نکرده‌ها» بدون سقف فرکانس.

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

Has-not روی نبودن در تاریخچه کار می‌کند؛ ایونت روی رخداد در استریم. منفی را روی فیلتر بگذار، نه روی fire ایونت.

گام بعدی

یک فلو که «انجام نداده» در عنوانش است باز کن. بنویس: enrollment از استریم است یا از کوئری؟ اگر نتوانستی جواب بدهی، تریگر را دوباره طراحی کن.

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

آیا هیچ‌وقت نمی‌توان با ایونت، منفی را گرفت؟

غیرمستقیم بله: ایونت مثبت ورود می‌کند، بعد شرط میانی has-not مسیر را عوض می‌کند. خودِ نبودن، ایونت نیست.

has-not برای «هرگز» یا «در بازه»؟

ترجیحاً بازه. «هرگز از ابتدا» اغلب بیش‌ازحد بزرگ و پرنویز است.

سگمنت nightly برای has-not کافی است؟

برای nurture روزانه بله؛ برای واکنش زیر‌دقیقه‌ای خیر — آنجا ورود ایونتی + شرط میانی بهتر است.

فرق فیلتر تریگر و فیلتر پروفایل میانی چیست؟

فیلتر تریگر دربارهٔ ورود است؛ فیلتر میانی دربارهٔ ادامه/اسکیپ یک قدم. has-not در هر دو جا ممکن است ظاهر شود ولی معنای عملیاتی فرق دارد.

چرا AIها گاهی می‌گویند ایونت has-not بساز؟

چون زبان محصول‌ها قاطی است. همیشه بپرس: این شرط روی stream است یا روی query؟

برای win-back کدام الگو؟

سگمنت has-not purchase در N روز + فیلتر enrollment یا کمپین زمان‌بندی‌شده؛ نه انتظار ایونت «خرید نکرد».

آیا باز نشدن پیامک ایونت است؟

معمولاً نه. عدم دریافت webhook باز شدن به‌معنای ایونت منفی قابل‌اتکا نیست؛ engagement منفی را با قاعدهٔ زمانی و سگمنت مدل کن.

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

تیم رشد می‌خواهد به کسانی که در ۷ روز بعد از ثبت‌نام app_open نداشته‌اند پیامک بدهد.

۱. ایونت Signed Up برای ورود لحظه‌ای به onboarding.
۲. صبر ۷ روز.
۳. شرط میانی: has-not app_open در ۷ روز → پیامک یادآوری؛ else مسیر آموزش پیشرفته.
۴. موازی: سگمنت روزانه برای کسانی که اصلاً وارد onboarding نشده‌اند (edge case ساخت پروفایل بدون ایونت).
۵. سقف پیامک و quiet hours.

این‌طور هم استریم و هم کوئری سرجایشان هستند.

الگوی ترکیبی که در عمل جواب می‌دهد

بهترین تیم‌ها has-not را قهرمان enrollment نمی‌کنند؛ آن را لایه‌بندی می‌کنند:

۱. ورود با ایونت مثبت واضح (ثبت‌نام، سبد، شروع trial).
۲. صبر معنادار با SLA کسب‌وکار.
۳. شرط میانی has-not برای انشعاب.
۴. سگمنت روزانه جدا برای کسانی که هرگز وارد لایهٔ ۱ نشدند (حفرهٔ داده یا مسیر جایگزین).

این چهار لایه هم دیباگ‌پذیر است هم با هزینهٔ پیامک ایران سازگارتر از یک سگمنت عظیم «هنوز نخربیده از ازل».

نگارش پیام برای «انجام‌نداده‌ها»

لحن اتهامی («چرا هنوز…؟») سریع unsubscribe می‌سازد. بهتر: مانع را بردار، ارزش را یادآوری کن، یک CTA. در پیامک یک خط؛ در ایمیل حداکثر یک اسکرول. اگر سه بار has-not پیام دادی و اثر نبود، به‌جای پیام چهارم، محصول یا onboarding را درست کن — اتومیشن جای نقص محصول را پر نمی‌کند.

تست صحت has-not

یک مجموعهٔ طلایی ۲۰ نفره بساز: ۱۰ نفر واقعاً عمل را کرده‌اند، ۱۰ نفر نه. سگمنت/شرط را روی آن‌ها ارزیابی کن. اگر حتی یکی غلط است، قبل از scale بایست. این تست ارزان‌تر از یک شنبهٔ پرشکایت است.

مطالب مرتبط

• اتومیشن event-centric در برابر contact-centric: استریم رفتار در برابر رکورد شخص
• مارکتینگ اتومیشن در برابر زمان‌بندی ارسال: واکنش به رویداد در برابر ساعت تقویم
• جرنی adaptive در برابر rule-based: تغییر مسیر وسط راه در برابر if/then ثابت

چرا این اشتباه این‌قدر رایج است؟

چون زبان محصول‌ها یکسان نیست. بعضی UIها فیلتر و ایونت را در یک پنل قاطی می‌کنند و لیبل «trigger» روی هر دو می‌گذارند. تیم رشد هم همان لیبل را در تیکت جیره‌بندی می‌کند. نتیجه: داک داخلی می‌گوید «تریگر has-not» درحالی‌که زیر پوست کوئری سگمنت است.

قبل از ساخت، یک جمله به فارسی بنویس: «ورود وقتی X رخ دهد» یا «ورود وقتی X در تاریخچه نباشد». اگر جمله اول است، ایونت؛ اگر دوم، فیلتر. این تمرین دهثانیه‌ای جلوی ساعت‌ها دیباگ را می‌گیرد.

کیفیت داده برای has-not

Has-not فقط به اندازهٔ ingestionت معتبر است. اگر app_open گاهی نمی‌آید، سگمنت «باز نکرده» پر از false positive می‌شود. قبل از پیامک انبوه:

• نرخ پوشش ایونت را در یک نمونهٔ تصادفی چک کن.
• نام ایونت را بین اپ و وب یکسان کن.
• برای کاربران anonymous که بعداً merge می‌شوند، تأخیر هویت را در نظر بگیر.

بدون این گاردها، has-not به معنای «داده ناقص» است نه «کاربر بی‌علاقه».