Consent Mode v2 এবং ২০২৬ সালের জুনে Google Signals-এর অবসান

১৫ জুন ২০২৬-এ Google বিজ্ঞাপন ডেটার একটি স্বাধীন নিয়ন্ত্রণ হিসেবে Google Signals সরিয়ে দেয়। ওই তারিখের পর, আপনার Consent Management Platform (CMP) যে ad_storage সম্মতি সংকেত পাঠায়, সেটিই হয়ে ওঠে একমাত্র গেট যা ঠিক করে visitor-স্তরের ডেটা Google Ads-এ পৌঁছাবে কি না। যদি আপনার CMP ভুলভাবে কনফিগার করা থাকে, তবে সেই ভুল ধরার জন্য Analytics-এ আর কোনো server-side সেটিং অবশিষ্ট নেই।

এটি একটি নিঃশব্দ কিন্তু তাৎপর্যপূর্ণ পরিবর্তন। এটি সম্মতির সঠিকতার সম্পূর্ণ ভার একটি JavaScript স্তরের ওপর চাপিয়ে দেয় যা কোনো ডেটা সংগ্রহের আগে visitor-এর browser-এ চলে। এই স্তরটি ঠিক কী করে তা বোঝা সার্থক, কারণ এটিই সেই জটিলতা যা cookie-বিহীন ডিজাইন কখনও বহন করে না।

Consent Mode v2 আসলে কী

Consent Mode v2 হলো Google-এর সেই framework যা তার tags-কে জানায় তারা storage ব্যবহার করার অনুমতিপ্রাপ্ত কি না। এটি কোনো সম্মতি ব্যানার নয় — এটি আপনার ব্যানার ও Google-এর tags-এর মধ্যেকার তার-জোড়া। আপনার CMP চারটি সংকেত সেট করে:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
});

• ad_storage বিজ্ঞাপন cookies, device শনাক্তকারী এবং Google Ads-এ পাঠানো visitor-স্তরের ডেটা নিয়ন্ত্রণ করে।
• analytics_storage সেই Analytics cookie নিয়ন্ত্রণ করে যা একটি client ID বরাদ্দ করে।
• ad_user_data, Enhanced Conversions-এর জন্য email-এর মতো first-party ডেটার hashing-এর অনুমতি দেয়।
• ad_personalization ঠিক করে Analytics ডেটা personalized বিজ্ঞাপন targeting-কে খাওয়ায় কি না।

visitor যখন সম্মতি দেয়, তখন আপনার CMP একটি দ্বিতীয় কল চালায় যা সংশ্লিষ্ট সংকেতগুলো granted-এ আপডেট করে। পরবর্তী সবকিছু নির্ভর করে সেই আপডেট সঠিকভাবে পৌঁছায় কি না তার ওপর।

basic বনাম advanced, এবং advanced কেন আছে

দুটি বাস্তবায়ন mode আছে, আর এদের পার্থক্য আইনগতভাবে গুরুত্বপূর্ণ।

basic mode-এ, সম্মতি না দেওয়া পর্যন্ত Google-এর tags একেবারেই লোড হয় না। প্রত্যাখ্যান করলে কিছুই পাঠানো হয় না।

advanced mode-এ, সমস্ত সংকেত ডিফল্টে denied রেখে tags তৎক্ষণাৎ লোড হয়, এবং তবুও Google-এ cookieless pings পাঠায় — এমন একটি অনুরোধ যাতে কোনো শনাক্তকারী, কোনো client ID এবং কোনো সংরক্ষিত অবস্থা নেই। Google এই pings-এর পরিমাণ, সঙ্গে যে সংখ্যালঘু সম্মতি দেয় তাদের আচরণ ব্যবহার করে সেই conversions মডেল করে যেগুলো সে সরাসরি পর্যবেক্ষণ করতে পারে না।

advanced mode আছে কারণ সম্মতির হার কম এবং বিজ্ঞাপনদাতারা তাদের সংখ্যা ফিরে পেতে চায়। কিন্তু সম্মতির আগে পাঠানো cookieless ping-ও তৃতীয় পক্ষের কাছে ডেটার সঞ্চালনই, আর ePrivacy-এর Article 5(3)-এর EDPB-র প্রযুক্তি-নিরপেক্ষ পাঠ কেবল cookie বাদ দেওয়ায় অনুরোধকে অব্যাহতি দেয় না। মডেল করা conversions-এর জন্য নির্ভরযোগ্য কিছু উৎপন্ন করতে সম্মতিপ্রাপ্ত sessions-এর একটি ন্যূনতম পুলও লাগে, তাই ছোট সাইট পায় কেবল নয়েজ।

১৫ জুনের অবসান কী সরিয়ে দেয়

এ পর্যন্ত Google Signals দ্বিতীয় একটি গেট হিসেবে কাজ করত। Consent Mode যা-ই রিপোর্ট করুক, বিজ্ঞাপন ডেটা শেয়ারিং সীমিত করতে আপনি এটি Analytics-এ বন্ধ রাখতে পারতেন। সেই নিরাপত্তা-জাল চলে গেল।

বন্ধ হওয়ার পর:

• Google Ads, Analytics-side সেটিং পড়া বন্ধ করে দেয় এবং একচেটিয়াভাবে আপনার CMP-র পাঠানো Consent Mode সংকেতের ওপর নির্ভর করে।
• Google Signals কেবল Analytics-ব্যবহারে সংকুচিত হয় — GA4-এর ভেতরে sessions-কে logged-in ব্যবহারকারীদের সঙ্গে সংযুক্ত করা।
• IP ঠিকানা সংগ্রহ চলতেই থাকে এবং লিঙ্ক করা Ads অ্যাকাউন্টে পাঠানোর আগে এনক্রিপ্ট করা হয়, যেখানে গন্তব্য অ্যাকাউন্টের সেটিং নিয়ন্ত্রণ নেয়।

ব্যবহারিক প্রভাব: একটিমাত্র ব্যর্থ gtag('consent', 'update', ...) কল — একটি race condition, প্রথম tag-এর পরে লোড হওয়া একটি CMP, ডিফল্ট অবস্থা ফেলে দেওয়া একটি deploy — এখন নীরবে এমন ডেটা পাঠায় যা আপনি আটকাতে চেয়েছিলেন। GDPR-এর অধীনে এটি বৈধ ভিত্তি ছাড়া প্রক্রিয়াকরণ, এবং server-side নিরাপত্তা-জাল সরে যাওয়ায় উন্মোচন সীমিত ছিল বলে যুক্তি দেওয়া কঠিন হয়।

সাম্প্রতিক নির্দেশনা অনুসারে এটিও বিজ্ঞাপন ডেটা শেয়ার করার পদ্ধতিতে একটি বাস্তবিক (material) পরিবর্তন। EU visitor-যুক্ত সাইটগুলোর জন্য, এটি ব্যবহারকারীদের অবহিত করার বাধ্যবাধকতা সৃষ্টি করতে পারে — একটি পর্যালোচনা যা সময়সীমার পরে নয়, আগেই করা উচিত।

যে জটিলতার কখনও থাকাই উচিত ছিল না

এক ধাপ পিছিয়ে দেখুন একটি সম্মতিসম্পন্ন Consent Mode v2 সেটআপ কী কী দাবি করে: একটি CMP, চারটি সম্মতি সংকেত, ডিফল্ট অবস্থা, tag লোডের সাপেক্ষে সঠিকভাবে ক্রমিত update কল, আইনি পরিণতিসহ advanced বনাম basic-এর সিদ্ধান্ত, মডেল করা conversions যা কেবল একটি traffic প্রান্তসীমার ওপরে কাজ করে, এবং এখন নিরাপত্তা-জাল ছাড়া একটিমাত্র ব্যর্থতা-বিন্দু।

এই গোটা যন্ত্রপাতি আছে শনাক্তকারী — client ID, বিজ্ঞাপন cookie, hashed email — ব্যবহার চালিয়ে যাওয়ার জন্য, একইসঙ্গে সম্মতি আইনের সঠিক দিকে থাকার জন্য। শনাক্তকারী সরিয়ে দিন, গোটা যন্ত্র শূন্যে ভেঙে পড়ে।

cookie-বিহীন tracker-এর আটকানোর মতো কোনো ad_storage নেই কারণ এটি কোনো বিজ্ঞাপন storage সেট-ই করে না। প্রত্যাখ্যান করার মতো কোনো client ID নেই কারণ পরিচয় হলো একটি একমুখী hash SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) যা edge-এ মেমোরিতে গণনা করা হয় এবং কখনও উল্টানো হয় না। কাঁচা IP ও User-Agent কেবল সেই hash গণনার জন্য ব্যবহৃত হয়; D1 ইনপুট নয়, hash সংরক্ষণ করে। ব্যর্থ হতে পারে এমন কোনো সম্মতি সংকেত নেই কারণ Article 5(3)-এর অধীনে সম্মতি দেওয়ার মতো কিছুই নেই — পৃষ্ঠা সরবরাহের জন্য visitor-এর device-এ প্রবেশাধিকার কঠোরভাবে প্রয়োজনীয়, আর /collect-এ পাঠানো ২ KB-র কম ওই script কোনো storage-ই পড়ে না।

১৫ জুনের বন্ধ হওয়া "আমার Consent Mode কি সঠিকভাবে কনফিগার করা" — এর চেয়ে ধারালো প্রশ্ন তোলার ভালো মুহূর্ত। জিজ্ঞাসা করুন, pageviews মাপতে আপনি প্রথমেই কেন একটি সম্মতি state machine চালাচ্ছেন। Google যে conversions-গুলো cookieless pings থেকে মডেল করে, সেগুলো এমন ডেটার অনুমান যা সংগ্রহের অনুমতিই আপনার কখনও ছিল না। কোনো শনাক্তকারী ছাড়াই যা সত্যিই ঘটেছে তা গোনা — সবসময়ই সহজতর ব্যবস্থা ছিল।

সূত্র

• Google Analytics ডেটা নিয়ন্ত্রণে আপডেট — Analytics সহায়তা
• সম্মতি মোড রেফারেন্স — Google Ads সহায়তা
• সম্মতি মোড সংক্ষিপ্ত বিবরণ — Google for Developers
• ওয়েবসাইটে সম্মতি মোড সেট আপ করুন — Google for Developers
• EU ব্যবহারকারী সম্মতি নীতি — Google