डेटाबेस से क्वेरी करते समय, उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, ग़ैर-ज़रूरी जानकारी जोड़ने की तकनीक का इस्तेमाल किया जाता है. यह किसी क्वेरी के एग्रीगेट करने वाले SELECT
क्लॉज़ में रैंडम नॉइज़ जोड़कर काम करता है. यह ग़ैर-ज़रूरी आवाज़, उपयोगकर्ता की निजता को सुरक्षित रखती है. साथ ही, इससे आपको सटीक नतीजे मिलते हैं. साथ ही, नतीजों के लिए एग्रीगेशन थ्रेशोल्ड की ज़रूरत भी कम हो जाती है. ज़्यादातर मौजूदा क्वेरी को ग़ैर-ज़रूरी आवाज़ों को कम करने वाले मोड में चलाया जा सकता है. हालांकि, इसके लिए कुछ सीमाएं हैं.
शोर इंजेक्शन का इस्तेमाल करने के फ़ायदों के बारे में जानें
अंतर की जांच तब लागू नहीं होती: ग़ैर-ज़रूरी डेटा जोड़कर क्वेरी चलाने पर, Ads Data Hub, पिछले नतीजों के सेट से मिलती-जुलती पंक्तियों को फ़िल्टर नहीं करता. इसका मतलब है कि उपयोगकर्ता की निजता को बनाए रखते हुए, अब भी आपको डेटा का पूरा व्यू मिल सकता है.
समस्या हल करना आसान हो गया है: एग्रीगेशन की ज़रूरतों की वजह से ही पंक्तियों को हटाया जाता है. इससे, क्वेरी को हल करना और उनमें बदलाव करना आसान हो जाता है.
कोई नया सिंटैक्स नहीं है: अंतर की जांच करने के बजाय, ग़ैर-ज़रूरी डेटा का इस्तेमाल करने के लिए, आपको कोई नया क्वेरी सिंटैक्स सीखने या निजता के कॉन्सेप्ट के बारे में जानने की ज़रूरत नहीं है.
नतीजे की सटीक जानकारी: नतीजा मिलने पर, गै़र-ज़रूरी डेटा के अनुमानित प्रतिशत के साथ डेटा का कुल प्रतिशत दिखता है.
जानें कि शोर की वजह से निजता से जुड़ी ज़रूरी शर्तों पर क्या असर पड़ता है
अंतर की जांच: नॉइज़ इंजेक्शन, Ads Data Hub में मौजूद अंतर की जांच पर निर्भर नहीं करता. नॉइज़ इंजेक्शन का इस्तेमाल करने पर, अंतर की जांच करने की सुविधा बंद हो जाती है.
एग्रीगेशन की ज़रूरी शर्तें: गड़बड़ी डालने की सुविधा से, इंप्रेशन का डेटा मिलता है. यह डेटा, करीब 20 या उससे ज़्यादा यूनीक उपयोगकर्ताओं से मिलता है. साथ ही, क्लिक या कन्वर्ज़न का डेटा, करीब 10 या उससे ज़्यादा यूनीक उपयोगकर्ताओं से मिलता है.
स्टैटिक जांच: कोई असर नहीं पड़ेगा.
बजट और क्वेरी की सीमाएं: ग़ैर-ज़रूरी डेटा का इस्तेमाल करके की गई क्वेरी, डेटा ऐक्सेस करने के लिए इस्तेमाल किए गए बजट को शेयर करती हैं. अंतर की जांच की तरह ही, अगर एक ही डेटासेट पर एक ही क्वेरी को कई बार चलाया जाता है, तो हो सकता है कि आपके पास डेटासेट में अक्सर क्वेरी की गई तारीखों का ऐक्सेस न रहे. ऐसा तब हो सकता है, जब स्लाइडिंग विंडो क्वेरी चलाई जाती हैं या एक ही अनुरोध कई बार किया जाता है.
गड़बड़ी वाले डेटा को हटाने वाले मोड की वजह से, एक ही तरह के एग्रीगेट नतीजों को फिर से कैलकुलेट करने पर, क्वेरी में या अलग-अलग क्वेरी के लिए ज़्यादा और सख्त सीमाएं लागू होती हैं. डेटा ऐक्सेस के बजट की तरह ही, डेटासेट में अक्सर क्वेरी की गई तारीखों का ऐक्सेस भी बंद हो सकता है. हालांकि, एक ही तरह के एग्रीगेट नतीजों को फिर से कैलकुलेट करने की वजह से होने वाली पाबंदियां, सिर्फ़ ग़ैर-ज़रूरी डेटा को हटाने वाले मोड में की गई क्वेरी पर लागू होंगी, न कि अंतर की जांच करने वाले मोड में की गई क्वेरी पर. ज़्यादा जानकारी के लिए, एक जैसे नतीजे देखें.
निजता जांच के बारे में ज़्यादा जानें.
जानें कि नॉइज़ इंजेक्शन से नतीजों पर क्या असर पड़ता है
Ads Data Hub, जानकारी ज़ाहिर होने के जोखिम को कम करने के लिए, ग़ैर-ज़रूरी जानकारी जोड़ता है. इस जोखिम का मतलब है कि कोई व्यक्ति किसी उपयोगकर्ता के बारे में जानकारी हासिल कर सकता है. यह निजता और उपयोगिता के बीच संतुलन बनाता है.
Ads Data Hub में नॉइज़ इंजेक्शन की सुविधा, क्वेरी के नतीजों को इस तरह बदल देती है:
- यह एग्रीगेट किए गए नतीजों में, ऐसे उपयोगकर्ताओं के योगदान को कम कर देता है जो सामान्य से काफ़ी अलग हैं. यह हर एग्रीगेशन में, हर उपयोगकर्ता के योगदान को जोड़ता है. इसके बाद, हर योगदान को कम से कम और ज़्यादा से ज़्यादा सीमा के साथ कैप करता है.
- यह हर उपयोगकर्ता के योगदान को इकट्ठा करता है.
- यह हर एग्रीगेट नतीजे में नॉइज़ जोड़ता है. यह हर लाइन में, हर एग्रीगेशन फ़ंक्शन कॉल का नतीजा होता है. इस रैंडम नॉइज़ का स्केल, क्लैंप किए गए सीमाओं के हिसाब से होता है.
- यह हर लाइन के लिए, ग़ैर-ज़रूरी उपयोगकर्ताओं की संख्या का हिसाब लगाता है. साथ ही, बहुत कम उपयोगकर्ताओं वाली लाइनों को हटा देता है. यह, अंतर की जांच मोड में k-anonymity जैसा ही है. हालांकि, ग़ैर-ज़रूरी डेटा की वजह से, एक ही डेटासेट पर चल रही जॉब अलग-अलग पंक्तियां हटा सकती हैं. साथ ही, ग़ैर-ज़रूरी डेटा हटाने की सुविधा से, कम पंक्तियां हटती हैं, क्योंकि एग्रीगेशन की ज़रूरत कम होती है (50 के मुकाबले करीब 20).
आखिर में, एक ऐसा डेटासेट मिलता है जिसमें हर लाइन में ग़ैर-ज़रूरी डेटा शामिल नहीं होता और छोटे ग्रुप हटा दिए जाते हैं. इससे, खोज के नतीजों पर किसी व्यक्ति के असर को छिपाया जाता है.
एग्रीगेशन क्लैंपिंग के बारे में जानकारी
Ads Data Hub में नॉइज़ इंजेक्शन, आउटलायर के योगदान को सीमित करने के लिए, एग्रीगेशन क्लैंपिंग का इस्तेमाल करता है. अपने इस्तेमाल के हिसाब से, क्लैंपिंग के किस टाइप का इस्तेमाल किया जा सकता है.
इंप्लिसिट क्लैंपिंग
इंप्लिसिट क्लैंपिंग में, सीमाएं अपने-आप तय होती हैं. इंप्लिसिट क्लैंपिंग का इस्तेमाल करने के लिए, आपको किसी खास एसक्यूएल सिंटैक्स की ज़रूरत नहीं होती. अगर किसी पंक्ति में वैल्यू की सीमा, दूसरी पंक्ति से ज़्यादा है, तो इन पंक्तियों के लिए, अपने-आप बॉउंडिंग की सुविधा अलग-अलग बॉउंड ढूंढती है. इससे आम तौर पर, हर नतीजे के लिए गड़बड़ी का मार्जिन कम होता है. दूसरी ओर, हर एग्रीगेशन के लिए क्लैंपिंग की सीमा और नॉइज़ लेवल अलग-अलग होते हैं. इस वजह से, इनकी तुलना करना मुश्किल हो सकता है.
जब किसी एग्रीगेशन को बहुत कम उपयोगकर्ताओं से डेटा मिलता है, तो इंप्लिसिट क्लैंपिंग काम नहीं कर सकती. उदाहरण के लिए, ऐसी स्थिति में COUNTIF()
कॉल. इन मामलों में NULL
नतीजे मिलते हैं. यह भी ध्यान दें कि COUNT(DISTINCT user_id)
, 0
और 1
के सीमाओं के साथ, एक्सप्लसिट क्लैंपिंग का इस्तेमाल अपने-आप करता है.
एक्सप्लिसिट क्लैंपिंग
एक्सप्लस क्लैंपिंग की मदद से, हर उपयोगकर्ता के योगदान को तय सीमा में रखा जाता है. साफ़ तौर पर तय किए गए सीमाएं, सभी पंक्तियों पर एक जैसी लागू होती हैं. साथ ही, ये लिटरल वैल्यू होनी चाहिए. भले ही, कुछ पंक्तियों में हर उपयोगकर्ता के योगदान की रेंज, दूसरी पंक्तियों की तुलना में ज़्यादा हो, लेकिन उन सभी पर एक ही सीमा लागू होती है. इससे अलग-अलग लाइनों के नतीजों की तुलना करने में आसानी होती है. हालांकि, कुछ लाइनों में, इंप्लिसिट क्लैंपिंग की तुलना में ज़्यादा गड़बड़ी होती है.
क्लैंपिंग के किसी दिए गए सीमा सेट के लिए, एक्सप्लिश क्लैंपिंग, इंप्लिश क्लैंपिंग के मुकाबले आधे नॉइज़ का इस्तेमाल करती है. इसलिए, अगर आपको लगता है कि आपके पास सीमाओं का अनुमान लगाने की क्षमता है, तो उन्हें साफ़ तौर पर सेट करके बेहतर नतीजे पाएं.
क्लैंपिंग का इस्तेमाल करने के लिए, हर एग्रीगेट फ़ंक्शन के लिए सीमाएं सेट करें. इसके लिए, निचली सीमा और ऊपरी सीमा दिखाने वाले पूर्णांक जोड़ें. उदाहरण के लिए:
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% से ज़्यादा हो.
जिन आउटपुट डेटा सेट पर असर पड़ा है उनके लिए, निजता की खास जानकारी में सबसे ज़्यादा नॉइज़ वाले 10 कॉलम की सूची दी गई है. इसमें, सबसे ज़्यादा से सबसे कम असर और नॉइज़ में उनके योगदान की जानकारी दी गई है. यहां गै़र-ज़रूरी डेटा की अनुमानित संख्या के बारे में बताया गया है.
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))
.
नीचे दिए गए फ़ंक्शन सीधे तौर पर काम नहीं करते. हालांकि, आंकड़ों के नतीजे पाने के लिए, इन्हें ग़ैर-ज़रूरी डेटा के साथ अन्य एग्रीगेट से बदला जा सकता है. ध्यान दें कि संख्या वाली वैल्यू सिर्फ़ उदाहरण के तौर पर दी गई हैं:
LOGICAL_OR(...)
. बदलाव का सुझाव:COUNT(DISTINCT IF(..., user_id, NULL)) > 0
LOGICAL_AND(...)
. बदलाव का सुझाव:COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0
पूर्णांक के नतीजों के बारे में जानकारी
हालांकि, Ads Data Hub इन एग्रीगेशन फ़ंक्शन के लिए अपने-आप नॉइज़ इंजेक्ट करेगा, लेकिन फ़ंक्शन के हस्ताक्षर नहीं बदलेंगे. INT64
के COUNT
या SUM
जैसे फ़ंक्शन, INT64
दिखाते हैं. इसलिए, गड़बड़ी वाले नतीजे के दशमलव वाले हिस्से को राउंड किया जाता है. आम तौर पर, नतीजे और ग़ैर-ज़रूरी डेटा के साइज़ के मुकाबले, यह नज़रअंदाज़ किया जा सकता है.
अगर आपको अपने नतीजे में दशमलव के बाद के अंकों की ज़्यादा जानकारी चाहिए, तो ऐसे फ़ंक्शन लिखने से बचें जो INT64
दिखाते हैं. उदाहरण के लिए, SUM
का इस्तेमाल करके, उसके इनपुट को FLOAT64
में बदलें.
काम करने वाले क्वेरी पैटर्न
अहम जानकारी: Ads Data Hub के ज़्यादातर स्टैंडर्ड सबसे सही तरीके अब भी उन क्वेरी पर लागू होते हैं जिनमें नॉइज़ इंजेक्शन का इस्तेमाल किया जाता है. हमारा सुझाव है कि आप एक ही डेटा के लिए बार-बार क्वेरी करने से जुड़े दिशा-निर्देश देखें.
इस सेक्शन में, ऐसे क्वेरी पैटर्न के बारे में बताया गया है जो ग़ैर-ज़रूरी डेटा जोड़कर क्वेरी चलाने के दौरान काम करते हैं.
उपयोगकर्ता-लेवल पर एग्रीगेट की गई जानकारी
बिना पाबंदी वाले उपयोगकर्ता-लेवल के एग्रीगेट, उसी तरह काम करते हैं जिस तरह वे अंतर की जांच करने वाले मोड में काम करते हैं. ग़ैर-ज़रूरी डेटा सिर्फ़ उन एग्रीगेशन में डाला जाता है जिनमें कई उपयोगकर्ताओं का डेटा शामिल होता है. user_id
के हिसाब से साफ़ तौर पर ग्रुप करने वाले एग्रीगेशन या user_id
के हिसाब से सेगमेंट बनाने वाले ऐनलिटिकल फ़ंक्शन में कोई ग़ैर-ज़रूरी डेटा नहीं दिखता. साथ ही, इनमें किसी भी फ़ंक्शन का इस्तेमाल किया जा सकता है. उपयोगकर्ता-लेवल के ऐसे एग्रीगेशन जिन्हें साफ़ तौर पर user_id
के हिसाब से ग्रुप नहीं किया जाता है, उदाहरण के लिए, GROUP BY impression_id
को क्रॉस-उपयोगकर्ता एग्रीगेशन माना जाता है. इसलिए, इसमें ग़ैर-ज़रूरी डेटा जोड़ा जाता है.
external_cookie के हिसाब से ग्रुपिंग करना काफ़ी नहीं है. external_cookie का इस्तेमाल, *_match टेबल को ग्राहक के मालिकाना हक वाली टेबल से जोड़ने के लिए किया जा सकता है. हालांकि, किसी एक उपयोगकर्ता के एग्रीगेशन को सिर्फ़ 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_clicks
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
इस मामले में, आपको दोहराव में से किसी एक को हटाना चाहिए.
ध्यान दें कि अगर एग्रीगेशन सिंटैक्स के हिसाब से अलग-अलग हैं, लेकिन एक ही वैल्यू का हिसाब लगाते हैं, तो इसे दोहराव के तौर पर गिना जाएगा. दूसरे शब्दों में, अगर condition1
और condition2
की वैल्यू, key
की किसी वैल्यू वाले सभी उपयोगकर्ताओं के लिए एक जैसी है, तो नीचे दी गई क्वेरी में दोहराव होगा:
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
क्वेरी से जुड़े अन्य सबसे सही तरीकों के बारे में जानें.
डायरेक्ट री-एग्रीगेशन
क्वेरी में, अलग-अलग उपयोगकर्ताओं के डेटा को इकट्ठा करने की पहली लेयर पर नॉइज़ लागू किया जाता है. एग्रीगेशन की कई लेयर वाली क्वेरी ब्लॉक की जाती हैं:
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_clicks USING(impression_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 यूनियन
ग़ैर-ज़रूरी डेटा के साथ एग्रीगेशन करने के लिए, उपयोगकर्ता आइडेंटिफ़ायर की बेहतर परफ़ॉर्मेंस ज़रूरी है. BigQuery में ग्राहक के मालिकाना हक वाले डेटा में कोई उपयोगकर्ता आइडेंटिफ़ायर नहीं होता. इसलिए, Ads Data Hub टेबल से जॉइन किए बिना, इसे ग़ैर-ज़रूरी डेटा के एग्रीगेशन में शामिल नहीं किया जा सकता.
इस क्वेरी की वजह से, पुष्टि करने में गड़बड़ी होती है:
SELECT COUNT(*) FROM (
SELECT 1 FROM adh.google_ads_impressions
UNION ALL
SELECT 1 FROM bigquery_project.dataset.table
)
इसे ठीक करने के लिए, आपको यूनियन के बजाय Ads Data Hub के डेटा को बढ़ाने के लिए, BigQuery टेबल में शामिल होना चाहिए. इसके अलावा, हर सोर्स को अलग-अलग इकट्ठा करने के लिए, डेटा को अलग करना चाहिए.
ध्यान दें कि उपयोगकर्ता के डेटा या ग्राहक के मालिकाना हक वाली कई BigQuery टेबल के साथ, Ads Data Hub की कई टेबल को यूनियन किया जा सकता है. हालांकि, इन दोनों को एक साथ नहीं जोड़ा जा सकता.
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)
ध्यान दें कि टेबल का क्रम बदलने पर, दोनों में से कोई भी जॉइन काम करेगा.
फ़िल्टर की गई लाइन की खास जानकारी
फ़िल्टर की गई पंक्ति की खास जानकारी, शोर वाले मोड में काम नहीं करती. फ़िल्टर करने की दर कम होने और अंतर की जांच से फ़िल्टर न होने की वजह से, नॉइज़ के लिए यह सुविधा ज़्यादातर ज़रूरी नहीं होती.
अगर आपको ग़ैर-ज़रूरी नतीजों में ज़्यादा डेटा फ़िल्टरिंग दिखती है, तो एग्रीगेट किए गए डेटा की संख्या बढ़ाएं. कुल अनुमान की तुलना करने के लिए, पूरे डेटासेट पर पैरलल एग्रीगेशन किया जा सकता है. उदाहरण के लिए:
SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1
ध्यान दें कि कुल संख्या में अलग से गड़बड़ी की जाती है और हो सकता है कि कुल वैल्यू एक साथ न जोड़ें. हालांकि, गड़बड़ी वाली पंक्तियों का जोड़ लेने के मुकाबले, कुल संख्या अक्सर ज़्यादा सटीक होती है.
अलग-अलग मोड में बनाई गई टेबल
Ads Data Hub में मौजूद ऐसी टेबल जिनका डेटा एक्सपोर्ट नहीं किया गया है उनका इस्तेमाल, सिर्फ़ उसी निजता मोड में किया जा सकता है जिसमें उन्हें बनाया गया था. सामान्य एग्रीगेशन मोड में टेबल बनाने के बाद, उसे नॉइज़ मोड में इस्तेमाल नहीं किया जा सकता. इसके अलावा, नॉइज़ मोड में बनाई गई टेबल को सामान्य मोड में इस्तेमाल नहीं किया जा सकता. हालांकि, अगर टेबल को पहले BigQuery में एक्सपोर्ट किया जाता है, तो ऐसा किया जा सकता है.