API برای انتقال داده میان سیستم شما و لژیون استفاده میشود. قبل از توسعه، مشخص کنید چه دادهای ارسال میشود، هر رویداد چه معنایی دارد و چگونه از ثبت دوباره جلوگیری میکنید.
API لژیون رابط فنی تبادل داده با سیستمهای دیگر است. میتوانید داده و رویدادهای پشتیبانیشده را با شناسه، زمان و ساختار مشخص ارسال کنید تا در پروفایل مشتری و سناریوهای لژیون استفاده شوند.
برندهایی که از لژیون برای مدیریت رابطه با مشتری استفاده کردهاند
اتصال فنی زمانی ارزش دارد که منبع حقیقت، هویت مشتری، زمان ایونت و مسئولیت هر سیستم روشن بماند. مسئلههای همین صفحه را قبل از توسعه دامنه اتصال بررسی کنید.
یک API بدون تعریف معنای رویداد میتواند داده معتبر از نظر فنی اما غلط از نظر کسبوکار تولید کند. کسبوکار ممکن است رفتارهای مهم مشتری را در نرمافزار داخلی یا اپ خود داشته باشد اما ابزار وفاداری به آن دسترسی نداشته باشد. API این فاصله را با قرارداد مشخص داده و رویداد پر میکند.
تلاش مجدد، خطای شبکه یا اجرای دوباره گردش کار میتواند یک ایونت را چند بار ارسال کند. اگر رویداد شناسه یکتا نداشته باشد، امتیاز، شمارش یا سفر مشتری ممکن است چند بار اجرا شود و داده مشتری را خراب کند.
اگر تاریخ واقعی ایونت حفظ نشود و همه دادههای درونریزی با زمان ارسال ثبت شوند، تحلیل تازگی خرید و سفرهای مشتری زمانمحور نتیجه نادرست میدهند. زمان ایونت باید بخشی از قرارداد یکپارچهسازی باشد. پیش از اتومیشن، باید معلوم باشد این مسئله با کدام داده قابل تشخیص است.
اگر هر سیستم نام فیلد و نوع داده متفاوتی بفرستد، نگهداری یکپارچهسازی دشوار میشود. طرحواره داده، نوع داده، الزامات فیلد و نسخهبندی باید قبل از توسعه بین دو سمت توافق شوند.
قابلیتهای این صفحه نشان میدهند اتصال فقط انتقال رکورد نیست؛ داده باید به هویت درست برسد و در ادامه بتواند در سگمنتبندی، سفر مشتری یا اقدام بعدی استفاده شود.
هر ایونت مهم میتواند با نوع رویداد، شناسه یکتا، زمان واقعی و اطلاعات لازم ارسال شود. شناسه رویداد باید پایدار باشد تا تلاش مجدد همان ایونت به ثبت تکراری منجر نشود.
ویژگیهای موردنیاز کسبوکار میتوانند برای غنیسازی پروفایل ارسال یا بهروزرسانی شوند. تعریف فیلد، نوع داده و منبع مالک آن باید روشن باشد تا چند سیستم مقدار یکدیگر را بهاشتباه بازنویسی نکنند.
علاوه بر خرید و ثبتنام، کسبوکار میتواند ایونتهای مرتبط با مدل خود را تعریف کند؛ مانند دریافت خدمت، تکمیل مرحله یا تعامل مشخص. این رویدادها سپس در سگمنت مشتریان و سفر مشتری قابل استفاده میشوند.
هر رویداد باید شناسهای داشته باشد که همان ایونت را بهصورت یکتا مشخص کند. ارسال دوباره همان شناسه نباید به ایجاد ایونت جدید و اجرای دوباره سناریو منجر شود؛ این موضوع برای تلاش مجددهای مطمئن ضروری است.
زمان ثبت باید نشان دهد اتفاق چه زمانی واقعاً رخ داده است، نه اینکه چه زمانی داده ارسالی به لژیون رسیده. این تفکیک برای داده تاریخی، گزارش و سناریوهای زمانمحور اهمیت زیادی دارد.
رویداد یا تغییر ویژگی میتواند محرک یا شرط باشد و مسیر اتومیشن را فعال یا شاخهبندی کند. قبل از استفاده باید مشخص شود تلاش مجدد، خطا و رویدادهای خارج از ترتیب چگونه مدیریت میشوند.
نتیجه اتصال باید در کیفیت داده، یکپارچگی هویت و امکان استفاده از ایونت در تصمیم بعدی مشتری دیده شود.
رفتارهایی که یکپارچهسازی آماده ندارند میتوانند از طریق API وارد لژیون شوند و بخشی از تصویر مشتری و سناریوهای عملیاتی باشند. رویدادها را با نمونههای واقعی، تکرار، ترتیب و زمان خارج از شبکه تست کنید.
رویداد تازه میتواند محرک سفر مشتری یا تغییر سگمنت مشتریان باشد و نیاز به انتقال دستی فایل یا اجرای پردازش دستهای جداگانه را کاهش دهد.
ویژگیها و رویدادهای سفارشی اجازه میدهند ساختار لژیون با اصطلاحات و فرایندهای واقعی هر کسبوکار هماهنگ شود.
تعریف شناسه، زمان ثبت و طرحواره داده مشخص باعث میشود یکپارچهسازی قابل تست، قابل مانیتور و در برابر ارسال تکراری مقاومتر باشد.
ترتیب مراحل کمک میکند قرارداد داده و مالکیت هر مرحله قبل از گسترش اتصال روشن بماند.
رویدادها، فیلدها، نوع داده، شناسه مشتری و شناسه رویداد مستند میشوند تا تیم مبدأ و مقصد یک برداشت مشترک از داده ارسالی داشته باشند.
روش دسترسی و نگهداری اطلاعات دسترسیها مطابق مستندات یکپارچهسازی تنظیم میشود و کلیدها نباید در بخش کاربر عمومی یا کد قابل دسترس کاربران قرار گیرند.
یک رویداد نمونه با زمان ثبت و شناسه مشخص ارسال میشود و نتیجه در پروفایل و تاریخچه بررسی میشود تا نگاشت پیش از توسعه کامل تأیید شود.
ارسال تکراری همان شناسه، داده ارسالی ناقص و پاسخهای خطا تست میشوند تا گردش کار منبع بتواند بدون ایجاد داده تکراری تلاش مجدد ایمن انجام دهد. اتصال کانال یا اقدام را بعد از تثبیت داده و منطق تصمیم انجام دهید.
پس از پایدار شدن داده، رویدادها در سگمنت مشتریان و سفر مشتری استفاده میشوند و مانیتورینگ یکپارچهسازی برای تشخیص خطا و افت حجم داده ادامه پیدا میکند. رویدادها را با نمونههای واقعی، تکرار، ترتیب و زمان خارج از شبکه تست کنید.
سناریوهای صفحه نشان میدهند داده ورودی چگونه باید به هویت مشتری و اقدام قابل استفاده متصل شود.
اگر فروش در برنامهریزی منابع سازمانی (ERP) یا بکاند اختصاصی ثبت میشود، همان ایونت با شناسه یکتا و تاریخ واقعی به لژیون ارسال میشود و میتواند روی امتیاز، سگمنت مشتریان یا سفر مشتری خرید بعدی اثر بگذارد. این سناریو را با یک گروه محدود، شرط خروج روشن و معیار نتیجه شروع کنید.
ثبت یک فرم، تکمیل شروع عضویت یا اقدام خاص در اپ میتواند رویداد سفارشی باشد. این رفتار برای سگمنتبندی تعامل یا شروع پیام بعدی استفاده میشود و لازم نیست به خرید محدود باشد. یک API بدون تعریف معنای رویداد میتواند داده معتبر از نظر فنی اما غلط از نظر کسبوکار تولید کند.
تغییر یک ویژگی مانند نوع قرارداد، شعبه مرجع یا وضعیت عضویت میتواند از سیستم مبدأ وارد شود. مالکیت فیلد باید روشن باشد تا همگامسازی دوطرفه باعث چرخه یا بازنویسی ناخواسته نشود. اگر مشتری رفتار هدف را انجام داد، مسیر باید بتواند متوقف یا تغییر کند.
در انتقال داده میتوان رویدادهای قدیمی را با زمان ثبت واقعی وارد کرد، به شرط اینکه شناسه یکتا و هویت مشتری قابل اتکا باشند. تاریخ درونریزی نباید جای تاریخ واقعی رفتار مشتری را بگیرد. مقایسه با رفتار طبیعی مشتری کمک میکند اثر سناریو بیشبرآورد نشود.
یک رویداد سفارشی میتواند شروع سفر مشتری باشد و پس از انتظار، شرطهای دیگر را بررسی کند. این الگو برای سناریوهای صنعتمحور مانند دریافت خدمت، تمدید یا تکمیل فرایند کاربرد دارد.
برای هر وابستگی باید نقش سیستم، منبع داده و رفتار خطا یا تلاش مجدد مشخص باشد.
ارسال رویداد و ویژگی مشتری از سرویسهای اصلی کسبوکار. در اتصال، هویت مشتری و زمان واقعی ایونت باید حفظ شوند.
برای تبدیل داده ارسالی و هماهنگسازی چند سیستم میتوان لایه واسط استفاده کرد. منبع حقیقت و رفتار داده تکراری را قبل از اجرای سناریو مشخص کنید.
رویداد و ویژگی در پروفایل مشتری و بخشهای مشتری استفاده میشوند. هدف یکپارچهسازی انتقال حداکثری داده نیست؛ داده باید کاربرد روشن داشته باشد.
رویدادهای معتبر میتوانند محرک یا شرط اتومیشن باشند. نمونه رکورد را از سیستم مبدأ تا استفاده نهایی انتهابهانتها کنترل کنید.
قبل از توسعه دامنه، منبع داده، قرارداد فیلدها، هویت مشتری و سناریوی خطا را روی دامنه محدود بررسی کنید.
در شروع، منابع داده مشتری، خرید و تعامل مشخص میشوند و کیفیت و ساختار اطلاعات بررسی میشود. این مرحله کمک میکند مدل اجرا روی داده واقعی کسبوکار طراحی شود و وابستگیهای فنی، محدودیتها و ریسکهای انتقال داده از ابتدا روشن باشند.
قواعد اصلی سگمنتبندی، وفاداری، ارتباط با مشتری و شاخصهای اندازهگیری متناسب با هدف سناریو تعریف میشوند. در این مرحله مشخص میشود هر قابلیت چه نقشی در سفر مشتری دارد و چه بخشی باید در فاز اول اجرا شود. دامنه فاز اول را عمداً محدود نگه دارید تا وابستگیها روشن بمانند.
اتصال سیستمهای فروش، فروشگاه اینترنتی، فایلها یا API انجام میشود و داده با ساختاری قابل استفاده وارد لژیون میشود. در صورت وجود داده تاریخی، هویت مشتری و تاریخ واقعی ایونتها باید تا حد امکان حفظ شود. تاریخ ایونت و هویت واقعی مشتری در انتقال داده نباید از بین بروند.
بخشهای مشتری، سفرهای مشتری، پیامها، قواعد وفاداری و تنظیمات موردنیاز ساخته میشوند. تمرکز این مرحله بر تبدیل طراحی اولیه به سناریوهای قابل اجرا، قابل تست و قابل اندازهگیری است؛ نه صرفاً فعال کردن مجموعهای از قابلیتهای جدا.
جریان داده، قوانین، مسیرهای اصلی و خروجیهای کلیدی پیش از انتشار تست میشوند. سپس تیم کسبوکار با منطق استفاده از سیستم آشنا میشود و استقرار با توجه به پیچیدگی اتصالها و دسترسیهای موردنیاز انجام میشود. استقرار پایان کار نیست؛ پس از اجرا باید کیفیت داده و رفتار سناریو بازبینی شوند.
پاسخ کوتاه به پرسشهایی که معمولاً هنگام بررسی این راهکار، نیازهای فنی و مسیر راهاندازی مطرح میشوند.
شناسه رویداد کمک میکند یک ایونت مشخص دوباره ثبت نشود. اگر ارسال بهدلیل خطا تکرار شد، همان شناسه باید حفظ شود.
پاسخ سؤال ۱در صورتی که تاریخ واقعی، شناسه یکتا و هویت مشتری در دسترس باشند، داده تاریخی میتواند با زمان اصلی ایونت ارسال شود. باید قبل از درونریزی انبوه روی نمونه کوچک تست شود تا ترتیب زمانی، جلوگیری از ثبت تکراری و اثر روی بخشهای مشتری و سفرهای مشتری قابل پیشبینی باشد. یک API بدون تعریف معنای رویداد میتواند داده معتبر از نظر فنی اما غلط از نظر کسبوکار تولید کند.
پاسخ سؤال ۲انتخاب کلید به مدل کسبوکار و منابع داده بستگی دارد. شماره موبایل، ایمیل یا شناسه داخلی هرکدام محدودیتهایی دارند. مهم است یک سیاست هویت مشخص وجود داشته باشد و نرمالسازی قبل از ارسال انجام شود تا یک مشتری به چند پروفایل شکسته نشود. رویدادها را با نمونههای واقعی، تکرار، ترتیب و زمان خارج از شبکه تست کنید.
پاسخ سؤال ۳سیستم مبدأ باید تلاش مجدد کنترلشده، ثبت خطا و شناسه ثابت رویداد داشته باشد. در تلاش مجدد همان ایونت نباید شناسه جدید تولید شود. همچنین بهتر است یکپارچهسازی مانیتور شود تا کاهش ناگهانی تعداد رویداد یا افزایش خطا بدون اطلاع باقی نماند. بهتر است اول روی یک نمونه محدود تست شود و بعد از تأیید داده و فرایند، دامنه اجرا بزرگتر شود.
پاسخ سؤال ۴بله، رویدادی که از API وارد میشود میتواند محرک یک سفر مشتری باشد، به شرط اینکه نوع رویداد و داده ارسالی آن در مدل لژیون قابل استفاده باشند. سفر مشتری باید شرایط توقف و رفتار در برابر رویداد تکراری یا دیررس را نیز در طراحی خود در نظر بگیرد. یک API بدون تعریف معنای رویداد میتواند داده معتبر از نظر فنی اما غلط از نظر کسبوکار تولید کند.
پاسخ سؤال ۵برای ووکامرس بهتر است ابتدا از یکپارچهسازی آماده لژیون استفاده شود. API زمانی لازم است که داده، ایونت یا فرایند اختصاصی خارج از پوشش اتصال آماده باشد. در اتصال سفارشی، شناسه مشتری، زمان ایونت و معنی هر ایونت باید از قبل مشخص شوند.
پاسخ سؤال ۶حداقل فهرست رویدادها، نمونه داده ارسالی، نوع و الزام فیلدها، شناسه مشتری، شناسه رویداد، زمان ثبت، نحوه احراز هویت و رفتار خطا و تلاش مجدد باید مشخص باشند. این قرارداد از اختلاف برداشت میان تیمها و تغییرات پرهزینه در میانه توسعه جلوگیری میکند. رویدادها را با نمونههای واقعی، تکرار، ترتیب و زمان خارج از شبکه تست کنید.
پاسخ سؤال ۷رویدادها را با نمونههای واقعی، تکرار، ترتیب و زمان خارج از شبکه تست کنید.
همه یکپارچهسازیهاپلتفرم داده مشتریباشگاه مشتریان لژیونمستندات فنی لژیونسفر مشتری خودکاردرخواست دمو
