এজেন্সিগুলো
একটি ফানেল, বিশ ক্লায়েন্ট, বিশটি আলাদা সুনাম
তিনজনের একটি এজেন্সি বিশটি স্থানীয় ব্যবসার মার্কেটিং চালালে একই সমস্যা বিশবার এবং একই সমাধান বিশবার থাকে — শুধু এই ব্যতিক্রম ছাড়া যে প্রতিটি ক্লায়েন্টের তালিকা, প্রেরণ পরিচয়, ডোমেইন ও সম্মতির রেকর্ড সম্পূর্ণভাবে তাদের নিজেদের থাকতে হবে। আসল কাজটা সেই "ব্যতিক্রম"-এর মধ্যেই।
প্রতি ক্লায়েন্টের জন্য একটি প্রজেক্ট, আর সীমানা রক্ষার দায়িত্ব ডেটাবেসের
এখানে সবকিছু একটি টেন্যান্ট ও একটি প্রজেক্টের সম্মিলিত পরিসরে থাকে — কন্টাক্ট, ফানেল, ক্রিয়েটিভ, ক্যাম্পেইন, প্রেরণ পরিচয়, রিপোর্ট। এই পরিসর ডেটাবেসের রো-লেভেল সিকিউরিটি দিয়ে প্রয়োগ করা হয়, কোনো কোয়েরিতে মনে রেখে যোগ করার শর্ত দিয়ে নয়। ভুলে যাওয়া কোনো প্রজেক্ট কিছুই দেখতে পায় না, প্রথম প্রজেক্টের সারিগুলো নয়।
এর অর্থ হলো এক ক্লায়েন্টের তালিকা ভুলবশত অন্য ক্লায়েন্টের ক্যাম্পেইনে ফাঁস হতে পারে না, এবং একটি রিপোর্ট এক ক্লায়েন্ট সম্পর্কেই হয়, কারণ কাঠামোগতভাবে এটি দুজনের সম্পর্কে হওয়াই অসম্ভব।
প্রতিটি ক্লায়েন্ট নিজের পরিচয়েই পাঠায়
একটি প্রেরণ পরিচয় একটি প্রজেক্টের অন্তর্গত: তাদের ডোমেইন, তাদের DKIM কী, তাদের মেইলবক্স বা তাদের প্রোভাইডার অ্যাকাউন্ট, তাদের রেট সীমা। এক ক্লায়েন্টের দুর্ভাগ্যজনক ক্যাম্পেইন অন্য ক্লায়েন্টের ডেলিভারেবিলিটির ক্ষতি করতে পারে না, কারণ ক্ষতি করার মতো কিছুই তারা কখনো ভাগ করেনি।
এতে একটি অস্বস্তিকর আলাপও শুরুতেই মিটে যায়। ক্লায়েন্ট তাদের প্রেরণ, তাদের তালিকা ও তাদের সম্মতির রেকর্ডের মালিক। তারা চলে গেলে — এবং কেউ কেউ যাবে — সবটা নিয়েই চলে যাবে, আর আপনাকে ব্যাখ্যা করতে হবে এমন কোনো জিম্মি পরিস্থিতি আপনি তৈরি করেননি।
- 1পরিচিতিপ্রতি প্রজেক্ট। ডেটাবেসে প্রয়োগ করা, মনে রাখতে হয় এমন কোনো কোয়েরি দিয়ে নয়।
- 2প্রেরণতাদের ডোমেইন, তাদের DKIM, তাদের মেইলবক্স বা প্রোভাইডার, তাদের রেট সীমা।
- 3সম্মতিতাদের নিজস্ব খতিয়ান। তারা চলে গেলে প্রমাণসহ সবটা তাদের সঙ্গেই যায়।
- 4প্রতিবেদনগঠনগতভাবেই প্রতি প্রজেক্ট। দুই ক্লায়েন্টের তথ্য ভুলবশত একত্রিত হওয়ার কোনো পথই নেই।
- iআপনি যা রাখেনফানেলের সংজ্ঞা এবং আপনার কাজের পদ্ধতি। এটিই আপনার পণ্য, আর এটিই পুনর্ব্যবহারের যোগ্য অংশ।
কোনো ভাগ করা সুনাম নেইকোনো ভাগ করা তালিকা নেই
কপি-পেস্ট ছাড়াই পুনর্ব্যবহার
ফানেলটি একবার তৈরি করুন। যতজন ক্লায়েন্ট আছে, ততবার স্থাপন করুন।
একটি ফানেল একটি গ্রাফ, আর একটি গ্রাফ হলো প্রকাশিত স্কিমাসহ JSON। অর্থাৎ আপনি যা পুনর্ব্যবহার করছেন তা একটি ডকুমেন্ট, প্রতিটি অ্যাকাউন্টে হাতে নতুন করে বানাতে হয় এমন কোনো স্ক্রিনের স্ক্রিনশট নয়।
আপনার নিজস্ব ফানেল
স্বাগত, পরিত্যক্ত ঝুড়ি, অনুপস্থিতি, বিরতি, পুনরুদ্ধার। যিনি সবচেয়ে ভালো পারেন তিনি একবারই লেখেন, আপনার নিজের রিপোজিটরিতে রাখেন, আর একটি API কলে ক্লায়েন্ট প্রজেক্টে তৈরি হয়।
সর্বত্র একইভাবে যাচাই
ভ্যালিডেটর আপনার ফানেলের ওপর চলে প্রতিটি প্রজেক্টে, যেখানেই সেটি পৌঁছাক। কোনো অপেক্ষা ছাড়া লুপ হয়ে যেত এমন গ্রাফ, বা বিষয় ছাড়া পাঠাত এমন গ্রাফ, সেখানেও প্রত্যাখ্যাত হবে ঠিক যেমন এখানে হয়।
চালানোর আগে সিমুলেশন
ওই ক্লায়েন্টের তালিকার একজন সত্যিকারের কন্টাক্টকে ফানেলের মধ্য দিয়ে ড্রাই-রান করুন এবং তাকে কী পাঠানো হতো তা দেখে নিন। প্রতিটি স্থাপনে একবার করলেই "ভুল করে চলে গেছে" জাতীয় আলাপ আর ঘটে না।
এক জায়গায় উন্নত
কিছু শিখলে — যেমন দ্বিতীয় রিমাইন্ডার সকাল দশটায় ভালো কাজ করে — আপনি সংজ্ঞা বদলে সেটি সামনে এগিয়ে দেন। পুরোনো সংস্করণে চলা ক্লায়েন্টরা পুরোনো সংস্করণেই শেষ করেন; চলমান কেউ বিঘ্নিত হয় না।
ক্রিয়েটিভও তাই
একটি ক্রিয়েটিভ হলো মার্জ ভেরিয়েবলসহ একটি ডকুমেন্ট। একই স্বাগত ইমেইল, প্রতিটি ক্লায়েন্টের ব্র্যান্ড, রং ও লোগো দিয়ে রেন্ডার করা — প্রথম চালানোতেই তাদের নিজের ওয়েবসাইট থেকে সংগ্রহ করা।
অথবা একটি এজেন্টকে করতে দিন
একটি অ্যাসিস্ট্যান্টকে MCP সার্ভারে নির্দেশ দিন, একটি প্রজেক্টের পরিসরে, আর ওই ক্লায়েন্টের জন্য ফানেল খসড়া ও যাচাই করান। কোনো সত্যিকারের মানুষের কাছে পৌঁছানো সবকিছুর জন্য স্পষ্ট নিশ্চিতকরণ এখনো দরকার এবং কোটার মধ্যেই থাকে।
এগারো ক্লায়েন্ট, এগারো প্রেরক, দেখার জন্য একটিই জায়গা।
মাসিক রিপোর্টের সমস্যা
একটি এজেন্সির রিপোর্টিং কষ্টের বেশিরভাগই সংখ্যা তৈরি করা নয়। সমস্যা হলো এমন সংখ্যা তৈরি করা যা ক্লায়েন্টের অনুসন্ধিৎসু প্রশ্নের পরেও টেকে, আর মাসের প্রথম দিনে তিন ঘণ্টা স্ক্রিনশট না নিয়ে সেগুলো তৈরি করা।
এখানে দুটি জিনিস সাহায্য করে। রিপোর্টগুলো API রুট, তাই মাসিক প্যাক একটি স্ক্রিপ্ট দিয়ে তৈরি করে PDF হিসেবে রপ্তানি করা যায়, কোনো ব্যক্তি ও স্প্রেডশিট দিয়ে নয়। আর সংখ্যাগুলো বট সম্পর্কে সৎ: কাঁচা ও ফিল্টার করা দুটোই লেবেলসহ পাওয়া যায়, তাই ক্লায়েন্ট জিজ্ঞেস করলে স্থানান্তরের পর ওপেন রেট কম কেন, আপনি এক বাক্যে ব্যাখ্যা করতে পারেন, চার বাক্যে রক্ষা করতে হয় না।
একই টাইলগুলো dash-b-তে পৌঁছায় — ক্যাম্পেইনের পারফরম্যান্স, ফানেল ড্রপ-অফ, তালিকার বৃদ্ধি, ডোমেইন অনুযায়ী ডেলিভারেবিলিটি — তাই লাইভ বোর্ড চাইলে ক্লায়েন্ট একটি পেতে পারেন, তাদের নিজের অ্যাকাউন্টে, তাদের নিজের ক্রেডেনশিয়ালসহ, পাতায় আপনার কোনো কী ছাড়াই।
- 1প্রতিটি প্রকল্পের জন্যএকটি টোকেন, একটি প্রকল্পের সুযোগ, একই স্ক্রিপ্ট।
- 2পুল করুনক্যাম্পেইনের পারফরম্যান্স, ফানেলে ঝরে পড়া, তালিকার প্রবৃদ্ধি, ডোমেইন অনুযায়ী ডেলিভারেবিলিটি।
- 3রেন্ডারতাদের ক্রিয়েটিভ ডকুমেন্ট একটি রিপোর্ট পেজ হিসেবে, তারপর PDF-এ।
- 4পাঠানঅথবা তাদের বোর্ডে ফেলে দিন। যেটা সেই ক্লায়েন্ট সত্যিই পড়ে।
- iকী পরিবর্তন হয়েছেস্ক্রিনশটের তিন ঘণ্টা একটি নির্ধারিত কাজে পরিণত হলো, কারণ রিপোর্টগুলো আসলে সবসময়ই রুট ছিল।
কাঁচা ও ফিল্টার করা, দুটোই লেবেলযুক্ত
সম্মতি নিয়ে কথাটা, শুরুতেই
প্রতিটি এজেন্সি এমন ক্লায়েন্টের মুখোমুখি হয়েছে, যিনি চার হাজার ঠিকানার একটি স্প্রেডশিট আর সেগুলো কোথা থেকে এলো সে বিষয়ে একটি অস্পষ্ট উত্তর নিয়ে আসেন। এখানে এটা এমন কোনো তর্ক নয় যা আপনাকে জিততে হবে; এটা একটি ফিল্ড।
ইমপোর্টটি সর্বোচ্চ বৈধ স্বার্থ (legitimate interest) হিসেবে গণ্য হয়, কখনোই সম্মতি হিসেবে নয়, এবং ভিত্তির মিশ্রণ যেকোনো ক্যাম্পেইন পাঠানোর আগেই দেখানো হয়। কোনো তালিকায় পাঠানো সম্ভব না হলে অভিযোগের সময় নয়, ইমপোর্টের মুহূর্তেই তা জানানো হয়। এতে একটি অস্বস্তিকর সিদ্ধান্ত পরিণত হয় একই স্ক্রিনের সম্মিলিত পাঠে — ক্লায়েন্ট জেদ করলে সেখানে থাকাটা আপনার জন্য অনেক ভালো অবস্থান।
ক্লায়েন্টকে মুখে বলার মতো কথা: খারাপ তালিকার কারণে যে সুনাম ঝুঁকিতে পড়ে তা তাঁদেরই, তাঁদের নিজের ডোমেইনে, কারণ প্রতিটি প্রকল্প নিজের পরিচয়ে পাঠায়। এটি যেকোনো আইনের চেয়ে জোরালো যুক্তি, এবং এটিই সাধারণত কাজ করে।