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

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

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

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

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

শেখার জন্য কোনও নতুন বাক্য গঠন নেই: পার্থক্য পরীক্ষা করার পরিবর্তে শব্দ ব্যবহার করার জন্য আপনাকে কোনও নতুন কোয়েরি বাক্য গঠন শেখার বা গোপনীয়তার ধারণা সম্পর্কে পারদর্শী হওয়ার প্রয়োজন নেই।

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

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

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

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

স্ট্যাটিক চেক: কোনও প্রভাব নেই।

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

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

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

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

বিজ্ঞাপন ডেটা হাব প্রকাশের ঝুঁকি কমাতে শব্দের ব্যবহার করে - অর্থাৎ, কোনও ব্যক্তি কোনও ব্যবহারকারীর তথ্য জানতে পারে এমন ঝুঁকি। এটি গোপনীয়তার সাথে উপযোগিতার ভারসাম্য বজায় রাখে।

বিজ্ঞাপন ডেটা হাবে নয়েজ ইনজেকশন কোয়েরির ফলাফলগুলিকে নিম্নরূপ রূপান্তরিত করে:

  • এটি সামগ্রিক ফলাফলে বহিরাগত ব্যবহারকারীদের অবদানকে ক্ল্যাম্প করে। এটি প্রতিটি সমষ্টিতে প্রতিটি ব্যবহারকারীর অবদানের যোগফল নির্ধারণ করে এবং তারপর প্রতিটি অবদানকে সর্বনিম্ন এবং সর্বোচ্চ ক্ল্যাম্পিং সীমা দিয়ে সীমাবদ্ধ করে।
  • এটি প্রতি ব্যবহারকারীর অবদানের ক্ল্যাম্পড সংখ্যা একত্রিত করে।
  • এটি প্রতিটি সমষ্টিগত ফলাফলে শব্দ যোগ করে—প্রতিটি সারিতে প্রতিটি সমষ্টিগত ফাংশন কলের ফলাফল। এই র্যান্ডম শব্দের স্কেল ক্ল্যাম্পড সীমানার সমানুপাতিক।
  • এটি প্রতিটি সারির জন্য একটি শব্দযুক্ত ব্যবহারকারীর সংখ্যা গণনা করে এবং খুব কম ব্যবহারকারীর সারি বাদ দেয়। এটি ডিফারেন্স চেক মোডে k-অ্যানোনিমিটির মতো, কিন্তু শব্দের কারণে, একই ডেটাসেটে চলমান কাজগুলি বিভিন্ন সারি বাদ দিতে পারে। এছাড়াও, শব্দ মোড কম সারি বাদ দেয় কারণ একত্রিতকরণের প্রয়োজনীয়তা কম (প্রায় 20 বনাম ঠিক 50)।

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

অ্যাগ্রিগেশন ক্ল্যাম্পিং সম্পর্কে

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

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

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

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

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

বিজ্ঞাপন ডেটা হাব স্পষ্ট ক্ল্যাম্পিংয়ের জন্য সম্পূরক 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

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

  1. একটি রিপোর্ট খুলুন।
  2. গোপনীয়তা শব্দ সেটিংসে ক্লিক করে "আওয়াজ ব্যবহার করুন" অবস্থানে টগল করুন।
  3. কোয়েরিটি চালান ।
  4. অতিরিক্ত শব্দের প্রভাব পর্যালোচনা করুন ।
  5. ঐচ্ছিক: শব্দের প্রভাব কমাতে কোয়েরিটি মানিয়ে নিন ।

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

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

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

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

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

কোয়েরিগুলি অ্যাডাপ্ট করুন

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

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

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

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

নিম্নলিখিত সমষ্টিগত ফাংশনগুলি শব্দের সাথে সমর্থিত:

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

DISTINCT কীওয়ার্ডটি শুধুমাত্র COUNT ফাংশনের সাথে সমর্থিত, এবং শুধুমাত্র যখন এটি কোনও বিজ্ঞাপন ডেটা হাব টেবিল থেকে user_id কলামের সরাসরি রেফারেন্সের সাথে ব্যবহার করা হয় অথবা এমন একটি এক্সপ্রেশন যা user_id বা NULL প্রদান করে, যেমন COUNT(DISTINCT IF(..., user_id, NULL)) ।

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

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

নিয়মিত অ্যাগ্রিগেটরদের সমর্থন করার পাশাপাশি, Ads Data Hub সম্পূরক ADH.ANON অ্যাগ্রিগেট ফাংশন চালু করে যা স্পষ্ট ক্ল্যাম্পিং সমর্থন করে। এই অ্যাগ্রিগেটরগুলি BigQuery ডিফারেন্সিয়াললি প্রাইভেট অ্যাগ্রিগেট ফাংশনের সাথে সিনট্যাক্স ভাগ করে, তবে, তাদের 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_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 : সংখ্যাসূচক আক্ষরিক যা একটি সমষ্টিতে অন্তর্ভুক্ত করার জন্য বৃহত্তম মান উপস্থাপন করে।

MIN এবং MAX গণনা করুন

শব্দ সমষ্টিতে 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

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

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

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

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

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

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

পাবলিক গ্রুপ

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

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

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

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

  • এগুলি একটি পাবলিক টেবিল থেকে আসে (একটি টেবিল বা SELECT ধারা যেখানে কোনও বিজ্ঞাপন ডেটা হাব ব্যবহারকারীর ডেটা নেই)।
  • তারা অনন্য মান প্রয়োগের জন্য 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 কলামে ব্যবহারকারীর ডেটা নেই। GROUP BY ক্লজে একই পাবলিক টেবিল age_group_id কলামটি প্রদর্শিত হবে।

একইভাবে, দ্বিতীয় উদাহরণে সুরক্ষিত 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;

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

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

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

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

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

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

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

external_cookie অনুসারে গ্রুপ করা যথেষ্ট নয়। যদিও 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)

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

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

যেহেতু Ads Data Hub শুধুমাত্র 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

এই ক্ষেত্রে, আপনার পুনরাবৃত্তিগুলির একটি অপসারণ করা উচিত।

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

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

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

যখন একটি বিজ্ঞাপন ডেটা হাব টেবিল একটি BigQuery টেবিলের সাথে এমনভাবে যুক্ত করা হয় যাতে বিজ্ঞাপন ডেটা হাব টেবিলের প্রতিটি সারি BigQuery টেবিলের একাধিক সারি মিলে যায়, তখন সারিটির ডুপ্লিকেশন ঘটে। উদাহরণস্বরূপ, 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 , এই ক্ষেত্রে)।

মনে রাখবেন যে, Ads Data Hub টেবিল থেকে একটি অ্যারে আননেস্ট করলেও একই প্রভাব পড়তে পারে যদি বেশিরভাগ ব্যবহারকারীর মান একই রকম থাকে: 

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

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

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

সরাসরি পুনঃএকত্রীকরণ

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

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

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

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

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

নয়েজ মোডে থাকা কোয়েরিগুলি পৃথক ব্যবহারকারীর ডেটা একক সারিতে একত্রিত করা উচিত নয়, কেবল শব্দের সাথে একত্রিতকরণের সময়। ফলস্বরূপ, একত্রিত না করা বিজ্ঞাপন ডেটা হাব ডেটার যোগগুলি স্পষ্টভাবে 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) ।

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

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

Ads Data Hub-BigQuery ডানদিকে যোগদান করে

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

এই দুটি কোয়েরির ফলে যাচাইকরণের সতর্কতা দেখা দেয় কারণ এগুলি বিজ্ঞাপন ডেটা হাবের পাশে অনুপস্থিত ব্যবহারকারী শনাক্তকারী সহ অতুলনীয় সারিগুলির জন্য অনুমতি দেয়: 

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)

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

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

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

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

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

,

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

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

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

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

শেখার জন্য কোনও নতুন বাক্য গঠন নেই: পার্থক্য পরীক্ষা করার পরিবর্তে শব্দ ব্যবহার করার জন্য আপনাকে কোনও নতুন কোয়েরি বাক্য গঠন শেখার বা গোপনীয়তার ধারণা সম্পর্কে পারদর্শী হওয়ার প্রয়োজন নেই।

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

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

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

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

স্ট্যাটিক চেক: কোনও প্রভাব নেই।

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

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

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

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

বিজ্ঞাপন ডেটা হাব প্রকাশের ঝুঁকি কমাতে শব্দের ব্যবহার করে - অর্থাৎ, কোনও ব্যক্তি কোনও ব্যবহারকারীর তথ্য জানতে পারে এমন ঝুঁকি। এটি গোপনীয়তার সাথে উপযোগিতার ভারসাম্য বজায় রাখে।

বিজ্ঞাপন ডেটা হাবে নয়েজ ইনজেকশন কোয়েরির ফলাফলগুলিকে নিম্নরূপ রূপান্তরিত করে:

  • এটি সামগ্রিক ফলাফলে বহিরাগত ব্যবহারকারীদের অবদানকে ক্ল্যাম্প করে। এটি প্রতিটি সমষ্টিতে প্রতিটি ব্যবহারকারীর অবদানের যোগফল নির্ধারণ করে এবং তারপর প্রতিটি অবদানকে সর্বনিম্ন এবং সর্বোচ্চ ক্ল্যাম্পিং সীমা দিয়ে সীমাবদ্ধ করে।
  • এটি প্রতি ব্যবহারকারীর অবদানের ক্ল্যাম্পড সংখ্যা একত্রিত করে।
  • এটি প্রতিটি সমষ্টিগত ফলাফলে শব্দ যোগ করে—প্রতিটি সারিতে প্রতিটি সমষ্টিগত ফাংশন কলের ফলাফল। এই র্যান্ডম শব্দের স্কেল ক্ল্যাম্পড সীমানার সমানুপাতিক।
  • এটি প্রতিটি সারির জন্য একটি শব্দযুক্ত ব্যবহারকারীর সংখ্যা গণনা করে এবং খুব কম ব্যবহারকারীর সারি বাদ দেয়। এটি ডিফারেন্স চেক মোডে k-অ্যানোনিমিটির মতো, কিন্তু শব্দের কারণে, একই ডেটাসেটে চলমান কাজগুলি বিভিন্ন সারি বাদ দিতে পারে। এছাড়াও, শব্দ মোড কম সারি বাদ দেয় কারণ একত্রিতকরণের প্রয়োজনীয়তা কম (প্রায় 20 বনাম ঠিক 50)।

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

অ্যাগ্রিগেশন ক্ল্যাম্পিং সম্পর্কে

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

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

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

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

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

বিজ্ঞাপন ডেটা হাব স্পষ্ট ক্ল্যাম্পিংয়ের জন্য সম্পূরক 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

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

  1. একটি রিপোর্ট খুলুন।
  2. গোপনীয়তা শব্দ সেটিংসে ক্লিক করে "আওয়াজ ব্যবহার করুন" অবস্থানে টগল করুন।
  3. কোয়েরিটি চালান ।
  4. অতিরিক্ত শব্দের প্রভাব পর্যালোচনা করুন ।
  5. ঐচ্ছিক: শব্দের প্রভাব কমাতে কোয়েরিটি মানিয়ে নিন ।

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

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

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

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

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

কোয়েরিগুলি অ্যাডাপ্ট করুন

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

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

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

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

নিম্নলিখিত সমষ্টিগত ফাংশনগুলি শব্দের সাথে সমর্থিত:

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

DISTINCT কীওয়ার্ডটি শুধুমাত্র COUNT ফাংশনের সাথে সমর্থিত, এবং শুধুমাত্র যখন এটি কোনও বিজ্ঞাপন ডেটা হাব টেবিল থেকে user_id কলামের সরাসরি রেফারেন্সের সাথে ব্যবহার করা হয় অথবা এমন একটি এক্সপ্রেশন যা user_id বা NULL প্রদান করে, যেমন COUNT(DISTINCT IF(..., user_id, NULL)) ।

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

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

নিয়মিত অ্যাগ্রিগেটরদের সমর্থন করার পাশাপাশি, Ads Data Hub সম্পূরক ADH.ANON অ্যাগ্রিগেট ফাংশন চালু করে যা স্পষ্ট ক্ল্যাম্পিং সমর্থন করে। এই অ্যাগ্রিগেটরগুলি BigQuery ডিফারেন্সিয়াললি প্রাইভেট অ্যাগ্রিগেট ফাংশনের সাথে সিনট্যাক্স ভাগ করে, তবে, তাদের 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_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 : সংখ্যাসূচক আক্ষরিক যা একটি সমষ্টিতে অন্তর্ভুক্ত করার জন্য বৃহত্তম মান উপস্থাপন করে।

MIN এবং MAX গণনা করুন

শব্দ সমষ্টিতে 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)

Alternatively, if you have a MIN or MAX of granular values with known bounds, you can use PERCENTILE_CONT with explicit bounds for an approximate result.

উদাহরণ:

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

About integer results

Although Ads Data Hub will automatically inject noise for these aggregate functions, the function signatures don't change. Because functions like COUNT or SUM of INT64 return INT64 , any decimal part of the noised result is rounded. This is usually negligible relative to the size of the result and noise.

If you need the granularity of the decimal in your result, then avoid writing functions that return INT64 –for example, by using SUM with its input cast to FLOAT64 .

About negative results

In principle, noise with very small values can result in negative numbers, even when this should be semantically impossible for the query. To maintain expected behavior, all forms of COUNT and COUNTIF are automatically clamped at zero, so they never give negative results. If you want this same behavior with another function, such as SUM , then you can clamp results manually using GREATEST(0, SUM(...)) .

This change is usually negligible, but it does introduce a small positive bias to overall results.

পাবলিক গ্রুপ

With a GROUP BY clause, the anonymized results of a query are aggregated over groups. Aggregation thresholding is applied to make sure that a sufficient number of users are present in the group so that individual user data is protected. The process of determining which groups can be released is called "partition selection".

In many cases groups may be public knowledge. For example, grouping by browser version, day of the week, or a geographical region does not depend on user data if the grouping key values are known in advance. In this instance, the partition selection can be omitted, since the presence or absence of a group in the output does not provide any new information about the users.

Ads Data Hub identifies queries eligible for public groups and does not apply aggregation thresholding to these queries. This means that no output rows are filtered out. Note that results computed from a small number of users can be heavily impacted by noise.

To be eligible for public groups, the query must be structured to ensure that all grouping keys are known in advance. The grouping columns must satisfy the following conditions:

  • They come from a public table (a table or SELECT clause with no Ads Data Hub user data).
  • They have SELECT DISTINCT applied to enforce unique values.
  • They are joined into the query with an OUTER JOIN on all of the individual columns.

Examples of public groups queries:

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

In the first example, the protected adh.google_ads_impressions table is joined with the adh.age_group table that does not contain user data on the age_group_id column. The same public table age_group_id column appears in the GROUP BY clause.

Similarly, in the second example the protected adh.google_ads_impressions table is joined with the public table, which is provided explicitly as UNNEST([1, 2, 3]) . Notice that in both examples, the grouping key age_group_id comes from the public table.

Multiple grouping items can be provided as well, for example:

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;

The absence of filtering in the public groups queries can be beneficial for recurrently run queries, since the output is always returned for the same fixed grouping keys' values. This can be particularly useful, for example, for building periodical dashboards.

A caveat: if a public table provides a very large number of grouping key values, then you may get many rows with little or no data, and these rows will all be reported as having high noise impact. In this case, you should consider explicitly providing a smaller list of keys with just the values you are interested in.

Supported query patterns

Important : Most of Ads Data Hub's standard best practices still apply to queries that use noise injection. In particular, we recommend that you review the guidance on repeatedly querying the same data .

This section describes query patterns that are supported when running queries using noise injection.

User-level aggregates

Unrestricted user-level aggregates are supported in the same way that they are in difference check mode. Noise is only injected in aggregations that combine data across multiple users. Aggregations that explicitly group by user_id , or analytic functions that partition by user_id , don't receive any noise and any function is allowed. User-level aggregations that don't explicitly group by user_id –for example, GROUP BY impression_id , are treated as cross-user aggregations, so noise is added.

Grouping by external_cookie is not enough. While external_cookie can be used to join *_match tables with customer-owned tables, any single-user aggregations should explicitly group by user_id column, not just the external_cookie column.

Aggregate function example:

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;

Analytic function example:

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;

Parallel aggregates

Each cross-user aggregation receives noise independently. You can run multiple such aggregations in a single statement, combining results into one table using a JOIN or 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)

Note that this would be supported but should be avoided in difference check mode. This practice is not a problem with noise, as each parallel aggregate is noised and filtered independently.

Aggregated data joined with unaggregated data

Since Ads Data Hub only supports analytic windows that partition by user_id , it is a common workaround to aggregate these results separately and self-join them before aggregating again. These queries are supported in noise mode, and often perform better than they would with in difference check mode due to privacy requirements being resolved earlier.

উদাহরণ: 

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

Noise mode discourages reaggregating aggregate results, such as AVG(campaign_imps) .

Unsupported query patterns

This section describes query patterns that are not supported when running queries using noise injection.

Today-inclusive queries

Noise mode queries don't support querying the current day's data. (This is discouraged in difference check mode.) The current date is not selectable for queries that use noise injection.

Repeated results

In noise mode, Ads Data Hub limits how often you can repeat the same aggregation. If you reach these limits, your noise mode queries will lose access to frequently queried dates in the dataset. The following are examples of how this can occur.

Query repetition happens when the same query is run multiple times with the same parameters or highly similar parameters, such as overlapping date ranges. You can avoid this by using data that is already exported to your BigQuery project.

Note that if two jobs are querying overlapping date ranges, they might produce repetitions if performing the same computation on the same users. For example, the following query, executed on overlapping date ranges, creates repetitions because it partitions by date: 

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

In this case, you should run the query on disjoint date segments.

Another example of a repetition happens when data is somewhat date independent. The following query produces repetitions when executed on overlapping dates, where both jobs cover the entire lifetime of a campaign: 

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

In this case, you should run this query only once since the result doesn't change.

Aggregation repetition happens when the same aggregation is repeated multiple times within a query: 

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

In this case, you should remove one of the repetitions.

Note that even if the aggregations are syntactically different but compute the same value, it would count as a repetition. In other words, if the values of condition1 and condition2 are the same for all users with some value of key , the following query would have a repetition: 

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

If you have conditions that are very similar for some groups of users, you might consider rewriting the query to have only one COUNT .

Row duplication happens when an Ads Data Hub table is joined with a BigQuery table in a way that each row from the Ads Data Hub table matches multiple rows in the BigQuery table. For example, the following query produces a repetition if there are multiple rows with the same campaign ID in bq_table : 

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

In this case, you should restructure the query so that bq_table would have only one row per join key value ( campaign_id , in this case).

Note that unnesting an array from the Ads Data Hub table could produce the same effect if most users have the same arrays of values: 

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

Learn about other query best practices .

About Lookback Windows

Some query patterns generate reports over a large timeframe, periodically regenerating to include new results. These queries may need adjustments to work in noise mode because if they recompute previous results, they will be blocked. Instead, each job should only generate new results, then new results can be combined with results from previous jobs for a full report.

For example, if you are creating a report of metrics by date, refreshed daily: 

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

You shouldn't run this with a large date range as this will recompute results of previous days. Instead, you should run each job only the latest day, which has new data, then combine with results from previous jobs.

If you do need to refresh a previous result (for example to account for late arriving data), then you should avoid recomputing any single result more than 1 or 2 times. Otherwise, you may get errors due to repeated query attempts.

Direct reaggregation

Noise is applied to the first layer of cross-user aggregation in the query. Queries with multiple layers of aggregation will combine noisy results, so final aggregates may have much higher noise. These queries receive a warning on validation: 

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

To get the best results from noise, compute all cross-user operations within a single aggregation. For example, take a SUM of events rather than a SUM of intermediate counts.

If multi-layer aggregation is unavoidable, you can resolve the warning by exporting results directly from the first layer instead. To do this within a single job without changing script results, create a temp table (or a table exported to your BigQuery project) with the OPTIONS(privacy_checked_export=true) syntax. For example: 

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

Learn more about temp tables .

If the first layer of aggregation is too granular for privacy checks, consider rewriting the query with user-level aggregates . If this is not possible, then this query is not supported in noise mode.

Unjoined user IDs

Queries in noise mode must not combine data from separate users into a single row, except when performing an aggregation with noise. As a result, joins of unaggregated Ads Data Hub data should explicitly join on the user_id column.

This query does not explicitly join on the user_id column, which results in a validation warning: 

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

Joins like this may not behave as expected because only rows with the same user_id value will match. This can be fixed by adjusting the USING clause to explicitly include user_id – for example, USING(impression_id, user_id) .

Note that this limitation applies only to joins between Ads Data Hub tables (with the exception of dimension tables). It does not apply to customer-owned tables. For example, the following is allowed: 

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

Ads Data Hub-BigQuery right joins

Outer joins with customer-owned data can lead to rows with missing user identifiers, which prevents noise from working well.

Both of these queries result in validation warnings because they allow for unmatched rows with missing user identifiers on the Ads Data Hub side: 

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)

Note that either join would work if the order of the tables was reversed. There is also an exception for RDID tables that join directly on device_id_md5 . For example, the following query will work with no warnings: 

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

Filtered Row Summary

The filtered row summary spec is not supported in noise mode. This feature is most often unnecessary with noise due to lower filtering rates and the lack of filtering from difference checks.

If you observe significant data filtering in a noise result, then increase the aggregated data. You may perform a parallel aggregation over the full dataset to compare an estimate of the total, for example: 

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

Note that the total count is independently noised and total values may not add up, but the total count is often more accurate than taking the sum of noised rows.

Cross-mode created tables

Unexported tables in Ads Data Hub can only be used with the same privacy mode where they were created. You can't create a table in normal aggregation mode and use it in noise mode, or the other way around (unless that table is exported to BigQuery first).