পরিচিতি ও সম্মতি
এমন একটি তালিকা যা আপনি রক্ষা করতে পারেন, শুধু যে তালিকা আপনার আছে তা নয়
দশ হাজার ই-মেইল ঠিকানা যে কেউ রাখতে পারে। যে প্রশ্নটি গুরুত্বপূর্ণ — যা একজন নিয়ন্ত্রক, একটি প্রোভাইডার এবং আপনার নিজের বিবেক সামান্য ভিন্ন শব্দে জিজ্ঞেস করে — তা হলো প্রতিটি ঠিকানা কোথা থেকে এসেছে এবং কী ভিত্তিতে আপনি সেখানে লিখতে পারেন। ClickSomo এটিকে পুনর্গঠন করার কিছু নয়, সংরক্ষিত একটি তথ্য বানায়।
পরিচয় মানেই ই-মেইল ঠিকানা
প্রতি প্রকল্পে প্রতি ঠিকানায় একটি পরিচিতি, আশার ওপর নয়, ডাটাবেস দ্বারা প্রয়োগকৃত। ঠিকানাগুলো লেখার সময় স্বাভাবিকীকৃত হয়, পড়ার সময় কখনও নয় — পড়ার সময় স্বাভাবিকীকরণ করলে সেই সীমাবদ্ধতা শুধুই একটি অলংকার হয়ে যায়, যা Anna@ এবং anna@ উভয়কেই ঢুকতে দেয়।
ফোন নম্বর থাকলে E.164 ফরম্যাটে সংরক্ষিত হয়, তবে ফোন নম্বর একটি বৈশিষ্ট্য, পরিচয় নয়। এখানে কোনো পরিচয়-নির্ণয় গ্রাফ নেই, কোনো মার্জ প্রোটোকল নেই এবং মার্জের কোনো অডিট ট্রেইল নেই, কারণ এখানে প্রতিটি পরিচিতি এমন একটি চ্যানেলের মাধ্যমে আসে যার ইতিমধ্যেই একটি ঠিকানা থাকে: একটি ইমপোর্ট, একটি ফর্ম, একটি সাবস্ক্রাইব, অথবা আপনার নিজের কোড।
নাম সম্পূর্ণভাবে সংরক্ষিত হয়
display_name যেভাবে দেওয়া হয়েছে সেভাবেই রাখা হয় এবং কখনও খণ্ডে ভাগ করা হয় না। নাম ভাগ করা একটি বাগ-উৎপাদক — "van der Berg", "Kim Min-jun", একক-নাম, উপাধি, এবং অ্যাংলো নয় এমন প্রতিটি ক্রম-রীতি — আর ভুল বিভাজন একটি মার্জ ট্যাগে "Dear van," রূপে ফুটে ওঠে, যা কোনো ব্যক্তিগতকরণ না থাকার চেয়েও খারাপ।
কাঠামোবদ্ধ অংশগুলো শুধুমাত্র সেই উৎসগুলোর জন্য বিদ্যমান যারা সেগুলো ইতিমধ্যেই আলাদা করে সরবরাহ করে। কিছুই সেগুলো অনুমান করে তৈরি করে না। আর কোনো ব্যক্তি নিজে টাইপ করা নাম কখনও পরে আসা কোনো CSV দ্বারা ওভাররাইট হয় না, যা ভিন্ন কিছু পর্যবেক্ষণ করেছে বলে কাকতালীয়ভাবে দাবি করে — কারণ last-write-wins নীতিতে সবচেয়ে অসাবধান ইমপোর্টই জিতে যায়।
- 1পরিচয়ই-মেইল, স্বাভাবিকীকৃত। প্রকল্পের মধ্যে অনন্য।
- 2নামসম্পূর্ণভাবে সংরক্ষিত।
first_nameরেন্ডারের সময় গণনা করা হয়, কখনও সংরক্ষণ করা হয় না। - 3বৈশিষ্ট্যসমূহআপনার পছন্দমতো যা-ই হোক, JSON আকারে। এগুলো আপনার, এবং
attrs.*হিসেবে ইন্টারপোলেটযোগ্য। - 4ট্যাগ ও তালিকাট্যাগগুলো প্রথম শ্রেণির বস্তু এবং একটি স্টোরে থাকে; তালিকাগুলো স্পষ্ট সদস্যপদ।
- 5সম্মতিপ্রতি চ্যানেলে একটি সারি, একটি বৈধ ভিত্তি এবং তার প্রমাণসহ।
- 6ইভেন্টসমূহএই ব্যক্তি যা কিছু করেছেন তার একটি শুধুমাত্র-সংযোজনযোগ্য লগ। পণ্যটি যে টেবিলের ওপর দাঁড়িয়ে আছে।
- ×কখনও নয়কোনো পাসওয়ার্ড নেই, কোনো হ্যাশ নেই, কোনো সেশন নেই, কোনো API কী নেই। কাউকে প্রমাণীকরণকারী একটি কলাম একটি ঘটনা হতো, বৈশিষ্ট্য নয়।
টেন্যান্ট ও প্রকল্প — উভয় ক্ষেত্রেই সীমাবদ্ধ
সম্মতি খাতা
অনুপস্থিতি অনুমতি নয়
প্রতি পরিচিতির জন্য প্রতি চ্যানেলে একটি সারি — ই-মেইল, SMS, চিঠি, পুশ — প্রতিটিতে একটি অবস্থা, একটি বৈধ ভিত্তি, একটি উৎস, প্রমাণ, টাইমস্ট্যাম্প এবং এখতিয়ারভুক্ত এলাকা থাকে। যে পরিচিতির কোনো চ্যানেলের জন্য ভিত্তি-সারি নেই, তাকে সেই চ্যানেলে কিছুই পাঠানো যাবে না। "পতাকাঙ্কিত" নয়। পাঠানো যাবেই না।
consent
কেউ সক্রিয়ভাবে অনুরোধ করেছেন। প্রমাণ সংরক্ষিত একটি ফর্ম জমা, একটি ডাবল অপ্ট-ইন, বা তিনি নিজে টিক দেওয়া একটি চেকবক্স। এটি সবচেয়ে শক্তিশালী ভিত্তি এবং একটি ফর্ম যে একমাত্র ভিত্তি তৈরি করতে পারে তা-ই এটি।
legitimate_interest
একটি CSV ইমপোর্ট সর্বোচ্চ যে স্তরে পৌঁছাতে পারে তা-ই এটি। একটি স্প্রেডশিট কারও কিছুতে সম্মতি দেওয়ার স্মৃতি রাখতে পারে না, তাই তাকে কখনও এমন দাবি করতে দেওয়া হয় না — এবং একই ফাইল পুনরায় আপলোড করলেও এটি উন্নীত হয় না।
contract
আপনি তাদের লিখছেন এমন কিছুর কারণে যাতে আপনি উভয়েই অংশীদার। সেবা স্মারক, নবায়ন নোটিশ — যা না পেলে তারা বিরক্ত হতেন।
একটি ক্যাম্পেইন পাঠানোর আগে, আপনি এর দর্শকের ভিত্তি-মিশ্রণ দেখতে পান: এদের মধ্যে কতজন নিজে অনুরোধ করেছেন, কতজনকে বৈধ স্বার্থের অধীনে পৌঁছাচ্ছেন, এবং কতজন চুক্তির কারণে এখানে আছেন। এটি একটি সংখ্যা যা এ পর্যন্ত লেখা যেকোনো সতর্কবার্তা-ব্যানারের চেয়ে বেশি খারাপ পাঠানো থামিয়েছে।
আপনার জন্য প্রয়োজনের চেয়েও কেন এটি কঠোর: এটি আসলে আপনার ব্যাপার নয়। বাল্ক পাঠানোর সুনাম একটি সাধারণ সম্পদ, এবং একটি অসাবধান তালিকা একই অবকাঠামো থেকে পাঠানো সবার জন্যই কূপ বিষাক্ত করে দেয়। প্রতি-টেন্যান্ট অভিযোগ ও বাউন্স হার পর্যবেক্ষণ করা হয়, এবং যে অ্যাকাউন্টের হার সীমা লঙ্ঘন করে তাকে এখানেই থ্রটল করা হয় — কোনো প্রোভাইডার সবার জন্য একসাথে তা করার আগেই।
তালিকার প্রতিটি সারির আড়ালে, কেউ একজন হ্যাঁ বলেছেন।
প্রবেশের চারটি পথ
আপনার তালিকায় প্রতিটি পথই আপনি, আপনার নিজের ডেটার ওপর কাজ করছেন
এখানে কোনো সার্ভিস-টোকেন ইনজেস্ট লেন নেই এবং কোনো সহোদর পণ্য নীরবে আপনার পরিচিতিগুলোতে লিখছে না। আপনি যদি কাউকে একটি তালিকায় রাখতে চান, এই চারটির একটি তাকে সেখানে রেখেছে।
CSV ইমপোর্ট
কলাম ধরে ধরে ম্যাপ করা, লেখার সময় স্বাভাবিকীকৃত, MX-যাচাইকৃত যাতে মৃত ও ভুল-বানানের ডোমেইন হার্ড-বাউন্সের আগেই ধরা পড়ে, এবং আপনার স্পষ্টভাবে নির্ধারিত একটি ভিত্তি নিয়ে সংরক্ষিত। ইমপোর্টটি একটি আইডি পায়, এবং এটি তৈরি করা প্রতিটি পরিচিতি সেই আইডির দিকে নির্দেশ করে।
একটি ClickSomo ফর্ম
বাকি সবকিছুর মতো একই ডকুমেন্ট থেকে রেন্ডার করা, ভ্যালিডেশন, একটি হানিপট এবং একটি রেট লিমিটসহ। একটি জমা হলো একমাত্র পথ যা বৈধভাবে consent তৈরি করতে পারে, কারণ এটিই একমাত্র পথ যেখানে ব্যক্তি উপস্থিত থাকেন।
dash-b-তে আপনার নির্মিত একটি পৃষ্ঠা
ড্যাশবোর্ড ডিজাইনার পৃষ্ঠা প্রকাশ করে; এর কোনো একটির ওপর থাকা ফর্ম আপনার নিজের ক্রেডেনশিয়াল দিয়ে এখানে পোস্ট করে। একই ভ্যালিডেশন, একই সম্মতি-ব্যবস্থাপনা, রক্ষণাবেক্ষণের জন্য কোনো দ্বিতীয় ইন্টিগ্রেশন নেই।
পাবলিক API
আপনার নিজের টোকেন সহ POST /v1/contacts, upsert আচরণ, আইডেম্পোটেন্সি কী সম্মানিত। আপনার অ্যাপ ইতিমধ্যেই জানে কে সাইন আপ করেছেন; সেই তথ্য থেকে একটি ফানেলে পৌঁছানোর সবচেয়ে ছোট পথ এটি।
সেগমেন্ট হলো একটি প্রেডিকেট, কম্পাইল করা
একটি সেগমেন্ট হলো পরিচিতির ফিল্ড, অ্যাট্রিবিউট, ট্যাগ, তালিকার সদস্যপদ ও আচরণের ওপর একটি সংরক্ষিত প্রেডিকেট ট্রি, যা SQL-এ কম্পাইল হয় এবং একটি গণনাসহ ক্যাশ করা থাকে। অপারেটরগুলো সাধারণ ধরনেরই — সমান, সমান নয়, এর মধ্যে, এর মধ্যে নয়, দিয়ে শুরু, দিয়ে শেষ, ধারণ করে, সেট করা আছে, সেট করা নেই — এবং সেগুলো and, or ও not দিয়ে যত গভীরে প্রয়োজন একত্রিত করা যায়।
ব্যবহারের আগে প্রিভিউ দেখে নিন। এন্ডপয়েন্ট প্রকৃত পরিচিতিগুলো ফেরত দেয়, তাই "এর মধ্যে আসলে কারা আছে" — এই প্রশ্নের উত্তর আপনি পাঠিয়ে জেনে নয়, দেখে নেন।
সেগমেন্ট তখন দ্বৈত ভূমিকা পালন করে: একটি ক্যাম্পেইনের দর্শক হিসেবে, একটি ফানেল শাখার শর্ত হিসেবে, এবং নিজেই একটি ট্রিগার হিসেবে — segment_enter কেউ যোগ্য হওয়ার মুহূর্তেই একটি রান শুরু করে।
- 1ট্যাগ
tags contains "regular" - 2অ্যাট্রিবিউট
attrs.total_orders >= 3— আপনার ফিল্ড, তার জন্য আপনার নাম। - 3আচরণগত ৯০ দিনে কোনো
order.paidইভেন্ট নেই। - 4সম্মতিএকটি ব্যবহারযোগ্য ই-মেইল ভিত্তি। যাদের তা নেই তারা গণনায় আসে না, কারণ তাদের কাছে পাঠানোই সম্ভব নয়।
- iপ্রিভিউ৪১২টি পরিচিতি, তালিকাভুক্ত। পাঠানোর সময় আবার গণনা করা হয়, কারণ সেগমেন্ট একটি প্রশ্ন, স্ন্যাপশট নয়।
SQL-এ কম্পাইল করাগণনা ক্যাশে, উত্তর লাইভ
সাপ্রেশন এবং কখন তা পরীক্ষা করা হয়
সাপ্রেশন প্রজেক্ট-স্কোপড ও গ্লোবাল: হার্ড বাউন্স, অভিযোগ, আনসাবস্ক্রাইব, ম্যানুয়াল এন্ট্রি এবং রোল অ্যাড্রেস। সেগুলো পাঠানোর সময়ে পরীক্ষা করা হয়, এবং তারপর আবার পাঠানোর সার্ভিসের ভেতরেও।
দ্বিতীয় পরীক্ষাটিই আসল কাজটি করে। তিন দিনের অপেক্ষা থাকা একটি ফানেলে তিন দিনের সময়সীমা থাকে, যার মধ্যে কেউ আনসাবস্ক্রাইব করতে পারে, এবং মেসেজ কিউ হওয়ার সময় সাপ্রেশন পরীক্ষা করা একটি সিস্টেম তবুও তাদের মেইল পাঠাবে। পাঠানোর সময়ে পরীক্ষা করাই আনসাবস্ক্রাইব সম্মান করা ও শুধু তা রেকর্ড করার মধ্যে পার্থক্য।
মুছে ফেলাও একইভাবে কাজ করে: একটি ডিলিশন রিকোয়েস্ট এখানে পরিচিতি ও তার মেসেজ ইতিহাস সরিয়ে দেয়, এবং পরিবারের বাকিরা যে অভ্যন্তরীণ লেন ব্যবহার করে, সেই একই লেন দিয়ে কপি রাখা প্রতিটি সহোদর সার্ভিসে পৌঁছে যায়। অনুরোধ করার একটি জায়গা, এবং ঘটে যাওয়া একটি বিষয়।