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 দিয়ে তৈরি করা সম্ভব, কারণ অন্য ধরনের কিছুই নেই। আপনি যদি নিজের অ্যাডমিনে একটি ক্যাম্পেইন রিপোর্ট এমবেড করতে চান, তবে কিছুই আপনার পথে নেই এবং কিছুই রিভার্স-ইঞ্জিনিয়ার করতে হবে না।
সর্বত্র আইডেম্পোটেন্সি কী
প্রতিটি মিউটেটিং রুটে। আপনার রিট্রাই লজিক, আপনার at-least-once কিউ এবং আপনার অস্থির নেটওয়ার্ক — সবই অন্য কারও সমস্যা হয়ে যায়; সুনির্দিষ্টভাবে বললে, একটি ইউনিক ইনডেক্সের সমস্যা।
শিপ করার আগে সিমুলেট করুন
POST /v1/simulate একটি কন্টাক্টকে ফানেলের মধ্য দিয়ে ড্রাই-রান করে এবং পথটি ও যে প্রতিটি মেসেজ পাঠানো হতো তা ফেরত দেয়। চাইলে এটি CI-তে রাখুন: ফানেল একটি গ্রাফ, আর গ্রাফ পরীক্ষা করা যায়।
একটি MCP সার্ভার
একটি এজেন্টকে /mcp-এ নির্দেশ করুন এবং ফানেল তৈরি ও যাচাই করতে দিন। পাঠানোর ক্ষমতাসম্পন্ন টুলগুলোর জন্য স্পষ্ট নিশ্চিতকরণ প্রয়োজন এবং কোটা দিয়ে সীমাবদ্ধ, তাই ভুল পড়া একটি প্রম্পট পঞ্চাশ হাজার ই-মেইলে পরিণত হতে পারে না।
ওয়েবহুক আউট
স্বাক্ষরিত, ব্যাকঅফ সহ রিট্রাই করা, অন্তত একবার। রিপোর্টগুলো যে ইভেন্ট শব্দভাণ্ডার ব্যবহার করে, ঠিক সেটিই — যাতে আপনার ওয়্যারহাউজ আর আপনার ড্যাশবোর্ড "delivered" মানে কী, তা নিয়ে একমত না হয়।
মুছে ফেলা যা সত্যিই পৌঁছায়
একটি ডিলিট অনুরোধ কন্টাক্ট ও তার মেসেজ ইতিহাস এখান থেকে সরিয়ে দেয় এবং কপি রাখা প্রতিটি সিবলিং সার্ভিসে ছড়িয়ে পড়ে। একটি অনুরোধ, একটি ফলাফল, এবং জিজ্ঞাসা করা হলে যা দেখাতে পারবেন।
সীমানা কোথায়
ClickSomo একটি মেইলিং লিস্ট এবং সেই লিস্ট কী করেছে তা রাখে। এটি আপনার ইউজার ডেটাবেস নয় এবং হওয়ার চেষ্টাও করে না: একটি কন্টাক্ট কখনো ক্রেডেনশিয়াল বহন করে না, কখনো সাইন ইন করে না, এবং কখনো অ্যাকাউন্টে পরিণত হয় না। আপনার ইউজাররা আপনার প্রোডাক্টে থাকে; কন্টাক্টরা এখানে থাকে, এবং দুটি যুক্ত হয় একটি ই-মেইল ঠিকানা ও আপনার পাঠানো ইভেন্টগুলোর মাধ্যমে।
এই বিভাজন ইচ্ছাকৃত, এবং এ কারণেই কনসেন্ট মডেলটি কাজ করে। আপনার ইউজারদের জন্য আপনিই ডেটা কন্ট্রোলার; আমরা আপনার পক্ষে প্রসেস করি। এমন একটি ডিজাইন যেখানে একটি মার্কেটিং টুল নিঃশব্দে আইডেন্টিটি স্টোর হয়ে যায়, তা পরে আর আলাদা করা যায় না — এবং এই ডিজাইন ঠিক সেই ব্যর্থতা এড়াতেই তৈরি।
ব্যবহারিক সংস্করণ: ইভেন্টগুলো পাঠান, যে অ্যাট্রিবিউটগুলোর ওপর সেগমেন্ট করতে চান সেগুলো পাঠান, এবং বাকি সব যেখানে আছে সেখানেই রাখুন। যদি দেখেন আপনি নিজের পুরো স্কিমা এখানে ঠেলে দিচ্ছেন, তবে যে সেগমেন্ট তৈরি করার চেষ্টা করছেন সেটি সম্ভবত আপনার নিজের ডেটাবেসের একটি কোয়েরি, যা একটি বুলিয়ান অ্যাট্রিবিউট হিসেবে আসা উচিত।