ورود به جرنی با وبهوک در برابر ورود با رویداد رفتار: هل سیستم خارجی در برابر سیگنال خود کاربر
فرق enrollment با وبهوک و با ایونت رفتار: منبع سیگنال، هویت، جدول مقایسه، مثال فروشگاه و SaaS، نگاشت Leadara و FAQ.
سارا مرادی
طراحی سفر مشتری و کمپینهای مارکتینگ اتومیشن برای نگهداشت کاربر و کاهش ریزش.
۳ مهر ۱۴۰۵ · 8 دقیقه مطالعه
نسخه دیگر English
ورود به جرنی با وبهوک وقتی شروع میشود که یک سیستم خارجی payload را POST کند و به پروفایل موجود مپ شود؛ ورود با رویداد رفتار وقتی شروع میشود که خود همان پروفایل بعد از زنده بودن ورکفلو یک ایونت tracked بزند.
ورود با وبهوک و ورود با ایونت رفتار دقیقاً چه فرقی دارند؟
هر دو مسیر یک نفر را داخل جرنی میاندازند، ولی منبع سیگنال فرق دارد. در ورود با وبهوک (webhook-received enrollment)، هل از بیرون میآید: CRM فروش، درگاه پرداخت، ERP انبار، یا پنل پشتیبانی یک HTTP POST میفرستد و Leadara (یا هر MA) آن را به پروفایل وصل میکند و enrollment را fire میکند. در ورود با ایونت رفتار (event enrollment)، سیگنال از خود کاربر است: product_viewed، cart_updated، lesson_completed—همان استریم رفتاری که بعد از go-live زنده است.
اگر این دو را قاطی کنی، یا پیام را قبل از اینکه کاربر واقعاً کاری کرده بفرستی، یا منتظر سیگنالی میمانی که هرگز از کلاینت نمیآید چون منبع حقیقت جای دیگری است.
هر کدام چطور کار میکند؟
ورود با وبهوک
- سیستم خارجی رویدادی را در دنیای خودش ثبت میکند (مثلاً فاکتور صادر شد).
- به endpoint وبهوک شما POST میزند؛ payload معمولاً شناسه مشتری، نوع رویداد، و چند فیلد کمکی دارد.
- لایه دریافت، پروفایل را با email/phone/external_id پیدا یا میسازد.
- اگر ورکفلو روی «دریافت این وبهوک / این نوع پیام» enrollment داشته باشد، کاربر وارد جرنی میشود—حتی اگر هنوز هیچ کلیک یا بازکردنی در اپ شما نزده باشد.
ورود با ایونت رفتار
- SDK یا پیکسل یا API رویداد، رفتار کاربر را به استریم میفرستد.
- ورکفلو روی همان نام ایونت (و فیلترهای اختیاری) listen میکند.
- فقط وقتی پروفایل بعد از زنده بودن فلو آن ایونت را بزند وارد میشود—مگر جداگانه backfill گذاشته باشی.
- ترتیب و تکرار ایونتها مهم است؛ برای کنترل تکرار، سیاستهایی مثل هر ایونت در برابر یکبار در پنجره را جدا ببین.
| بُعد | ورود با وبهوک | ورود با ایونت رفتار |
|---|---|---|
| منبع سیگنال | سیستم خارجی (هل push) | خود کاربر / کلاینت (رفتار tracked) |
| وابستگی به SDK | معمولاً کم | معمولاً زیاد |
| زمانبندی نسبت به go-live | میتواند رویداد گذشته را هم هل کند | معمولاً فقط مچهای بعد از زنده بودن |
| ریسک هویت | مپ اشتباه external_id → پروفایل غلط | ایونت بدون شناسه پایدار گم میشود |
| مناسب برای | پرداخت، ERP، تیکت، وضعیت سفارش سمت سرور | browse، سبد، درس، کلیک داخل محصول |
| دیباگ | لاگ HTTP و retry وبهوک | نام ایونت، payload، و ترتیب استریم |
این جدول را کنار اتومیشن event-centric در برابر contact-centric بگذار: آنجا سؤال «استریم رفتار یا رکورد شخص» است؛ اینجا سؤال «هل بیرونی یا سیگنال خود کاربر برای ورود به جرنی» است.
مثال واقعی از فروشگاه و SaaS ایرانی
فروشگاه لوازم خانگی—وضعیت ارسال از ERP
ERP وقتی وضعیت را به shipped عوض میکند وبهوک میزند. جرنی «پس از ارسال» باید با وبهوک enroll شود، نه با امید به اینکه کاربر صفحه پیگیری را باز کند. ایونت tracking_page_viewed برای nurture بعد از باز کردن لینک خوب است، ولی برای خودِ شروع مسیر ارسال قابل اعتماد نیست.
اگر فقط روی ایونت رفتار enrollment بگذاری و بخشی از مشتریان لینک را باز نکنند، هیچوقت پیام «مرسوله حرکت کرد» را نمیگیرند—در حالی که حقیقت در ERP بوده.
SaaS آموزشی—خرید اشتراک از درگاه
درگاه بعد از پرداخت موفق وبهوک payment_succeeded میفرستد. این باید enrollment آنبوردینگ پولی باشد. ایونت first_lesson_started داخل محصول برای شاخه بعدی است، نه برای اولین ورود به مسیر «پرداخت شد». قاطی کردن این دو یعنی کاربر پول داده ولی تا وقتی درس را باز نکند هیچ آنبوردینگی نمیبیند.
پشتیبانی—تیکت بحرانی از هلپدسک
هلپدسک روی اولویت P1 وبهوک میزند تا جرنی «آرامسازی مشتری» با پیامک و ایمیل شروع شود. اینجا رفتار کاربر در اپ ممکن است صفر باشد؛ سیگنال از سیستم تیکت است.
کی وبهوک و کی ایونت؟
- حقیقت در سیستم دیگری است (پرداخت، انبار، CRM فروش) → وبهوک.
- حقیقت همان رفتاری است که در محصول خودت track میکنی → ایونت.
- اگر هر دو داری، enrollment را روی منبع حقیقت بگذار و ایونت دیگر را برای شاخه/صبر استفاده کن—نه برای دوبارهوارد کردن بیدلیل.
- برای مخاطبان فعلی در لحظه روشنشدن، سیاست جداگانهای مثل ورود مخاطبان فعلی در لحظهٔ روشنشدن در برابر فقط مچهای آینده لازم است؛ وبهوک بهتنهایی backfill را حل نمیکند مگر تاریخچه را replay کنی.
- تریگر «انجام نداده» را با وبهوک اشتباه نگیر؛ برای نبودن سیگنال، مطلب تریگر فیلتر «انجام نداده» در برابر تریگر ایونت را ببین.
نگاشت به Leadara (events، segments، journeys، email/SMS)
در Leadara این الگو را با بلوکهای موجود میسازی:
- Events: ایونتهای رفتاری را با نام پایدار تعریف کن (
order_completedنه گاهیpurchase). وبهوک ورودی را هم در صورت امکان به یک ایونت نرمالشده مپ کن تا گزارش یکدست بماند. - Journeys: enrollment را صریح انتخاب کن—«روی دریافت وبهوک/ایونت سیستم» در برابر «روی ایونت رفتار کاربر». شاخههای بعدی میتوانند صبر روی ایونت دیگر باشند.
- Segments: برای فیلتر کمکی (مثلاً فقط VIP یا فقط استان خاص) از سگمنت استفاده کن، نه بهجای خودِ منبع enrollment.
- Email / SMS: برای وبهوکهای عملیاتی (ارسال، پرداخت) پیامک کوتاه + ایمیل جزئیات؛ برای ایونتهای اکتشافی داخل محصول، ایمیل توضیحی اغلب بهتر است.
اشتباههای رایج
- Enrollment روی
page_viewبرای رویدادی که فقط در ERP رخ میدهد. - وبهوک بدون idempotency: هر retry یک بار دیگر وارد جرنی میشود.
- مپ کردن همه payloadها به یک پروفایل مهمان وقتی email خالی است.
- فرض اینکه «وبهوک = همیشه فوری»؛ صف و retry میتواند دقیقه یا ساعت تأخیر بدهد.
- دوبار enrollment: یکبار از وبهوک پرداخت و یکبار از ایونت
order_completedکلاینت بدون گارد re-entry. - تست فقط با Happy Path؛ نبودن فیلد
external_idرا در staging شبیهسازی کن.
جمعبندی یکخطی برای تیم
وبهوک = هل سیستم خارجی روی پروفایل مپشده؛ ایونت رفتار = سیگنال خود کاربر بعد از زنده بودن فلو.
گام بعدی چیست؟
یک جرنی زنده را باز کن که امروز «گاهی دیر» یا «گاهی اصلاً» enroll میشود. روی کاغذ بنویس: منبع حقیقت این شروع کجاست—سرور خارجی یا کلاینت کاربر؟ همان را enrollment کن و سیگنال دیگر را به شاخه منتقل کن.
سؤالات پرتکرار
اگر وبهوک و ایونت تقریباً همزمان بیایند چه؟
یک منبع را enrollment اصلی کن و روی دیگری فقط شاخه یا صبر بگذار. در غیر این صورت با re-entry دو مسیر موازی میگیری.
وبهوک برای کاربر جدید بدون پروفایل؟
اول هویت را بساز یا resolve کن؛ enrollment روی پروفایل یتیم گزارش را خراب میکند.
میشود ایونت گذشته را با وبهوک replay کرد؟
از نظر فنی بله اگر endpoint را با تاریخچه صدا بزنی؛ از نظر محصول باید بدانی کاربران «قدیمی» ناگهان پیام امروز میگیرند یا نه.
برای OTP یا تراکنش بانکی کدام؟
مسیر تراکنشی حساس را از nurture جدا نگه دار. وبهوک پرداخت برای شروع آنبوردینگ خوب است؛ خودِ OTP نباید داخل همان جرنی بازاریابی پیچیده شود.
تفاوت با تریگر «انجام نداده» چیست؟
«انجام نداده» روی نبودن سیگنال enroll میکند؛ وبهوک روی رسیدن سیگنال بیرونی. دو منطق مخالف.
چطور بفهمم وبهوک رسیده ولی enrollment نشده؟
لاگ دریافت، نتیجه resolve پروفایل، و شرط فیلتر enrollment را جدا چک کن. خیلی وقتها فیلتر سگمنت بعد از resolve شکست میخورد.
SMS از وبهوک ارسال و ایمیل از ایونت باز کردن صفحه؟
بله؛ کانال را به منبع سیگنال گره بزن. ارسال = پیامک؛ تعامل بعدی = ایمیل عمیقتر.
سناریوی قدمبهقدم برای تیم رشد
- رویداد شروع را به فارسی بنویس: «چه حقیقتی باید رخ دهد تا مسیر شروع شود؟»
- مالک آن حقیقت را مشخص کن: تیم محصول، مالی، انبار، پشتیبانی.
- اگر مالک خارج از اپ است → قرارداد وبهوک (فیلدها، retry، امضا).
- اگر مالک داخل اپ است → نام ایونت و فیلترها را در Leadara قفل کن.
- ده پروفایل تست: وبهوک تکراری، فیلد خالی، ایونت بدون شناسه.
- بعد از go-live یک هفته نرخ «enrolled ولی بدون پیام» را ببین—معمولاً فیلتر خاموش است.
طراحی مثل کد
on inbound_webhook(payload):
profile = resolve(payload.external_id | email | phone)
if profile and matches(enrollment_filters):
enroll(journey, profile, source="webhook")
on behavior_event(name, profile):
if journey.live and name in trigger_events and matches(filters):
enroll(journey, profile, source="event")
گاردها: idempotency key روی وبهوک؛ نام ایونت پایدار؛ یک منبع enrollment اصلی.
متریکهایی که باید ببینی
- نرخ resolve موفق وبهوک به پروفایل
- فاصله زمانی وبهوک تا اولین پیام
- سهم enrollment از وبهوک در برابر ایونت (باید با طراحی یکی باشد)
- ورودهای تکراری ظرف ۲۴ ساعت
زبان گزارش برای مدیر محصول
بهجای «اتومیشن خراب است» بگو: «enrollment روی page_view بود؛ حقیقت shipped در ERP است—سوییچ به وبهوک.»
چکلیست کانال
- وبهوک عملیاتی → پیامک کوتاه با لینک پیگیری
- ایونت اکتشافی → ایمیل با محتوا
- هر دو کانال را با یک منبع enrollment شروع کن، نه دو enrollment موازی
تست پذیرش
- همان وبهوک را دو بار با یک idempotency key بفرست → فقط یک enrollment.
- وبهوک با external_id ناشناس → مسیر resolve/create طبق طراحی (بدون تلنبار شدن روی پروفایل مهمان).
- ایونت رفتار قبل از go-live جرنی → نباید وارد شود (مگر backfill روشن باشد).
- وبهوک پرداخت enroll میکند؛
first_lesson_startedبعدی فقط شاخه است—سفر موازی دوم باز نکند. - وبهوک با تأخیر صف ۱۵ دقیقهای هنوز به پروفایل و نسخه کریتیو درست مپ شود.
در برابر enrollment «انجام نداده»
تریگر نبودن رفتار را میبیند؛ وبهوک رسیدن سیگنال بیرونی را. اگر ERP پست نکند، has-not نجاتت نمیدهد—مانیتورینگ خود لوله وبهوک لازم است.
