Wstrzykiwanie szumu

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

Wpisz zapytanie lub otwórz wcześniejsze zapytanie. O tym, których funkcji agregacji można używać, dowiesz się w sekcji Obsługiwane funkcje agregacji.
W Edytorze zapytań kliknij Wykonaj i wpisz szczegóły nowego zadania.
Kliknij przełącznik Ustawienia prywatności, aby go ustawić w pozycji Użyj szumu.
Wykonaj zapytanie.
Sprawdź dodany szum.
Opcjonalnie: dostosuj zapytanie, aby ograniczyć wpływ szumu.

Sprawdzanie wpływu szumu

Gdy zapytanie zakończy się powodzeniem, Centrum danych reklam poda stopień wiarygodności wyniku na podstawie tego, ile komórek w danych wyjściowych zawiera oczekiwaną ilość szumu. 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. Zakresy wpływu znajdziesz w tabeli poniżej.

W przypadku zbiorów danych wyjściowych zawierających szum możesz na karcie Szczegóły znaleźć 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.

Dane z oczekiwaną ilością szumu	Oznaczenie kolorem	Wpływ
>95%	Zielony	Mały wpływ
85–95%	Żółty	Średni wpływ
75–85%	Pomarańczowy	Duży wpływ
<75%	Czerwony	Bardzo duży wpływ

Aby zobaczyć szczegółowe informacje o wpływie szumu:

Kliknij Raporty.
Na liście wybierz raport. Etykietka Podsumowanie ustawień prywatności podaje odsetek wyników, które zawierają oczekiwaną ilość szumu odpowiadającą ilości dodanego szumu przekraczającej 5% wyniku.
Aby uzyskać więcej informacji, kliknij Zadania > Szczegóły
W szczegółach zadania wyświetl Wiadomości dotyczące ochrony prywatności. Wyniki zaliczają się do jednej z podanych kategorii.
W razie potrzeby dostosuj zapytanie, aby poprawić wynik.

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ę COUNTIF funkcją 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)).

Te funkcje nie są obsługiwane bezpośrednio, ale można je zastąpić innymi funkcjami agregacji ze wstrzykiwaniem szumu, aby uzyskać wyniki statystyczne. Pamiętaj, że podane tu wartości numeryczne mają tylko charakter poglądowy:

LOGICAL_OR(...). Zalecany zamiennik: COUNT(DISTINCT IF(..., user_id, NULL)) > 0
LOGICAL_AND(...). Zalecany zamiennik: COUNT(DISTINCT IF(NOT ..., user_id, NULL)) <= 0

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.

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 zabrania ponownej agregacji 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 są blokowane:

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ń. Można zmodyfikować zapytanie, aby ponownie zagregować zaszumione złączone dane, ale wynikowe złączone dane mogą mieć znacznie wyższy poziom szumu.

Jeśli jest to nie do uniknięcia, możesz zmodyfikować zapytanie, aby eksportować 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). 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 muszą jawnie przeprowadzać złączenie w kolumnie user_id.

To zapytanie nie wykonuje jawnego złączenia danych w kolumnie user_id, co powoduje błąd weryfikacji:

SELECT …
FROM adh.google_ads_impressions
JOIN adh.google_ads_clicks USING(impression_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)

Sumy zbiorów danych Centrum danych reklam i BigQuery

Prawidłowe przeprowadzenie agregacji z szumem wymaga identyfikatorów użytkowników. Dane w BigQuery należące do klientów nie zawierają identyfikatorów użytkowników, więc nie można ich sumować z zaszumioną agregacją bez uprzedniego złączenia z tabelą Centrum danych reklam.

To zapytanie spowoduje błąd weryfikacji:

SELECT COUNT(*) FROM (
  SELECT 1 FROM adh.google_ads_impressions
  UNION ALL
  SELECT 1 FROM bigquery_project.dataset.table
)

Aby to poprawić, musisz albo złączyć tabelę BigQuery w celu wzbogacenia danych Centrum danych reklam zamiast jej zsumowania, albo wydzielić te dane, aby zagregować każde źródło z osobna.

Pamiętaj, że można zsumować ze sobą kilka tabel Centrum danych reklam z danymi użytkowników lub kilka tabel BigQuery należących do klientów, ale nie można sumować ze sobą tych 2 rodzajów tabel.

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ą błędy 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.

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).