clickSomo
باز کردن ClickSomo

تیم‌های SaaS و محصول

محصول شما چیزهایی می‌داند که هیچ ابزار بازاریابی نمی‌تواند ببیند

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

رویدادها کل یکپارچه‌سازی هستند

POST /v1/events با توکن خودتان: یک نام که شما انتخاب کرده‌اید، یک مخاطب، یک محموله، یک کلید یکسان‌سازی. کل اتصال همین است. نه SDK‌ای هست که به‌روز نگه دارید، نه صفحه‌ای برای نگاشت، و نه واژگانی از ما که مجبور باشید محصول خود را به آن ترجمه کنید.

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

همین مورد سوم است که پیام‌رسانی چرخه حیات را قابل تحمل می‌کند. تشویق به تکمیل راه‌اندازی حساب باید همان ثانیه‌ای که حساب راه‌اندازی شد از بین برود، و در بیشتر ابزارها نمی‌رود، چون دنباله و محصول با هم حرف نمی‌زنند.

فعال‌سازیاجرای #۲۱۱۸
  • ⚡راه‌اندازapi_event — signup.completed، طرح free.
  • 2ارسال ایمیلتنها کاری که اول باید انجام دهید. نه گشتی در یازده قابلیت.
  • 3صبر ۲ روزwake_at روی اجرا. هیچ چیز در صف نیست، و اگر فردا این را بازنویسی کنید چیزی برای باز کردن نیست.
  • ?شرطآیا project.created رسیده؟ نه ← شاخه راهنما. بله ← هدف پایین.
  • 4شاخه راهنمایک پیام، که همان کار مشخصی را که انجام نداده‌اند پیشنهاد می‌دهد. سپس یک صبر دوم.
  • 5هدفproject.created می‌رسد. اجرا پایان می‌یابد. دیگر هرگز هیچ ایمیل آنبوردینگی برای این شخص ارسال نمی‌شود.

نام رویدادهای شماتعریف شما از فعال‌سازی

پنج قیف

چرخه عمر، به همان ترتیبی که واقعاً رخ می‌دهد

۱ · فعال‌سازی

محرک: ثبت‌نام. دو یا سه پیام، هر کدام درباره یک اقدام، هر کدام با هدفی که با وقوع آن اقدام، دنباله را پایان می‌دهد. ارزشمندترین قیفی که خواهید ساخت، و یکی که بیش از همه ارزش سه بار بازنویسی را دارد.

۲ · رکود

محرک: segment_enter — ثبت‌نام کرده، اما هفت روز هیچ رویداد معناداری نداشته. یک پیام که می‌پرسد نه اینکه بگوید، و یکی که پیشنهاد مشخصی می‌دهد. سپس دست بکشید. پیام چهارم برای کسی که سه پیام را نادیده گرفته، پیامی است برای هیچ‌کس.

۳ · لحظه رشد

محرک: رویدادی که نشان می‌دهد ارزش دریافت می‌کنند — رسیدن به سقف، دعوت از همکار سوم، دومین برون‌سپاری خروجی. این تنها لحظه‌ای است که پیام ارتقا خوشایند است، و لحظه‌ای است که محصول شما می‌تواند آن را دقیقاً نام‌گذاری کند.

۴ · تمدید و وصول مطالبات

محرک: date_field پیش از تمدید، یا یک رویداد پرداخت. اطلاع‌رسانی، یادآوری، و — اگر پرداخت ناموفق بود — دنباله‌ای کوتاه که همان لحظه‌ای که موفق می‌شود متوقف می‌شود. گره‌های هدف در وصول مطالبات اختیاری نیستند؛ آن‌ها تفاوت میان یک یادآوری و آزار و اذیت‌اند.

۵ · بازگرداندن مشتری

محرک: segment_enter — لغو شده یا شصت روز غیرفعال. دو پیام، صادقانه، سپس یک برچسب و سکوت. «از زمان رفتن شما چه چیزهایی تغییر کرده» پیام بهتری از یک تخفیف است.

و مورد داخلی

notify_team به یک انسان خبر می‌دهد وقتی حسابی که ارزش توجه انسانی را دارد از حدی عبور می‌کند. قیف لازم نیست به ایمیل به مشتری ختم شود؛ گاهی اقدام درست این است که به کسی در سمت شما بگویید تلفن را بردارد.

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

چرا یک توسعه‌دهنده ممکن است واقعاً از این خوشش بیاید

بخش‌هایی که اهمیت دارند وقتی شما کسی هستید که یکپارچه‌سازی را انجام می‌دهید

بدون نقاط پایانی خصوصی

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

کلیدهای idempotency همه‌جا

روی هر مسیر تغییردهنده. منطق تلاش مجدد شما، صف at-least-once شما و شبکه ناپایدار شما همگی به مشکل کس دیگری تبدیل می‌شوند — دقیق‌تر بگویم، مشکل یک ایندکس یکتا.

شبیه‌سازی پیش از انتشار

POST /v1/simulate یک مخاطب را به‌صورت آزمایشی از یک قیف عبور می‌دهد و مسیر و هر پیامی که ارسال می‌شد را برمی‌گرداند. اگر بخواهید آن را در CI بگذارید: قیف یک گراف است، و گراف را می‌توان تست کرد.

یک سرور MCP

یک عامل (agent) را به /mcp اشاره دهید و بگذارید قیف‌ها را بنویسد و بررسی کند. ابزارهای دارای قابلیت ارسال به تأیید صریح نیاز دارند و سهمیه‌ای محدودشان می‌کند، پس یک پرامپت بدخوانده نمی‌تواند به پنجاه هزار ایمیل تبدیل شود.

وب‌هوک‌های خروجی

امضاشده، با backoff تلاش مجدد شده، حداقل یک بار. همان واژگان رویدادی که گزارش‌ها استفاده می‌کنند، تا انبار داده شما و داشبورد شما درباره معنای «تحویل‌شده» اختلاف نظر نداشته باشند.

محو اطلاعاتی که واقعاً می‌رسد

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

مرز کجاست

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

این جداسازی عامدانه است و دلیل کارکرد مدل رضایت همین است. شما مسئول داده (data controller) کاربران خود هستید؛ ما از طرف شما پردازش می‌کنیم. طراحی‌ای که در آن یک ابزار بازاریابی بی‌سروصدا به مخزن هویت تبدیل می‌شود، طراحی‌ای است که بعداً نمی‌توان گره‌گشایی‌اش کرد، و دقیقاً همان شکستی است که این طراحی برای پرهیز از آن ساخته شده.

نسخه عملی: رویدادها را ارسال کنید، ویژگی‌هایی را که می‌خواهید روی آن‌ها بخش‌بندی کنید ارسال کنید، و بقیه را سر جای خود نگه دارید. اگر دیدید دارید کل اسکیمای خود را به اینجا می‌رانید، احتمالاً بخشی که می‌خواهید بسازید یک کوئری در پایگاه داده خودتان است که باید به‌جای آن به‌صورت یک ویژگی بولی برسد.