داده زنده وسط جرنی در برابر کاتالوگ میزبان: فیلد API در رانتایم در برابر سرچ کاتالوگ موقع رندر پیام
فرق داده زنده میانی جرنی با کاتالوگ میزبان: مسیر شکست، سقف حجم، مثال امتیاز و FAQ.
امیر حسینی
اجرای کمپینهای ایمیل، پیامک و پوش برای جذب، نگهداشت و بازگشت کاربر.
۲ مهر ۱۴۰۵ · 6 دقیقه مطالعه
نسخه دیگر English
کاشی داده زنده وسط جرنی یک وبهوک HTTPS صدا میزند، فیلدهای پاسخ را برمیدارد و برای مسیریابی/پرسونالایز با مسیر شکست مشخص استفاده میکند؛ کاتالوگ میزبان آیتمهایی است که داخل پلتفرم آپلود کردهای و بیشتر موقع رندر پیام سرچ میشوند.
داده زنده میانی جرنی و کاتالوگ میزبان چه فرقی دارند؟
در تیکتها دو جمله قاطی میشود: «قیمت را زنده بکش» و «از کاتالوگ محصول استفاده کن.» این دو انتخاب زیرساختی جدا با حالت شکست جدا هستند.
داده زنده = فراخوانی HTTPS وسط مسیر، مپ فیلد به تریپ، شاخه روی آنها، مسیر Failure صریح (سقف حجم/تعداد فیلد معمولاً گارد طراحی است).
کاتالوگ میزبان = آیتمهایی که در ابزار MA آپلود/سینک کردهای؛ سرچ بیشتر هنگام رندر ایمیل/پیامک—اگر اسنپشات داخل پلتفرم باشد، به بالا بودن APIتو در لحظه ارسال وابسته نیست.
هر کدام چطور کار میکند؟
داده زنده / Data Retrieval
کاشی جرنی endpoint را صدا میزند، در خیلی از ابزارها قبل از ذخیره تست موفق لازم است، فیلدها را انتخاب میکنی، و اگر خطا/تایماوت شد مسیر Failure میروی. همان فیلدها بعداً فیلتر و اسپلیت و متن پیام را تغذیه میکنند.
کاتالوگ میزبان
محصول/محتوا را آپلود یا سینک میکنی. موقع رندر (یا با قدم query روی collection) تمپلیت آیتم را با id یا ترجیح سرچ میکند. تازگی = آخرین سینک، نه قیمت میلیثانیهای PDP.
| بُعد | داده زنده | کاتالوگ میزبان |
|---|---|---|
| زمان اجرا | وسط جرنی | بیشتر رندر پیام / کوئری محلی |
| زیرساخت تو | API، auth، latency | سینک کاتالوگ داخل ابزار |
| شکست | مسیر Failure | آیتم نبود / سرچ خالی |
| مناسب برای | امتیاز، موجودی لحظهای، واجدشرایطی | کارت محصول پایدار |
| گارد | سقف payload، تایماوت | تأخیر سینک، کاملبودن کاتالوگ |
با پرسونالایزیشن در برابر سگمنتیشن: چه کسی پیام را میگیرد در برابر چه چیزی میبیند و اتومیشن event-centric در برابر contact-centric: استریم رفتار در برابر رکورد شخص بخوان تا لایهها قاطی نشوند.
مثال
امتیاز باشگاه از API
GET زنده /loyalty/{id} → points, tier. شاخه Gold → پیامک VIP؛ وگرنه ایمیل عادی. Failure → ایمیل بدون عدد امتیاز (عدد جعلی نساز).
کارت محصول از کاتالوگ
ایمیل بعد از خرید با last_product_id تصویر و نام را از کاتالوگ میگیرد—بدون زدن PDP در لحظه ارسال اگر سینک ساعتی کافی است.
آپسل حساس به موجودی
اگر موجودی دقیقهای عوض میشود، زنده (یا کش TTL کوتاه) بهتر از سینک ۱۲ ساعته است. اگر پایدار است، کاتالوگ ارزانتر و امنتر است.
کی کدام؟
- مقدار باید مسیر جرنی را عوض کند → داده زنده (یا پراپرتی ایونت از قبل).
- بلوک زیبای SKUهای شناخته → کاتالوگ.
- همیشه Failure داشته باش؛ روی تخفیف fail-open نکن.
- وبهوک را با payload شبیه پروداکشن تست کن.
- سکرت را در query نگذار؛ هدر بگذار.
نگاشت به Leadara
هسته صادق Leadara: events، segments، journeys، email/SMS. الگو را بدون اختراع فیچر مپ کن:
- Events: idهایی که بعداً لازم داری (
product_id,order_id). - Segments: واجدشرایطی قبل از خرج کردن API.
- Journeys: اول روی پراپرتی ایونت موجود شاخه بزن؛ اگر باید بیرون بزنی، رفتار Failure را مستند کن.
- Email / SMS: برای ظاهر محصول از ماژولهای کاتالوگمانند؛ عدد زنده را اگر ممکن است در subject نگذار.
اگر خودِ ورود باید از تغییر وضعیت محصول باشد، فلو با تریگر کاتالوگ در برابر فلو با تریگر ایونت را ببین.
اشتباههای رایج
- API زنده برای هر پیکسل ایمیلی که کاتالوگ میتواند بدهد
- نبود Failure
- JSON بزرگتر از سقف ابزار
- فرض realtime بودن کاتالوگ
- ریختن PII پاسخ وبهوک در attribute بدون سیاست نگهداری
جمعبندی یکخطی
داده زنده = فیلد API در رانتایم با مسیر شکست؛ کاتالوگ = سرچ قالب روی آیتم آپلودشده.
گام بعدی
سه فیلد پرسونالایز در جرنی اصلی را لیست کن. هر کدام L یا C. اگر همه L است، هزینه latency و حادثه اضافه میپردازی.
سؤالات پرتکرار
داده زنده همان outbound-only است؟
نه. outbound فقط خبر میدهد؛ retrieval فیلد برمیگرداند.
سقف حجم/تعداد فیلد؟
گارد طراحی: فیلد انتخاب کن، ERP کامل نریز.
آپدیت کاتالوگ خودش فلو را تریگر میکند؟
در بعضی استکها بله—با لوکاپ رندر فرق دارد.
Failure چطور؟
روی پول fail-closed؛ روی فیلد تزئینی fail-soft.
کش؟
TTL کوتاه جلوی endpoint؛ کهنگی را بنویس.
پیامک با قیمت زنده؟
اگر کال وسط ارسال بمیرد خطرناک است؛ ترجیح با پراپرتی ایونت از پیش محاسبهشده.
SLA endpoint با کی است؟
در تیکت: مارکتینگ مالک جرنی؛ بکاند مالک latency و چرخش auth.
راهاندازی ذهنی
- قرارداد JSON را بنویس.
- خلاق Failure بساز.
- با حجم مورد انتظار load-test کن.
- تصویر/عنوان از کاتالوگ؛ امتیاز/واجدشرایطی زنده.
- پروفایل واقعی + استاب ۵۰۰.
- نرخ ورود Failure را بعد از go-live ببین.
متریکها
- موفقیت کال / p95
- سهم مسیر Failure
- پوشش کاتالوگ (تصویر+url)
- شکایت قیمت/امتیاز غلط
خط تیکت
liveGET /loyalty/{id} → points,tier; failure=email_no_points; catalog کارت محصول سینک ساعتی; تخفیف fail-open ممنوع
گارد امنیت و حریم
- هدر auth نه توکن در URL
- حداقل فیلد روی تریپ
- در صورت امکان attributeها با خروج تریپ منقضی شوند
- بدنه کامل وبهوک را در HTML ایمیل پژواک نکن
در برابر پر کردن همه چیز در ایونت
اگر تولیدکننده میتواند loyalty_tier را روی order_completed بفرستد، شاید اصلاً به fetch میانی نیاز نباشد. اول ایونت؛ بعد زنده؛ کاتالوگ برای ظاهر.
ویگنت خردهفروشی ایرانی
فروشگاه لوازم الکترونیک میخواهد در پیامک وسط جرنی «اعتبار معاوضه شما X تومان» بفرستد. عدد باید از API زنده با مسیر Failure بیاید که پیامک عمومی «اعتبار را در اپ ببین» میفرستد—هرگز عدد حدسی. تصویر محصول در ایمیل بعدی میتواند از کاتالوگ ساعتی باشد. ترکیب درست، پول را از حادثه دور و ظاهر را تمیز نگه میدارد.
تست پذیرش
- HTTP ۵۰۰ استیجینگ → فقط Failure؛ صفر فیلد جعلی در اینباکس.
- تأخیر ۲ث → داخل بودجه تایماوت یا fail-closed.
- حذف SKU از کاتالوگ → کارت حذف شود نه URL شکسته.
- چرخش auth → مسئول بهروزرسانی سکرت مشخص باشد.
چکلیست نویسنده قبل از انتشار
- فقط فیلدهای انتخابشده
- خلاق Failure با پشتیبانی مرور شده
- گزارش پوشش کاتالوگ برای SKUهای پرترافیک
- ترجیح پراپرتی ایونت وقتی از قبل هست
- تا جای ممکن عدد فقطزنده در subject نباشد
## مطالب مرتبط
- پرسونالایزیشن در برابر سگمنتیشن: چه کسی پیام را میگیرد در برابر چه چیزی میبیند
- فلو با تریگر کاتالوگ در برابر فلو با تریگر ایونت: تغییر محصول در برابر عمل کاربر
- اتومیشن event-centric در برابر contact-centric: استریم رفتار در برابر رکورد شخص
