Wstrzykiwanie szumu to metoda służąca do ochrony prywatności użytkowników podczas wysyłania zapytań do bazy danych. Polega ona na dodawaniu losowego szumu do agregującej klauzuli SELECT w zapytaniu. Ten szum chroni prywatność użytkowników, a zarazem zapewnia wystarczającą dokładność wyników, eliminuje potrzebę sprawdzania różnic i zmniejsza wymagany próg agregacji danych wyjściowych. Większość dotychczasowych zapytań można wykonywać w trybie szumu z pewnymi ograniczeniami.
Zalety wstrzykiwania szumu
Sprawdzanie różnic nie ma zastosowania: podczas wykonywania zapytań z wstrzykiwaniem szumu Centrum danych reklam nie odfiltrowuje wierszy ze względu na podobieństwo do wcześniejszych zbiorów wyników. Oznacza to, że zachowujesz całościowy wgląd w dane, a jednocześnie zapewniasz ochronę prywatności użytkowników.
Ułatwione rozwiązywanie problemów: wiersze są pomijane tylko z powodu wymagań agregacji, co ułatwia rozwiązywanie problemów i dostosowywanie zapytań.
Brak nowej składni do opanowania: aby używać szumu zamiast sprawdzania różnic, nie musisz się uczyć żadnej nowej składni zapytań ani poznawać szczegółowo zasad ochrony prywatności.
Masz wgląd w dokładność wyników: pomyślnie zakończone zadanie podaje łączny odsetek danych z oczekiwaną ilością szumu.
Jak szum wpływa na wymagania dotyczące ochrony prywatności
Sprawdzanie różnic: wstrzykiwanie szumu nie korzysta z wyników dotychczasowego sprawdzania różnic w Centrum danych reklam. Gdy stosujesz wstrzykiwanie szumu, sprawdzanie różnic zostaje wyłączone.
Wymaganie agregacji: wstrzykiwanie szumu podaje dane o wyświetleniach pochodzące od co najmniej 20 unikalnych użytkowników oraz dane o kliknięciach lub konwersjach pochodzące od co najmniej 10 unikalnych użytkowników.
Kontrole statyczne: brak wpływu.
Limity dostępu do danych i zapytań: zapytania wykonywane z wykorzystaniem szumu podlegają temu samemu limitowi dostępu do danych co sprawdzanie różnic. Podobnie jak w przypadku sprawdzania różnic, jeśli będziesz wielokrotnie wykonywać to samo zapytanie na tym samym zbiorze danych, możesz utracić możliwość wysyłania zapytań dotyczących najczęściej używanych dat. Może się to zdarzyć, jeśli wykonujesz zapytania typu „okno przesuwne” lub wielokrotnie wysyłasz to samo żądanie.
Tryb szumu narzuca dodatkowe, niższe limity na ponowne obliczanie tych samych wyników zagregowanych za pomocą jednego lub różnych zapytań. Podobnie jak w przypadku limitu dostępu do danych możesz utracić dostęp do najczęściej używanych w zapytaniach dat w zbiorze danych, ale limity związane z ponownym obliczaniem tych samych wyników zagregowanych mają wpływ tylko na zapytania w trybie szumu, a nie na zapytania w trybie sprawdzania różnic. Więcej informacji znajdziesz w sekcji Powtórzone wyniki.
Więcej informacji o mechanizmach kontroli prywatności
Jak wstrzykiwanie szumu wpływa na wyniki
Centrum danych reklam wstrzykuje szum, aby zmniejszyć ryzyko ujawnienia danych, czyli zagrożenie, że ktoś mógłby poznać informacje o pojedynczym użytkowniku. Ma to na celu zapewnienie równowagi między ochroną prywatności a użytecznością danych.
Wstrzykiwanie szumu w Centrum danych reklam przekształca wyniki zapytania w taki sposób:
- Ogranicza w wynikach zbiorczych zakres danych użytkowników odstających od reszty. Sumuje dane poszczególnych użytkowników w każdej agregacji, a następnie nakłada na każdą porcję informacji minimalny i maksymalny próg ograniczenia zakresu.
- Agreguje dane poszczególnych użytkowników objęte ograniczeniem zakresu.
- Dodaje szum do każdego zagregowanego wyniku – wyniku każdego wywołania funkcji agregacji w każdym wierszu. Skala tego losowego szumu jest proporcjonalna do progów ograniczenia zakresu.
- Oblicza w przypadku każdego wiersza liczbę użytkowników, których dane zawierają szum, i eliminuje wiersze ze zbyt małą liczbą użytkowników. Jest to podobne do k-anonimowości używanej w trybie sprawdzania różnic, ale ze względu na szum zadania wykonywane na tym samym zbiorze danych mogą pomijać inne wiersze. Poza tym w trybie szumu pomijane jest mniej wierszy ze względu na niższe wymagania dotyczące agregacji (około 20 w porównaniu do dokładnie 50).
Końcowy wynik to zbiór danych, w którym każdy wiersz zawiera wyniki zbiorcze z szumem i z którego zostały usunięte niewielkie grupy. Maskuje to wpływ poszczególnych użytkowników na zwracane wyniki.
Ograniczanie zakresu agregacji
Wstrzykiwanie szumu w Centrum danych reklam używa niejawnego lub jawnego ograniczania zakresu agregacji, aby zmniejszać udział danych użytkowników odstających od reszty. Typ stosowanego ograniczania zakresu możesz wybierać zależnie od swojego przypadku użycia.
Niejawne ograniczanie zakresu
W przypadku niejawnego ograniczania zakresu progi są ustalane automatycznie. Do jego stosowania nie potrzebujesz żadnej specjalnej składni języka SQL. Jeśli jeden wiersz ma szerszy zakres wartości niż drugi, niejawne ograniczanie zakresu ustali dla tych wierszy różne progi. Zwykle zmniejsza to margines błędu każdego wyniku. Z drugiej strony każda agregacja otrzymuje inne progi ograniczania zakresu i poziomy szumu, co utrudnia ich porównywanie.
Niejawne ograniczanie zakresu może zawieść, gdy agregacja ma dane od zbyt małej liczby użytkowników – przykładem może być wywołanie funkcji COUNTIF() z rzadkim warunkiem. Takie przypadki zwracają w wynikach wartość NULL. Pamiętaj także, że funkcja COUNT(DISTINCT user_id) używa automatycznie jawnego ograniczania zakresu z wartościami progowymi 0 i 1.
Jawne ograniczanie zakresu
Jawne ograniczanie zakresu ogranicza ogół danych pochodzących od każdego użytkownika do wyznaczonego zakresu. Jawne progi są jednolicie stosowane do wszystkich wierszy i muszą być literałami. Nawet wtedy, gdy niektóre wiersze mają szerszy zakres danych poszczególnych użytkowników niż inne, do wszystkich wierszy stosowane są te same progi. Zwiększa to porównywalność wyników pochodzących z różnych wierszy, chociaż do niektórych wierszy trafia więcej szumu, niż miałoby to miejsce w przypadku niejawnego ograniczania zakresu.
Jawne ograniczanie zakresu używa o połowę mniej szumu niż niejawne ograniczanie zakresu w przypadku danego zbioru progów ograniczania zakresu. Dlatego jeśli możesz oszacować prawdopodobne wartości progowe, będziesz uzyskiwać lepsze wyniki, ustawiając je w sposób jawny.
Aby używać jawnego ograniczania zakresu, wyznacz progi dla każdej obsługiwanej funkcji agregującej, dodając liczby całkowite reprezentujące dolny i górny próg. Przykład:
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
Wykonywanie zapytania z użyciem wstrzykiwania szumu
- Otwórz raport.
- Kliknij przełącznik Ustawienia szumu do ochrony prywatności, aby był w pozycji Użyj szumu.
- Wykonaj zapytanie.
- Sprawdź wpływ dodanego szumu.
- Opcjonalnie: dostosuj zapytanie, aby ograniczyć wpływ szumu.
Sprawdzanie wpływu szumu
Gdy zadanie zakończy się powodzeniem, Centrum danych reklam wyświetli w podsumowaniu dotyczącym prywatności stopień wiarygodności wyniku. Wiarygodność zależy od odsetka komórek w danych wyjściowych, na które w dużym stopniu wpłynął szum. Wpływ szumu na wartość w tabeli wyników uznaje się za duży, jeśli skala dodanego szumu przekracza 5% wyniku w komórce.
W przypadku zbiorów danych wyjściowych zawierających szum w podsumowaniu dotyczącym prywatności znajdziesz listę 10 najbardziej zaszumionych kolumn uszeregowanych w kolejności od najbardziej do najmniej zaszumionej. Przy każdej z nich zobaczysz też jej udział w szumie. Oto zestawienie oczekiwanej ilości szumu.
| Wyniki z szumem powyżej 5% | Oznaczenie kolorem | Wpływ |
|---|---|---|
| <5% | Zielony | Mały wpływ |
| 5–15% | Żółty | Średni wpływ |
| 15–25% | Orange | Duży wpływ |
| >25% | Czerwony | Bardzo duży wpływ |
Podsumowanie dotyczące ochrony prywatności w przypadku ostatnich zadań związanych z raportami możesz też wyświetlić na stronie Główna. Aby wyświetlić podgląd ustawień prywatności dla konkretnego zadania, najedź wskaźnikiem na ikonę wskazówki dotyczącej prywatności privacy_tip na karcie zadania w sekcji Ostatnia aktywność.
Dostosowywanie zapytań
W przypadku zagregowanych wyników, w których udział ma niewielu użytkowników, jest większe prawdopodobieństwo wystąpienia nieoczekiwanej ilości szumu. Może się to zdarzyć, gdy wiersze zawierają niską liczbę użytkowników lub gdy użytkownicy nie wpływają na wyniki, np. przy korzystaniu z funkcji COUNTIF. Znając szczegóły szumu, możesz dostosować zapytanie, aby zwiększyć odsetek danych z oczekiwaną ilością szumu.
Oto ogólne wskazówki dotyczące sposobu postępowania:
- Poszerz zakres danych.
- Zmodyfikuj zapytanie, aby zmniejszyć szczegółowość danych, np. grupując parametry w celu zmniejszenia ich liczby lub zastępując funkcję
COUNTIFfunkcjąCOUNT. - Usuń zaszumione kolumny.
- Używaj jawnego ograniczania zakresu.
Obsługiwane funkcje agregujące
W przypadku tych funkcji agregacji można stosować wstrzykiwanie szumu:
SUM(...)COUNT(*)COUNT(...)COUNTIF(...)COUNT(DISTINCT user_id)APPROX_COUNT_DISTINCT(user_id)AVG(...)
Słowo kluczowe DISTINCT jest obsługiwane tylko w przypadku funkcji COUNT i to jedynie wtedy, gdy odwołuje się ona bezpośrednio do kolumny user_id z poziomu tabeli Centrum danych reklam lub wyrażenia, które zwraca wartość user_id lub NULL, np. COUNT(DISTINCT IF(..., user_id, NULL)).
Wyniki w postaci liczb całkowitych
Chociaż Centrum danych reklam będzie automatycznie wstrzykiwać szum w przypadku tych funkcji agregacji, sygnatury funkcji nie ulegną zmianie. Funkcje takie jak COUNT i SUM stosowane do wartości INT64 zwracają wartości INT64, więc część dziesiętna zaszumionego wyniku jest zaokrąglona. Zwykle można to pominąć ze względu na wielkość wyniku i szumu.
Jeśli potrzebujesz wyniku z dokładnością do części dziesiętnej, unikaj używania w zapytaniu funkcji, które zwracają wartości INT64, np. korzystaj z funkcji SUM z danymi wejściowymi przekształconymi w wartości FLOAT64.
Informacje o wynikach negatywnych
Z założenia szum o bardzo małych wartościach może powodować powstawanie liczb ujemnych, nawet jeśli w przypadku danego zapytania jest to semantycznie niemożliwe. Aby zachować oczekiwane działanie, wszystkie formy COUNT i COUNTIF są automatycznie ograniczane do zera, więc nigdy nie dają wyników ujemnych. Jeśli chcesz uzyskać to samo działanie w przypadku innej funkcji, np. SUM, możesz ręcznie ograniczyć wyniki za pomocą funkcji GREATEST(0, SUM(...)).
Ta zmiana jest zwykle nieznaczna, ale wprowadza niewielkie dodatnie odchylenie do ogólnych wyników. Jeśli chcesz tego uniknąć, użyj funkcji ADH.ANON_COUNT zamiast COUNT lub funkcji GROUP BY ROLLUP, aby obliczyć łączną liczbę w wierszach.
Obsługiwane wzorce zapytań
Ważne: większość standardowych sprawdzonych metod dotyczących Centrum danych reklam ma też zastosowanie do zapytań, które używają wstrzykiwania szumu. W szczególności zalecamy zapoznanie się z poradami dotyczącymi wielokrotnego wysyłania zapytań o te same dane.
W tej sekcji omawiamy wzorce zapytań, które są obsługiwane w przypadku wykonywania zapytań objętych wstrzykiwaniem szumu.
Agregacje na poziomie użytkownika
Nieograniczone agregacje na poziomie użytkownika są obsługiwane w taki sam sposób jak w trybie sprawdzania różnic. Szum jest wstrzykiwany tylko w przypadku agregacji, które łączą dane różnych użytkowników. Agregacje, które jawnie grupują dane według parametru user_id, lub funkcje analityczne, które dzielą dane według parametru user_id, nie otrzymują żadnego szumu, a każda funkcja jest dozwolona. Agregacje na poziomie użytkownika, które nie wykonują jawnego grupowania według parametru user_id, np. GROUP BY impression_id, są traktowane jako agregacje danych różnych użytkowników, więc w ich przypadku następuje wstrzykiwanie szumu.
Grupowanie według parametru external_cookie nie wystarcza. Parametr external_cookie może być używany do łączenia tabel *_match z tabelami należącymi do klientów, ale wszystkie agregacje obejmujące pojedynczych użytkowników powinny być grupowane bezpośrednio według kolumny user_id, a nie tylko według kolumny external_cookie.
Przykład funkcji agregującej:
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;
Przykład funkcji analitycznej:
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;
Agregacje równoległe
Każda agregacja danych różnych użytkowników otrzymuje szum z osobna. W pojedynczej instrukcji możesz zastosować kilka takich agregacji i połączyć wyniki w jedną tabelę za pomocą funkcji JOIN lub UNION.
Przykład:
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)
Pamiętaj, że będzie to obsługiwane, ale w trybie sprawdzania różnic należy tego unikać. Ta metoda nie stanowi problemu w przypadku szumu, ponieważ każda agregacja równoległa jest zaszumiana i filtrowana niezależnie.
Dane zagregowane złączone z danymi niezagregowanymi
Centrum danych reklam obsługuje tylko okna analityczne, które dzielą dane według parametru user_id, więc typową metodą obejścia tego ograniczenia jest osobne zagregowanie tych wyników i samodzielne ich złączenie przed ponowną agregacją. Te zapytania są obsługiwane w trybie szumu i często przynoszą wtedy lepsze efekty, niż gdyby były wykonywane w trybie sprawdzania różnic, ponieważ w ich przypadku wymagania dotyczące ochrony prywatności zostają spełnione na wcześniejszym etapie.
Przykład:
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
Tryb szumu odradza ponowną agregację zagregowanych wyników, np. za pomocą funkcji AVG(campaign_imps).
Nieobsługiwane wzorce zapytań
W tej sekcji omawiamy wzorce zapytań, które nie są obsługiwane w przypadku wykonywania zapytań objętych wstrzykiwaniem szumu.
Zapytania uwzględniające bieżący dzień
Zapytania w trybie szumu nie obsługują danych z bieżącego dnia. (W trybie sprawdzania różnic należy tego unikać). W przypadku zapytań, które używają wstrzykiwania szumu, nie można wybrać bieżącej daty.
Powtórzone wyniki
W trybie szumu Centrum danych reklam ogranicza częstotliwość, z jaką możesz powtarzać tę samą agregację. Jeśli osiągniesz te limity, zapytania w trybie szumu utracą dostęp do najczęściej używanych dat w zbiorze danych. Poniżej podajemy przykłady, kiedy może to nastąpić.
Powtarzanie zapytania może nastąpić, gdy to samo zapytanie jest wykonywane kilka razy z identycznymi lub bardzo podobnymi parametrami, np. z nakładającymi się zakresami dat. Możesz tego uniknąć, używając danych, które zostały już wyeksportowane do projektu BigQuery.
Pamiętaj, że jeśli 2 zadania wykonują zapytania z pokrywającymi się zakresami dat, mogą powodować powtórzenia z powodu przeprowadzania tego samego obliczenia na identycznych użytkownikach. Na przykład to zapytanie wykonane w przypadku pokrywających się zakresów dat powoduje powtórzenie, ponieważ dzieli dane według daty:
SELECT DATE(TIMESTAMP_MICROS(event.event_time)) AS date,
COUNT(*) AS cnt
FROM adh.cm_dt_clicks
GROUP BY 1
W tej sytuacji wykonaj to zapytanie na rozłączonych segmentach danych.
Oto kolejny przykład powtórzenia, które następuje, gdy dane są w pewien sposób niezależne od daty. To zapytanie powoduje powtórzenie, gdy zostaje wykonane w przypadku pokrywających się dat, kiedy to oba zadania obejmują cały okres prowadzenia kampanii:
SELECT campaign_id, COUNT(*) AS cnt
FROM adh.google_ads_impressions
GROUP BY 1
W tej sytuacji wykonaj to zapytanie tylko raz, ponieważ nie zmieni to jego wyniku.
Powtórzenie agregacji następuje, gdy ta sama agregacja zostaje powtórzona kilka razy w obrębie jednego zapytania:
SELECT COUNT(*) AS cnt1, COUNT(*) AS cnt2
FROM table
W takiej sytuacji usuń jedno z powtórzeń.
Pamiętaj, że nawet wtedy, gdy agregacje różnią się pod względem składni, ale obliczają tę samą wartość, uznaje się to za powtórzenie. Inaczej mówiąc, jeśli wartości warunków condition1 i condition2 są identyczne dla wszystkich użytkowników z pewną wartością parametru key, to zapytanie spowoduje powtórzenie:
SELECT key, COUNTIF(condition1) AS cnt1, COUNTIF(condition2) AS cnt2
FROM table
GROUP BY key
Jeśli stosujesz warunki, które są bardzo podobne dla pewnych grup użytkowników, spróbuj zmodyfikować zapytanie, tak aby zawierało tylko jedną funkcję COUNT.
Powielanie wierszy następuje, gdy tabela Centrum danych reklam jest złączona z tabelą BigQuery w taki sposób, że każdy wiersz z tabeli Centrum danych reklam odpowiada kilku wierszom w tabeli BigQuery. Na przykład to zapytanie powoduje powtórzenie, jeśli w tabeli bq_table występuje kilka wierszy z tym samym identyfikatorem kampanii:
SELECT r.campaign_id, COUNT(*) AS cnt
FROM adh_table
INNER JOIN bq_table ON l.campaign_id = r.campaign_id
W tej sytuacji zmień strukturę zapytania, tak aby tabela bq_table zawierała tylko jeden wiersz na wartość klucza złączania (w tym przypadku campaign_id).
Pamiętaj, że cofnięcie umieszczenia tablicy w tabeli Centrum danych reklam może wywołać ten sam efekt, jeśli większość użytkowników ma te same tablice wartości:
SELECT in_market_id, COUNT(*)
FROM adh.dv360_youtube_impressions,
UNNEST(in_market) AS in_market_id
GROUP BY 1
Więcej informacji o innych sprawdzonych metodach dotyczących zapytań
Bezpośrednia ponowna agregacja
Szum jest stosowany w zapytaniu do pierwszej warstwy agregacji danych różnych użytkowników. Zapytania z kilkoma warstwami agregacji będą łączyć zaszumione wyniki, więc wynikowe złączone dane mogą mieć znacznie wyższy poziom szumu. Te zapytania otrzymują ostrzeżenie podczas weryfikacji:
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
Aby uzyskać najlepsze wyniki po zastosowaniu szumu, oblicz wszystkie operacje na danych różnych użytkowników w ramach jednej agregacji. Na przykład funkcję SUM stosuj do zdarzeń, a nie do pośrednich wyników obliczeń.
Jeśli agregacja wielowarstwowa jest nieunikniona, możesz rozwiązać problem, eksportując wyniki bezpośrednio z pierwszej warstwy. Aby to zrobić w ramach pojedynczego zadania bez zmiany wyników skryptu, utwórz tabelę tymczasową (lub tabelę eksportowaną do projektu BigQuery) ze składnią OPTIONS(privacy_checked_export=true). Na przykład:
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
Więcej informacji o tabelach tymczasowych
Jeśli pierwsza warstwa agregacji ma zbyt duży poziom szczegółowości z punktu widzenia mechanizmów kontroli prywatności, rozważ zmodyfikowanie zapytania, aby używać agregacji na poziomie użytkownika. Jeśli to nie jest możliwe, to zapytanie nie będzie obsługiwane w trybie szumu.
Rozłączone identyfikatory użytkowników
Zapytania w trybie szumu nie mogą łączyć w jednym wierszu danych pochodzących od osobnych użytkowników, chyba że w przypadku przeprowadzania agregacji z szumem. Z tego powodu złączenia niezagregowanych danych Centrum danych reklam powinny jawnie przeprowadzać złączenie w kolumnie user_id.
To zapytanie nie wykonuje jawnego złączenia danych w kolumnie user_id, co powoduje ostrzeżenie o błędzie weryfikacji:
SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_id)
Takie złączenia mogą nie działać zgodnie z oczekiwaniami, ponieważ będą dopasowywane tylko wiersze o tej samej wartości user_id. Można to poprawić, modyfikując klauzulę USING, tak aby jawnie uwzględniała parametr user_id, np. USING(impression_id, user_id).
Pamiętaj, że to ograniczenie dotyczy tylko złączeń między tabelami Centrum danych reklam (z wyjątkiem tabel wymiarów). Nie odnosi się do tabel należących do klientów. Na przykład to jest dozwolone:
SELECT …
FROM adh.google_ads_impressions
JOIN bigquery_project.dataset.table USING(any_column)
Złączenia prawe danych Centrum danych reklam i BigQuery
Złączenia zewnętrzne z danymi należącymi do klientów mogą powodować powstawanie wierszy, w których brakuje identyfikatorów użytkowników, co uniemożliwia prawidłowe działanie szumu.
Oba te zapytania wywołują ostrzeżenia dotyczące weryfikacji, ponieważ umożliwiają powstawanie po stronie Centrum danych reklam niepasujących do siebie wierszy, w których brakuje identyfikatorów użytkowników:
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)
Pamiętaj, że każde z tych złączeń zadziałałoby, gdyby kolejność tabel była odwrotna. Wyjątkiem są też tabele identyfikatorów RDID, które są złączane bezpośrednio z użyciem device_id_md5. Na przykład to zapytanie będzie działać bez ostrzeżeń:
SELECT …
FROM bigquery_project.dataset.table
LEFT JOIN adh.google_ads_impressions_rdid USING(device_id_md5)
Podsumowanie wierszy po zastosowaniu filtra
Specyfikacja podsumowania wierszy po zastosowaniu filtra nie jest obsługiwana w trybie szumu. Gdy stosuje się szum, ta funkcja jest najczęściej zbędna z powodu niższych poziomów filtrowania i braku filtrowania w ramach sprawdzania różnic.
Jeśli w wyniku z szumem zauważysz znaczne filtrowanie danych, zwiększ ilość zagregowanych danych. Możesz przeprowadzić agregację równoległą na pełnym zbiorze danych, aby porównać prognozę łącznej liczby, np.:
SELECT campaign_name, COUNT(*)
FROM data
GROUP BY 1
UNION ALL
SELECT 'Total', COUNT(*)
FROM data
GROUP BY 1
Pamiętaj, że łączna liczba jest zaszumiana niezależnie, a łączne wartości mogą się nie sumować, jednak łączna liczba jest często dokładniejsza od sumy zaszumionych wierszy.
Tabele utworzone w różnych trybach
Niewyeksportowanych tabel w Centrum danych reklam można używać tylko w tym samym trybie ochrony prywatności, w którym je utworzono. Nie możesz utworzyć tabeli w normalnym trybie agregacji, a potem użyć jej w trybie szumu ani na odwrót (chyba że najpierw wyeksportujesz tę tabelę do BigQuery).