গ্রাহক সম্মতি ও পছন্দসমূহ পর্যালোচনা ও পরিচালনা করতে একটি ওয়েব অ্যাপ তৈরি করুন

লক্ষ্য, স্কোপ, এবং সম্মতির ধরন নির্ধারণ করুন

স্ক্রীন ডিজাইন বা কোড লেখার আগে স্পষ্টভাবে ঠিক করে নিন আপনি কী বানাচ্ছেন—এবং কী বানাচ্ছেন না। “সম্মতি” ও “পছন্দ” শব্দ দুটি মিলছে শুনতে, কিন্তু আইনি ও অপারেশনাল অর্থে আলাদা হওয়াই স্বাভাবিক। সঠিকভাবে সংজ্ঞা দিলে তা ভাঙা UX এবং ভঙ্গুর ইন্টেগ্রেশনের ঝামেলা পরে এড়ানো যায়।

সম্মতি বনাম পছন্দ (সহজ ভাষায়)

সম্মতি হলো এমন একটি অনুমতি যার পরে প্রমাণ দেওয়া যেতে হবে (কে সম্মত হলো, কোন বিষয়ে, কখন এবং কীভাবে)। উদাহরণ: মার্কেটিং ইমেল পাওয়ার সম্মতি বা ট্র্যাকিং কুকি অনুমোদন।

পছন্দ হলো ব্যবহারকারীর অভিজ্ঞতা বা ফ্রিকোয়েন্সি নির্ধারণকারী নির্বাচন (সাপ্তাহিক বনাম মাসিক আপডেট, কোন বিষয়গুলোতে আগ্রহ)। এগুলোও নির্ভরযোগ্যভাবে সংরক্ষণ করা উচিত, কিন্তু সাধারণত আইনি অপ্ট-ইনের সমান নয়।

স্কোপ নির্ধারণ: চ্যানেল, বিষয়, এবং সংগ্রহ পয়েন্ট

দিন-একটায় আপনি কী ম্যানেজ করবেন তা লিখে নিন:

• চ্যানেল: ইমেল, SMS, পুশ নোটিফিকেশন, ইন-অ্যাপ মেসেজ, ফোন কল
• বিষয়: প্রোডাক্ট আপডেট, নিউজলেটার, প্রোমোশন, ইভেন্ট আমন্ত্রণ, পার্টনার অফার
• যেখানে সিদ্ধান্তগুলো সংগৃহীত হবে: সাইনআপ, চেকআউট, লিড ফর্ম, একাউন্ট সেটিংস, ইন-অ্যাপ প্রম্পট, সাপোর্ট ইন্টারঅ্যাকশন

একটি সাধারণ ভুল হল মার্কেটিং সম্মতি কে লেনদেনভিত্তিক বার্তা (রসিদ বা পাসওয়ার্ড রিসেটের মতো) সঙ্গে মিশিয়ে ফেলা। এগুলোকে আপনার সংজ্ঞা, ডেটা মডেল এবং UI-তে আলাদা রাখুন।

স্টেকহোল্ডার ও মালিকানা নির্ধারণ

একটি সম্মতি ব্যবস্থাপনা ওয়েব অ্যাপ বহু টিমকে স্পর্শ করে:

• Marketing (ক্যাম্পেইন নিয়ম, সাবস্ক্রিপশন পছন্দ)
• Product (ইন-অ্যাপ প্রম্পট, প্রেফারেন্স সেন্টার)
• Support (পরিবর্তন হ্যান্ডলিং, ট্রাবলশুটিং)
• Legal/compliance (সংজ্ঞা, সংরক্ষণ, প্রমাণের চাহিদা)

ফয়সলা গ্রহণের জন্য একটি স্পষ্ট মালিক বরাদ্দ করুন, এবং যখন নীতি, ভেন্ডর বা মেসেজিং বদলে যায় তখন হালকা-ওজন প্রক্রিয়া নির্ধারণ করুন।

মাপযোগ্য সাফল্য মেট্রিক নির্ধারণ

কয়েকটি পরিমাপযোগ্য আউটকাম বেছে নিন, যেমন: কম স্প্যাম অভিযোগ, বিভ্রান্তির কারণে কম আনসাবস্ক্রাইব, GDPR সম্মতি রেকর্ড দ্রুত উদ্ধার করা, সাবস্ক্রিপশন পছন্দ সম্পর্কিত কম সাপোর্ট টিকিট, এবং অনুরোধ পাওয়ার সময় প্রমাণ প্রদানে কম সময় লাগা।

প্রাইভেসি নিয়মের সঙ্গে অনুবাদ করুন (GDPR/CCPA বেসিক)

প্রাইভেসি নিয়মগুলোকে ব্যবহারিক প্রোডাক্ট রিকোয়ারমেন্টে অনুবাদ করুন। এই অংশটি উচ্চ-স্তরের দিকনির্দেশ, আইনি পরামর্শ নয়—ফিচারগুলো সাজাতে এটি ব্যবহার করুন, তারপর কনসেল দিয়ে বিশদ নিশ্চিত করুন।

আপনার অ্যাপে ন্যূনতম কী সমর্থন থাকা উচিত (কোম্প্লায়েন্স জন্য MVP)

কার্যকরী দিক থেকে, একটি সম্মতি পরিচালনার ওয়েব অ্যাপ সাধারণত করতে হবে:

• Opt-in (যেমন, মার্কেটিং ইমেল, SMS, প্রয়োজনীয় যেখানে কুকি)
• Opt-out (যেমন, “Do not sell/share my personal information”)
• গ্রানুলার পছন্দ (চ্যানেল, বিষয়, ফ্রিকোয়েন্সি অনুযায়ী)
• প্রমাণ (ব্যবহারকারী কী সম্মত হয়েছে তার প্রতিরক্ষাযোগ্য রেকর্ড)
• সহজ প্রত্যাহার (মনে পরিবর্তন হলে একই সহজে প্রত্যাহার করা যায়)

আঞ্চলিক পার্থক্য (সরলীকৃত)

• GDPR (EU/UK) বৈধ “lawful basis” থাকা নিয়ে জোর দেয়। অনেক মার্কেটিং ও কুকি কেসে তা স্পষ্ট, সক্রিয় সম্মতি এবং প্রত্যাহারের ক্ষমতা প্রয়োজন।
• ePrivacy নিয়ম (দেশভেদে ভিন্ন, প্রায়শই EU নির্দেশনার সাথে সামঞ্জস্যপূর্ণ) সাধারণত কুকি ও অনুরূপ ট্র্যাকিং প্রভাবিত করে, অ-আবশ্যক ট্র্যাকিংয়ের জন্য স্পষ্ট পছন্দ চায়।
• CCPA/CPRA (California) “বিক্রি” বা “শেয়ার” সম্পর্কিত অপ্ট-আউট অধিকার ও স্পষ্টতার ওপর গুরুত্ব দেয়, সংবেদনশীল ডেটা নিয়ন্ত্রণ ও ট্রান্সপারেন্সি বাড়ায়।

কী রেকর্ড করবেন: কে, কী, কখন, কীভাবে এবং কেন

আপনার সম্মতি রেকর্ডগুলোতে থাকা উচিত:

• Who: ব্যবহারকারী আইডি (এবং/অথবা ইমেল/ফোন), অ্যাকাউন্ট/টেন্যান্ট প্রসঙ্গ
• What: উদ্দেশ্য(গুলি) ও চ্যানেল(গুলো) (উদাহরণ: “প্রোডাক্ট আপডেট ইমেলের মাধ্যমে”)
• When: টাইমস্ট্যাম্প, টাইমজোন, এবং কার্যকর তারিখ
• How: UI সূত্র (প্রেফারেন্স সেন্টার, চেকআউট), পদ্ধতি (চেকবক্স, ডাবল অপ্ট-ইন), এবং প্রদর্শিত নোটিশ/পলিসির ভার্সন
• Why: আইনি ভিত্তি/উদ্দেশ্য লেবেল এবং যে কোন আঞ্চলিক ফ্ল্যাগ (GDPR সম্মতি বনাম CCPA অপ্ট-আউট)

সংরক্ষণ ও অডিটেবিলিটি

সম্মতি রেকর্ড এবং অডিট লগ এর জন্য ডেটা সংরক্ষণ নীতি নির্ধারণ করুন (অften মার্কেটিং ডেটার চেয়ে দীর্ঘক্ষণ রাখা হয়)। যা দরকার ততটুকুই রাখুন, সুরক্ষিত রাখুন, এবং সংরক্ষণ সময়কাল নথিভুক্ত করুন। নিশ্চিত না হলে “legal decision প্রয়োজন” প্লেসহোল্ডার যোগ করে অভ্যন্তরীণ নীতি ডকস বা /privacy লিংক করুন।

চূড়ান্ত পলিসি সিদ্ধান্ত—বিশেষ করে কি “বিক্রি/শেয়ার” গোনা হবে, কুকি ক্যাটাগরাইজেশন, এবং সংরক্ষণ—আইনি পরামর্শ নিয়ে নিন।

ডেটা মডেল ও সম্মতি রেকর্ড স্কিমা ডিজাইন করুন

একটি সম্মতি পরিচালনা ওয়েব অ্যাপ তার ডেটা মডেলের উপর নির্ভর করে। যদি স্কিমা “কে কী-তে সম্মত হয়েছে, কখন, এবং কীভাবে” জবাব না দিতে পারে, তাহলে আপনি কমপ্লায়েন্স, কাস্টমার সাপোর্ট, এবং ইন্টেগ্রেশনে সমস্যায় পড়বেন।

মূল এন্টিটিগুলো মডেল করুন

কয়েকটি স্পষ্ট বিল্ডিং ব্লক দিয়ে শুরু করুন:

• Customer/Identity: ব্যক্তি (বা অ্যাকাউন্ট) যাকে আপনি চিনেন
• Identifier: ইমেল, ফোন, অভ্যন্তরীণ ইউজার ID, ডিভাইস ID—আলোক করে আলাদা সারিতে সঞ্চয় করুন যাতে একাধিক সমর্থন করতে পারেন
• Purpose: কেন আপনি ডেটা প্রসেস করছেন (উদাহরণ: “মার্কেটিং ইমেল”, “অর্ডার আপডেট”, “অ্যানালিটিক্স”)
• Channel: ইমেল, SMS, পুশ, ফোন

এই বিভাজন প্রেফারেন্স সেন্টারকে নমনীয় রাখে এবং পরিষ্কার GDPR সম্মতি রেকর্ড ও CCPA অপ্ট-আউট সিগন্যাল উত্পাদন করে।

ভার্সনিং: তারা কোন টেক্সটটি অনুমোদন করেছিল?

প্রতিটি সিদ্ধান্তের সঙ্গে সঠিক নোটিশ/পলিসি ভার্সন সংরক্ষণ করুন:

• notice_id এবং notice_version (বা কন্টেন্ট হ্যাশ)
• লোকেল (EN/FR ইত্যাদি), যদি লোকালাইজড টেক্সট দেখান
• প্রদর্শিত নির্দিষ্ট চেকবক্স লেবেল বা ডিসক্লোজার স্নিপেট

এইভাবে, শব্দ পরিবর্তনে পুরনো সম্মতিগুলো প্রমাণযোগ্য থাকবে।

প্রমাণ (প্রুফ) ফিল্ড

প্রতি সম্মতি ইভেন্টে ঝুঁকি স্তরের জন্য উপযুক্ত প্রমাণ রেকর্ড করুন:

• টাইমস্ট্যাম্প (UTC) এবং প্রয়োজনে টাইমজোন
• সূত্র (web, iOS, support agent), সাথে সূত্র পেজ/পাথ
• user agent
• IP ঠিকানা শুধু যদি আপনার একটি স্পষ্ট দরকার এবং সংরক্ষণ নীতি থাকে

পরিচয় মার্জ এবং প্রত্যাহার ফ্ল্যাগ

মানুষ দ্বিগুণ সাইন আপ করে। একাধিক শনাক্তকারীকে একটি কাস্টমারের সাথে লিংক করে এবং একটি merge history রেকর্ড করুন।

উল্টানো স্পষ্টভাবে উপস্থাপন করুন:

• status: granted / withdrawn
• withdrawn_at এবং কারণ (ব্যবহারকারী ক্রিয়া, অ্যাডমিন অনুরোধ)
• CCPA অপ্ট-আউট ও সাবস্ক্রিপশন পছন্দ উভয়কে সমর্থন করার জন্য আলাদা ফ্ল্যাগ রাখুন (উদাহরণ: do not sell/share)

এমন একটি প্রেফারেন্স সেন্টার UX তৈরি করুন যা ব্যবহারকারী বোঝে

একটি প্রেফারেন্স সেন্টার কাজ করে যদি লোকজন দ্রুত উত্তর দিতে পারে: “আপনি আমাকে কী পাঠাবেন, এবং আমি কীভাবে এটি পরিবর্তন করব?” কৌতুকের চেয়েও স্পষ্টতার লক্ষ্য রাখুন, এবং সিদ্ধান্তগুলো উল্টানো যেতে পারে।

সঠিক এন্ট্রি পয়েন্ট নির্বাচন করুন

যেখানে ব্যবহারকারীরা আপনার সাথে ইন্টারঅ্যাক্ট করে সেখানে সহজেই খোঁজা যায় এমন রাখুন:

• এম্বেডেড উইজেট গুরুত্বপূর্ণ পেজে (চেকআউট, একাউন্ট সেটিংস)
• হোস্টেড প্রেফারেন্স সেন্টার পেজ প্রতিটি ইমেল ফুটারে এবং SMS সাহায্য ফ্লোতে লিংক (উদাহরণ: /preferences)
• ইন-অ্যাপ স্ক্রিন লগ-ইনকৃত ব্যবহারকারীর জন্য (Settings → Notifications / Privacy)

একই শব্দ এবং স্ট্রাকচার তিনটিতেই ব্যবহার করুন যাতে ব্যবহারকারীরা অপরিচিত কোনো জায়গায় পৌঁছে গেছে মনে না করে।

সরল ভাষায় পছন্দগুলি লিখুন (ক্যাচ ট্রাপ এড়িয়ে)

ছোট লেবেল ব্যবহার করুন যেমন “Product updates” বা “Tips and how-tos,” এবং প্রয়োজনে এক-লাইন বর্ণনা যোগ করুন। আইনি ভাষা এড়িয়ে চলুন।

যেখানে নিয়ম বা প্ল্যাটফর্ম নীতি সক্রিয় সম্মতি দাবি করে, সেখানে পূর্ব-চেক করা বক্স ব্যবহার করবেন না। একাধিক অনুমতি চাইলে তাদের স্পষ্টভাবে আলাদা করুন (উদাহরণ: মার্কেটিং ইমেল বনাম SMS বনাম তথ্য শেয়ারিং)।

গ্রানুলার পছন্দ এবং একটি সহজ এক্সিট অফার করুন

লোকদের বিষয় অনুযায়ী অপ্ট-ইন করতে দিন এবং প্রয়োজনে চ্যানেলও নির্বাচন করতে দিন। তারপর সবসময় দৃশ্যমান একটি সহজ গ্লোবাল আনসাবস্ক্রাইব রাখুন।

একটি ভালো প্যাটার্ন:

• “Unsubscribe from all marketing” (একক অ্যাকশন)
• টপিক টগল (বিস্তারিত নিয়ন্ত্রণ)
• চ্যানেল টগল (যেখানে প্রযোজ্য)

উদ্দেশ্য নিশ্চিত করুন (অতিরিক্ত friction ছাড়া)

ইমেল সাইনআপের জন্য যেখানে প্রয়োজন ডাবল অপ্ট-ইন ব্যবহার করুন: ব্যবহারকারী পছন্দ নির্বাচন করলে একটি কনফার্মেশন ইমেল পাঠান যা লিংকে ক্লিক করলে সাবস্ক্রিপশন সক্রিয় হবে। পাতায় ব্যাখ্যা করুন পরবর্তী ধাপ কী হবে।

প্রথম দিন থেকেই অ্যাক্সেসিবিলিটি নির্মাণ করুন

সবকিছু কীবোর্ড ন্যাভিগেশন-এ কাজ করবে, ক্লিয়ার ফোকাস স্টেট থাকবে, পর্যাপ্ত কনট্রাস্ট থাকবে, এবং টগল লেবেলগুলো স্ক্রিন রিডার বোঝার মতো হবে (উদাহরণ: “Receive weekly digest emails: On/Off”)।

ব্যাকএন্ড API নির্মাণ করুন সম্মতি ও পছন্দের জন্য

আপনার ব্যাকএন্ড API-ই হলো কি গ্রাহক সম্মত হয়েছে এবং তারা কী পেতে চায় তার সোর্স-অফ-ট্রুথ। একটি পরিষ্কার, পূর্বানুমেয় API ইন্টেগ্রেশনগুলো সহজ করে ফেলে যাতে প্রেফারেন্স সেন্টার থেকে ইমেল, SMS, CRM টুল পর্যন্ত সবকিছু কনফ্লিকট ছাড়াই কাজ করে।

কোর এন্ডপয়েন্ট নির্ধারণ করুন

সারফেস এরিয়া ছোট ও স্পষ্ট রাখুন। সাধারণ সেট:

• Read preferences: GET /api/preferences (অথবা অ্যাডমিন ব্যবহারের জন্য GET /api/users/{id}/preferences)
• Update preferences: PUT /api/preferences (বর্তমান সেট প্রতিস্থাপন করা সাফ—পার্শিয়াল আপডেটের চেয়ে পরিষ্কার)
• Withdraw consent: POST /api/consents/{type}/withdraw (“update”-থেকে আলাদা যাতে তা কখনো আকস্মিক না হয়)

প্রতিটি consent টাইপ সাদাসিধে নাম দিন (উদাহরণ: email_marketing, sms_marketing, data_sharing)।

আপডেটগুলো idempotent করুন (রিট্রাই নিরাপদ হবে)

ব্রাউজার এবং ইন্টেগ্রেশন রিকোয়েস্ট রিট্রাই করবে। যদি রিট্রাই একটি দ্বিতীয় “unsubscribe” ইভেন্ট তৈরি করে, আপনার অডিট ট্রেইল এলোমেলো হয়ে যাবে। Idempotency-Key হেডার (বা request_id) গ্রহণ করে একই রিকোয়েস্টে একই আউটকাম সংরক্ষণ করুন যাতে পুনরাবৃত্তি একই ফল দেয়।

ইনপুট যাচাই ও অনুমোদিত স্টেট

আপনি যা পরে প্রতিরক্ষা করতে চান না এমন কিছু গ্রহণ করবেন না:

• শুধু পরিচিত ফিল্ডই গ্রহণ করুন; কিছুই চুপ করে উপেক্ষা করবেন না
• অনুমোদিত মান জোর দিন (granted, denied, withdrawn) এবং বৈধ ট্রানজিশন
• এমন হিডেন ফিল্ড এড়িয়ে চলুন যা মান পরিবর্তন করে (উদাহরণ: একটি চেকবক্স যা একই সময়ে “data sharing” টগল করে)

কনসিস্টেন্ট এরর এবং রেট লিমিটিং

পূর্বরূপ ভঙ্গি আকার ফেরত দিন (code, message, field_errors) এবং সংবেদনশীল এন্ডপয়েন্ট যেমন সম্মতি প্রত্যাহার এবং অ্যাকাউন্ট লুকআপ রেট-লিমিট করুন যাতে অপব্যবহার কমে।

উদাহরণসহ ডকুমেন্টেশন করুন

ফ্রন্টএন্ড ও ইন্টেগ্রেশনের জন্য কপি-পেস্ট অনুরোধ ও রেসপন্সসহ একটি অভ্যন্তরীণ API রেফারেন্স প্রকাশ করুন। এটিকে ভার্সনেড রাখুন (উদাহরণ: /api/v1/...) যাতে পরিবর্তনগুলি বিদ্যমান ক্লায়েন্ট ভাঙে না।

অ্যাপ সিকিউর করুন: অথ, অথরাইজেশন, এবং ডেটা সুরক্ষা

সিকিউরিটি সম্মতির অংশ: যদি কেউ একটি অ্যাকাউন্ট জিপ করেও বা রিকোয়েস্ট নকল করে পছন্দ বদলে দিতে পারে, তবে ব্যবহারকারীরা অসম্মতভাবে যোগাযোগ পেতে পারেন। আইডেনটিটি রক্ষা করে শুরু করুন, তারপর সম্মতি পরিবর্তনকারী প্রতিটি অ্যাকশন লক করুন।

ব্যবহারকারীদের প্রমাণীকরণ করুন ঘর্ষণ বাড়ানো ছাড়াই

আপনার শ্রোতা ও ঝুঁকি অনুসারে একটি পন্থা ব্যবহার করুন:

• সেশন লগইন (ইমেল + পাসওয়ার্ড) শক্ত পাইচ পাসওয়ার্ড নিয়ম ও ঐচ্ছিক MFA সহ
• ম্যাজিক লিংক কম-ঘর্ষণ প্রবেশের জন্য (সময়-সীমাবদ্ধ, একবার ব্যবহারযোগ্য, ডিভাইস সচেতন)
• SSO/SAML/OIDC B2B পোর্টালের জন্য যেখানে কোম্পানি আইডেনটিটি প্রদানকারী উৎস

অ্যাকাউন্ট টেকওভার প্রতিরোধে প্রটেকশন যোগ করুন: লগইনে রেট-লিমিট, সংবেদনশীল পরিবর্তনের নোটিফিকেশন, এবং উচ্চ-প্রভাব সেটিং পরিবর্তনের আগে step-up verification বিবেচনা করুন (উদাহরণ: সব চ্যানেলে মার্কেটিং অপ্ট-ইন পরিবর্তন)।

প্রতিটি এন্ডপয়েন্টে অথরাইজেশন বলবৎ করুন

UI-কে অবিশ্বস্ত ভাবুন। আপনার ব্যাকএন্ড যাচাই করবে:

• রিকোয়েস্টকারী প্রমাণীকৃত কিনা
• রিকোয়েস্টকারী ওই নির্দিষ্ট ব্যবহারকারী/বিষয়ের উপর কাজ করতে অনুমোদিত কিনা (কোনো “edit by email” শর্টকাট নয়)
• অ্যাকশন আপনার আগে সংজ্ঞায়িত সম্মতি নিয়মের সাথে মেলে কিনা (কারা কী বদলাতে পারে, কখন)

ব্রাউজার-ফেসিং এন্ডপয়েন্টগুলিতে CSRF সুরক্ষা (কুকি-ভিত্তিক সেশন জন্য), কঠোর CORS নিয়ম (শুধু আপনার অরিজিন অনুমোদন), এবং ID-চেক করে অনুভূমিক প্রিভিলেজ এসকলের বিরুদ্ধে কড়া নিয়ম রাখুন।

ডেটা এনক্রিপ্ট ও মিনিমাইজ করুন

ডেটা ইন ট্রানজিট (HTTPS) এবং অ্যাট রেস্ট এনক্রিপ্ট করুন। প্রেফারেন্স সেন্টার পরিচালনার জন্য প্রয়োজনীয় সর্বনিম্ন ফিল্ড সংগ্রহ করুন—প্রায়শই আপনি কাঁচা শনাক্তকারী সংরক্ষণ না করে অভ্যন্তরীণ ID বা হ্যাশড লুকআপ কী ব্যবহার করতে পারেন। পুরাতন লগ এবং অন‍্য ক্রিয়াশীল নয় এমন অ্যাকাউন্টের জন্য ডেটা সংরক্ষণ নীতিপালন সেট ও বাস্তবায়ন করুন।

লগ নিরাপদভাবে রাখুন ও পাবলিক ফর্ম রক্ষা করুন

অডিট লগিং অপরিহার্য, কিন্তু লগগুলো নিরাপদ রাখুন: পূর্ণ সেশন টোকেন, ম্যাজিক-লিংক টোকেন, বা অপ্রয়োজনীয় পার্সোনাল ডেটা স্টোর করবেন না। পাবলিক সাবস্ক্রিপশন ফর্মে CAPTCHA বা থ্রটলিং যোগ করে বট সাইন-আপ ও পছন্দ-ট্যাম্পারিং কমান।

অডিট লগ ও সম্মতির প্রমাণ বাস্তবায়ন করুন

অডিট লগ হলো রসিদ যে কোনো ব্যক্তি অনুমতি দিয়েছে (বা প্রত্যাহার করেছে)। অভিযোগ, নিয়ন্ত্রক তদন্ত, বা অভ্যন্তরীণ ঘটনার সময় এরা কী ঘটেছে তা ব্যাখ্যা করার উপায়।

প্রতিটি পরিবর্তনের জন্য কী রেকর্ড করবেন

প্রতিটি সম্মতি বা পছন্দ আপডেটে একটি append-only অডিট ইভেন্ট তৈরি করুন যা ধারণ করবে:

• পূর্ব মান এবং নতুন মান (উদাহরণ: marketing_email: true → false)
• অভিনেতা ধরন ও পরিচয়: user, admin, automated sync, API key/service account
• টাইমস্ট্যাম্প (UTC) এবং সূত্র (preference center, checkout, webhook, support tool)
• প্রমাণের প্রসঙ্গ: পলিসি/ভার্সন দেখানো, ধরন (checkbox, double opt-in), এবং ব্যবহারকৃত ব্যবহারকারী শনাক্তকারী

এই তথ্য আপনাকে সম্পূর্ণ ইতিহাস পুনর্গঠন করতে দেয়—শুধু সাম্প্রতিক রাষ্ট্র নয়।

নির্ভরযোগ্য প্রমাণ রাখুন: অপারেশনাল বনাম অডিট লগ আলাদা রাখুন

অপারেশনাল লগ (ডিবাগ, পারফরম্যান্স, এরর) দ্রুত ঘুরে যায় এবং সহজে ফিল্টার বা ড্রপ করা যায়। অডিট লগগুলিকে প্রমাণ হিসেবে বিবেচনা করুন:

• অ্যাপ লগ থেকে আলাদা রাখুন
• append-only রাখুন (আপডেট নয়; শুধুই নতুন ইভেন্ট)
• ইন্টিগ্রিটি কন্ট্রোল যোগ করুন (সীমিত লিখন পথ, সংরক্ষণ নিয়ম, ঐচ্ছিক হ্যাশিং/চেইন-অফ-কাস্টডি মেটাডেটা)

অডিটকে ব্যবহারযোগ্য করুন: সার্চ ও এক্সপোর্ট

অডিট ট্রেইল তখনই সহায়ক যখন আপনি এটি উদ্ধার করতে পারেন। ব্যবহারকারী ID, ইমেল, ইভেন্ট টাইপ, তারিখ পরিসর, এবং অভিনেতা দিয়ে সার্চ ক্রিয়াযোগ্য ভিউ প্রদান করুন। তদন্তের জন্য এক্সপোর্ট (CSV/JSON) সাপোর্ট করুন—তবে এক্সপোর্টগুলোও ওয়াটারমার্কেড ও ট্রেসেবল রাখুন।

এক্সেস ও এক্সপোর্ট লক করুন

অডিট ডেটায় প্রায়ই শনাক্তকারী ও সংবেদনশীল প্রসঙ্গ থাকে। কঠোর অ্যাক্সেস নিয়ন্ত্রণ নির্ধারণ করুন:

• শুধুমাত্র অনুমোদিত রোলগুলো অডিট ইভেন্ট ভিউ বা ডাউনলোড করতে পারবে
• অ্যাডমিন ভিউতে “কেন” অ্যাক্সেস দরকার তা দেখান (টিকিট/রেফারেন্স ফিল্ড)
• প্রতিটি এক্সপোর্টকেও একটি অডিট ইভেন্ট হিসেবে লগ করুন (কে, কোন স্কোপ, কখন)

ভালভাবে করা হলে, অডিট লগ সম্মতি ব্যবস্থাপনাকে “আমরা মনে করি আমরা ঠিক করেছি” থেকে “এখানে প্রমাণ” এ পরিণত করে।

ইমেল, SMS, এবং CRM সিস্টেমের সাথে ইন্টিগ্রেট করুন

আপনার সম্মতি পরিচালনা ওয়েব অ্যাপ তখনই কার্যকর যদি প্রতিটি ডাউনস্ট্রিম সিস্টেম (ইস্প, SMS প্রদানকারী, CRM, সাপোর্ট টুল) সর্বশেষ গ্রাহক পছন্দটি সম্মান করে। ইন্টিগ্রেশন কেবল “API সংযোগ” না, বরং পছন্দগুলো সময়ের সাথে drift না করে ঠিক রাখা—এটাই মূল।

ডাউনস্ট্রিম টুলগুলির জন্য সরল ইভেন্ট ফরম্যাট বেছে নিন

প্রেফারেন্স পরিবর্তনকে ইভেন্ট হিসেবে ট্রিট করুন যাতে পুনরায় চালানো যায়। একটি ব্যবহারিক ন্যূনতম পে-লোড:

• who (customer/user ID, প্রয়োজনে ইমেল/ফোন)
• topic (উদাহরণ: Product Updates, Billing, Promotions)
• channel (email, SMS, phone)
• action (opt-in, opt-out, unsubscribe-all)
• legal basis (consent, legitimate interest)
• (UTC) এবং (user, admin, system)

এই স্ট্রাকচার প্রমাণ তৈরিকে সাহায্য করে এবং ইন্টেগ্রেশনকে সরল রাখে।

সিংক নিয়ম: মেসেজিং সর্বশেষ পছন্দ অনুসরণ করবে

যখন ব্যবহারকারী আপনার প্রেফারেন্স সেন্টারে আপডেট করে, তৎক্ষণাৎ পরিবর্তনটি আপনার ইমেল/SMS প্রদানকারী এবং CRM-এ পুশ করুন। যদি কোনো প্রদানকারী আপনার সুনির্দিষ্ট ট্যাক্সোনমি সমর্থন না করে, আপনার অভ্যন্তরীণ টপিকগুলো তাদের লিস্ট/সেগমেন্ট মডেলের সাথে ম্যাপ করুন এবং ম্যাপিং ডকুমেন্ট করুন।

ফলাফলে কোন সিস্টেমকে source of truth রাখবেন তা সিদ্ধান্ত নিন—সাধারণত তা আপনার সম্মতি API হওয়া উচিত, ESP/CRM কাচ হিসেবেই কাজ করবে।

বিশ্বাস ভাঙার এজ কেসগুলি হ্যান্ডল করুন

অপারেশনাল বিবরণগুলো গুরুত্বপূর্ণ:

• বাউন্স ও suppressed contacts: ইমেল হার্ড-বাউন্স বা suppression লিস্টে থাকলে suppression স্ট্যাটাস আপনার অ্যাপে দৃশ্যমান রাখুন যাতে টিমগুলো ভুলবশত “re-subscribe” না করে
• ব্লক বা অপ্রযোজ্য নম্বর: SMS প্রদানকারী সমস্যাগ্রস্ত নম্বর চিহ্নিত করলে, সম্মতি থাকলেও বার বার পাঠানো বন্ধ করুন
• প্রোভাইডার-লেভেল গ্লোবাল আনসাবস্ক্রাইব: এগুলোকে ক্যাম্পেইন-লেভেল সেটিংয়ের চেয়ে অধিক অগ্রাধিকার দিন

ড্রিফট মিটিগেশনের জন্য শিডিউলড জব চালান

ওয়েবহুক থাকলেও সিস্টেমগুলো ড্রিফট করে (ব্যর্থ অনুরোধ, ম্যানুয়াল এডিট, আউটেজ)। প্রতিদিন একটি reconciliation জব চালান যা আপনার সম্মতি রেকর্ডগুলোকে প্রদানকারী স্টেটের সঙ্গে তুলনা করে এবং বৈষম্যগুলো ঠিক করে—স্বয়ংক্রিয় সংশোধনের জন্য একটি অডিট এন্ট্রি লিখে।

ব্যবহারকারীর অনুরোধ হ্যান্ডল করুন: অ্যাক্সেস, মুছে ফেলা, ও সংশোধন

আপনার সম্মতি অ্যাপটি বাস্তবে সম্পূর্ণ তখনই হবে যখন এটি বাস্তব গ্রাহক অনুরোধগুলো নিরাপদে হ্যান্ডল করতে পারে: “আপনার কাছে কী আছে দেখান”, “আমাকে মুছে ফেলুন”, এবং “সেটা ঠিক করুন।” এসব GDPR-এর (access/rectification/erasure) কেন্দ্রিক প্রত্যাশা এবং CCPA-স্টাইল অধিকারের সঙ্গেও সঙ্গত।

অ্যাক্সেসের অধিকার: সম্মতি ইতিহাস এক্সপোর্ট

একটি স্ব-সার্ভ এক্সপোর্ট প্রদান করুন যা সহজে বোঝা যায় এবং যদি ব্যবহারকারী তার অ্যাকাউন্টে না পৌঁছাতে পারে তাহলে সাপোর্টকে সহজে দিতে পারে।

এক্সপোর্টে থাকা উচিত:

• সম্মতি ইভেন্টের টাইমলাইন (opt-in, opt-out, পছন্দ পরিবর্তন)
• ব্যবহারকারী কীতে সম্মত হয়েছে (উদাহরণ: উদ্দেশ্য + চ্যানেল)
• কখন, কোথায়, এবং কীভাবে: টাইমস্ট্যাম্প, সূত্র (web form, preference center, support), এবং প্রমাণ সংকেত (উদাহরণ: double opt-in কনফার্মেশন)

ফরম্যাট পোর্টেবল রাখুন (CSV/JSON) এবং নাম স্পষ্ট রাখুন, যেমন “Consent history export।”

মুছে ফেলা ও এনোনিমাইজেশন—অনুমোদিত প্রমাণ না হারিয়ে

যখন কেউ মুছে ফেলার অনুরোধ করে, প্রায়ই আপনাকে সীমিত রেকর্ড রাখতে হতে পারে আইনগত কমপ্লায়েন্স বা পুনরায় যোগাযোগ রোধের জন্য। দুটি পথ বাস্তবায়ন করুন:

• Hard delete এমন ডেটার জন্য যার ওপর কোনো সংরক্ষণ দাবি নেই
• Anonymization/pseudonymization এমন প্রমাণের জন্য যা রাখা চলবে (উদাহরণ: শনাক্তকারীকে এক-দিকের হ্যাশ দিয়ে প্রতিস্থাপন, টাইমস্ট্যাম্প ও পলিসি ভার্সন রাখা)

এটিকে ডেটা সংরক্ষণ নীতির সঙ্গে মিলিয়ে রাখুন যাতে প্রমাণ অনির্দেশ্যভাবে চিরকালের জন্য না থাকে।

সংশোধন ও সাপোর্ট ওয়ার্কফ্লো (অনুমোদনসহ)

সাপোর্ট টিকিটের জন্য অ্যাডমিন টুল বানান: ব্যবহারকারী অনুসন্ধান, বর্তমান পছন্দ দেখান, এবং পরিবর্তন সাবমিট করুন। যে কোন এক্সপোর্ট, মুছে ফেলা, বা সম্পাদনের আগে একটি স্পষ্ট আইডেন্টিটি যাচাই ধাপ (ইমেল চ্যালেঞ্জ, সক্রিয় সেশন চেক, বা ডকুমেন্টেড ম্যানুয়াল যাচাই) বাধ্যতামূলক করুন।

high-risk অ্যাকশনগুলোতে অনুমোদন ওয়ার্কফ্লো (দুই-ব্যক্তির রিভিউ বা রোল-ভিত্তিক অনুমোদন) ব্যবহার করুন। প্রতিটি অ্যাকশন ও অনুমোদন অডিট ট্রেইলে লগ করুন যাতে পরে “কে কী বদলালো, কখন, এবং কেন” জিজ্ঞেস করলে উত্তর দেওয়া যায়।

শেষ-থেকে-শেষ পর্যন্ত কনসেন্ট ফ্লো টেস্ট করুন

সম্মতি ব্যবস্থাপনা অ্যাপ টেস্ট করা মানে শুধু “টগল কি চলে?” না। এটা নিশ্চিত করা যে প্রতিটি ডাউনস্ট্রিম অ্যাকশন (ইমেল, SMS, এক্সপোর্ট, অডিয়েন্স সিংক) সর্বশেষ গ্রাহক পছন্দটি সম্মান করে—চাপ ও এজ কেস সহ।

কখনোই ব্যর্থ হওয়া ঠিক নয় এমন নিয়মগুলোর জন্য টেস্ট লিখুন

উচ্চ-ঝুঁকিপূর্ণ নিয়মগুলো নিয়ে অটোমেটেড টেস্ট শুরু করুন—বিশেষত যেগুলো অনিচ্ছাকৃত আউটরিচ ঘটাতে পারে:

• Opt-out সবখানেই ব্লক করবে (মার্কেটিং ইমেল, SMS, পুশ, এবং কোনো রিসেন্ড/ক্যাম্পেইন রিট্রাই জব)
• “Transactional” বনাম “marketing” ক্যাটাগরি আপনার নীতিমত ঠিক কাজ করবে
• ডাবল অপ্ট-ইন নিশ্চিত করবে কনফার্মেশন ছাড়া সাবস্ক্রিপশন অ্যাক্টিভ না হবে

একটি সহায়ক প্যাটার্ন: “দেওয়া consent state X হলে সিস্টেম অ্যাকশন Y অনুমোদিত/ব্লক” টেস্ট করুন, একই ডিসিশন লজিক ব্যবহার করে যা আপনার সেন্ডিং সিস্টেমগুলো কল করে।

কনকারেন্সি ও অর্ডারিং টেস্ট করুন

সম্মতি পরিবর্তন অদ্ভুত সময়ে ঘটে: দুইটি ব্রাউজার ট্যাব খুলে থাকা, ব্যবহারকারী দুবার ক্লিক করা, একটি ওয়েবহুক এজেন্টের সম্পাদনের সাথে সংঘর্ষ—

• কনকারেন্সি টেস্ট করুন: একসাথে দুইটি আপডেট স্টেট ভাঙ্গা উচিত নয়
• “last write wins” (অথবা আপনার নির্বাচিত নিয়ম) কনসিস্টেন্ট ও অডিটেবল তা নিশ্চিত করুন
• আপডেট সংঘর্ষের সময় মেটাডেটা (টাইমস্ট্যাম্প, সূত্র, অঞ্চল, পলিসি ভার্সন) হারাবেন না

আসল ব্যবহারকারী আচরণে UI টেস্ট যোগ করুন

প্রেফারেন্স সেন্টারে ভুল করা সহজ:

• টগল, কনফার্মেশন, এবং এরর স্টেটের UI টেস্ট যোগ করুন
• স্পষ্ট সাকসেস মেসেজিং নিশ্চিত করুন এবং রিফ্রেশের পর পেজ স্টোর্ড স্টেট প্রতিফলিত করে কিনা যাচাই করুন
• অ্যাক্সেসিবিলিটি বেসিক টেস্ট করুন (কীবোর্ড ন্যাভিগেশন, ফোকাস স্টেট, পাঠযোগ্য লেবেল)

সিকিউরিটি ও আঞ্চলিক সিনারিও চেক করুন

সম্মতি ডেটা সংবেদনশীল এবং প্রায়ই আইডেন্টিটির সাথে যুক্ত:

• সিকিউরিটি চেক (ডিপেন্ডেন্সি স্ক্যানিং, বেসিক পেন-টেস্ট) চালান
• আঞ্চলিক সিনারিও (বিভিন্ন ডিফল্ট, শব্দভঙ্গি, ও প্রয়োজনীয় নোটিশ) টেস্ট করুন, বিশেষত ব্যবহারকারী দেশ/রিজিয়ন বদলালে কি ঘটে

একটি পূর্ণ-জার্নি স্ক্রিপ্ট অন্তত একবার চালান: sign up → confirm (প্রয়োজনে) → preferences পরিবর্তন → verify sends ব্লক/অনুমোদন → consent প্রমাণ এক্সপোর্ট।

ডিপ্লয়, মনিটর, এবং রিলায়েবিলিটি বজায় রাখুন

একটি সম্মতি অ্যাপ “একবার বানিয়ে ছেড়ে দেওয়া” নয়। লোকেরা প্রতিবার তাদের পছন্দ ঠিক দেখতে চায়। রিলায়েবিলিটি মূলত অপারেশনাল: কীভাবে আপনি ডিপ্লয় করেন, ব্যর্থতা পর্যবেক্ষণ করেন, এবং কিভাবে রিকভার করেন।

আলাদা পরিবেশ (এবং ডেটা নিরাপদ রাখুন)

dev, staging, এবং production আলাদা রাখুন। স্টেজিং প্রোডাকশন-সদৃশ হওয়া উচিত (একই ইন্টিগ্রেশন, একই কনফিগারেশন ধরন), কিন্তু বাস্তব ব্যক্তিগত ডেটা কপি করা এড়িয়ে চলুন। বাস্তবসম্মত পে-লোড দরকার হলে সিনথেটিক ব্যবহারকারী ও এনোনিমাইজড শনাক্তকারী ব্যবহার করুন।

মাইগ্রেশনকে উচ্চ-ঝুঁকির ইভেন্ট হিসেবে বিবেচনা করুন

সম্মতি ইতিহাস হল আইনি রেকর্ড, তাই ডেটাবেস মাইগ্রেশনগুলোর পরিকল্পনা সাবধানে করুন। ঐতিহাসিক সারি রিরাইট বা কল্যাপ্সিং করা এড়িয়ে চলুন। অ্যাডিটিভ মাইগ্রেশন (নতুন কলাম/টেবিল) এবং ব্যাকফিল পছন্দ করুন যাতে মূল ইভেন্ট ট্রেইল অক্ষুণ্ণ থাকে।

মাইগ্রেশন শিপ করার আগে যাচাই করুন:

• পুরনো সম্মতি রেকর্ড এখনও সঠিকভাবে ভ্যালিডেট করে
• টাইমস্ট্যাম্প ও সূত্র (web form, API, import) অক্ষুণ্ণ আছে
• roll-forward স্ক্রিপ্টগুলো ঐতিহাসিক মানগুলো অনুপঠ্যভাবে পুনঃবিবেচনা করছে না

গুরুত্বপূর্ণ বিষয়গুলো মনিটর করুন (বিশেষ করে সিংক ব্যর্থতা)

মনিটরিং ও এলার্ট সেট করুন:

• ইমেল/SMS/CRM টুলে failed sync (কিউ ব্যাকলগ, রিট্রাই)
• সম্মতি এন্ডপয়েন্টে API এরর রেট ও লেটেন্সি স্পাইক
• রেকর্ড হওয়া সম্মতি ইভেন্টের অপ্রত্যাশিত পতন (ফর্ম ভাঙার ইঙ্গিত)

এলার্টগুলো কার্যকরযোগ্য রাখুন: ইন্টিগ্রেশন নাম, এরর কোড, এবং দ্রুত ডিবাগের জন্য একটি স্যাম্পল রিকোয়েস্ট ID অন্তর্ভুক্ত করুন।

রোলব্যাক পলিসি পরিকল্পনা করুন যা ব্যবহারকারীর পছন্দ রক্ষা করে

রিলিজের জন্য একটি রোলব্যাক কৌশল রাখুন যা ভুলভাবে ডিফল্ট পাল্টে ফেলা, প্রেফারেন্স সেন্টার ভাঙ্গা, বা অপ্ট-আউট ভুলভাবে হ্যান্ডল করা উন্নত। কমন প্যাটার্ন: ফিচার ফ্ল্যাগ, ব্লু/গ্রীন ডিপ্লয়, এবং দ্রুত “ডিসেবল writes” সুইচ যা আপডেট বন্ধ করে দেয় পড়া চালিয়ে রেখে।

দ্রুত ইটারেশন সাইকেলে তৈরি করলে, স্ন্যাপশট এবং রোলব্যাক সুবিধা বিশেষভাবে উপকারী—উদাহরণস্বরূপ, Koder.ai-তে আপনি React প্রেফারেন্স সেন্টার ও Go + PostgreSQL কনসেন্ট API প্রোটোটাইপ করে নিরাপদে রোলব্যাক করতে পারেন যদি কোনো পরিবর্তন সম্মতি ক্যাপচার বা অডিট লগিং প্রভাবিত করে।

রুনবুক রাখুন এবং আপডেট করুন

লাইটওয়েট ডকুমেন্টেশন রাখুন: রিলিজ ধাপ, এলার্টের মানে, অন-কॉल কনট্যাক্ট, এবং ইন্সিডেন্ট চেকলিস্ট। একটি সংক্ষিপ্ত রুনবুক একটি স্ট্রেসফুল আউটেজকে একটি পূর্বনির্ধারিত প্রক্রিয়ায় পরিণত করে—এবং দেখায় আপনি দ্রুত ও ধারাবাহিকভাবে কিভাবে কাজ করেছেন।

সাধারণ জালপথ ও কীভাবে এড়াবেন

ভালভাবে নির্মিত সিস্টেমও বিবরণে ফেল করে ফেলতে পারে। এই জালপথগুলো সাধারণত পরে (আইনি পর্যালোচনা বা গ্রাহক অভিযোগের সময়) বেরিয়ে আসে, তাই এগুলোকে আগে থেকে প্রতিরোধ করে ডিজাইন করা উচিত।

1) সিস্টেমগুলোর মধ্যে লুকানো কাপলিং

সাধারণ ব্যর্থতাই হচ্ছে downstream টুলগুলো ধীরে ধীরে পছন্দগুলো ওভাররাইট করে—উদাহরণ: আপনার ESP ইম্পোর্টের পরে আবার ব্যবহারকারীকে “subscribed” করে দেয়, বা CRM ওয়ার্কফ্লো সম্মতি ফিল্ড পরিবর্তন করে।

এটা এড়াতে আপনার অ্যাপকে consent ও সাবস্ক্রিপশন পছন্দের source-of-truth বানান এবং ইন্টিগ্রেশনগুলোকে listener হিসেবে গ্রহণ করুন। ইভেন্ট-ভিত্তিক আপডেট (append-only ইভেন্ট) পছন্দ করুন পিরিয়ডিক সিঙ্কের চেয়ে যা স্টেট ক্লবের ঝুঁকি বাড়ায়। কারা কী বদলাতে পারবে ও কোন সিস্টেম থেকে—এসব স্পষ্ট নিয়ম রাখুন।

2) অতিরিক্ত ডেটা সংগ্রহ (বিশেষ করে IP/ডিভাইস)

“প্রয়োজন হলে সবকিছু লগ করে রাখি” এর লোভ আছে, কিন্তু IP ঠিকানা, ডিভাইস ফিঙ্গারপ্রিন্ট, বা সুনির্দিষ্ট লোকেশন সংগ্রহ করলে আপনার কমপ্লায়েন্স বোঝা বাড়ে ও ঝুঁকি বাড়ে।

GDPR সম্মতি রেকর্ডে মনোযোগ দিন: user identifier, purpose, timestamp, policy/version, channel, এবং action—এগুলোই সাধারণত যথেষ্ট। যদি IP/ডিভাইস ডেটা রাখেন, কারণ নথিভুক্ত করুন, রিটেনশন সীমাবদ্ধ করুন, এবং অ্যাক্সেস সীমাবদ্ধ রাখুন।

3) ডিফল্ট ও ডার্ক প্যাটার্ন

পূর্ব-চেক করা বক্স, বিভ্রান্তিকর টগল, bundled purposes (“marketing + partners + profiling”), বা খুঁজে পাওয়া কঠিন অপ্ট-আউট সম্মতি অবৈধ করে দিতে পারে এবং বিশ্বাস নষ্ট করে।

স্পষ্ট লেবেল, নিরপেক্ষ ডিজাইন, এবং সুরক্ষিত ডিফল্ট ব্যবহার করুন। অপ্ট-আউটকে অপ্ট-ইনের সমতুল্য সহজ রাখুন। ডাবল অপ্ট-ইন ব্যবহার করলে নিশ্চিত করুন কনফার্মেশন ধাপ একই উদ্দেশ্য(গুলি) ও পলিসি টেক্সটের সঙ্গে সংযুক্ত।

4) পলিসি টেক্সট পরিবর্তন হলেও পুনর-সম্মতি না করা

আপনার পলিসি টেক্সট, উদ্দেশ্য বিবরণ, বা ভেন্ডর তালিকা পরিবর্তিত হবে। যদি সিস্টেম ভার্সন ট্র্যাক করতে না পারে, আপনি জানতে পারবেন না কোন ব্যবহারকারী কোন টেক্সটে সম্মত হয়েছে।

প্রতিটি সম্মতি ইভেন্টের সঙ্গে পলিসি/ভার্সন রেফারেন্স সংরক্ষণ করুন। যখন পরিবর্তনগুলি উপাদেয় হয়, শুধুমাত্র তখন re-consent ট্রিগার করুন এবং পুরোনো প্রমাণ অক্ষুণ্ণ রাখুন।

5) দ্রুত সিদ্ধান্ত “বিল্ড বনাম বাই” না নেওয়া

বিল্ড করলে কন্ট্রোল বেশি, কিন্তু চলমান কাজও বেশি (অডিট, এজ-কেস, ভেন্ডর পরিবর্তন)। বাই করলে সময় বাঁচে কিন্তু কাস্টমাইজেশনে সীমা থাকতে পারে।

যদি অপশনগুলো যাচাই করেন, প্রথমে রিকোয়ারমেন্ট ম্যাপ করুন, তারপর মোট খরচ ও অপারেশনাল শ্রম তুলনা করুন। দ্রুত কাজ করতে চাইলে, Koder.ai-র মত প্ল্যাটফর্ম আপনাকে React প্রেফারেন্স সেন্টার, Go + PostgreSQL কনসেন্ট API দ্রুত প্রটোটাইপ করতে সাহায্য করতে পারে—তারপর কোড বের করে আপনার এক্সিস্টিং পাইপলাইনে নেওয়া যায়।

যদি দ্রুত পথ চান, দেখুন /pricing.