Dopasowywanie danych własnych i przekazywanych przez użytkowników

Dopasowywanie danych własnych i przekazywanych przez użytkowników (UPDM) łączy zebrane przez Ciebie dane własne o użytkowniku (np. informacje z Twoich witryn, aplikacji i sklepów stacjonarnych) z danymi o aktywności tego samego zalogowanego użytkownika powiązanej z danymi reklam Google, w tym z danymi należącymi do Google i obsługiwanymi przez tę firmę. Obejmuje to dane kupione za pomocą usług Google Marketing Platform (GMP), np. YouTube, kupione za pomocą Display & Video 360. Inne usługi GMP, które nie należą do Google i nie są przez Google obsługiwane, nie są obsługiwane.

Aby kwalifikować się do dopasowywania danych własnych i przekazywanych przez użytkowników, zdarzenie reklamy musi być powiązane z zalogowanym użytkownikiem w danych reklam Google.

W tym dokumencie opisujemy funkcję dopasowywania danych przekazywanych przez użytkowników oraz podajemy wskazówki dotyczące jej konfigurowania i używania.

Omówienie dopasowania w chmurze prywatnej

Uzyskanie cennych statystyk dotyczących reklam często wymaga połączenia danych z wielu źródeł. Stworzenie własnego rozwiązania tego problemu z potokiem danych wymaga znacznych nakładów czasu i pracy inżynierów. Funkcja Private Cloud Match w Centrum danych reklam upraszcza ten proces, udostępniając szablon zapytania Centrum danych reklam do tworzenia tabeli dopasowań w BigQuery, którą można następnie wykorzystać w zapytaniach Centrum danych reklam do dopasowywania danych reklam do danych własnych. Wzbogacanie zapytań za pomocą danych własnych może zapewniać bogatsze doświadczenia klienta i jest bardziej odporne na ogólnobranżowe zmiany sposobów śledzenia reklam.

Dopasowywanie danych własnych i przekazywanych przez użytkowników jest dostępne tylko w przypadku zalogowanych użytkowników w zasobach reklamowych należących do Google i zarządzanych przez Google, więc zbliżające się wycofanie plików cookie innych firm nie będzie miało na nie wpływu. Są one bardziej odporne na zmiany zachodzące w branży niż dane innych firm, dzięki czemu mogą dostarczać bardziej szczegółowych statystyk, co może prowadzić do większego zaangażowania klientów.

Podsumowanie procesu

  1. Konfigurowanie pozyskiwania i dopasowywania danych
    • Ty Sprawdź, czy Twoje dane własne znajdują się w BigQuery i czy Twoje konto usługi ma do nich dostęp z możliwością odczytu. Zobacz Konfigurowanie pozyskiwania danych.
  2. Pozyskiwanie i dopasowywanie danych własnych
    • Ty formatujesz i przesyłasz dane własne do zbioru danych BigQuery.
    • Ty inicjujesz żądanie dopasowania danych, tworząc zapytanie analizy dopasowania w chmurze prywatnej Match i ustalając harmonogram.
    • Google łączy dane z Twojego projektu z danymi należącymi do Google, które zawierają identyfikator użytkownika Google i zaszyfrowane dane przekazane przez użytkowników, aby tworzyć i aktualizować tabele dopasowań.
    • Zobacz Pozyskiwanie danych własnych.
  3. Bieżące zapytania w Centrum danych reklam na podstawie dopasowanych danych
    • Zapytania do tabel odpowiedników wykonujesz w taki sam sposób jak zwykłe zapytania w Centrum danych reklam. Patrz Zapytanie o dopasowane dane.

Więcej informacji o wymaganiach dotyczących ochrony prywatności

Zbieranie danych o klientach

Jeśli używasz dopasowywania danych własnych i przekazywanych przez użytkowników, musisz przesyłać dane własne. Mogą to być informacje zebrane przez Ciebie w Twoich witrynach, aplikacjach, sklepach stacjonarnych lub dowolne informacje, które klient udostępnił Ci bezpośrednio.

Musisz:

  • umieścić w polityce prywatności informację, że udostępniasz dane klientów firmom zewnętrznym, które realizują w Twoim imieniu różne usługi, oraz że uzyskujesz zgodę na udostępnianie danych w ten sposób, jeśli wymaga tego prawo;
  • do przesyłania danych klientów używać wyłącznie interfejsów lub API zatwierdzonych przez Google;
  • przestrzegać wszystkich obowiązujących przepisów i regulacji prawnych, w tym wszelkich regulacji wewnętrznych i wytycznych branżowych;

Potwierdzenie samodzielnie uzyskanej zgody użytkowników

Aby móc używać w Centrum danych reklam danych własnych, musisz potwierdzić, że masz uzyskaną prawidłową zgodę użytkowników z Europejskiego Obszaru Gospodarczego na udostępnianie danych Google, która została otrzymana w sposób określony przez politykę w zakresie zgody użytkownika z UE i zasady Centrum danych reklam. To wymaganie obowiązuje w przypadku każdego konta Centrum danych reklam, a swoje potwierdzenie uzyskania zgody użytkowników musisz aktualizować za każdym razem, gdy przesyłasz nowe dane własne. Potwierdzenie to może przekazać w imieniu całego konta dowolny jego użytkownik.

Pamiętaj, że te same reguły dotyczące zapytań kierowanych do usług Google, które obowiązują w przypadku zapytań analitycznych, mają zastosowanie do zapytań o identyfikatory UPDM. Na przykład, gdy tworzysz tabelę odpowiedników, nie możesz wykonywać zapytań dotyczących użytkowników z Europejskiego Obszaru Gospodarczego i obejmujących różne usługi.

Aby dowiedzieć się, jak potwierdzić w Centrum danych reklam uzyskanie zgody użytkowników, zapoznaj się z artykułem Wymagania dotyczące zgody użytkownika w Europejskim Obszarze Gospodarczym.

Rozmiar danych

Aby chronić prywatność użytkowników, dopasowywanie danych własnych i przekazywanych przez użytkowników wymaga spełnienia tych warunków dotyczących rozmiaru danych:

  • Musisz przesłać listę użytkowników zawierającą co najmniej 1000 rekordów.

Konfigurowanie pozyskiwania danych

Zanim zaczniesz, upewnij się, że:

  • Dane własne muszą znajdować się w BigQuery. Jeśli masz obwód VPC-SC, te dane własne muszą się znajdować w jego obrębie.
  • Twoje konto usługi Centrum danych reklam musi mieć dostęp do danych własnych z możliwością odczytu.
  • Dane własne muszą być prawidłowo sformatowane i zaszyfrowane. Więcej informacji znajdziesz w następnej sekcji.

Poza tym nie ma żadnych dodatkowych czynności związanych z wprowadzeniem do funkcji Private Cloud Match. Jeśli możesz uruchomić zapytanie analityczne, możesz też uruchomić zapytanie Private Cloud Match.

Pozyskiwanie i dopasowywanie danych własnych

Uprawnienia źródłowe i wymagania dotyczące połączenia

Połączenia w Centrum danych reklam korzystają z konta usługi widocznego w sekcji Ustawienia > Szczegóły > Konto usługi (zwykle service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com). Przypisz mu te role:

  • Źródło BigQuery: roles/bigquery.dataViewer (Wyświetlający dane BigQuery) w źródłowym zbiorze danych lub tabeli.
  • Źródło Cloud Storage: roles/storage.objectViewer (Wyświetlający obiekty w Cloud Storage) w zasobniku lub obiekcie źródłowym.
  • Miejsce docelowe importu danych własnych: roles/bigquery.dataEditor (Edytujący dane BigQuery) w docelowym zbiorze danych, jeśli tabela nie znajduje się w domyślnym zbiorze danych.

Wymagania dotyczące pól i typów danych

  1. Dopasowywanie danych własnych i przekazywanych przez użytkowników:
    • Zmapuj user_id i co najmniej 1 pole z informacjami umożliwiającymi identyfikację (email, phone lub pełny adres: first_name, last_name, country, zip_code).
    • user_id, country i zip_code: zwykły tekst STRING (niezaszyfrowany). W przypadku źródła BigQuery te kolumny muszą już mieć typ STRING. Inne typy (np. INT64) powodują błąd podczas tworzenia połączenia. Połączenia rzutują user_id na BYTES w tabeli odpowiedników. country musi być 2-literowym kodem ISO 3166-1 alfa-2.
    • email, phone, first_name i last_name: HASH – musi być już zahaszowany za pomocą algorytmu SHA-256 i zakodowany w standardzie Base64 (akceptowana jest też 64-znakowa wartość szesnastkowa SHA-256). Połączenia nie szyfrują danych. Wartości w postaci zwykłego tekstu nie są wykrywane podczas tworzenia połączenia. Każde uruchomienie kończy się błędem ... must be encoded using TO_BASE64(SHA256(...)).
    • Połączenia dopasowywania danych własnych i przekazywanych przez użytkowników nie mają tabeli docelowej. Wszystkie zapytania na koncie i zapytania UPDM uruchamiane ręcznie zapisują dane w tej samej tabeli dopasowań, więc każde uruchomienie zastępuje poprzednie. Wystarczy jedno połączenie UPDM na konto.
    • Reguły dotyczące poszczególnych pól znajdziesz w artykule Formatowanie danych wejściowych.
  2. Importowanie danych własnych:
    • Używaj tylko typów danych dostępnych w interfejsie: INTEGER, STRING, HASH, DOUBLE, DATE i TIMESTAMP. Inne typy BigQuery nie są obsługiwane.
    • Źródło BigQuery: zmapowany typ nie jest stosowany. Każda kolumna docelowa zachowuje typ kolumny źródłowej.
    • Źródło Cloud Storage: kolumny są odczytywane jako STRING i rzutowane na zmapowany typ. Wartości, których nie można rzutować, stają się NULL, ale nie powodują niepowodzenia uruchomienia.
    • Każde uruchomienie zastępuje całą tabelę docelową, a nie dołącza do niej dane. Jeśli źródło nie zawiera wierszy, miejsce docelowe będzie puste. Nie używaj tabeli źródłowej ani tabeli, której dane chcesz zachować, jako tabeli docelowej.

Wymagania dotyczące kolumn w pliku CSV w Cloud Storage

  • Dodaj wiersz nagłówka. Pierwszy wiersz jest pomijany, a nazwy kolumn nie są używane.
  • Plik musi zawierać dokładnie zmapowane kolumny źródłowe, nie więcej i nie mniej. Dodatkowe kolumny powodują niepowodzenie uruchomienia.
  • Import danych własnych: kolumny muszą być w tej samej kolejności co mapowania pól.
  • Dopasowywanie danych własnych i przekazywanych przez użytkowników: kolumny muszą być w tej kolejności, przy czym należy zachować tylko mapowane pola: user_id, email, phone, first_name, last_name, country, zip_code. Kolejność wierszy mapowania nie ma znaczenia.
  • Inna kolejność kolumn nie jest wykrywana: wartości są wczytywane do nieprawidłowych pól (lub współczynniki dopasowania spadają) bez błędu.

Obsługiwane źródła danych i limity połączeń

  • Źródła danych: obsługiwane są tylko źródła BigQuery i Cloud Storage.
  • Nazwy tabel BigQuery: źródłowe i docelowe tabele BigQuery muszą mieć pełną nazwę project.dataset.table.
  • Ścieżki plików w Cloud Storage: podaj identyfikator URI pojedynczego pliku (np. gs://bucket/path/file.csv). Ścieżki z symbolami wieloznacznymi * lub ? nie są obsługiwane.
  • Nazwy połączeń: każde połączenie na koncie musi mieć unikalną nazwę.

Formatowanie danych wejściowych

Aby dane mogły zostać prawidłowo dopasowane, muszą spełniać te wymagania dotyczące formatowania:

  • W miejscach wskazanych w opisach pól do wprowadzania danych musisz przesłać dane zaszyfrowane za pomocą algorytmu SHA256.
  • UPDM obsługuje kodowanie Base64. Zobacz TO_BASE64.
  • Pola do wprowadzania danych muszą być sformatowane jako ciągi znaków. Jeśli na przykład używasz funkcji skrótu SHA256 BigQuery, zastosuj to przekształcenie: TO_BASE64(SHA256(user_data)).

Identyfikator użytkownika

  • Typ danych: BYTES
  • Haszowanie: brak

E-mail

  • Usuń spacje na początku i na końcu ciągu.
  • Używaj tylko małych liter.
  • Wszystkie adresy e-mail muszą zawierać domenę, np. gmail.com lub poczta.onet.pl.
  • Usuń znaki diakrytyczne – na przykład zmień è, é, ê lub ë na e.
  • usunąć wszystkie kropki (.) poprzedzające nazwę domeny w adresach e-mail w gmail.com i googlemail.com.
  • Szyfrowanie: SHA256 zakodowany w formacie Base64

Ważność: TO_BASE64(SHA256("jeffersonloveshiking@gmail.com"))

Nieprawidłowe: TO_BASE64(SHA256("JéffersonLôvesHiking@gmail.com"))

Telefon

  • Usuń odstępy
  • Format E.164 – na przykład: +14155552671 (USA), +442071838750 (Wielka Brytania)
  • Usuń wszystkie znaki specjalne z wyjątkiem znaku „+” przed kodem kraju.
  • Szyfrowanie: SHA256 zakodowany w formacie Base64

Ważność: TO_BASE64(SHA256("+18005550101"))

Nieprawidłowe: TO_BASE64(SHA256("(800) 555-0101"))

Imię

  • Usuń odstępy
  • Używaj tylko małych liter.
  • Usuń wszystkie prefiksy, np. Pani, Pan, Pani, Dr
  • Nie usuwaj znaków diakrytycznych, takich jak ę, é, ê czy ë.
  • Szyfrowanie: SHA256 zakodowany w formacie Base64

Ważność: TO_BASE64(SHA256("daní"))

Nieprawidłowe: TO_BASE64(SHA256("Daní"))

Nazwisko

  • Usuń odstępy
  • Używaj tylko małych liter.
  • Usuń wszystkie sufiksy, np. Jr., Sr., 2nd, 3rd, II, III, PHD, MD
  • Nie usuwaj znaków diakrytycznych, takich jak ę, é, ê czy ë.
  • Szyfrowanie: SHA256 zakodowany w formacie Base64

Ważność: TO_BASE64(SHA256("délacruz"))

Nieprawidłowe: TO_BASE64(SHA256("dé la Cruz, Jr."))

Kraj

  • Podawaj kod kraju, nawet jeśli wszystkie dane o klientach pochodzą z tego samego kraju.
  • Nie szyfruj danych kraju
  • Używaj kodów kraju w formacie ISO 3166-1 alfa-2.
  • Haszowanie: brak

Ważność: US

Nieprawidłowe: United States of America lub USA

Kod pocztowy

  • Nie szyfruj danych kodu pocztowego.
  • Dopuszczalne są zarówno amerykańskie, jak i międzynarodowe kody pocztowe
  • W przypadku Stanów Zjednoczonych:
    • Dozwolone są kody 5-cyfrowe, np. 94043.
    • Format 5-cyfrowy z 4-cyfrowym rozszerzeniem też jest dozwolony, np. 94043-1351 lub 940431351.
  • W przypadku pozostałych krajów:
    • Nie jest wymagane formatowanie (nie trzeba zmieniać wielkości liter ani usuwać spacji i znaków specjalnych).
    • Nie dodawaj rozszerzeń kodu pocztowego
  • Haszowanie: brak

Weryfikacja haszy i kodowanie danych

Aby upewnić się, że dane są prawidłowo sformatowane, możesz użyć podanych niżej skryptów do sprawdzania poprawności szyfrowania.

JavaScript

  /**
   * @fileoverview Provides the hashing algorithm, as well as some valid hashes of
   * sample data for testing.
  */

  async function hash(token) {
    // Removes leading or trailing spaces and converts all characters to lowercase.
    const formattedToken = token.trim().toLowerCase();
    // Hashes the formatted string using the SHA-256 hashing algorithm.
    const hashBuffer = await crypto.subtle.digest(
        'SHA-256', (new TextEncoder()).encode(formattedToken));
    // Converts the hash buffer to a base64-encoded string and returns it.
    const base64Str = btoa(String.fromCharCode(...new Uint8Array(hashBuffer)));
    return base64Str;
  }

  function main() {
    // Expected hash for test@gmail.com:
    // h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    hash('test@gmail.com').then(result => console.log(result));

    // Expected hash for +18005551212:
    // YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    hash('+18005551212').then(result => console.log(result));

    // Expected hash for John: ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    hash('John').then(result => console.log(result));

    // Expected hash for Doe: eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
    hash('Doe').then(result => console.log(result));
  }

  main()

Python

  """Provides the hashing algorithm, as well as some valid hashes of sample data for testing.

  Supports: Python 2, Python 3

  Sample hashes:

    - Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '+18005551212':   YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    - First name 'John':      ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    - Last name 'Doe':        eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
  """

  import base64
  import hashlib

  def hash(token):
  # Generates a base64-encoded SHA-256 hash of a normalized input string.
    return base64.b64encode(
        hashlib.sha256(
            token.strip().lower().encode('utf-8')).digest()).decode('utf-8')

  def print_hash(token, expected=None):
  # Computes and displays the hash of a token, with optional validation.
    hashed = hash(token)

    if expected is not None and hashed != expected:
      print(
          'ERROR: Incorrect hash for token "{}". Expected "{}", got "{}"'.format(
              token, expected, hashed))
      return

    print('Hash: "{}"\t(Token: {})'.format(hashed, token))

  def main():
  # Tests the hash function with sample tokens and expected results.
    print_hash(
        'test@gmail.com', expected='h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=')
    print_hash(
        '+18005551212', expected='YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=')
    print_hash('John', expected='ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=')
    print_hash('Doe', expected='eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=')

  if __name__ == '__main__':
    main()

Go

  /*
  Provides the hashing algorithm, as well as some valid hashes of sample data for testing.

  Sample hashes:

    - Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '+18005551212':   YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    - First name 'John':      ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    - Last name 'Doe':        eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
  */
  package main

  import (
    "crypto/sha256"
    "encoding/base64"
    "fmt"
    "strings"
  )

  // Hash hashes an email, phone, first name, or last name into the correct format.
  func Hash(token string) string {
    formatted := strings.TrimSpace(strings.ToLower(token))
    hashed := sha256.Sum256([]byte(formatted))
    encoded := base64.StdEncoding.EncodeToString(hashed[:])
    return encoded
  }

  // PrintHash prints the hash for a token.
  func PrintHash(token string) {
    fmt.Printf("Hash: \"%s\"\t(Token: %s)\n", Hash(token), token)

  }

  func main() {
    PrintHash("test@gmail.com")
    PrintHash("+18005551212")
    PrintHash("John")
    PrintHash("Doe")
  }

Java

  package updm.hashing;

  import static java.nio.charset.StandardCharsets.UTF_8;

  import java.security.MessageDigest;
  import java.security.NoSuchAlgorithmException;
  import java.util.Base64;

  /**
  * Example of the hashing algorithm.
  *
  * <p>Sample hashes:
  *
  * <ul>
  *   <li>Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
  *   <li>Phone '+18005551212': YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
  *   <li>First name 'John': ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
  *   <li>Last name 'Doe': eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
  * </ul>
  */
  public final class HashExample {

  private HashExample() {}

  public static String hash(String token) {
    // Normalizes and hashes the input token using SHA-256 and Base64 encoding.
    String formattedToken = token.toLowerCase().strip();

    byte[] hash;
    try {
      hash = MessageDigest.getInstance("SHA-256").digest(formattedToken.getBytes(UTF_8));
    } catch (NoSuchAlgorithmException e) {
      throw new IllegalStateException("SHA-256 not supported", e);
    }

    return Base64.getEncoder().encodeToString(hash);
  }

  public static void printHash(String token) {
    // Calculates and prints the hash for the given token.
    System.out.printf("Hash: \"%s\"\t(Token: %s)\n", hash(token), token);
  }

  public static void main(String[] args) {
    // Executes hash calculations and prints results for sample tokens.
    printHash("test@gmail.com");
    printHash("+18005551212");
    printHash("John");
    printHash("Doe");
  }
  }

SQL

  /*
  Provides the hashing algorithm, as well as some valid hashes of sample data for testing.

  The following code uses Google Standard SQL and can be run on BigQuery to generate match tables from unhashed data.

  Sample hashes:

    - Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '+18005551212':   YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    - First name 'John':      ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    - Last name 'Doe':        eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=

  The unhashed input table schema is assumed to be:

  - Column name: UserID, Type: String
  - Column name: Email, Type: String
  - Column name: Phone, Type: String
  - Column name: FirstName, Type: String
  - Column name: LastName, Type: String
  - Column name: PostalCode, Type: String
  - Column name: CountryCode, Type: String
  */

  -- Creates a new table with Base64-encoded SHA-256 hashes of specified columns.
  CREATE TABLE `your_project_name.your_dataset_name.output_hashed_table_name`
  AS
  SELECT
    UserID,
    TO_BASE64(SHA256(LOWER(Email))) AS Email,
    TO_BASE64(SHA256(Phone)) AS Phone,
    TO_BASE64(SHA256(LOWER(FirstName))) AS FirstName,
    TO_BASE64(SHA256(LOWER(LastName))) AS LastName,
    PostalCode,
    CountryCode,
  FROM
    `your_project_name.your_dataset_name.input_unhashed_table_name`;

Połącz klucze

Niektóre kombinacje danych przekazywanych przez użytkowników są skuteczniejsze od innych. Poniżej znajdziesz listę różnych kombinacji danych przekazywanych przez użytkowników, uporządkowanych według względnej skuteczności. Jeśli używasz adresu, musisz podać: imię, nazwisko, kraj i kod pocztowy.

  1. E-mail, telefon, adres (najsilniejszy sygnał)
  2. Telefon, adres
  3. Adres e-mail, adres
  4. E-mail, telefon
  5. Adres
  6. Telefon
  7. Adres e-mail (najsłabszy)

Tworzenie tabeli dopasowań

  1. Kliknij add Utwórz > Raport.
  2. Wybierz szablon Generowanie tabeli odpowiedników dla chmury prywatnej. Opcjonalnie: jeśli dane nie są jeszcze zaszyfrowane, możesz wybrać Generowanie tabeli odpowiedników dla chmury prywatnej (z haszowaniem).
  3. Kliknij Edytuj zapytanie, a następnie zastąp nazwy parametrów nazwami kolumn, aby zapewnić prawidłowe aliasowanie.
  4. Kliknij Ustaw harmonogram, aby określić częstotliwość odświeżania tabeli dopasowań. Każde uruchomienie spowoduje zastąpienie bieżącej tabeli dopasowań.

Migracja istniejących połączeń

Dotychczasowe połączenia na karcie Połączenia zostaną przeniesione do zaktualizowanej wersji Połączeń, która jest wbudowana bezpośrednio w Centrum danych reklam. Zaktualizowane połączenia odczytują źródła i zapisują miejsca docelowe za pomocą konta usługi widocznego w sekcji Ustawienia > Szczegóły > Konto usługi (zwykle service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) zamiast starszych kont usługi Data Fusion, Dataproc i UPDM.

Wykonaj te działania zanim połączenia zostaną przeniesione:

  1. Przyznaj uprawnienia kontu usługi: przyznaj kontu usługi widocznemu w sekcji Ustawienia > Szczegóły > Konto usługi (zwykle service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) wymagane role źródłowe i docelowe (roles/bigquery.dataViewer, roles/storage.objectViewer i roles/bigquery.dataEditor w niedomyślnych docelowych zbiorach danych). Połączenia z nieczytelnymi, usuniętymi lub zmienionymi źródłami mogą nadal zostać przeniesione (zwłaszcza źródła Cloud Storage, które nie są sprawdzane podczas przenoszenia), ale uruchomienia będą się niepowodzeniem, dopóki nie przyznasz dostępu lub nie naprawisz źródła.
  2. Konwertowanie nieobsługiwanych połączeń: połączenia z tymi konfiguracjami nie zostaną przeniesione. Przekonwertuj je na obsługiwane połączenia z BigQuery lub Cloud Storage:
    • Inne źródła danych (Amazon S3, Snowflake, MySQL, PostgreSQL, Amazon Redshift, sFTP lub Salesforce): najpierw umieść dane w BigQuery lub Cloud Storage, a następnie utwórz połączenie z BigQuery lub Cloud Storage.
    • Nieobsługiwane mapowania pól lub typy danych: zaktualizuj lub utwórz ponownie połączenie, aby spełniało wymagania dotyczące pól i typów danych.
    • Ścieżki Cloud Storage z symbolami wieloznacznymi (* lub ?): zastąp identyfikator URI z symbolem wieloznacznym identyfikatorem URI pojedynczego pliku lub najpierw wczytaj pliki do BigQuery.
    • Zduplikowane nazwy połączeń: zmień nazwy zduplikowanych połączeń lub je usuń, aby każde połączenie na koncie miało unikalną nazwę.
  3. Usuń nieużywane połączenia: usuń nieaktualne połączenia, których już nie potrzebujesz.

Dane dopasowane do zapytania

Wykonywanie zapytań dotyczących tabel odpowiedników

Gdy tabele odpowiedników zawierają wystarczającą ilość danych, aby spełnić wymagania mechanizmów kontroli prywatności, możesz wykonywać zapytania dotyczące tych tabel.

Pierwotna tabela danych własnych jest reprezentowana przez my_data. Obejmuje to zarówno informacje umożliwiające identyfikację, jak i inne dane. Korzystanie z pierwotnej tabeli może poprawić jakość raportów, ponieważ zawiera ona więcej statystyk, ponieważ w porównaniu z tabelą odpowiedników reprezentuje wszystkie dane własne w zakresie.

Każdej tabeli w schemacie Centrum danych reklam, która zawiera pole user_id, towarzyszy tabela odpowiedników. Na przykład w przypadku tabeli adh.google_ads_impressions Centrum danych reklam generuje też tabelę odpowiedników o nazwie adh.google_ads_impressions_updm, która zawiera Twoje identyfikatory użytkowników. W przypadku tabel sieciowych odseparowanych zgodnie z zasadami tworzone są osobne tabele odpowiedników. Na przykład w przypadku tabeli adh.google_ads_impressions_policy_isolated_network Centrum danych reklam generuje też tabelę odpowiedników o nazwie adh.google_ads_impressions_policy_isolated_network_updm, która zawiera Twoje identyfikatory użytkowników.

Te tabele obejmują podzbiór użytkowników dostępnych w pierwotnych tabelach dopasowanych do identyfikatorów user_id. Jeśli na przykład pierwotna tabela zawiera dane dotyczące użytkowników A i B, ale dopasowane zostanie tylko konto użytkownika A, użytkownik B nie znajdzie się w tabeli odpowiedników.

Tabele odpowiedników zawierają dodatkową kolumnę o nazwie customer_data_user_id, która przechowuje identyfikator użytkownika w postaci bajtów.

Podczas tworzenia zapytań należy zwracać uwagę na typ pola. Operatory porównania SQL wymagają, aby porównywane literały były tego samego typu. Ostrzeżenie: w zależności od sposobu, w jaki w tabeli danych własnych przechowywane są dane (user_id), przed przystąpieniem do dopasowywania danych może być konieczne zakodowanie wartości w tabeli. Aby zapewnić prawidłowe dopasowanie, musisz przeformatować klucz łączenia na bajty:

JOIN ON
  adh.google_ads_impressions_updm.customer_data_user_id = CAST(my_data.user_id AS BYTES)

Poza tym porównania ciągów znaków w języku SQL uwzględniają wielkość liter, więc dokładne porównywanie ciągów znaków może wymagać ich zakodowania po obu stronach porównania.

Przykładowe zapytania

Zliczanie dopasowanych użytkowników

To zapytanie zlicza liczbę dopasowanych użytkowników w tabeli wyświetleń reklam Google Ads.

/* Count matched users in Google Ads impressions table */

SELECT COUNT(DISTINCT user_id)
FROM adh.google_ads_impressions_updm

Obliczanie współczynnika dopasowania

Nie wszyscy użytkownicy kwalifikują się do dopasowania. Na przykład wylogowani użytkownicy, dzieci i użytkownicy, którzy nie wyrazili zgody, nie są dopasowywani za pomocą UPDM. Aby dokładniej obliczać współczynniki dopasowania danych własnych i przekazywanych przez użytkowników, możesz używać pola is_updm_eligible. Pamiętaj, że pole is_updm_eligible jest dostępne od 1 października 2024 r. Nie możesz używać tego pola do obliczania współczynników dopasowania przed tą datą.

/* Calculate the UPDM match rate */

CREATE TEMP TABLE total_events OPTIONS(privacy_checked_export=TRUE) AS
SELECT
  customer_id,
  COUNT(*) AS n
FROM adh.google_ads_impressions
WHERE is_updm_eligible
GROUP BY 1;

CREATE TEMP TABLE matched_events OPTIONS(privacy_checked_export=TRUE) AS
SELECT
  customer_id,
  COUNT(*) AS n
FROM adh.google_ads_impressions_updm
GROUP BY 1;

SELECT
  customer_id,
  SAFE_DIVIDE(matched_events.n, total_events.n) AS match_rate
FROM total_events
LEFT JOIN matched_events
  USING (customer_id)

Łączenie danych własnych i danych reklam Google Ads

To zapytanie pokazuje, jak połączyć dane własne z danymi reklam Google Ads:

/* Join first-party data with Google Ads data. The customer_data_user_id field
contains your ID as BYTES. You need to cast your join key into BYTES for
successful matches. */

SELECT
  inventory_type,
  COUNT(*) AS impressions
FROM
  adh.yt_reserve_impressions_updm AS google_data_imp
LEFT JOIN
  `my_data`
ON
  google_data_imp.customer_data_user_id = CAST(my_data.user_id AS BYTES)
GROUP BY
  inventory_type

UPDM – najczęstsze pytania

Listę najczęstszych pytań dotyczących UPDM znajdziesz w tym artykule.