چگونه اتومیشن را در WebEngage بودجه‌بندی کنیم؟

در این مسئله، API فقط بخش قابل‌دیدن ماجرا بود. سؤال اصلی این بود که چطور می‌شود Journeyها همیشه فعال بمانند، اما هزینه و ریسکشان از کنترل خارج نشود؛ آن هم بدون اینکه هر بار کسی مجبور باشد دستی دخالت کند.

یکی از بزرگ‌ترین مزیت‌های ابزارهایی مانند WebEngage، امکان ساخت Journeyهای دائمی برای سناریوهایی مانند Churn Prevention، Acquisition و Lifecycle Marketing است. اما همین مزیت، زمانی که کسب‌وکار بزرگ‌تر می‌شود، می‌تواند به یک چالش جدی تبدیل شود.

فرض کنید یک Journey برای کاربران در معرض ریزش (Churn) طراحی کرده‌اید که هر روز اجرا می‌شود. اگر تعداد کاربران واجد شرایط به‌صورت ناگهانی افزایش پیدا کند، ممکن است Journey بدون هیچ محدودیتی پیام، پوش یا ووچر ارسال کند و در نتیجه هزینه کمپین از بودجه‌ای که برای آن در نظر گرفته‌اید فراتر برود.

در زمان نگارش این مقاله، WebEngage راهکار مستقیمی برای Budget Capping روی Journeyها ارائه نمی‌دهد. راهکار رایج این است که به جای Journey، کمپین‌های One-Time ساخته شوند و هر بار به‌صورت دستی اجرا شوند؛ اما این روش عملاً مزیت اتومیشن را از بین می‌برد.

راهکار: Budget Cap با یک API ساده

راهکاری که ما برای حل این مسئله استفاده می‌کنیم، اضافه کردن یک سرویس بسیار ساده برای مدیریت ظرفیت ارسال (Capacity Management) است.

ایده کاملاً ساده است:

• برای هر Journey یک ظرفیت (Capacity) تعریف می‌کنیم.
• مثلاً مشخص می‌کنیم این Journey در طول یک هفته فقط مجاز است ۱۰۰۰ ارسال داشته باشد.
• سپس دو API در اختیار Journey قرار می‌دهیم:
  • GET Capacity
  • POST Consume Capacity

معماری راهکار

فرآیند اجرای Journey به شکل زیر خواهد بود:

User enters Journey
        │
        ▼
GET /capacity
        │
        ├── Capacity > 0
        │         │
        │         ▼
        │    Send Message
        │         │
        │         ▼
        │   POST /consume
        │
        └── Capacity = 0
                  │
                  ▼
             Stop Journey

مرحله اول: بررسی ظرفیت

قبل از ارسال پیام، Journey از طریق API وضعیت ظرفیت را بررسی می‌کند.

اگر پاسخ API نشان دهد که هنوز ظرفیت باقی مانده است، Journey ادامه پیدا می‌کند.

مرحله دوم: ارسال پیام

در این مرحله Push Notification، SMS، Email یا هر اکشن دیگری اجرا می‌شود.

مرحله سوم: مصرف ظرفیت

بعد از ارسال موفق، Journey یک درخواست POST به سرویس ارسال می‌کند تا یک واحد از ظرفیت کم شود.

در نتیجه اگر ظرفیت اولیه ۱۰۰۰ بوده باشد، بعد از هر ارسال این عدد کاهش پیدا می‌کند تا در نهایت به صفر برسد.

چرا بهتر است هنگام اتمام ظرفیت Status Code را تغییر دهیم؟

بسیاری از افراد زمانی که ظرفیت صفر می‌شود همچنان پاسخ HTTP 200 برمی‌گردانند و داخل Response اعلام می‌کنند که ظرفیت تمام شده است.

اما تجربه نشان داده روش بهتری وجود دارد.

اگر هنگام اتمام ظرفیت، سرویس به جای 200 یکی از Status Codeهای محدوده 4xx (مانند 409 یا 429 بسته به طراحی سرویس) را برگرداند، خود Journey می‌تواند Failure را تشخیص دهد و روی آن اکشن انجام دهد.

این کار چند مزیت مهم دارد:

• خروج از Journey کاملاً استاندارد انجام می‌شود.
• می‌توانید مسیرهای مختلف برای Failure طراحی کنید.
• نیاز به Parse کردن Response وجود ندارد.
• کنترل Journey بسیار ساده‌تر خواهد شد.

مزیت اصلی این معماری

با این روش دیگر نیازی نیست هر هفته کمپین‌های One-Time بسازید.

کافی است:

• Journey همیشه فعال باشد.
• هر هفته Capacity موردنظر را تنظیم کنید.
• باقی کارها کاملاً خودکار انجام شوند.

به عنوان مثال:

هر Journey فقط تا سقف بودجه تعیین‌شده اجرا می‌شود و پس از آن به‌صورت خودکار متوقف خواهد شد.

این ایده فقط مخصوص WebEngage نیست

در واقع این الگو یک Budget Control Pattern برای سیستم‌های Marketing Automation است و تقریباً در هر ابزاری که امکان فراخوانی API در جریان اتومیشن وجود داشته باشد قابل پیاده‌سازی است.

به‌جای اینکه بودجه را در خود ابزار مدیریت کنید، آن را به یک سرویس مستقل منتقل می‌کنید؛ سرویسی که مسئول تصمیم‌گیری درباره ادامه یا توقف ارسال است.

نتیجه این معماری، اتومیشنی است که هم همیشه روشن است و هم هیچ‌وقت از سقف بودجه‌ای که برای آن تعریف کرده‌اید عبور نمی‌کند.

چیزی که از این راهکار یاد گرفتم

جداکردن کنترل بودجه از منطق هر Journey باعث شد قاعده‌ی هزینه برای مارکتینگ، محصول، مالی و فنی قابل‌فهم‌تر باشد و اتومیشن بدون کنترل دائمی یک نفر ادامه پیدا کند.

برای رسیدن به این راهکار، لازم بود مسئله‌ی هزینه را از زاویه‌ی چند تیم ببینیم و بعد آن را به قاعده‌ای ساده و قابل‌اندازه‌گیری تبدیل کنیم. آشنایی فنی کمک کرد محدودیت‌های اجرا را زودتر ببینم، اما بخش مهم‌تر پیدا کردن نقطه‌ای بود که نیاز کسب‌وکار و واقعیت سیستم به هم می‌رسیدند.