Sprawdzone metody

Poniżej znajdziesz sprawdzone metody tworzenia wydajnych zapytań, które zapewniają ochronę prywatności.

Ochrona prywatności a dokładność danych

Tworzenie zapytań na podstawie danych piaskownicy

Sprawdzona metoda: zapytania dotyczące danych ze środowiska produkcyjnego wysyłaj tylko wtedy, gdy korzystasz aktualnie z tego środowiska.

Podczas tworzenia zapytań używaj w miarę możliwości danych piaskownicy. Zadania korzystające z danych piaskownicy nie stwarzają dla mechanizmów kontroli różnic dodatkowych okazji do filtrowania wyników Twoich zapytań. Poza tym ze względu na brak kontroli prywatności zapytania kierowane do piaskownicy działają szybciej, co pozwala na częstsze ich wysyłanie na etapie opracowywania.

Jeśli chcesz tworzyć zapytania, korzystając ze swoich rzeczywistych danych (np. gdy używasz tabel odpowiedników), to aby zmniejszyć ryzyko pokrywania się wierszy, wybieraj takie zakresy dat i inne parametry, które prawdopodobnie nie będą się pokrywać w przypadku poszczególnych powtórzeń zapytania. Pamiętaj również o kierowaniu zapytania na odpowiedni zakres danych.

Uważne sprawdzanie wyników historycznych

Sprawdzona metoda: zmniejsz prawdopodobieństwo pokrywania się zestawów wyników wysyłanych niedawno zapytań.

Pamiętaj, że tempo zmiany wyników zapytań może wpływać na prawdopodobieństwo późniejszego pomijania wyników przez mechanizmy kontroli prywatności. Drugi zestaw wyników, który jest bardzo zbliżony do ostatnio zwróconego zestawu, zostanie raczej pominięty.

Aby temu zapobiec, zmień kluczowe parametry zapytania, np. zakresy dat lub identyfikatory kampanii. Zmniejszy to prawdopodobieństwo znacznego pokrywania się wyników.

Niewysyłanie zapytań o dane z bieżącego dnia

Sprawdzona metoda: nie wysyłaj kilku zapytań o dacie zakończenia przypadającej na bieżący dzień.

Takie działanie prowadzi często do filtrowania wierszy. Ta porada dotyczy też wysyłania tuż po północy zapytań o dane z poprzedniego dnia.

Niewysyłanie zapytań o te same dane częściej niż jest to konieczne

Sprawdzone metody:

  • Wybieraj ściśle powiązane daty rozpoczęcia i zakończenia.
  • Zamiast wysyłać zapytania dotyczące pokrywających się okresów, kieruj je na niepołączone zbiory danych, a potem agreguj wyniki w BigQuery.
  • Korzystaj z zapisanych wyników zamiast ponownie wysyłać zapytanie.
  • Utwórz tabele tymczasowe dla każdego zakresu dat, na który kierujesz zapytania.

Centrum danych reklam stosuje limit liczby zapytań, które mogą obejmować te same dane. Dlatego nie zalecamy wielokrotnego uzyskiwania dostępu do konkretnego fragmentu danych.

Nieużywanie w tym samym zapytaniu większej liczby agregacji niż jest to konieczne

Sprawdzone metody:

  • Minimalizuj liczbę agregacji w zapytaniu.
  • W miarę możliwości zmodyfikuj zapytania, aby połączyć agregacje.

Centrum danych reklam ogranicza do 100 liczbę agregacji obejmujących wielu użytkowników, które są możliwe do użycia w podzapytaniu. Dlatego zalecamy tworzenie zapytań, które zwracają więcej wierszy z kluczami grupowania ukierunkowanego i prostymi agregacjami zamiast większej liczby kolumn z kluczami ogólnego grupowania i złożonymi agregacjami. Należy unikać tego wzorca:

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

Zapytania, które zliczają zdarzenia zależne od tego samego zbioru pól, należy napisać ponownie z użyciem instrukcji GROUP BY.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

Wyniki można agregować w ten sam sposób w BigQuery.

Zapytania, które tworzą kolumny na podstawie tablicy, a potem agregują te dane w późniejszym czasie, trzeba zmodyfikować w celu scalenia tych działań. 

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

Poprzednie zapytanie można napisać ponownie w takiej postaci:

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

Zapytania, które wykorzystują różne kombinacje pól w rozmaitych agregacjach, możesz napisać ponownie w formie kilku bardziej konkretnych zapytań.

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

Poprzednie zapytanie możesz podzielić na:

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

oraz

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

Możesz podzielić te wyniki na osobne zapytania, tworzyć tabele i złączać je w pojedyncze zapytanie lub łączyć je za pomocą instrukcji UNION (jeśli mają zgodne schematy).

Optymalizowanie i analizowanie złączeń danych

Sprawdzona metoda: do łączenia kliknięć i konwersji z wyświetleniami używaj polecenia LEFT JOIN zamiast INNER JOIN.

Nie wszystkie wyświetlenia są powiązane z kliknięciami lub konwersjami. Dlatego, jeśli do łączenia kliknięć i konwersji z wyświetleniami używasz polecenia INNER JOIN, wyświetlenia niepowiązane z kliknięciami ani konwersjami będą odfiltrowywane z Twoich wyników.

Obraz przedstawiający na diagramie Venna różne metody łączenia danych

Łączenie niektórych ostatecznych wyników w BigQuery

Sprawdzona metoda: nie wysyłaj w Centrum danych reklam zapytań, które łączą wyniki zbiorcze. Zamiast tego używaj 2 osobnych zapytań i łącz ich wyniki w BigQuery.

Wiersze, które nie spełniają wymagań agregacji, są odfiltrowywane z Twoich wyników. Dlatego też, jeśli zapytanie łączy niewystarczająco zagregowany wiersz z wystarczająco zagregowanym wierszem, wynikowy wiersz zostanie przefiltrowany. Poza tym zapytania poddane kilkukrotnej agregacji są mniej wydajne w Centrum danych reklam.

Możesz łączyć wyniki (w BigQuery) różnych zapytań (z Centrum danych reklam) objętych agregacją. Wyniki obliczone z użyciem popularnych zapytań będą wykazywać wspólne ostateczne schematy.

Podane niżej zapytanie pobiera poszczególne wyniki z Centrum danych reklam (campaign_data_123 i campaign_data_456), a potem łączy je w BigQuery:

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

Używanie podsumowań wierszy po zastosowaniu filtra

Sprawdzona metoda: dodawaj do zapytań podsumowania wierszy po zastosowaniu filtra.

Podsumowania wierszy po zastosowaniu filtra zliczają dane, które zostały odfiltrowane w efekcie kontroli prywatności. Dane z przefiltrowanych wierszy są sumowane i dodawane do wiersza zbiorczego. Odfiltrowanych danych nie można dokładniej analizować, ale przynajmniej uzyskujesz podsumowanie ilości danych, które zostały odfiltrowane z wyników.

Uwzględnianie wyzerowanych identyfikatorów użytkowników

Sprawdzona metoda: uwzględniaj w wynikach wyzerowane identyfikatory użytkowników.

Identyfikator użytkownika może zostać wyzerowany z różnych powodów, m.in. z uwagi na rezygnację z personalizacji reklam lub na obowiązujące przepisy. W efekcie dane pochodzące od wielu użytkowników zostaną przypisane do parametru user_id o wartości 0.

Jeśli chcesz znać łączne dane, np. łączną liczbę wyświetleń lub kliknięć, musisz uwzględniać te zdarzenia. Te dane nie będą się jednak nadawać do uzyskiwania statystyk dotyczących klientów i wymagają filtrowania, jeśli przeprowadzasz taką analizę.

Dane te możesz wykluczyć z wyników, dodając do zapytań fragment kodu WHERE user_id != "0".

Wydajność

Unikanie ponownej agregacji

Sprawdzona metoda: unikaj stosowania kilkukrotnej agregacji użytkowników.

Przetwarzanie zapytań, które łączą zagregowane już wyniki, np. zapytań z kilkoma poleceniami GROUP BY lub z zagnieżdżoną agregacją, wymaga więcej zasobów.

Zapytania z kilkukrotną agregacją często można podzielić na osobne zapytania, aby przyspieszyć ich wykonywanie. Staraj się wtedy zachowywać podczas przetwarzania wiersze na poziomie zdarzenia lub użytkownika, a potem łącz je w ramach pojedynczej agregacji.

Należy unikać takich wzorców:

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

Zapytania, które korzystają z kilkukrotnej agregacji, należy zmodyfikować tak, aby przeprowadzały pojedynczą agregację.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

Zapytania, które można łatwo podzielić na osobne zapytania, należy podzielić. Ich wyniki możesz łączyć w BigQuery.

Optymalizacja pod kątem BigQuery

Ogólnie wydajniejsze są te zapytania, które wykonują mniej działań. Podczas oceny wydajności zapytania wymagana ilość pracy zależy od tych czynników:

Jeśli wykonanie zapytania nie spełnia warunków określonych w Twojej gwarancji jakości usług lub wywołuje błędy z powodu wyczerpania zasobów albo przekroczenia limitu czasu, wypróbuj te sposoby:

  • Używanie wyników poprzednich zapytań zamiast ich ponownego obliczania. Na przykład suma tygodniowa może być sumą obliczoną w BigQuery z 7 pojedynczych zapytań zbiorczych dotyczących poszczególnych dni.
  • Rozłożenie zapytań na logiczne zapytania podrzędne (np. rozdzielenie kilku operacji łączenia danych na różne zapytania) lub ograniczenie zbioru przetwarzanych danych w inny sposób. W BigQuery możesz łączyć wyniki pojedynczych zadań w jeden zbiór danych. Chociaż pomaga to w przypadku wyczerpywania zasobów, może spowolnić wykonywanie zapytania.
  • Jeśli w BigQuery występują błędy związane z wyczerpywaniem zasobów, spróbuj użyć tabel tymczasowych, aby podzielić zapytanie na kilka zapytań BigQuery.
  • Można odwoływać się w pojedynczym zapytaniu do mniejszej liczby tabel, ponieważ umożliwia to ograniczenie zużycia pamięci i ryzyka nieudanej realizacji zapytania.
  • Można modyfikować zapytania tak, aby łączyły mniejszą liczbę tabel użytkowników.
  • Można modyfikować zapytania tak, aby unikać łączenia tej samej tabeli z nią samą.

Doradca ds. zapytań

Jeśli kod SQL jest prawidłowy, ale może powodować nadmierne filtrowanie, doradca ds. zapytań wyświetla praktyczne porady na etapie tworzenia zapytania, aby pomóc Ci uniknąć niepożądanych wyników.

Porady te mogą się wyświetlać w takich przypadkach:

Aby korzystać z pomocy doradcy ds. zapytań: