اسپلیت تریگر در برابر اسپلیت شرطی: دادهٔ همین ایونت در برابر تاریخچهٔ پروفایل

اسپلیت تریگر روی فیلدهای همان ایونتی که فرد را وارد فلو کرده شاخه می‌زند؛ اسپلیت شرطی روی ویژگی‌های پروفایل یا رفتار گذشته. برای «همین الان چه شد» تریگر، برای «این شخص کیست» شرطی.

اسپلیت تریگر و اسپلیت شرطی دقیقاً چه فرقی دارند؟

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

اسپلیت تریگر (trigger split) شاخه را با پراپرتی‌های همان ایونت ورود می‌سازد: مبلغ سبد، SKU، کانال فرم، کد کوپن، یا هر فیلدی که داخل payload همان لحظه است. اسپلیت شرطی (conditional split) شاخه را با attribute پروفایل یا کوئری روی ایونت‌های قبلی می‌سازد: VIP بودن، تعداد خرید، آخرین باز شدن ایمیل، عضویت در سگمنت.

اگر بخواهی یک جمله برای تیم محصول بگویی: تریگر یعنی branch روی event payload؛ شرطی یعنی branch روی profile store. این همان زبانی است که در جرنی adaptive در برابر rule-based هم می‌بینی — فقط اینجا تمرکز روی نوع شرط شاخه است، نه کل مدل مسیر.

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

اسپلیت تریگر چطور شاخه می‌سازد؟

فرض کن ورود با ایونت Cart Abandoned است. داخل payload فیلدهایی مثل cart_value، item_count، category داری. اسپلیت تریگر می‌گوید: اگر cart_value >= 2000000 برو شاخهٔ A، وگرنه شاخهٔ B. ارزیابی در همان لحظهٔ ورود (یا همان نود اسپلیت که به تریگر چسبیده) انجام می‌شود و به تاریخچهٔ پروفایل نگاه نمی‌کند مگر اینکه عمداً آن را هم قاطی کنی.

نکتهٔ عملی: اگر فیلد ایونت خالی باشد، شاخهٔ «else» یا مسیر پیش‌فرض باید تعریف شده باشد. خیلی از تیم‌ها شاخهٔ سوم «داده ناقص» می‌گذارند تا پیام اشتباه نرود.

اسپلیت شرطی چطور شاخه می‌سازد؟

همان فلو را تصور کن، ولی این‌بار می‌خواهی VIPها مسیر کوتاه‌تری ببینند. اسپلیت شرطی می‌پرسد: آیا پروفایل tier = vip است؟ یا آیا در ۳۰ روز گذشته خرید داشته؟ این داده از store پروفایل یا از سگمنت زنده می‌آید، نه لزوماً از payload همان Cart Abandoned.

شرطی برای تصمیم‌هایی است که به «هویت و سابقه» وابسته‌اند. اگر فقط به مبلغ همین سبد نگاه می‌کنی، شرطی اضافه است و فقط latency و پیچیدگی می‌آورد.

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

مثال‌های واقعی از فروشگاه و سرویس

فروشگاه مد: سبد رها شده. اگر cart_value بالای آستانه است → پیامک فوری با کد محدود؛ اگر پایین است → فقط ایمیل نرم. این تریگر است. اگر بعداً بخواهی VIPها اصلاً تخفیف نگیرند، آن شاخه شرطی روی tier است.

سرویس SaaS: ایونت Trial Started با فیلد plan_interest. تریگر شاخهٔ «می‌خواست Pro» در برابر «می‌خواست Free» می‌سازد. شرطی جداگانه می‌پرسد آیا قبلاً trial داشته یا نه — چون آن داده در payload فعلی نیست.

اپ فود: Order Placed با payment_method. تریگر می‌تواند مسیر «پرداخت در محل» را از «آنلاین» جدا کند. شرطی می‌تواند بگوید آیا کاربر در منطقهٔ ارسال سریع است یا نه.

چه وقت تریگر، چه وقت شرطی؟

۱. اگر تصمیم فقط با فیلد همین ایونت گرفته می‌شود → تریگر.
۲. اگر تصمیم به هویت، سطح، یا گذشته وابسته است → شرطی.
۳. اگر هر دو لازم است → اول تریگر برای جدا کردن «چه چیزی رخ داد»، بعد شرطی برای «با چه کسی حرف می‌زنیم». زنجیر کردن دوتایی بهتر از یک شرط غول‌آسا است.
۴. اگر فیلد ایونت را مرتب در پروفایل هم mirror می‌کنی، مواظب باش دو منبع یکی نشوند؛ برای شاخهٔ همان لحظه هنوز تریگر خواناتر است.

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

در Leadara فکر کن این‌طور:

• Events: هر اسپلیت تریگر به payload همان ایونت ورود وابسته است. ایونت را با پراپرتی‌های تمیز و نام‌گذاری پایدار بفرست (cart_value عددی، نه رشتهٔ مبهم).
• Segments: اسپلیت شرطی اغلب روی سگمنت زنده یا attribute پروفایل سوار می‌شود (مثلاً VIP، خریدار ۳۰روزه).
• Journeys: هر دو نوع شاخه داخل جرنی معنا دارند؛ تریگر نزدیک entry، شرطی در میانهٔ مسیر هم رایج است.
• Email/SMS: محتوای پیام را بر اساس شاخه عوض کن، نه اینکه دو فلو تقریباً یکسان بسازی. هزینهٔ پیامک در ایران یعنی شاخهٔ اشتباه = سوخت بودجه.

تمیز نگه داشتن event schema مهم‌تر از زیبا کردن کانوس است. اگر payload ناقص است، اول ingestion را درست کن، بعد اسپلیت بساز.

اشتباه‌های رایجی که گزارش را خراب می‌کنند

• گذاشتن شرط VIP داخل اسپلیت تریگر درحالی‌که VIP فقط روی پروفایل است.
• ساختن دو فلو جدا فقط برای دو SKU، درحالی‌که یک تریگر کافی بود.
• فراموش کردن شاخهٔ else وقتی فیلد ایونت گاهی null است.
• ارزیابی شرطی روی سگمنتی که nightly به‌روز می‌شود، برای تصمیم لحظه‌ای سبد.

جمع‌بندی یک‌خطی برای تیم

تریگر = شاخه روی «همین سیگنال». شرطی = شاخه روی «این پروفایل». اگر این دو را قاطی کنی، هم دیباگ سخت می‌شود هم پیام نامربوط می‌رود.

گام بعدی چیست؟

یک فلو سبد رها شدهٔ واقعی را باز کن. برای هر اسپلیت بنویس: منبع داده event است یا profile؟ اگر نتوانستی در ده ثانیه جواب بدهی، اسپلیت را دوباره طراحی کن. بعد یک جدول کوچک از فیلدهای payload و attributeهای لازم برای شاخه‌ها بساز و با تیم داده هم‌تراز کن.

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

اسپلیت تریگر همان فیلتر تریگر است؟

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

می‌توانم هر دو را پشت سر هم بگذارم؟

بله، و اغلب درست‌تر است: اول با تریگر «چه چیزی رخ داد» را جدا کن، بعد با شرطی «با چه کسی» را تنظیم کن.

اگر مبلغ سبد هم در پروفایل ذخیره شود کدام را انتخاب کنم؟

برای تصمیم همان لحظهٔ abandonment، تریگر روی payload ایونت پایدارتر است؛ mirror پروفایل ممکن است با تأخیر یا overwrite اشتباه همراه باشد.

اسپلیت شرطی برای سگمنت پویا مناسب است؟

بله، به شرطی که latency به‌روز شدن سگمنت با SLA همان نود بخواند. برای تصمیم زیر دقیقه، attribute مستقیم پروفایل معمولاً امن‌تر است.

چند شاخه در یک اسپلیت منطقی است؟

دو یا سه شاخهٔ واضح بهتر از هفت شاخهٔ تو در تو است. اگر بیش از سه حالت داری، چند اسپلیت پشت سر هم یا جدول تصمیم جدا بنویس.

آیا این موضوع به اتومیشن event-centric مربوط است؟

بله. وقتی سیستم event-centric است، اسپلیت تریگر طبیعی‌تر می‌نشیند؛ در مدل صرفاً contact-centric وسوسه می‌شوی همه‌چیز را شرط پروفایل کنی.

برای پیامک گران‌قیمت کدام مهم‌تر است؟

هر دو. تریگر جلوی ارسال به سبد خیلی کوچک را می‌گیرد؛ شرطی جلوی اسپم به VIP یا به کسانی که همین دیروز خریده‌اند را.

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

فرض کن فروشگاه لوازم خانگی داری و ایونت Cart Abandoned این فیلدها را می‌فرستد: cart_value، has_large_appliance، coupon_applied. پروفایل هم tier و last_purchase_at دارد.

۱. ورود به جرنی با ایونت سبد.
۲. اسپلیت تریگر اول: اگر has_large_appliance = true → مسیر مشاورهٔ تلفنی + ایمیل مشخصات نصب؛ وگرنه مسیر استاندارد.
۳. روی مسیر استاندارد، اسپلیت شرطی: اگر tier = vip → بدون تخفیف، فقط یادآوری موجودی؛ اگر نه → کد محدود ۱۲ساعته با پیامک.
۴. روی مسیر لوازم بزرگ، شرطی جدا: اگر last_purchase_at در ۹۰ روز گذشته است → پیام «نیاز به لوازم جانبی؟» به‌جای فشار تخفیف.

این زنجیره نشون می‌دهد تریگر و شرطی رقیب هم نیستند؛ لایه‌های مختلف تصمیم‌اند. وقتی تیم فقط یک اسپلیت «بزرگ» می‌سازد که هم SKU و هم VIP را قاطی می‌کند، دیباگ فردا غیرممکن می‌شود.

چک‌لیست قبل از پابلیش فلو

• برای هر شاخه یک جملهٔ فارسی نوشته‌ای که منبع داده را می‌گوید؟
• فیلدهای payload در استیجینگ با پروداکشن یکی هستند؟
• شاخهٔ else برای دادهٔ ناقص تست شده؟
• هزینهٔ پیامک هر شاخه برآورد شده؟
• سگمنت شرطی اگر استفاده شده، SLA به‌روز شدنش با زمان نود جور است؟

اگر یکی از این‌ها نه است، همان را قبل از روشن کردن فلو درست کن. زیباسازی کانوس بدون این چک‌ها فقط بدهی فنی می‌سازد.

مطالب مرتبط

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