فلو با تریگر کاتالوگ در برابر فلو با تریگر ایونت: تغییر محصول در برابر عمل کاربر

فلو با تریگر کاتالوگ با فلو با تریگر ایونت چه فرقی دارد؟

فلو با تریگر ایونت وقتی شروع می‌شود که شخص کاری می‌کند (دیدن محصول، شروع چک‌اوت، رها کردن سبد). فلو با تریگر کاتالوگ وقتی شروع می‌شود که رکورد محصول عوض می‌شود (افت قیمت، برگشت موجودی، واریانت جدید) و به کسانی که آن محصول را دنبال می‌کنند فن‌اوت می‌شود.

یک‌خطی برای تیم eCRM: تریگر ایونت = عمل کاربر؛ تریگر کاتالوگ = تغییر وضعیت محصول. همان اینباکس، مالک جرقه فرق دارد.

فروشگاه‌های مد و دیجیتال در ایران معمولاً پیامک سبد رهاشده را خوب می‌سازند، بعد می‌پرسند چرا «برگشت موجودی» می‌لنگد. سبد تریگر ایونت است. برگشت موجودی و افت قیمت تریگر کاتالوگ‌اند — به فید محصول، لیست علاقه/ویولیست، و قاعدهٔ فن‌اوت نیاز دارند، نه یک لیسنر دیگر روی cart_updated.

این قاب مکمل انتخاب کانال روی سبد است: ایمیل سبد رهاشده در برابر پیامک.

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

فلو با تریگر ایونت

شخص ایونت رفتار می‌فرستد: product_viewed، cart_updated، checkout_started. فلو همان نفر را وارد می‌کند، صبر و پیام و خروج روی goal مثل order_completed. اندازه مخاطب با ترافیک رشد می‌کند. payload ایونت (SKU، مبلغ سبد) معمولاً پرسونالایز را می‌راند.

فلو با تریگر کاتالوگ

کاتالوگ (یا فید محصول) عوض می‌شود: قیمت از ۴٫۲ میلیون به ۳٫۵، موجودی از ۰ به ۱۲، رنگ جدید. سیستم افراد واجد شرایط همان SKU را پیدا می‌کند — دیده‌اند، ویولیست کرده‌اند، یا در سگمنت علاقه به دسته هستند — و برای هر نفر فلو را شروع می‌کند. جرقه ردیف محصول است، نه کلیک تازه.

مثال ایران: کفش و برگشت سایز

یک فروشگاه کفش در تهران پیامک سبد بعد از cart_updated را خوب دارد. سایز ۴۲ یک مدل پرطرفدار یک هفته صفر می‌شود، سه‌شنبه برمی‌گردد. تیم دستی به اکسل «کسانی که پرسیدند» پیامک می‌زند. نصف‌شان جای دیگر خریده‌اند؛ نصف رضایت SMS ندارند. در همان حال فلو سبد روی SKUهای دیگر کار می‌کند.

تشخیص

اصلاح عملی

1. سبد/چک‌اوت را تریگر ایونت نگه دار.
2. هوک کاتالوگ اضافه کن: موجودی از ۰ به مثبت؛ افت قیمت ≥ X٪.
3. واجد شرایط: بازدید SKU در ۳۰ روز، یا ویولیست، یا شروع چک‌اوت روی همان SKU — نه کل دسته.
4. اگر از زمان بازدید order_completed همان SKU آمده، suppress.
5. ایمیل برای شرح قیمت/موجودی؛ پیامک فقط با رضایت و سقف فرکانس.

برای تفاوت چک‌اوت و سبد: رها کردن چک‌اوت در برابر رها کردن سبد. قاب browse در برابر سبد: browse رهاشده در برابر سبد رهاشده.

چه وقت ایونت، چه وقت کاتالوگ؟

1. شخص همین الان در سشن کاری کرده؟ → تریگر ایونت.
2. محصول موجود یا ارزان‌تر شده و دنبال‌کننده‌ها باید بفهمند؟ → تریگر کاتالوگ.
3. هر دو: ایونت browse علاقه می‌سازد؛ بعداً تغییر کاتالوگ فلو اطلاع را شروع می‌کند.
4. فید محصول قابل‌اعتماد به سمت ایونت‌های Leadara دارید؟
5. قبل از فن‌اوت خریداران همان SKU را suppress می‌کنید؟

اتصال به Leadara: events، segments، journeys، ایمیل و پیامک

Leadara روی ایونت، سگمنت، جرنی، ایمیل و پیامک کار می‌کند. تریگر کاتالوگ را می‌توانی به‌صورت ایونت تغییر محصول که جرنی را شروع می‌کند مدل کنی، به‌همراه سگمنت دنبال‌کننده‌ها:

1. ایونت‌ها: cart_updated، product_viewed، checkout_started را نگه دار؛ product_back_in_stock / product_price_dropped را وقتی فید عوض شد از بک‌اند بفرست (نه از کلیک فروشگاهی).
2. سگمنت: «بازدید SKU X در ۳۰ روز»، «ویولیست شامل X»، suppress «خریدار X».
3. جرنی: مسیر سبد با تریگر ایونت؛ مسیر جدا برای اطلاع کاتالوگ با تأخیر کوتاه و خروج محکم.
4. ایمیل: شرح قیمت/موجودی با بلاک محصول؛ پیامک: پینگ کوتاه restock فقط با رضایت SMS.
5. Goal + guard: خرید همان SKU (یا خالی شدن سبد) مسیر را می‌بندد تا پینگ کهنه نرود.

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

• هر ایمیل محصول را «تریگر کاتالوگ» نامیدن وقتی فقط بلست هفتگی است
• فن‌اوت به همهٔ بازدیدکننده‌های یک‌سالِ دسته
• نبود suppress خرید روی restock
• استفاده از cart_updated به‌عنوان سیگنال جعلی موجودی
• پیامک افت قیمت بدون رضایت یا شفافیت مبلغ

سوالات پرتکرار

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

تریگر ایونت از عمل شخص شروع می‌شود؛ تریگر کاتالوگ از تغییر رکورد محصول و اطلاع به واجدین شرایط.

برگشت موجودی ایونت است یا کاتالوگ؟

جرقه وضعیت موجودی/کاتالوگ است. ممکن است بک‌اند product_back_in_stock بفرستد — باز هم منشأ کاتالوگ است، نه کلیک خریدار.

یک جرنی هم سبد هم افت قیمت را پوشش بدهد؟

بهتر دو جرنی با قوانین suppress مشترک. جرقه، کپی و بودجه فرکانس فرق دارد.

حتماً ویولیست لازم است؟

کمک می‌کند. پنجره علاقه browse (مثلاً بازدید SKU در ۱۴–۳۰ روز) فیلتر سبک‌تری است.

اگر فید تأخیر داشته باشد؟

پینگ restock بعد از اتمام دوباره موجودی اعتماد را می‌شکند. قبل از ارسال، موجودی زنده را چک کن.

آیا Leadara کاتالوگ کامل محصول برای تریگر دارد؟

تریگرها را با ایونت و سگمنت‌هایی که Leadara می‌فهمد می‌رانی؛ سیگنال تغییر محصول را از سرویس کاتالوگ به همان ایونت‌ها سینک کن.

متریک درست چیست؟

برای فلو کاتالوگ: اطلاع → خرید همان SKU، STOP، و نرخ هدررفت (پینگ به کسی که خریده). برای فلو ایونت: زمان تا تبدیل بعد از رفتار.

جمع‌بندی و قدم بعدی

تریگر ایونت = عمل کاربر؛ تریگر کاتالوگ = تغییر وضعیت محصول. این هفته سبد را ایونت‌محور نگه دار، یک جرنی برگشت موجودی با واجد شرایط بازدید ۳۰روزه + suppress خرید اضافه کن و با تبدیل همان SKU قضاوت کن — نه با حجم خام پیامک.

الگوی تست ۱۴ روزه

روز ۱–۲: از سرویس انبار product_back_in_stock بفرست.
روز ۳–۵: سگمنت بازدید ۳۰روزه + جرنی با ایمیل اول.
روز ۶–۱۰: پیامک اختیاری برای رضایت‌دارهای high-intent.
روز ۱۱–۱۴: نرخ خرید را با پینگ اکسلی مقایسه کن؛ STOP را ببین.

اگر B در تبدیل SKU برد و STOP کمتر شد، اکسل را بازنشسته کن.

زبان تیم: مالک جرقه کیست؟

در استنداپ بپرس: شخص کاری کرد یا ردیف محصول عوض شد؟ «سبد رها کرد» → ایونت. «سایز ۴۲ برگشت» → کاتالوگ.

چک‌لیست go-live برای تریگر کاتالوگ

1. ایونت تغییر محصول از انبار پایدار است؟
2. پنجره واجد شرایط مستند است (بازدید/ویولیست) نه «کل دیتابیس»؟
3. suppress خرید قبل از ارسال؟
4. چک موجودی زنده هنگام ارسال؟
5. بودجه فرکانس جدا از پیامک سبد؟
6. داشبورد: اندازه فن‌اوت، خرید SKU، STOP، ارسال روی موجودی صفر؟

بدون بند ۶، «restock اتومات شد» افسانهٔ عملیات است.

مرز با کمپین هفتگی محصول

بلست سه‌شنبه «وصولی‌های جدید» به کل لیست هنوز کمپین است. تریگر کاتالوگ یعنی ردیف مشخص SKU عوض شده و فقط واجدین شرایط وارد می‌شوند. اگر مرچندایزینگ داستان دسته می‌خواهد، کمپین؛ اگر انبار می‌گوید «سایز ۴۲ برگشت»، تریگر کاتالوگ + واجد شرایط.

قاطی کردنشان فوریت جعلی می‌سازد: یک نفر هم بلست دسته می‌گیرد هم پینگ restock همان کفش در یک بعدازظهر.

نشانه‌های سالم بودن فلو کاتالوگ

مطالب مرتبط

• ایمیل سبد رهاشده در برابر پیامک
• رها کردن چک‌اوت در برابر رها کردن سبد
• browse رهاشده در برابر سبد رهاشده