স্টোরেজ লিমিটেশন ২০২৬ সালে অ্যানালিটিক্সের জন্য প্রয়োগের নতুন সম্মুখসারি

GDPR-এর ব্যয়বহুল প্রশ্নটি আগে ছিল এটি সংগ্রহ করার বৈধ ভিত্তি আপনার আছে কি। ২০২৬ সালে তা হয়ে দাঁড়াল এটি এখনও আপনার ডেটাবেসে কেন। দুটি প্রয়োগ-ঘটনা রিটেনশনকে নথির ফুটনোট থেকে তুলে এনে সম্মুখসারিতে দাঁড় করিয়েছে, এবং অ্যানালিটিক্স সিস্টেমগুলো ঠিক সেই প্রভাব-বলয়ের মধ্যেই আছে।

দুটি রায় যা লক্ষ্য বদলে দিল

২০২৬ সালের ১৩ জানুয়ারি CNIL Free Mobile-কে ২.৭ কোটি ইউরো এবং Free-কে ১.৫ কোটি ইউরো জরিমানা করে। বেশিরভাগ প্রতিবেদন ২০২৪ সালের সেই লঙ্ঘনে মনোযোগ দিয়েছিল যেখানে ২.৪ কোটি গ্রাহক চুক্তি ফাঁস হয়েছিল, কিন্তু রায়টি সরাসরি অনুচ্ছেদ ৫(১)(e) — স্টোরেজ লিমিটেশন — উল্লেখও করেছে। Free Mobile কোনো যুক্তি ছাড়াই দশ বছরেরও বেশি আগে বাতিল হওয়া ২৮ লক্ষ চুক্তির ডেটা রেখে দিয়েছিল। ডেটা অবৈধভাবে সংগ্রহ করা হয়নি। তা অবৈধভাবে রাখা হয়েছিল।

এক মাস পরে, EDPB তাদের ২০২৫ সালের সমন্বিত প্রয়োগ-পদক্ষেপের ফলাফল প্রকাশ করে। বত্রিশটি ডেটা সুরক্ষা কর্তৃপক্ষ ইরেজার চর্চা নিয়ে ৭৬৪টি কন্ট্রোলার অডিট করে দুটি কাঠামোগত ব্যর্থতা পায়: অভ্যন্তরীণ ডেটা শ্রেণিবিন্যাসের অনুপস্থিতি, এবং IT সিস্টেমের ভেতরেই স্বয়ংক্রিয় মুছে ফেলার অনুপস্থিতি। প্রযুক্তিগতভাবে যা কিছু প্রয়োগ করে না এমন একটি নথিভুক্ত রিটেনশন নীতিকে লঘুকারী নয়, বরং গুরুতরকারী উপাদান হিসেবে গণ্য করা হয়েছে।

সংকেতটি দ্ব্যর্থহীন। নিয়ন্ত্রকেরা এখন ধরে নেন সংগ্রহ ঘটেছে; তাঁরা মুছে ফেলা অডিট করেন।

অ্যানালিটিক্সই কেন দেখার সুস্পষ্ট জায়গা

অনুচ্ছেদ ৫(১)(e) অনুযায়ী স্টোরেজ লিমিটেশন বলে, উদ্দেশ্য যতটা প্রয়োজন তার চেয়ে বেশি সময় ব্যক্তিগত ডেটাকে শনাক্তযোগ্য রূপে রাখা যাবে না। বেশিরভাগ অ্যানালিটিক্স স্ট্যাক নীরবেই এতে ব্যর্থ হয়।

একটি সাধারণ ইভেন্ট টেবিল প্রতিটি ইন্টারঅ্যাকশনের জন্য একটি রো সংরক্ষণ করে যা একটি স্থিতিশীল আইডেন্টিফায়ারের সঙ্গে যুক্ত — একটি cookie ID, একটি ডিভাইস ID, একটি হ্যাশ করা ইমেল — টাইমস্ট্যাম্পসহ এবং কোনো মেয়াদ ছাড়াই। স্কিমা এমনভাবে নকশা করা হয় যাতে সবকিছু চিরকাল রাখা যায়, যাতে "হয়তো পরে এটি কোয়েরি করতে চাইব" টিকে থাকে। এটিই ঠিক সেই সাবধানতাবশত রিটেনশন যার জন্য CNIL শাস্তি দিয়েছে।

সমস্যা আরও বাড়ে কারণ আইডেন্টিফায়ারই একটি রো-কে ব্যক্তিগত ডেটা করে তোলে। যতক্ষণ user_id = a91f... মাসের পর মাস ইভেন্ট জুড়ে কোনো ব্যক্তির সঙ্গে ফিরে যুক্ত করা যায়, ততক্ষণ সেই রো-গুলোর প্রতিটি পরিসরের মধ্যে থাকে, প্রতিটি অ্যাক্সেস ও ইরেজার অনুরোধের অধীন, এবং প্রতিটি লঙ্ঘনের সময় একটি দায়। রিটেনশন কোনো স্টোরেজ খরচ নয়। এটি সময় দিয়ে পরিমাপিত এক্সপোজার।

লেখার সময় ন্যূনতমকরণ, পড়ার সময় মুছে ফেলার চেয়ে ভালো

টেকসই সমাধান কোনো উন্নততর cron জব নয় যা পুরোনো রো ছেঁটে দেয়। এটি এমন একটি ডেটা মডেল যেখানে শনাক্তযোগ্য রূপ প্রথম থেকেই কখনও টিকে থাকে না।

Monoid-এর আইডেন্টিটি মডেল এরই চারপাশে গড়া। একজন ভিজিটরকে শুধু একটি দৈনিক হ্যাশ দিয়ে উপস্থাপন করা হয়:

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

কাঁচা IP ও User-Agent শুধু Worker মেমরিতে ততক্ষণই থাকে যতক্ষণ সেই হ্যাশ গণনা করতে প্রয়োজন; D1 হ্যাশ সংরক্ষণ করে, কখনোই কাঁচা মান নয়। যেহেতু তারিখ একটি ইনপুট, একই ভিজিটরের হ্যাশ প্রতি মধ্যরাতে বদলে যায়। রাখার মতো কোনো স্থিতিশীল দিন-পেরোনো আইডেন্টিফায়ার নেই, তাই স্টোরেজ লিমিটেশন যে ক্রস-সেশন প্রোফাইলকে লক্ষ্য করে তা জমা হতেই পারে না — নীতির মাধ্যমে নয়, বরং গঠনের মাধ্যমে।

এটিই লেখার সময় ডেটা ন্যূনতমকরণ। আপনি পরে সংযোগটি মোছেন না কারণ আপনি তা কখনও লেখেনইনি। যখন মুছে ফেলার মতো কোনো টেকসই কী থাকে না, তখন ইরেজার অনুরোধ তুচ্ছ হয়ে যায়।

এমন রিটেনশন যা আপনি সত্যিই প্রমাণ করতে পারেন

স্টোরেজ লিমিটেশনের তবুও একটি বাইরের সীমা দরকার, এবং রক্ষণযোগ্য সীমা ছোট ও প্রয়োগকৃত, দীর্ঘ ও আকাঙ্ক্ষামূলক নয়। Monoid পেজভিউ ডেটা সর্বোচ্চ ৭৩০ দিন রাখে। দুই বছর প্রবণতা বিশ্লেষণের জন্য একটি ইচ্ছাকৃত ঊর্ধ্বসীমা, এবং পার্জ টেবিলের ওপর একটি বাস্তব অপারেশন, কোনো নীতির PDF-এ লেখা একটি লাইন নয়। EDPB-এর সিদ্ধান্ত ছিল, প্রয়োগহীন নীতিই সেই ফাঁক যা তদন্ত কাজে লাগায়; এমন একটি রিটেনশন যা সত্যিই কার্যকর হয় তা সেটি বন্ধ করে দেয়।

সংমিশ্রণটি যেকোনো একক অংশের চেয়ে বেশি গুরুত্বপূর্ণ। প্রতিদিন ঘূর্ণায়মান হ্যাশের অর্থ রিটেনশন প্রযোজ্য হওয়ার আগেই ডেটা ইতিমধ্যে সমষ্টিগত আকারে। ৭৩০-দিনের পার্জের অর্থ সেই সমষ্টিগত সংকেতেরও একটি কঠোর, প্রমাণযোগ্য সমাপ্তি আছে।

আপনি যে অ্যানালিটিক্সের ওপর নির্ভর করেন তা কীভাবে যাচাই করবেন

আপনার সাইটের পেছনে যে অ্যানালিটিক্সই থাকুক, তিনটি যাচাই সরাসরি নিয়ন্ত্রকেরা যা অডিট করেছেন তার সঙ্গে মেলে:

• এমন প্রতিটি ফিল্ড খুঁজুন যা সময় জুড়ে একটি রেকর্ডকে কোনো ব্যক্তির সঙ্গে যুক্ত করে। একটি স্থিতিশীল user ID, একটি persistent cookie মান, একটি কাঁচা IP, একটি fingerprint। প্রতিটি একটি ইভেন্ট লগকে একটি সংরক্ষিত প্রোফাইলে রূপান্তরিত করে — তাই জিজ্ঞেস করুন আপনি যে অ্যানালিটিক্স ব্যবহার করেন তা আদৌ এগুলোর কোনোটি সংরক্ষণ করে কি না।
• জিজ্ঞেস করুন রিটেনশন কখন প্রয়োগ হয় — ইনজেশনে নাকি ত্রৈমাসিক পর্যালোচনায়। ডেটা লেখার সময় যে ন্যূনতমকরণ ঘটে তা এমন একটি মুছে ফেলার জবের চেয়ে ভালো যা চালানোর কথা কাউকে মনে রাখতে হয়। সবচেয়ে শক্তিশালী উত্তর হলো এমন একটি মডেল যেখানে শনাক্তযোগ্য রূপ প্রথম থেকেই কখনও সংরক্ষণ করা হয়নি।
• জিজ্ঞেস করুন মুছে ফেলা প্রমাণযোগ্য কি না। কোনো ভেন্ডর যদি এমন একটি কঠোর রিটেনশন সীমা দেখাতে না পারে যা সত্যিই কার্যকর হয়, তবে তার কাছে একটি নীতি আছে, নিয়ন্ত্রণ নয় — এবং EDPB-এর যাচাই এইমাত্র বলে দিল এই দুইয়ের মধ্যে কোনটিতে জরিমানা হয়।

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

সূত্র

• GDPR অনুচ্ছেদ 5 — ব্যক্তিগত ডেটা প্রক্রিয়াকরণের নীতিমালা (স্টোরেজ লিমিটেশন)
• রেগুলেশন (EU) 2016/679 (GDPR), EUR-Lex অফিসিয়াল টেক্সট
• EDPB — মুছে ফেলার অধিকার বাস্তবায়ন সংক্রান্ত 2025 সমন্বিত প্রয়োগ পদক্ষেপ
• Google Analytics 4 — ডেটা রিটেনশন