नॉइज़ इंजेक्शन एक ऐसी तकनीक है जिसका इस्तेमाल डेटाबेस से क्वेरी करते समय, उपयोगकर्ता की निजता को सुरक्षित रखने के लिए किया जाता है. यह क्वेरी के एग्रीगेट करने वाले SELECT क्लॉज़ में रैंडम नॉइज़ जोड़कर काम करता है. इस नॉइज़ से उपयोगकर्ता की निजता को सुरक्षित रखने में मदद मिलती है. साथ ही, सटीक नतीजे मिलते हैं. इससे अंतर की जांच करने की ज़रूरत नहीं पड़ती और आउटपुट के लिए ज़रूरी एग्रीगेशन थ्रेशोल्ड कम हो जाता है. ज़्यादातर मौजूदा क्वेरी को नॉइज़ मोड में चलाया जा सकता है. हालांकि, कुछ सीमाएं लागू होती हैं.
नॉइज़ इंजेक्शन का इस्तेमाल करने के फ़ायदों के बारे में जानें
डिफ़रेंस चेक लागू नहीं होते: नॉइज़ इंजेक्शन के साथ क्वेरी चलाने पर, Ads Data Hub, पिछली क्वेरी के नतीजों से मिलते-जुलते होने की वजह से लाइनों को फ़िल्टर नहीं करता. इसका मतलब है कि उपयोगकर्ता की निजता को सुरक्षित रखते हुए भी, आपको डेटा का पूरा व्यू मिल सकता है.
समस्या हल करना आसान हो जाता है: एग्रीगेशन की ज़रूरी शर्तों की वजह से ही लाइनों को हटाया जाता है. इससे क्वेरी से जुड़ी समस्याओं को हल करना और उन्हें अडजस्ट करना आसान हो जाता है.
कोई नया सिंटैक्स सीखने की ज़रूरत नहीं है: अंतर की जांच के बजाय नॉइज़ का इस्तेमाल करने के लिए, आपको किसी नए क्वेरी सिंटैक्स को सीखने या निजता के कॉन्सेप्ट के बारे में जानने की ज़रूरत नहीं है.
नतीजों की सटीकता की जानकारी दी जाती है: अगर कोई जॉब पूरी हो जाती है, तो इससे उस डेटा का कुल प्रतिशत दिखता है जिस पर नॉइज़ का असर पड़ सकता है.
जानें कि शोर से निजता से जुड़ी ज़रूरी शर्तों पर क्या असर पड़ता है
अंतर की जांच: नॉइज़ इंजेक्शन, Ads Data Hub में मौजूद अंतर की जांच पर निर्भर नहीं करता. नॉइज़ इंजेक्शन का इस्तेमाल करने पर, अंतर की जांच करने की सुविधा बंद हो जाती है.
एग्रीगेशन से जुड़ी ज़रूरी शर्तें: नॉइज़ इंजेक्शन से मिले इंप्रेशन डेटा में, करीब 20 या इससे ज़्यादा यूनीक उपयोगकर्ताओं का डेटा शामिल होना चाहिए. साथ ही, क्लिक या कन्वर्ज़न डेटा में करीब 10 या इससे ज़्यादा यूनीक उपयोगकर्ताओं का डेटा शामिल होना चाहिए.
स्टैटिक जांच: कोई असर नहीं पड़ता.
बजट और क्वेरी की सीमाएं: नॉइज़ का इस्तेमाल करके की गई क्वेरी, डेटा ऐक्सेस करने के लिए इस्तेमाल किए गए बजट को शेयर करती हैं. इस बजट का इस्तेमाल, अंतर की जांच करने के लिए किया जाता है. अंतर की जांच करने की सुविधा की तरह ही, अगर एक ही क्वेरी को एक ही डेटासेट पर कई बार चलाया जाता है, तो हो सकता है कि आपको डेटासेट में अक्सर क्वेरी की जाने वाली तारीखों का ऐक्सेस न मिले. ऐसा तब हो सकता है, जब स्लाइडिंग विंडो क्वेरी चलाई जाती हैं या एक ही अनुरोध को कई बार किया जाता है.
नॉइज़ मोड में, एक ही एग्रीगेट किए गए नतीजों को क्वेरी के अंदर या अलग-अलग क्वेरी में फिर से कंप्यूट करने पर, ज़्यादा पाबंदियां लगाई जाती हैं. डेटा ऐक्सेस बजट की तरह ही, डेटासेट में अक्सर क्वेरी की जाने वाली तारीखों का ऐक्सेस भी खत्म हो सकता है. हालांकि, एक ही एग्रीगेट नतीजे को फिर से कंप्यूट करने की वजह से होने वाली सीमाएं, सिर्फ़ नॉइज़ मोड में क्वेरी को सीमित करेंगी. ये सीमाएं, अंतर की जांच करने वाले मोड में क्वेरी को सीमित नहीं करेंगी. ज़्यादा जानकारी के लिए, बार-बार दिखने वाले नतीजे लेख पढ़ें.
निजता से जुड़ी जांच के बारे में ज़्यादा जानें.
समझें कि नॉइज़ इंजेक्शन से नतीजों पर क्या असर पड़ता है
Ads Data Hub, डेटा में नॉइज़ जोड़ता है, ताकि किसी व्यक्ति की पहचान ज़ाहिर होने के जोखिम को कम किया जा सके. यह जोखिम तब होता है, जब कोई व्यक्ति किसी उपयोगकर्ता के बारे में जानकारी हासिल कर सकता है. यह निजता और काम की जानकारी के बीच संतुलन बनाए रखता है.
Ads Data Hub में नॉइज़ इंजेक्शन की सुविधा, क्वेरी के नतीजों को इस तरह बदल देती है:
- यह एग्रीगेट किए गए नतीजों में, आउटलायर उपयोगकर्ताओं के योगदान को कम करता है. यह हर एग्रीगेशन में हर उपयोगकर्ता के योगदान को जोड़ता है. इसके बाद, हर योगदान को कम से कम और ज़्यादा से ज़्यादा क्लैंपिंग बाउंड्री के साथ कैप करता है.
- यह हर उपयोगकर्ता के लिए तय की गई सीमा के हिसाब से योगदान को इकट्ठा करता है.
- यह हर एग्रीगेट नतीजे में नॉइज़ जोड़ता है. हर एग्रीगेट नतीजे का मतलब, हर लाइन में एग्रीगेशन फ़ंक्शन कॉल का नतीजा होता है. इस रैंडम नॉइज़ का स्केल, क्लैंप किए गए बाउंड के हिसाब से होता है.
- यह हर लाइन के लिए, उपयोगकर्ताओं की अनुमानित संख्या का हिसाब लगाता है. साथ ही, उन लाइनों को हटा देता है जिनमें उपयोगकर्ताओं की संख्या बहुत कम होती है. यह अंतर की जांच करने वाले मोड में k-anonymity की तरह ही होता है. हालांकि, नॉइज़ की वजह से, एक ही डेटासेट पर चलने वाले जॉब अलग-अलग लाइनें हटा सकते हैं. साथ ही, नॉइज़ मोड में कम पंक्तियां हटाई जाती हैं, क्योंकि एग्रीगेशन की ज़रूरत कम होती है. जैसे, करीब 20 पंक्तियां बनाम 50 पंक्तियां.
आखिरी नतीजे के तौर पर एक ऐसा डेटासेट मिलता है जिसमें हर लाइन में, कुल नतीजों की गड़बड़ी वाली जानकारी होती है. साथ ही, छोटे ग्रुप हटा दिए जाते हैं. इससे खोज नतीजों पर किसी व्यक्ति के असर को छिपाया जाता है.
एग्रीगेशन क्लैंपिंग के बारे में जानकारी
Ads Data Hub में नॉइज़ इंजेक्शन की सुविधा, आउटलायर के योगदान को सीमित करने के लिए, इंप्लिसिट या एक्सप्लिसिट एग्रीगेशन क्लैंपिंग का इस्तेमाल करती है. अपने इस्तेमाल के उदाहरण के हिसाब से, यह चुना जा सकता है कि किस तरह की क्लैंपिंग का इस्तेमाल करना है.
इंप्लिसिट क्लैंपिंग
इम्प्लिसिट क्लैंपिंग का इस्तेमाल करने के लिए, आपको किसी खास एसक्यूएल सिंटैक्स की ज़रूरत नहीं होती. यह डिफ़ॉल्ट रूप से लागू होता है. इंप्लिसिट बाउंड्री, डेटा से ही मिलती हैं. इन्हें हर एग्रीगेशन के लिए तय किया जाता है. अगर कुछ एग्रीगेशन में वैल्यू की रेंज, दूसरों की तुलना में ज़्यादा है, तो इंप्लिसिट बाउंडिंग, अलग-अलग एग्रीगेशन के लिए अलग-अलग बाउंड्री का अनुमान लगा सकती है. इससे आम तौर पर गड़बड़ियां कम होती हैं. ध्यान दें कि COUNT(DISTINCT
user_id), 1 की ऊपरी सीमा के साथ एक्सप्लिसिट क्लैंपिंग का इस्तेमाल अपने-आप करता है.
एक्सप्लिसिट क्लैंपिंग
एक्सप्लिसिट क्लैंपिंग, हर उपयोगकर्ता के कुल योगदान को तय की गई सीमा में सीमित कर देती है. एक्सप्लिसिट बाउंड को सभी एग्रीगेशन पर एक जैसा लागू किया जाता है. साथ ही, ये लिटरल वैल्यू होनी चाहिए. अगर आम तौर पर सीमाएं पता हैं, तो एक्सप्लिसिट क्लैंपिंग से बेहतर नतीजे मिल सकते हैं. उदाहरण के लिए, 0 से 100 के बीच की उम्र की सीमा, सार्वजनिक जानकारी को दिखाती है. ऐसा इसलिए, क्योंकि ज़्यादातर लोगों की उम्र आम तौर पर इसी सीमा में होती है.
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
नॉइज़ इंजेक्शन का इस्तेमाल करके क्वेरी चलाना
- कोई रिपोर्ट खोलें.
- निजता से जुड़े ग़ैर-ज़रूरी डेटा के लिए सेटिंग टॉगल को ग़ैर-ज़रूरी डेटा का इस्तेमाल करें पर सेट करें.
- क्वेरी चलाएं.
- जोड़े गए नॉइज़ के असर की समीक्षा करें.
- ज़रूरी नहीं: क्वेरी में बदलाव करें, ताकि नॉइज़ का असर कम हो.
शोर के असर की समीक्षा करना
जब कोई जॉब पूरी हो जाती है, तो Ads Data Hub, निजता की खास जानकारी में नतीजे की विश्वसनीयता दिखाता है. भरोसेमंद होने का स्कोर, आउटपुट में मौजूद उन सेल के प्रतिशत के आधार पर तय किया जाता है जिन पर नॉइज़ का ज़्यादा असर पड़ सकता है. नतीजे की टेबल में मौजूद किसी वैल्यू पर तब असर पड़ता है, जब जोड़े गए नॉइज़ का स्केल, सेल में मौजूद नतीजे के 5% से ज़्यादा हो.
जिन आउटपुट डेटा सेट पर असर पड़ा है उनके लिए, निजता की खास जानकारी में सबसे ज़्यादा नॉइज़ वाले दस कॉलम की सूची दी जाती है. इस सूची में, कॉलम को सबसे ज़्यादा से सबसे कम असर के हिसाब से क्रम में लगाया जाता है. साथ ही, यह भी बताया जाता है कि नॉइज़ में उनका कितना योगदान है. यहां नॉइज़ इंपैक्ट लेबल के बारे में जानकारी दी गई है.
| असर पड़े नतीजों का प्रतिशत | इंडिकेटर का रंग | असर |
|---|---|---|
| <5% | हरा | कम असर |
| 5% से 15% | पीला | सामान्य असर |
| 15% से 25% | Orange | काफ़ी असरदार |
| >25% | लाल | बहुत ज़्यादा असर |
हाल ही में की गई रिपोर्टिंग की निजता से जुड़ी खास जानकारी को होम पेज पर जाकर भी देखा जा सकता है. किसी नौकरी के लिए निजता की जानकारी देखने के लिए, हाल की गतिविधि में जाकर, नौकरी के कार्ड में मौजूद निजता से जुड़ी सलाह वाले आइकॉन privacy_tip पर कर्सर घुमाएं.
क्वेरी को अडैप्ट करना
जब कुछ ही उपयोगकर्ता, नतीजे में योगदान देते हैं, तो एग्रीगेशन पर नॉइज़ का असर पड़ने की संभावना ज़्यादा होती है. ऐसा तब हो सकता है, जब एग्रीगेशन की गिनती, उपयोगकर्ताओं के छोटे सेट से की जाती है या जब कुछ उपयोगकर्ताओं से नतीजों पर कोई असर नहीं पड़ता. ऐसा, उदाहरण के लिए, COUNTIF फ़ंक्शन के साथ हो सकता है. शोर की रिपोर्ट के आधार पर, क्वेरी में बदलाव किया जा सकता है, ताकि क्वेरी के नतीजों पर पड़ने वाले असर को कम किया जा सके.
यहां सामान्य दिशा-निर्देश दिए गए हैं:
- तारीख की सीमा बढ़ाएं.
- डेटा की जानकारी के लेवल को कम करने के लिए, क्वेरी को फिर से लिखें. जैसे, कम पैरामीटर के हिसाब से ग्रुप करके या
COUNTIFकोCOUNTसे बदलकर. - बेकार कॉलम हटाएं.
- जब सही सीमाएं चुनी जा सकती हैं, तब एक्सप्लिसिट क्लैंपिंग का इस्तेमाल करें.
एग्रीगेट फ़ंक्शन के साथ काम करने वाली सुविधाएं
नॉइज़ के साथ इन एग्रीगेट फ़ंक्शन का इस्तेमाल किया जा सकता है:
SUM(...)COUNT(*)COUNT(...)COUNTIF(...)COUNT(DISTINCT user_id)APPROX_COUNT_DISTINCT(user_id)AVG(...)
DISTINCT कीवर्ड का इस्तेमाल सिर्फ़ COUNT फ़ंक्शन के साथ किया जा सकता है. साथ ही, इसका इस्तेमाल सिर्फ़ तब किया जा सकता है, जब इसे Ads Data Hub टेबल के 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 है जिनका इस्तेमाल ग्रुपिंग कुंजियों के तौर पर किया जा सकता है, जैसे कि इवेंट की तारीख, तो पहले उस वैल्यू के हिसाब से 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)
इसके अलावा, अगर आपके पास सीमाएं तय करने के लिए, कम से कम या ज़्यादा से ज़्यादा वैल्यू मौजूद हैं, तो अनुमानित नतीजे पाने के लिए, तय की गई सीमाओं के साथ 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 दिखाते हैं. उदाहरण के लिए, SUM को FLOAT64 में बदलकर उसके साथ SUM का इस्तेमाल न करें.
नेगेटिव नतीजों के बारे में जानकारी
सिद्धांत के तौर पर, बहुत कम वैल्यू वाले नॉइज़ की वजह से नेगेटिव नंबर मिल सकते हैं. भले ही, क्वेरी के लिए ऐसा होना सेमैंटिक तौर पर मुमकिन न हो. अनुमान के मुताबिक काम करने के लिए, COUNT और COUNTIF के सभी फ़ॉर्म को अपने-आप शून्य पर सेट कर दिया जाता है, ताकि वे कभी भी नेगेटिव नतीजे न दें. अगर आपको किसी दूसरे फ़ंक्शन, जैसे कि SUM के साथ भी ऐसा ही व्यवहार चाहिए, तो GREATEST(0,
SUM(...)) का इस्तेमाल करके, नतीजों को मैन्युअल तरीके से सीमित किया जा सकता है.
आम तौर पर, यह बदलाव न के बराबर होता है. हालांकि, इससे कुल नतीजों पर थोड़ा सकारात्मक असर पड़ता है.
सार्वजनिक ग्रुप
GROUP BY क्लॉज़ की मदद से, पहचान छिपाकर की गई क्वेरी के नतीजों को ग्रुप के हिसाब से इकट्ठा किया जाता है. एग्रीगेशन थ्रेशोल्ड का इस्तेमाल यह पक्का करने के लिए किया जाता है कि ग्रुप में उपयोगकर्ताओं की संख्या इतनी हो कि किसी उपयोगकर्ता के डेटा को सुरक्षित रखा जा सके. यह तय करने की प्रोसेस कि कौनसे ग्रुप रिलीज़ किए जा सकते हैं, "पार्टिशन चुनना" कहलाती है.
कई मामलों में, ग्रुप के बारे में सार्वजनिक तौर पर जानकारी उपलब्ध हो सकती है. उदाहरण के लिए, ब्राउज़र के वर्शन, हफ़्ते के दिन या भौगोलिक क्षेत्र के हिसाब से ग्रुपिंग करने के लिए, उपयोगकर्ता के डेटा की ज़रूरत नहीं होती. ऐसा तब होता है, जब ग्रुपिंग की मुख्य वैल्यू पहले से पता हों. इस उदाहरण में, पार्टीशन चुनने की सुविधा को हटाया जा सकता है. ऐसा इसलिए, क्योंकि आउटपुट में किसी ग्रुप के मौजूद होने या न होने से, उपयोगकर्ताओं के बारे में कोई नई जानकारी नहीं मिलती.
Ads Data Hub, सार्वजनिक ग्रुप के लिए ज़रूरी क्वेरी की पहचान करता है. साथ ही, इन क्वेरी पर एग्रीगेशन थ्रेशोल्ड लागू नहीं करता है. इसका मतलब है कि आउटपुट की किसी भी लाइन को फ़िल्टर नहीं किया गया है. ध्यान दें कि कम उपयोगकर्ताओं से मिले डेटा के आधार पर तैयार किए गए नतीजों पर, नॉइज़ का काफ़ी असर पड़ सकता है.
सार्वजनिक ग्रुप के लिए ज़रूरी है कि क्वेरी इस तरह से स्ट्रक्चर की गई हो कि सभी ग्रुपिंग कुंजियों के बारे में पहले से पता हो. ग्रुपिंग कॉलम में ये शर्तें पूरी होनी चाहिए:
- ये सार्वजनिक टेबल से आते हैं. सार्वजनिक टेबल ऐसी टेबल या
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 कॉलम में उपयोगकर्ता का डेटा शामिल नहीं है. वही public टेबल 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;
सार्वजनिक ग्रुप की क्वेरी में फ़िल्टर न होने से, बार-बार चलाई जाने वाली क्वेरी के लिए फ़ायदेमंद हो सकता है. ऐसा इसलिए, क्योंकि आउटपुट हमेशा एक ही ग्रुपिंग कुंजियों की वैल्यू के लिए मिलता है. यह खास तौर पर, समय-समय पर अपडेट होने वाले डैशबोर्ड बनाने के लिए मददगार हो सकता है.
हालांकि, अगर किसी सार्वजनिक टेबल में ग्रुपिंग की वैल्यू की संख्या बहुत ज़्यादा है, तो आपको ऐसी कई लाइनें मिल सकती हैं जिनमें बहुत कम या कोई डेटा नहीं होता. इन सभी लाइनों को, नॉइज़ के असर वाली लाइनें माना जाएगा. ऐसे मामले में, आपको सिर्फ़ उन वैल्यू के साथ कुंजियों की छोटी सूची देनी चाहिए जिनमें आपकी दिलचस्पी है.
क्वेरी के ऐसे पैटर्न जिनका इस्तेमाल किया जा सकता है
अहम जानकारी: Ads Data Hub के ज़्यादातर स्टैंडर्ड सबसे सही तरीके, नॉइज़ इंजेक्शन का इस्तेमाल करने वाली क्वेरी पर अब भी लागू होते हैं. खास तौर पर, हमारा सुझाव है कि आप एक ही डेटा के लिए बार-बार क्वेरी करने से जुड़े दिशा-निर्देश देखें.
इस सेक्शन में, क्वेरी के उन पैटर्न के बारे में बताया गया है जिनका इस्तेमाल, नॉइज़ इंजेक्शन का इस्तेमाल करके क्वेरी चलाने के दौरान किया जा सकता है.
उपयोगकर्ता-लेवल पर एग्रीगेट किया गया डेटा
उपयोगकर्ता-लेवल के एग्रीगेट को बिना किसी पाबंदी के इस्तेमाल किया जा सकता है. ये उसी तरह काम करते हैं जैसे अंतर की जांच करने वाले मोड में काम करते हैं. नॉइज़ को सिर्फ़ उन एग्रीगेशन में शामिल किया जाता है जिनमें कई उपयोगकर्ताओं का डेटा शामिल होता है. user_id के हिसाब से ग्रुप किए गए एग्रीगेशन या user_id के हिसाब से बांटे गए विश्लेषण फ़ंक्शन में कोई नॉइज़ नहीं होती. साथ ही, किसी भी फ़ंक्शन का इस्तेमाल किया जा सकता है. उपयोगकर्ता-लेवल के ऐसे एग्रीगेशन जो साफ़ तौर पर user_id के हिसाब से ग्रुप नहीं किए जाते हैं उन्हें क्रॉस-यूज़र एग्रीगेशन माना जाता है. उदाहरण के लिए, GROUP BY impression_id. इसलिए, इनमें नॉइज़ जोड़ा जाता है.
external_cookie के हिसाब से ग्रुप बनाना काफ़ी नहीं है. external_cookie का इस्तेमाल, *_match टेबल को ग्राहक के मालिकाना हक वाली टेबल से जोड़ने के लिए किया जा सकता है. हालांकि, एक उपयोगकर्ता के डेटा को इकट्ठा करने के लिए, user_id कॉलम के हिसाब से ग्रुप बनाना ज़रूरी है. सिर्फ़ external_cookie कॉलम के हिसाब से ग्रुप नहीं बनाया जा सकता.
एग्रीगेट फ़ंक्शन का उदाहरण:
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).
क्वेरी के ऐसे पैटर्न जिनका इस्तेमाल नहीं किया जा सकता
इस सेक्शन में, क्वेरी के उन पैटर्न के बारे में बताया गया है जिनका इस्तेमाल, नॉइज़ इंजेक्शन का इस्तेमाल करके क्वेरी चलाने के दौरान नहीं किया जा सकता.
आज की तारीख को शामिल करके की गई क्वेरी
नॉइज़ मोड की क्वेरी में, आज के डेटा के बारे में क्वेरी नहीं की जा सकती. (अंतर की जांच करने वाले मोड में, ऐसा करने से बचने की सलाह दी जाती है.) नॉइज़ इंजेक्शन का इस्तेमाल करने वाली क्वेरी के लिए, मौजूदा तारीख को नहीं चुना जा सकता.
दोहराए गए नतीजे
नॉइज़ मोड में, Ads Data Hub यह तय करता है कि एक ही एग्रीगेशन को कितनी बार दोहराया जा सकता है. इन सीमाओं तक पहुंचने पर, नॉइज़ मोड की क्वेरी, डेटासेट में अक्सर क्वेरी की जाने वाली तारीखों का डेटा ऐक्सेस नहीं कर पाएंगी. यहां कुछ उदाहरण दिए गए हैं कि ऐसा कैसे हो सकता है.
क्वेरी को दोहराना तब होता है, जब एक ही क्वेरी को एक से ज़्यादा बार चलाया जाता है. ऐसा तब होता है, जब एक ही पैरामीटर या मिलते-जुलते पैरामीटर का इस्तेमाल किया जाता है. जैसे, तारीख की ऐसी सीमाएं जो एक-दूसरे से ओवरलैप करती हैं. 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 टेबल की कई लाइनों से मैच करती है. उदाहरण के लिए, अगर 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
टेंप टेबल के बारे में ज़्यादा जानें.
अगर निजता की जांच के लिए, एग्रीगेशन की पहली लेयर बहुत ज़्यादा बारीक है, तो उपयोगकर्ता-लेवल के एग्रीगेट का इस्तेमाल करके क्वेरी को फिर से लिखें. अगर ऐसा नहीं किया जा सकता, तो यह क्वेरी नॉइज़ मोड में काम नहीं करेगी.
ऐसे यूज़र आईडी जो शामिल नहीं किए गए हैं
नॉइज़ मोड में की गई क्वेरी में, अलग-अलग उपयोगकर्ताओं के डेटा को एक ही लाइन में नहीं जोड़ा जाना चाहिए. हालांकि, नॉइज़ के साथ एग्रीगेशन करते समय ऐसा किया जा सकता है. इसलिए, 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 क्लॉज़ में बदलाव करके, इस समस्या को ठीक किया जा सकता है. इसके लिए, USING को साफ़ तौर पर शामिल करें. उदाहरण के लिए, USING(impression_id, user_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)
ध्यान दें कि अगर टेबल का क्रम उलट दिया जाता है, तो दोनों में से कोई भी जॉइन काम करेगा. हालांकि, आरडीआईडी टेबल के लिए एक अपवाद भी है. ये टेबल सीधे 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 में एक्सपोर्ट किया गया है, तो ऐसा किया जा सकता है.