এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

নয়েজ ইনজেকশন

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

নয়েজ ইনজেকশন ব্যবহারের সুবিধাগুলো জানুন

পার্থক্য যাচাই প্রযোজ্য নয়: নয়েজ ইনজেকশন সহ কোয়েরি চালানোর সময়, অ্যাডস ডেটা হাব পূর্ববর্তী ফলাফল সেটের সাথে সাদৃশ্যের কারণে সারি ফিল্টার করে না। এর মানে হলো, ব্যবহারকারীর গোপনীয়তা রক্ষা করার পাশাপাশিও আপনি ডেটার একটি সামগ্রিক চিত্র পেতে পারেন।

সমস্যা সমাধান সহজতর হয়েছে: শুধুমাত্র অ্যাগ্রিগেশনের প্রয়োজনে সারিগুলো বাদ দেওয়া হয়, ফলে কোয়েরিগুলোর সমস্যা সমাধান এবং সেগুলোকে প্রয়োজন অনুযায়ী পরিবর্তন করা সহজ হয়।

নতুন কোনো সিনট্যাক্স শেখার নেই: ডিফারেন্স চেকের পরিবর্তে নয়েজ ব্যবহার করতে আপনাকে কোনো নতুন কোয়েরি সিনট্যাক্স শিখতে হবে না বা প্রাইভেসি ধারণা সম্পর্কে পারদর্শী হতে হবে না।

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

কোলাহল কীভাবে গোপনীয়তার প্রয়োজনীয়তাকে প্রভাবিত করে তা জানুন

পার্থক্য যাচাই: নয়েজ ইনজেকশন অ্যাডস ডেটা হাব-এর বিদ্যমান পার্থক্য যাচাইয়ের উপর নির্ভর করে না। আপনি যখন নয়েজ ইনজেকশন ব্যবহার করেন, তখন পার্থক্য যাচাই নিষ্ক্রিয় হয়ে যায়।

একত্রীকরণের প্রয়োজনীয়তা: নয়েজ ইনজেকশন প্রায় ২০ বা তার বেশি স্বতন্ত্র ব্যবহারকারীর ইম্প্রেশন ডেটা এবং প্রায় ১০ বা তার বেশি স্বতন্ত্র ব্যবহারকারীর ক্লিক বা কনভার্সন ডেটা আউটপুট করে।

স্থির পরীক্ষা: কোনো প্রভাব নেই।

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

নয়েজ মোড একই কোয়েরির মধ্যে বা একাধিক কোয়েরিতে একই অ্যাগ্রিগেট ফলাফল পুনরায় গণনা করার ক্ষেত্রে অতিরিক্ত ও কঠোর সীমাবদ্ধতা আরোপ করে। ডেটা অ্যাক্সেস বাজেটের মতোই, আপনি ডেটাসেটের ঘন ঘন ব্যবহৃত তারিখগুলোর অ্যাক্সেস হারাতে পারেন; কিন্তু একই অ্যাগ্রিগেট ফলাফল পুনরায় গণনা করার কারণে সৃষ্ট সীমাবদ্ধতা শুধুমাত্র নয়েজ মোডের কোয়েরিগুলোকেই সীমিত করবে, ডিফারেন্স চেক মোডের কোয়েরিগুলোকে নয়। আরও তথ্যের জন্য, ‘Repeated results’ দেখুন।

গোপনীয়তা যাচাই সম্পর্কে আরও জানুন ।

নয়েজ ইনজেকশন কীভাবে ফলাফলকে প্রভাবিত করে তা বুঝুন।

অ্যাডস ডেটা হাব তথ্য ফাঁসের ঝুঁকি কমাতে কিছু অপ্রয়োজনীয় তথ্য যোগ করে—এই ঝুঁকি হলো যে, কেউ কোনো নির্দিষ্ট ব্যবহারকারীর তথ্য জেনে ফেলতে পারে। এটি গোপনীয়তা এবং উপযোগিতার মধ্যে ভারসাম্য রক্ষা করে।

Ads Data Hub-এ নয়েজ ইনজেকশন কোয়েরির ফলাফলকে নিম্নোক্তভাবে রূপান্তরিত করে:

এটি সামগ্রিক ফলাফলে ব্যতিক্রমী ব্যবহারকারীদের অবদানকে সীমাবদ্ধ করে। এটি প্রতিটি সমষ্টিতে প্রত্যেক ব্যবহারকারীর অবদান যোগ করে এবং তারপর সর্বনিম্ন ও সর্বোচ্চ সীমাবদ্ধতার সীমা দিয়ে প্রতিটি অবদানকে সর্বোচ্চ করে দেয়।
এটি ব্যবহারকারী-ভিত্তিক সীমাবদ্ধ অবদানসমূহকে একত্রিত করে।
এটি প্রতিটি সমষ্টিগত ফলাফলে—অর্থাৎ প্রতিটি সারিতে থাকা প্রতিটি অ্যাগ্রিগেশন ফাংশন কলের ফলাফলে—নয়েজ যোগ করে। এই র‍্যান্ডম নয়েজের মাত্রা নির্ধারিত সীমার সমানুপাতিক।
এটি প্রতিটি সারির জন্য একটি নয়েজি ইউজার কাউন্ট গণনা করে এবং খুব কম ব্যবহারকারী থাকা সারিগুলো বাদ দিয়ে দেয়। এটি ডিফারেন্স চেক মোডে থাকা কে-অ্যানোনিমিটির মতোই, কিন্তু নয়েজের কারণে একই ডেটাসেটে চলমান জবগুলো ভিন্ন ভিন্ন সারি বাদ দিতে পারে। এছাড়াও, নয়েজ মোডে কম সারি বাদ দেওয়া হয়, কারণ এর অ্যাগ্রিগেশন রিকোয়ারমেন্ট কম (ঠিক ৫০-এর পরিবর্তে প্রায় ২০)।

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

সমষ্টিগত ক্ল্যাম্পিং সম্পর্কে

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

অন্তর্নিহিত ক্ল্যাম্পিং

ইমপ্লিসিট ক্ল্যাম্পিং ব্যবহার করার জন্য আপনার কোনো বিশেষ SQL সিনট্যাক্সের প্রয়োজন নেই, এটি ডিফল্টরূপে প্রয়োগ করা হয়। ইমপ্লিসিট বাউন্ডস ডেটা থেকেই উদ্ভূত হয় এবং প্রতিটি অ্যাগ্রিগেশনের জন্য নির্ধারিত হয়। যদি কিছু অ্যাগ্রিগেশনের মানের পরিসর অন্যদের তুলনায় বিস্তৃত হয়, তবে ইমপ্লিসিট বাউন্ডিং প্রয়োজন অনুযায়ী বিভিন্ন অ্যাগ্রিগেশনের জন্য ভিন্ন ভিন্ন বাউন্ডস অনুমান করতে পারে। এর ফলে সাধারণত ভুলের হার কম হয়। উল্লেখ্য যে, COUNT(DISTINCT user_id) স্বয়ংক্রিয়ভাবে প্রতি ব্যবহারকারীর অবদানকে 1 এ ক্ল্যাম্প করে।

সুস্পষ্ট ক্ল্যাম্পিং

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

Ads Data Hub সুস্পষ্ট ক্ল্যাম্পিং-এর জন্য সম্পূরক ADH.ANON অ্যাগ্রিগেট ফাংশন সরবরাহ করে। সুস্পষ্ট ক্ল্যাম্পিং ব্যবহার করতে, নিম্ন সীমা এবং উচ্চ সীমা নির্দেশকারী পূর্ণসংখ্যা যোগ করে প্রতিটি সমর্থিত অ্যাগ্রিগেট ফাংশনের জন্য সীমা নির্ধারণ করুন। উদাহরণস্বরূপ:

SELECT
campaign_name,
-- Set lower and upper bounds to 0 and 1, respectively
ADH.ANON_COUNT(*, contribution_bounds_per_group => (0,1))
FROM data
GROUP BY 1

নয়েজ ইনজেকশন ব্যবহার করে একটি কোয়েরি চালান

একটি রিপোর্ট খুলুন।
প্রাইভেসি নয়েজ সেটিংস টগলটি ক্লিক করে ‘ইউজ নয়েজ’ পজিশনে নিয়ে যান।
কোয়েরিটি চালান ।
অতিরিক্ত কোলাহলের প্রভাব পর্যালোচনা করুন ।
ঐচ্ছিক: নয়েজের প্রভাব কমাতে কোয়েরিটি পরিবর্তন করুন ।

শব্দের প্রভাব পর্যালোচনা করুন

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

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

প্রভাবিত ফলাফলের শতাংশ	সূচক রঙ	প্রভাব
<৫%	সবুজ	কম প্রভাব
৫%-১৫%	হলুদ	মাঝারি প্রভাব
১৫%-২৫%	কমলা	উচ্চ প্রভাব
>২৫%	লাল	খুব উচ্চ প্রভাব

আপনি হোম পেজে সাম্প্রতিক রিপোর্ট জবগুলির গোপনীয়তার সারাংশও প্রিভিউ করতে পারেন। কোনো নির্দিষ্ট জবের গোপনীয়তা প্রিভিউ করার জন্য, ‘সাম্প্রতিক কার্যকলাপ’ (Recent activity) -এর অধীনে জব কার্ডে থাকা প্রাইভেসি টিপ আইকন ‘privacy_tip’- এর উপর পয়েন্টারটি ধরে রাখুন।

কোয়েরিগুলো অভিযোজিত করুন

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

নিম্নলিখিতগুলি সাধারণ নির্দেশিকা:

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

সমর্থিত সমষ্টিগত ফাংশন

নিম্নলিখিত সমষ্টিগত ফাংশনগুলি নয়েজ সহ সমর্থিত:

SUM(...)
COUNT(*)
COUNT(...)
COUNTIF(...)
COUNT(DISTINCT ...)
APPROX_COUNT_DISTINCT(...)
AVG(...)

DISTINCT কীওয়ার্ডটি শুধুমাত্র COUNT ফাংশনের সাথেই সমর্থিত। যখন এটি Ads Data Hub টেবিলের user_id কলামের সরাসরি রেফারেন্সের সাথে অথবা এমন কোনো এক্সপ্রেশনের সাথে ব্যবহৃত হয় যা user_id বা NULL রিটার্ন করে, যেমন COUNT(DISTINCT IF(..., user_id, NULL)) , তখন COUNT DISTINCT এবং APPROX_COUNT_DISTINCT(...) ফাংশনগুলো প্রতি ব্যবহারকারীর অবদানকে 1 ক্ল্যাম্প করে গণনা করা হয়। যখন COUNT DISTINCT কোনো নন- user_id কলামকে রেফারেন্স করে, তখন এটিকে ইমপ্লিসিট ক্ল্যাম্পিং সহ APPROX_COUNT_DISTINCT ব্যবহার করে আনুমানিক করা হয়।

পরিপূরক সমষ্টিগত ফাংশন

নিয়মিত অ্যাগ্রিগেটর সমর্থন করার পাশাপাশি, অ্যাডস ডেটা হাব অতিরিক্ত ADH.ANON অ্যাগ্রিগেট ফাংশন চালু করেছে যা সুস্পষ্ট ক্ল্যাম্পিং সমর্থন করে। এই অ্যাগ্রিগেটরগুলোর সিনট্যাক্স বিগকোয়েরি ডিফারেনশিয়ালি প্রাইভেট অ্যাগ্রিগেট ফাংশনগুলোর মতোই, তবে এগুলোর জন্য WITH DIFFERENTIAL_PRIVACY ক্লজটির প্রয়োজন হয় না।

ADH.ANON_SUM( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )
ADH.ANON_COUNT( *, [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )
ADH.ANON_COUNT( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )
ADH.ANON_AVG( ..., [ contribution_bounds_per_group => (lower_bound, upper_bound) ] )
ADH.ANON_PERCENTILE_CONT( ..., percentile, contribution_bounds_per_row => (lower_bound, upper_bound) )
ADH.ANON_COUNT_DISTINCT( ..., [ max_contributions_per_group => upper_bound ] )

ADH.ANON_SUM , ADH.ANON_COUNT এবং ADH.ANON_AVG প্যারামিটারসমূহ:

প্রতি contribution_bounds_per_group : GROUP BY কী দ্বারা সংজ্ঞায়িত প্রতিটি পার্টিশনের জন্য ব্যবহারকারী প্রতি অবদানের পরিমাণ সীমিত করা হয়। ব্যবহারকারী প্রতি মানগুলি একত্রিত করার পরে, প্রতিটি গ্রুপের মানের উপর উচ্চ এবং নিম্ন সীমা প্রয়োগ করা হয়।
lower_bound : একটি সাংখ্যিক লিটারেল যা অ্যাগ্রিগেশনে অন্তর্ভুক্ত করার জন্য সর্বনিম্ন মানকে বোঝায়।
upper_bound : একটি সাংখ্যিক লিটারেল যা অ্যাগ্রিগেশনে অন্তর্ভুক্ত করার জন্য বৃহত্তম মানকে প্রতিনিধিত্ব করে।

ADH.ANON_PERCENTILE_CONT প্যারামিটারসমূহ:

percentile : যে পার্সেন্টাইলটি গণনা করতে হবে, [0, 1] পরিসরের মধ্যে একটি আক্ষরিক মান।
contribution_bounds_per_row : ব্যবহারকারী প্রতি অবদান প্রতি-সারি (প্রতি-রেকর্ড) ভিত্তিতে সীমাবদ্ধ করা হয়। উল্লেখ্য যে, পার্সেন্টাইলের জন্য সুস্পষ্ট সীমাবদ্ধ সীমা প্রয়োজন এবং তাই এটি শুধুমাত্র একটি সম্পূরক ফাংশন হিসাবে সমর্থিত।
lower_bound : একটি সাংখ্যিক লিটারেল যা অ্যাগ্রিগেশনে অন্তর্ভুক্ত করার জন্য সর্বনিম্ন মানকে বোঝায়।
upper_bound : একটি সাংখ্যিক লিটারেল যা অ্যাগ্রিগেশনে অন্তর্ভুক্ত করার জন্য বৃহত্তম মানকে প্রতিনিধিত্ব করে।

ADH.ANON_COUNT_DISTINCT প্যারামিটারসমূহ:

max_contributions_per_group অবদান : GROUP BY কী দ্বারা সংজ্ঞায়িত প্রতিটি পার্টিশনের জন্য ব্যবহারকারী প্রতি অবদানের পরিমাণ সীমিত করা হয়। প্রতি ব্যবহারকারীর মান একত্রিত করার পর, এই ঊর্ধ্বসীমাটি প্রতি গ্রুপে ব্যবহারকারীর সর্বোচ্চ অবদানকে সীমাবদ্ধ করে।
upper_bound : একটি সাংখ্যিক লিটারেল যা অ্যাগ্রিগেশনে অন্তর্ভুক্ত করার জন্য বৃহত্তম মানকে প্রতিনিধিত্ব করে।

সর্বনিম্ন এবং সর্বোচ্চ গণনা করুন

নয়েজ অ্যাগ্রিগেশনে MIN এবং MAX ফাংশনগুলো সরাসরি সমর্থিত নয়, কিন্তু এই ফলাফলগুলো গণনা করার জন্য প্রায়শই বিকল্প পদ্ধতি রয়েছে।

যদি আপনার কাছে গ্রুপিং কী হিসাবে ব্যবহারযোগ্য মানগুলির কোনো MIN বা MAX থাকে, যেমন ইভেন্টের তারিখ, তাহলে আপনি প্রথমে সেই মানটি GROUP BY করতে পারেন এবং তারপরে MIN / MAX গণনা করতে পারেন। এটি সেই সর্বনিম্ন বা সর্বোচ্চ মানটি ফেরত দেয় যা অ্যাগ্রিগেশন থ্রেশহোল্ডিং পাস করে।

উদাহরণ:

WITH campaign_date_ranges AS (
  SELECT campaign_id, MIN(event_date) AS min_date, MAX(event_date) AS max_date
  FROM (
    # Aggregation thresholding will be applied here
    SELECT DISTINCT
      campaign_id,
      DATE(query_id.time_usec, @time_zone) AS event_date
    FROM adh.google_ads_impressions
  )
)
SELECT campaign_id, num_impressions, min_date, max_date
FROM (
  # Noise and aggregation thresholding will be applied here
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
)
JOIN campaign_date_ranges USING(campaign_id)

বিকল্পভাবে, যদি আপনার কাছে জানা সীমা সহ সূক্ষ্ম মানের MIN বা MAX থাকে, তাহলে একটি আনুমানিক ফলাফলের জন্য আপনি সুস্পষ্ট সীমা সহ PERCENTILE_CONT ব্যবহার করতে পারেন।

উদাহরণ:

SELECT
  campaign_id,
  COUNT(*) AS num_impressions,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 0,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS min_timestamp,
  ADH.ANON_PERCENTILE_CONT(
    query_id.time_usec, 1,
    contribution_bounds_per_row => (@min_timestamp, @max_timestamp))
    AS max_timestamp
FROM adh.google_ads_impressions

পূর্ণসংখ্যার ফলাফল সম্পর্কে

যদিও অ্যাডস ডেটা হাব এই অ্যাগ্রিগেট ফাংশনগুলোর জন্য স্বয়ংক্রিয়ভাবে নয়েজ যোগ করে, ফাংশন সিগনেচারগুলো পরিবর্তিত হয় না। যেহেতু COUNT বা SUM of INT64 এর মতো ফাংশনগুলো INT64 রিটার্ন করে, তাই নয়েজযুক্ত ফলাফলের যেকোনো দশমিক অংশ রাউন্ড করা হয়। ফলাফল এবং নয়েজের আকারের তুলনায় এটি সাধারণত নগণ্য।

আপনার ফলাফলে যদি দশমিকের সূক্ষ্মতা প্রয়োজন হয়, তাহলে INT64 রিটার্ন করে এমন ফাংশন লেখা এড়িয়ে চলুন – উদাহরণস্বরূপ, SUM ফাংশনের ইনপুটকে FLOAT64 এ কাস্ট করে ব্যবহার করুন।

নেতিবাচক ফলাফল সম্পর্কে

নীতিগতভাবে, খুব ছোট মানের নয়েজের কারণেও ঋণাত্মক সংখ্যা আসতে পারে, এমনকি যখন কোয়েরিটির জন্য এটি অর্থগতভাবে অসম্ভব হওয়া উচিত। প্রত্যাশিত আচরণ বজায় রাখার জন্য, COUNT এবং COUNTIF এর সমস্ত ফর্ম স্বয়ংক্রিয়ভাবে শূন্যতে ক্ল্যাম্প করা হয়, তাই এগুলি কখনও ঋণাত্মক ফলাফল দেয় না। আপনি যদি SUM মতো অন্য কোনো ফাংশনের ক্ষেত্রেও একই আচরণ চান, তাহলে আপনি GREATEST(0, SUM(...)) ব্যবহার করে ম্যানুয়ালি ফলাফল ক্ল্যাম্প করতে পারেন।

এই পরিবর্তন সাধারণত নগণ্য, কিন্তু এটি সামগ্রিক ফলাফলে একটি সামান্য ধনাত্মক পক্ষপাত সৃষ্টি করে।

জনসাধারণের গোষ্ঠী

GROUP BY ক্লজের মাধ্যমে, একটি কোয়েরির পরিচয় গোপন রাখা ফলাফলগুলোকে বিভিন্ন গ্রুপে একত্রিত করা হয়। গ্রুপে পর্যাপ্ত সংখ্যক ব্যবহারকারী আছেন কিনা তা নিশ্চিত করতে অ্যাগ্রিগেশন থ্রেশহোল্ডিং প্রয়োগ করা হয়, যাতে স্বতন্ত্র ব্যবহারকারীর ডেটা সুরক্ষিত থাকে। কোন গ্রুপগুলোকে উন্মুক্ত করা যাবে তা নির্ধারণ করার প্রক্রিয়াকে "পার্টিশন সিলেকশন" বলা হয়।

অনেক ক্ষেত্রে গ্রুপগুলো সর্বজনবিদিত হতে পারে। উদাহরণস্বরূপ, ব্রাউজার সংস্করণ, সপ্তাহের দিন বা ভৌগোলিক অঞ্চল অনুসারে গ্রুপিং ব্যবহারকারীর তথ্যের উপর নির্ভর করে না, যদি গ্রুপিং কী-ভ্যালুগুলো আগে থেকেই জানা থাকে। এই ক্ষেত্রে, পার্টিশন নির্বাচন বাদ দেওয়া যেতে পারে, কারণ আউটপুটে কোনো গ্রুপের উপস্থিতি বা অনুপস্থিতি ব্যবহারকারীদের সম্পর্কে নতুন কোনো তথ্য প্রদান করে না।

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

পাবলিক গ্রুপে অন্তর্ভুক্ত হওয়ার জন্য, কোয়েরিটি এমনভাবে গঠন করতে হবে যাতে সমস্ত গ্রুপিং কী আগে থেকেই জানা থাকে। গ্রুপিং কলামগুলোকে অবশ্যই নিম্নলিখিত শর্তগুলো পূরণ করতে হবে:

এগুলো একটি পাবলিক টেবিল থেকে আসে (এমন একটি টেবিল বা SELECT ক্লজ যেখানে Ads Data Hub ব্যবহারকারীর কোনো ডেটা নেই)।
তারা অনন্য মান নিশ্চিত করতে SELECT DISTINCT প্রয়োগ করেছে।
প্রতিটি স্বতন্ত্র কলামের উপর OUTER JOIN প্রয়োগ করে সেগুলোকে কোয়েরিতে যুক্ত করা হয়।

পাবলিক গ্রুপ কোয়েরির উদাহরণ:

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT age_group_id FROM adh.age_group)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

SELECT age_group_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT * FROM UNNEST([1, 2, 3]) AS age_group_id)
ON demographics.age_group = age_group_id
GROUP BY age_group_id

প্রথম উদাহরণে, সুরক্ষিত adh.google_ads_impressions table adh.age_group টেবিলের সাথে যুক্ত করা হয়েছে, যেটিতে age_group_id কলামে ব্যবহারকারীর ডেটা নেই। একই পাবলিক টেবিলের age_group_id কলামটি GROUP BY ক্লজে ব্যবহৃত হয়েছে।

একইভাবে, দ্বিতীয় উদাহরণে সুরক্ষিত adh.google_ads_impressions টেবিলটিকে পাবলিক টেবিলের সাথে যুক্ত করা হয়েছে, যা UNNEST([1, 2, 3]) হিসেবে স্পষ্টভাবে প্রদান করা হয়েছে। লক্ষ্য করুন যে উভয় উদাহরণেই, গ্রুপিং কী age_group_id পাবলিক টেবিল থেকে এসেছে।

একাধিক গ্রুপিং আইটেমও প্রদান করা যেতে পারে, উদাহরণস্বরূপ:

SELECT campaign_id, COUNT(*) FROM adh.google_ads_impressions
RIGHT OUTER JOIN (SELECT DISTINCT campaign_id, customer_id FROM adh.google_ads_campaign)
USING (campaign_id, customer_id)
GROUP BY campaign_id, customer_id

SELECT p.campaign_id, p.browser, COUNT(*) FROM adh.google_ads_impressions AS i
RIGHT OUTER JOIN (
 SELECT DISTINCT * FROM UNNEST([1, 2]) AS campaign_id
 CROSS JOIN UNNEST(['Chrome', 'Other']) AS browser
) AS p
 ON i.campaign_id = p.campaign_id AND i.browser = p.browser
GROUP BY campaign_id, browser;

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

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

সমর্থিত কোয়েরি প্যাটার্ন

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

এই বিভাগে নয়েজ ইনজেকশন ব্যবহার করে কোয়েরি চালানোর সময় সমর্থিত কোয়েরি প্যাটার্নগুলো বর্ণনা করা হয়েছে।

ব্যবহারকারী-স্তরের সমষ্টি

সীমাবদ্ধতাহীন ইউজার-লেভেল অ্যাগ্রিগেটগুলো ডিফারেন্স চেক মোডের মতোই সমর্থিত। শুধুমাত্র সেইসব অ্যাগ্রিগেশনে নয়েজ যুক্ত করা হয়, যেগুলো একাধিক ইউজারের ডেটা একত্রিত করে। যে অ্যাগ্রিগেশনগুলো স্পষ্টভাবে user_id দ্বারা গ্রুপ করে, অথবা যে অ্যানালিটিক ফাংশনগুলো user_id দ্বারা পার্টিশন করে, সেগুলোতে কোনো নয়েজ যুক্ত হয় না এবং যেকোনো ফাংশনই ব্যবহার করা যায়। যে ইউজার-লেভেল অ্যাগ্রিগেশনগুলো স্পষ্টভাবে user_id দ্বারা গ্রুপ করে না—উদাহরণস্বরূপ, GROUP BY impression_id সেগুলোকে ক্রস-ইউজার অ্যাগ্রিগেশন হিসেবে গণ্য করা হয়, তাই সেগুলোতে নয়েজ যুক্ত হয়।

শুধু external_cookie দিয়ে গ্রুপিং করাই যথেষ্ট নয়। যদিও *_match টেবিলগুলোকে customer-owned টেবিলের সাথে যুক্ত করতে external_cookie ব্যবহার করা যায়, যেকোনো একক-ব্যবহারকারী অ্যাগ্রিগেশনের ক্ষেত্রে শুধুমাত্র external_cookie কলাম দিয়ে নয়, বরং user_id কলাম দিয়েও সুস্পষ্টভাবে গ্রুপিং করা উচিত।

সমষ্টিগত ফাংশনের উদাহরণ:

WITH user_paths AS (
  # Grouping by user_id, no noise needed, all functions allowed
  SELECT user_id, STRING_AGG(campaign_id, ">" ORDER BY query_id.time_usec) AS path
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to num_users
SELECT path, COUNT(*) AS num_users
FROM user_paths
GROUP BY 1;

বিশ্লেষণাত্মক ফাংশনের উদাহরণ:

WITH events AS (
  # Partitioning by user_id, no noise needed, all functions allowed
  SELECT
    campaign_id,
    ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY query_id.time_usec) AS index
  FROM adh.google_ads_impressions
)
# Noise applied here to first_impressions
SELECT campaign_id, COUNT(*) AS first_impressions
FROM events
WHERE index = 1
GROUP BY 1;

সমান্তরাল সমষ্টি

প্রতিটি ক্রস-ইউজার অ্যাগ্রিগেশন স্বাধীনভাবে নয়েজ গ্রহণ করে। আপনি একটিমাত্র স্টেটমেন্টে এই ধরনের একাধিক অ্যাগ্রিগেশন চালাতে পারেন এবং JOIN বা UNION ব্যবহার করে ফলাফলগুলোকে একটি টেবিলে একত্রিত করতে পারেন।

উদাহরণ:

WITH result_1 AS (
  # Noise applied here to num_impressions
  SELECT campaign_id, COUNT(*) AS num_impressions
  FROM adh.google_ads_impressions
  GROUP BY 1
), result_2 AS (
  # Noise applied here to num_clicks
  SELECT campaign_id, COUNT(*) AS num_clicks
  FROM adh.google_ads_creative_conversions
  GROUP BY 1
)
SELECT * FROM result_1 JOIN result_2 USING(campaign_id)

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

সমষ্টিগত ডেটার সাথে অসমষ্টিগত ডেটা যুক্ত করা হয়েছে

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

উদাহরণ:

WITH campaign_totals AS (
  # Noise applied here to campaign_imps
  SELECT campaign_id, COUNT(*) AS campaign_imps
  FROM adh.google_ads_impressions
  GROUP BY 1
)
# Noise applied here to imps
SELECT campaign_id, demographics, campaign_imps, COUNT(*) AS imps
FROM adh.google_ads_impressions JOIN campaign_totals USING(campaign_id)
GROUP BY 1,2,3

নয়েজ মোড AVG(campaign_imps) এর মতো সমষ্টিগত ফলাফল পুনরায় একত্রিত করতে নিরুৎসাহিত করে ।

অসমর্থিত কোয়েরি প্যাটার্ন

এই বিভাগে এমন কোয়েরি প্যাটার্নগুলো বর্ণনা করা হয়েছে, যেগুলো নয়েজ ইনজেকশন ব্যবহার করে কোয়েরি চালানোর সময় সমর্থিত নয়।

আজকের অন্তর্ভুক্ত প্রশ্নাবলী

নয়েজ মোড কোয়েরি বর্তমান দিনের ডেটা কোয়েরি করা সমর্থন করে না। (ডিফারেন্স চেক মোডে এটি নিরুৎসাহিত করা হয়।) যে কোয়েরিগুলো নয়েজ ইনজেকশন ব্যবহার করে, সেগুলোর জন্য বর্তমান তারিখ নির্বাচনযোগ্য নয়।

পুনরাবৃত্ত ফলাফল

নয়েজ মোডে, অ্যাডস ডেটা হাব একই অ্যাগ্রিগেশন কতবার পুনরাবৃত্তি করা যাবে তা সীমিত করে দেয়। আপনি যদি এই সীমায় পৌঁছে যান, তাহলে আপনার নয়েজ মোড কোয়েরিগুলো ডেটাসেটের ঘন ঘন ব্যবহৃত তারিখগুলোতে অ্যাক্সেস হারাবে। এটি কীভাবে ঘটতে পারে তার কিছু উদাহরণ নিচে দেওয়া হলো।

একই কোয়েরি যখন একই প্যারামিটার বা অত্যন্ত সাদৃশ্যপূর্ণ প্যারামিটার (যেমন ওভারল্যাপিং ডেট রেঞ্জ) ব্যবহার করে একাধিকবার চালানো হয়, তখন কোয়েরির পুনরাবৃত্তি ঘটে। আপনার BigQuery প্রোজেক্টে আগে থেকেই এক্সপোর্ট করা ডেটা ব্যবহার করে আপনি এটি এড়াতে পারেন।

মনে রাখবেন যে, যদি দুটি জব একই তারিখের পরিসরে কোয়েরি করে, তবে একই ব্যবহারকারীদের উপর একই গণনা সম্পাদন করার সময় পুনরাবৃত্তি ঘটতে পারে। উদাহরণস্বরূপ, নিম্নলিখিত কোয়েরিটি, যা একই তারিখের পরিসরে চালানো হয়, পুনরাবৃত্তি তৈরি করে কারণ এটি তারিখ অনুসারে পার্টিশন করে:

SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1

এক্ষেত্রে, আপনার বিচ্ছিন্ন তারিখের অংশগুলোর উপর কোয়েরিটি চালানো উচিত।

পুনরাবৃত্তির আরেকটি উদাহরণ দেখা যায় যখন ডেটা কিছুটা তারিখ-নিরপেক্ষ হয়। নিম্নলিখিত কোয়েরিটি ওভারল্যাপিং তারিখে চালানো হলে পুনরাবৃত্তি তৈরি করে, যেখানে উভয় জবই একটি ক্যাম্পেইনের সম্পূর্ণ জীবনকাল জুড়ে থাকে:

SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1

এক্ষেত্রে, আপনার এই কোয়েরিটি কেবল একবারই চালানো উচিত, কারণ ফলাফলে কোনো পরিবর্তন হয় না।

একটি কোয়েরির মধ্যে একই অ্যাগ্রিগেশন একাধিকবার পুনরাবৃত্তি হলে অ্যাগ্রিগেশন রিপিটেশন ঘটে:

SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table

এক্ষেত্রে, আপনার একটি পুনরাবৃত্তি বাদ দেওয়া উচিত।

মনে রাখবেন যে, অ্যাগ্রিগেশনগুলো সিনট্যাক্টিকভাবে ভিন্ন হলেও যদি একই মান গণনা করে, তবে তা পুনরাবৃত্তি হিসাবে গণ্য হবে। অন্য কথায়, যদি key এর কোনো একটি নির্দিষ্ট মানের জন্য সকল ব্যবহারকারীর ক্ষেত্রে condition1 এবং condition2 এর মান একই হয়, তাহলে নিম্নলিখিত কোয়েরিটিতে একটি পুনরাবৃত্তি থাকবে:

SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key

যদি কিছু ব্যবহারকারী গোষ্ঠীর জন্য শর্তগুলো খুব একই রকম হয়, তাহলে আপনি কোয়েরিটি এমনভাবে পুনর্লিখন করার কথা বিবেচনা করতে পারেন যাতে কেবল একটি COUNT থাকে।

যখন একটি Ads Data Hub টেবিলকে একটি BigQuery টেবিলের সাথে এমনভাবে যুক্ত করা হয় যে Ads Data Hub টেবিলের প্রতিটি সারি BigQuery টেবিলের একাধিক সারির সাথে মিলে যায়, তখন সারি পুনরাবৃত্তি (Row duplication) ঘটে। উদাহরণস্বরূপ, bq_table এ একই ক্যাম্পেইন আইডি সহ একাধিক সারি থাকলে নিম্নলিখিত কোয়েরিটি একটি পুনরাবৃত্তি তৈরি করে:

SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id

এক্ষেত্রে, আপনার কোয়েরিটি এমনভাবে পুনর্গঠন করা উচিত যাতে bq_table প্রতিটি জয়েন কী ভ্যালুর (এই ক্ষেত্রে campaign_id ) জন্য কেবল একটি করে সারি থাকে।

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

SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1

সাধারণত, একই ফলাফলের গণনা ১০ বার বা তার কমের মধ্যে সীমাবদ্ধ রাখা উচিত। আপনি যখন এই সীমার কাছাকাছি পৌঁছাবেন, তখন অ্যাডস ডেটা হাব সতর্কবার্তা দেখাবে। যদি একই ফলাফল সীমার পরেও গণনা করা হতে থাকে, তাহলে আপনার জবগুলো ত্রুটির কারণে ব্লক হতে শুরু করবে।

কোয়েরির অন্যান্য সেরা অনুশীলনগুলো সম্পর্কে জানুন ।

লুকব্যাক উইন্ডোজ সম্পর্কে

কিছু কোয়েরি প্যাটার্ন একটি দীর্ঘ সময়কালের জন্য রিপোর্ট তৈরি করে এবং নতুন ফলাফল অন্তর্ভুক্ত করার জন্য পর্যায়ক্রমে পুনরায় তৈরি হয়। এই কোয়েরিগুলোকে নয়েজ মোডে কাজ করার জন্য সমন্বয়ের প্রয়োজন হতে পারে, কারণ যদি এগুলো পূর্ববর্তী ফলাফল পুনরায় গণনা করে, তবে সেগুলো ব্লক হয়ে যাবে। এর পরিবর্তে, প্রতিটি জবের কেবল নতুন ফলাফল তৈরি করা উচিত, এবং তারপর একটি সম্পূর্ণ রিপোর্টের জন্য নতুন ফলাফলগুলোকে পূর্ববর্তী জবের ফলাফলের সাথে একত্রিত করা যেতে পারে।

উদাহরণস্বরূপ, যদি আপনি তারিখ অনুযায়ী মেট্রিক্সের একটি রিপোর্ট তৈরি করেন, যা প্রতিদিন রিফ্রেশ করা হয়:

SELECT
  campaign_id,
  DATE(TIMESTAMP_MICROS(query_id.time_usec), @time_zone) AS event_date,
  COUNT(*) AS impressions
FROM adh.google_ads_impressions
GROUP BY 1,2

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

ফলাফল রিফ্রেশ করার জন্য আপনি পূর্ববর্তী তারিখের পরিসরগুলো পুনরায় গণনা করতে পারেন (উদাহরণস্বরূপ, দেরিতে আসা ডেটার হিসাব রাখার জন্য), কিন্তু পূর্বে বর্ণিত পদ্ধতি অনুযায়ী, কোনো একটি ফলাফল বারবার গণনা করা থেকে বিরত থাকা উচিত।

সরাসরি পুনঃসংযোজন

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

WITH layer_1 AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
)
# Reaggregation of partial_result with no user-level data, will be rejected
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

নয়েজ থেকে সেরা ফলাফল পেতে, সমস্ত ক্রস-ইউজার অপারেশন একটিমাত্র অ্যাগ্রিগেশনের মধ্যে গণনা করুন। উদাহরণস্বরূপ, অন্তর্বর্তী গণনার SUM পরিবর্তে ইভেন্টগুলোর SUM নিন।

যদি একাধিক স্তর জুড়ে অ্যাগ্রিগেশন অপরিহার্য হয়, তবে আপনি সরাসরি প্রথম স্তর থেকে ফলাফল এক্সপোর্ট করে সতর্কবার্তাটি সমাধান করতে পারেন। স্ক্রিপ্টের ফলাফল পরিবর্তন না করে একটিমাত্র জবের মধ্যে এটি করার জন্য, OPTIONS(privacy_checked_export=true) সিনট্যাক্স ব্যবহার করে একটি টেম্প টেবিল (অথবা আপনার BigQuery প্রজেক্টে এক্সপোর্ট করা একটি টেবিল) তৈরি করুন। উদাহরণস্বরূপ:

CREATE TEMP TABLE layer_1 OPTIONS(privacy_checked_export=true) AS (
  # Noise applied here to partial_result
  SELECT campaign_id, demographics, location, COUNT(*) AS partial_result
  FROM adh.google_ads_impressions
  GROUP BY 1,2,3
  HAVING partial_result > 5
);
# Reaggregation of privacy checked data, no noise needed
SELECT campaign_id, SUM(partial_result) AS final_result
FROM layer_1
GROUP BY 1

টেম্প টেবিল সম্পর্কে আরও জানুন ।

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

যোগদান না করা ব্যবহারকারী আইডি

নয়েজ মোডে থাকা কোয়েরিগুলো আলাদা আলাদা ব্যবহারকারীর ডেটা একটিমাত্র সারিতে একত্রিত করতে পারবে না, তবে নয়েজ ব্যবহার করে অ্যাগ্রিগেশন করার ক্ষেত্রে এটি প্রযোজ্য নয়। ফলস্বরূপ, অ্যাগ্রিগেট না করা Ads Data Hub ডেটার জয়েন করার ক্ষেত্রে user_id কলামের উপর ভিত্তি করে স্পষ্টভাবে জয়েন করতে হবে।

এই কোয়েরিটি user_id কলামের উপর স্পষ্টভাবে জয়েন করে না, যার ফলে একটি ভ্যালিডেশন ওয়ার্নিং দেখা দেয়:

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_creative_conversions USING(impression_id)

এই ধরনের জয়েনগুলো প্রত্যাশিতভাবে কাজ নাও করতে পারে, কারণ শুধুমাত্র একই user_id ভ্যালুযুক্ত সারিগুলোই মিলবে। USING ক্লজটি পরিবর্তন করে সেখানে স্পষ্টভাবে user_id অন্তর্ভুক্ত করার মাধ্যমে এটি ঠিক করা যায় – উদাহরণস্বরূপ, USING(impression_id, user_id) ।

উল্লেখ্য যে, এই সীমাবদ্ধতা শুধুমাত্র Ads Data Hub টেবিলগুলোর মধ্যেকার জয়েনের ক্ষেত্রে প্রযোজ্য (ডাইমেনশন টেবিল ব্যতীত)। এটি গ্রাহকের মালিকানাধীন টেবিলের ক্ষেত্রে প্রযোজ্য নয়। উদাহরণস্বরূপ, নিম্নলিখিতটি অনুমোদিত:

SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)

Ads Data Hub-BigQuery রাইট জয়েন

গ্রাহকের নিজস্ব ডেটার সাথে আউটার জয়েন করার ফলে এমন সারি তৈরি হতে পারে যেখানে ব্যবহারকারী শনাক্তকারী অনুপস্থিত থাকে, যা নয়েজকে সঠিকভাবে কাজ করতে বাধা দেয়।

এই দুটি কোয়েরির ফলেই ভ্যালিডেশন ওয়ার্নিং দেখা দেয়, কারণ এগুলোতে Ads Data Hub-এর দিকে ইউজার আইডেন্টিফায়ার অনুপস্থিত থাকায় অমিল সারি থেকে যায়:

SELECT …
FROM adh.google_ads_impressions
RIGHT JOIN bigquery_project.dataset.table USING(column)

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions USING(column)

উল্লেখ্য যে, টেবিলগুলোর ক্রম উল্টে দিলেও যেকোনো জয়েনই কাজ করবে। এছাড়া, যে RDID টেবিলগুলো সরাসরি device_id_md5 উপর ভিত্তি করে জয়েন করে, তাদের ক্ষেত্রেও একটি ব্যতিক্রম রয়েছে। উদাহরণস্বরূপ, নিম্নলিখিত কোয়েরিটি কোনো সতর্কতা ছাড়াই কাজ করবে:

SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)

ফিল্টার করা সারির সারাংশ

নয়েজ মোডে ফিল্টার করা সারির সারাংশ স্পেকটি সমর্থিত নয়। কম ফিল্টারিং রেট এবং পার্থক্য যাচাই থেকে ফিল্টারিংয়ের অনুপস্থিতির কারণে নয়েজের ক্ষেত্রে এই বৈশিষ্ট্যটি প্রায়শই অপ্রয়োজনীয়।

যদি কোনো নয়েজ ফলাফলে উল্লেখযোগ্য ডেটা ফিল্টারিং লক্ষ্য করেন, তাহলে একত্রিত ডেটার পরিমাণ বাড়িয়ে দিন। মোট পরিমাণের একটি আনুমানিক হিসাব তুলনা করার জন্য আপনি সম্পূর্ণ ডেটাসেটের উপর একটি সমান্তরাল একত্রীকরণ সম্পাদন করতে পারেন, উদাহরণস্বরূপ:

SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1

উল্লেখ্য যে, মোট গণনা স্বাধীনভাবে ত্রুটিপূর্ণ হতে পারে এবং মোট মানগুলো যোগফল নাও মিলতে পারে, কিন্তু ত্রুটিপূর্ণ সারিগুলোর যোগফল নেওয়ার চেয়ে মোট গণনা প্রায়শই বেশি নির্ভুল হয়।

ক্রস-মোডে তৈরি টেবিল

Ads Data Hub-এ এক্সপোর্ট না করা টেবিলগুলো শুধুমাত্র সেই প্রাইভেসি মোডেই ব্যবহার করা যাবে, যে মোডে সেগুলো তৈরি করা হয়েছিল। আপনি নরমাল অ্যাগ্রিগেশন মোডে একটি টেবিল তৈরি করে নয়েজ মোডে ব্যবহার করতে পারবেন না, বা এর বিপরীতটিও করতে পারবেন না (যদি না সেই টেবিলটি প্রথমে BigQuery-তে এক্সপোর্ট করা হয়)।