سلام. در این مقاله قصد دارم تجربه شخصی خودم را از راه‌اندازی یک پروژه مقیاس‌پذیر از صفر با استفاده از C# و React.js شرح بدهم.
پروژه موردنظر یک سیستم Engagement است که قرار است حجم زیادی از داده را مدیریت و پردازش کند. این سیستم باید امکان تعریف و اجرای کمپین‌های مختلف با ساختارهای متفاوت را داشته باشد. تعداد کاربران هر کمپین نیز می‌تواند حدود ۴۰۰ هزار نفر باشد.
سگمنت کاربران از سیستم‌های مختلفی مانند Metabase و Superset دریافت می‌شود. سپس سیستم باید این داده‌ها را پردازش کرده و بر اساس تنظیمات هر کمپین، اقداماتی مانند ارسال Push Notification، پیامک یا ایمیل را انجام دهد.
در ادامه، عملکرد کمپین و KPIهای مربوط به آن محاسبه می‌شود تا بتوان از نتایج به‌دست‌آمده برای برنامه‌ریزی ارسال‌های بعدی و ایجاد سگمنت‌های جدید استفاده کرد.
این پروژه در پاسخ به نیاز تیم داده طراحی شده است؛ تیمی که به سیستمی برای دریافت سگمنت از منابع مختلف، اجرای کمپین، ارسال پیام و اندازه‌گیری نتایج آن نیاز داشت.
پروژه از یک نیاز مشخص در تیم داده شروع شد: نیاز به بستری که بتواند سگمنت کاربران را از منابع مختلف دریافت کند، روی حجم بالایی از داده پردازش انجام دهد، کمپین‌های ارتباطی را اجرا کند و نتیجه هر اجرا را قابل اندازه‌گیری کند.
این سیستم در نهایت یک پلتفرم Engagement است. هر کمپین می‌تواند حدود ۴۰۰ هزار کاربر داشته باشد و بسته به تنظیمات خود، از کانال‌هایی مانند Push Notification، پیامک و ایمیل استفاده کند. داده کاربران نیز قرار است از منابعی مانند Metabase و Superset وارد سیستم شود.
اما هدف فقط ارسال پیام نبود. بخش مهم‌تر این بود که بعد از هر ارسال بتوانیم نتیجه کمپین را بررسی کنیم، KPIها را محاسبه کنیم و بر اساس داده‌های به‌دست‌آمده، برای ارسال‌ها و سگمنت‌های بعدی تصمیم بگیریم.
---
پیش از بررسی Featureها، ابتدا واقعیت‌های مسئله و محدودیت‌های موجود را مشخص کردیم.
از یک طرف، سیستم باید توان اجرای کمپین روی چندصد هزار کاربر را داشته باشد. از طرف دیگر، سگمنت کاربران در خود سیستم تولید نمی‌شد و باید از Data Providerهای مختلف دریافت می‌شد. همچنین هر کمپین می‌توانست ساختار، زمان‌بندی، کانال ارسال و منطق متفاوتی داشته باشد.
محدودیت مهم‌تر، نبود Tracking مستقیم و یکپارچه برای تمام رفتارهای کاربر بود. بنابراین امکان این‌که صرفاً با Event Tracking مشخص کنیم هر کاربر بعد از دریافت پیام چه عملی انجام داده، همیشه وجود نداشت.
این محدودیت از همان ابتدا روی طراحی سیستم اثر گذاشت و باعث شد مدل اندازه‌گیری نتیجه، یکی از تصمیم‌های اصلی پروژه باشد؛ نه صرفاً یک Feature جانبی.
---
پس از روشن شدن مسئله و محدودیت‌ها، وارد مرحله Product Discovery و Benchmarking شدیم.
با کمک ابزارهای هوش مصنوعی، مدل‌های مختلف و بررسی نمونه‌های موجود، قابلیت‌هایی که یک سیستم Engagement یا Campaign Management می‌تواند داشته باشد استخراج شدند. در این مرحله، هوش مصنوعی نقش ابزار تحقیق، دسته‌بندی و چالش‌کردن فرض‌ها را داشت؛ نه تصمیم‌گیرنده نهایی.
قابلیت‌های استخراج‌شده شامل مواردی مانند مدیریت کمپین، دریافت سگمنت، زمان‌بندی اجرا، مدیریت کانال‌های ارسال، قالب پیام، اجرای آزمایشی، کنترل نسخه، گزارش‌گیری، محاسبه KPI، مدیریت Goal و تحلیل نتیجه کمپین‌ها بودند.
---
در مرحله بعد، قابلیت‌های استخراج‌شده با نیاز واقعی تیم داده تطبیق داده شدند.
هدف این نبود که تمام Featureهای محصولات دیگر را وارد سیستم کنیم. بررسی کردیم کدام قابلیت‌ها برای نسخه اول ضروری هستند، کدام‌ها باید به مراحل بعدی منتقل شوند و چه نیازهایی داریم که در نمونه‌های بررسی‌شده، دقیقاً با مدل کاری ما پوشش داده نشده‌اند.
خروجی این مرحله یک تحلیل شکاف یا Gap Analysis بود: تفاوت بین قابلیت‌های متداول سیستم‌های مشابه و نیازهای اختصاصی پروژه.
---
یکی از مهم‌ترین شکاف‌ها، روش اندازه‌گیری نتیجه کمپین بود.
به دلیل نبود Tracking مستقیم برای همه رفتارهای کاربران، تصمیم گرفتیم اندازه‌گیری Goal و KPI بر اساس داده‌های موجود و Queryهای تیم داده انجام شود. برای هر اجرای کمپین یا Campaign Run، یک UTM یا شناسه قابل ردیابی در نظر گرفته می‌شود تا داده‌های بعدی بتوانند به همان اجرا مرتبط شوند.
سپس Goalها با Query مشخص می‌کنند که کاربر هدف، رفتار موردنظر را انجام داده است یا نه؛ برای مثال ثبت‌نام، ورود، خرید، سرمایه‌گذاری یا هر اقدام دیگری که برای کمپین تعریف شده باشد.
KPIها نیز روی خروجی Goalها و داده‌های مرتبط محاسبه می‌شوند؛ مانند تعداد کاربران تبدیل‌شده، نرخ تبدیل، مجموع مبلغ، میانگین مبلغ یا مقایسه عملکرد نسخه‌های مختلف یک کمپین.
این تصمیم باعث شد سیستم به یک ابزار Tracking خاص وابسته نباشد و بتواند از منابع داده و زیرساخت تحلیلی فعلی تیم داده استفاده کند.
---
در پایان این مرحله، قابلیت‌های ضروری سیستم در قالب یک Capability Checklist سطح‌بالا جمع‌بندی شدند.
این چک‌لیست مشخص می‌کرد نسخه اول سیستم باید بتواند سگمنت را از منابع داده دریافت کند، کمپین تعریف کند، Run قابل کنترل ایجاد کند، پیام را از کانال مناسب ارسال کند و نتیجه را با Goal و KPI اندازه‌گیری کند.
این سند وارد جزئیات پیاده‌سازی نمی‌شد؛ وظیفه‌اش کنترل Scope بود تا در ادامه مشخص باشد هر Feature جدید واقعاً به نیاز پروژه مرتبط است یا صرفاً پیچیدگی اضافه می‌کند.
---
بعد از تثبیت نیازمندی‌ها، قابلیت‌های ضروری و مدل اندازه‌گیری، وارد مرحله Technical Discovery و طراحی معماری اولیه شدیم.
در این مرحله باید مشخص می‌شد سیستم چگونه داده را از Data Providerها دریافت می‌کند، چگونه حجم بالای کاربران را پردازش می‌کند، اجرای Campaign Runها چگونه مدیریت می‌شود، ارسال از کانال‌های مختلف چگونه توسعه‌پذیر باقی می‌ماند و داده‌های لازم برای محاسبه KPI و Goal در چه ساختاری ثبت می‌شوند.
هم‌زمان، زیرساخت موجود، سرویس‌های در دسترس، APIها، محدودیت‌های دسترسی به داده و ظرفیت اجرای پردازش‌های حجیم بررسی شدند تا طراحی اولیه با واقعیت‌های محیط اجرا سازگار باشد.
ادامه در پست بعدی
