WebView-তে সম্মতি: নেটিভ ও ওয়েব সম্মতি সিঙ্কে রাখা

ডাবল-ব্যানারের সমস্যা

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

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

প্রতিটি পক্ষ সম্মতি কোথায় সংরক্ষণ করে

নেটিভ

IAB TCF নির্দিষ্ট করে দিয়েছে ইন-অ্যাপ CMP কীভাবে সম্মতি সংরক্ষণ করে: iOS-এ NSUserDefaults এবং Android-এ SharedPreferences-এ, IABTCF_TCString, IABTCF_gdprApplies ও IABTCF_PurposeConsents-এর মতো স্ট্যান্ডার্ড কী ব্যবহার করে। বিজ্ঞাপন SDK এই কীগুলো সরাসরি পড়ে। IAB GPP IABGPP_ উপসর্গের অনুরূপ কী সংজ্ঞায়িত করেছে, যেমন IABGPP_HDR_GppString।

ওয়েব

একটি ওয়েব CMP সাধারণত তার সিদ্ধান্ত সাইটের ডোমেনের ফার্স্ট-পার্টি কুকি বা লোকাল স্টোরেজে সংরক্ষণ করে, এবং __tcfapi ও __gpp JavaScript ফাংশনের মাধ্যমে তা উন্মুক্ত করে। পেজের বিজ্ঞাপন ট্যাগ সেই ফাংশনগুলোই কল করে, নেটিভ স্টোরেজ নয়।

ফাঁক

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

সত্যের একটি উৎস বেছে নিন

প্রথম সিদ্ধান্ত হলো কোন পক্ষ সম্মতির মালিক। বেশির ভাগ অ্যাপের উত্তর নেটিভ CMP, কারণ:

যেসব হাইব্রিড অ্যাপের পুরো ইন্টারফেসই ওয়েব কনটেন্ট, সেগুলোর জন্য ওয়েব-ফার্স্ট যুক্তিসংগত হতে পারে, তবে তখন নেটিভ SDK-র জন্য আপনাকে সিদ্ধান্তটি নেটিভ স্টোরেজে ফিরিয়ে লিখতে হবে।

নেটিভ সম্মতি WebView-তে পৌঁছানো

নেটিভ সত্যের উৎস হলে WebView-কে একই সিদ্ধান্ত দেখতে পেতে হবে। প্রচলিত প্যাটার্ন:

  1. একটি __tcfapi বাস্তবায়ন ইনজেক্ট করুন। পেজের স্ক্রিপ্ট চলার আগে একটি ছোট স্ক্রিপ্ট ইনজেক্ট করুন যা __tcfapi (এবং দরকার হলে __gpp) সংজ্ঞায়িত করে এবং নেটিভ স্টোরেজ থেকে পড়া TC স্ট্রিং ও মান দিয়ে কলের উত্তর দেয়। তখন পেজের বিজ্ঞাপন ট্যাগ স্ট্যান্ডার্ড API-র মাধ্যমে নেটিভ সিদ্ধান্ত পায়।
  2. ওয়েব ব্যানার দমন করুন। পেজ আপনার অ্যাপের ভেতরে লোড হলে ওয়েব CMP যেন লুকানো থাকে তা কনফিগার করুন, যেমন কোয়েরি প্যারামিটার বা আপনার নিয়ন্ত্রণাধীন কাস্টম ইউজার এজেন্ট টোকেনের ভিত্তিতে। নইলে ব্যবহারকারী দ্বিতীয় ব্যানার দেখেন।
  3. লোডের সময় স্ট্রিং পাস করুন। কিছু ওয়েব CMP আরম্ভের সময় বিদ্যমান সম্মতি স্ট্রিং নিয়ে তা আপন করে নিতে পারে। সমর্থিত পদ্ধতির জন্য আপনার ওয়েব CMP-র ডকুমেন্টেশন দেখুন।

যে প্যাটার্নই ব্যবহার করুন, নিশ্চিত করুন ব্যবহারকারী নেটিভ সেটিংস স্ক্রিনে পছন্দ বদলালে ইনজেক্ট করা মান হালনাগাদ হয়, শুধু পরের অ্যাপ চালুর সময় নয়।

ওয়েব সম্মতি নেটিভে ফিরিয়ে দেওয়া

ব্যবহারকারীরা যদি WebView-র ভেতরে সম্মতি বদলাতে পারেন, উদাহরণস্বরূপ কোনো গোপনীয়তা সেটিংস পেজের মাধ্যমে, তাহলে অ্যাপকে তা জানতে হবে। একটি JavaScript ব্রিজ ব্যবহার করুন: iOS-এ মেসেজ হ্যান্ডলার বা Android-এ JavaScript ইন্টারফেস। ওয়েব পক্ষ __tcfapi('addEventListener', ...) দিয়ে শোনে এবং নতুন স্ট্রিং নেটিভ কোডে পাঠায়, যা স্ট্যান্ডার্ড কীগুলো লেখে। লেখার আগে WebView থেকে আসা ইনপুট যাচাই করুন; শুধু নিজের কনটেন্টের বার্তা গ্রহণ করুন।

WebView-র ভেতরে বিজ্ঞাপন

WebView-তে রেন্ডার হওয়া বিজ্ঞাপন ওয়েব বিজ্ঞাপন। বিজ্ঞাপন SDK দুটিকে যুক্ত করার উপায় না দিলে সেগুলো পেজ থেকে সম্মতি পড়ে, নেটিভ স্টোরেজ থেকে নয়। উদাহরণস্বরূপ, Google-এর Mobile Ads SDK WebView নিবন্ধনের একটি API দেয় যাতে তার ভেতরের বিজ্ঞাপন অ্যাপের সংকেত ব্যবহার করতে পারে; আপনার SDK-র বর্তমান ডকুমেন্টেশন দেখুন। যাই হোক, পরীক্ষা করে নিশ্চিত করুন WebView থেকে যাওয়া বিজ্ঞাপন অনুরোধ নেটিভ বিজ্ঞাপন অনুরোধের মতোই একই TC বা GPP স্ট্রিং বহন করে।

পরীক্ষার চেকলিস্ট

মূল বিষয়গুলো

← ব্লaderegistrdelays delays সবগুলো পড়ুন →