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