Mise en correspondance des données fournies par l'utilisateur

La mise en correspondance des données fournies par l'utilisateur (MCDFU) associe les données first party que vous avez collectées sur un utilisateur, telles que les informations issues de vos sites Web, applications ou magasins physiques, à l'activité de ce même utilisateur (lorsqu'il est connecté) dans toutes les données relatives aux annonces Google, y compris les données détenues et gérées par Google. Cela inclut les données achetées via les produits Google Marketing Platform (GMP), par exemple YouTube acheté via Display & Video 360. Les autres produits GMP qui ne sont pas détenus et exploités par Google ne sont pas compatibles.

Pour être éligible à la mise en correspondance des données fournies par l'utilisateur, l'événement d'annonce doit être associé à un utilisateur connecté dans les données relatives aux annonces Google.

Ce document décrit la fonctionnalité de mise en correspondance des données fournies par l'utilisateur et fournit des conseils sur sa configuration et son utilisation.

Onglet Connexions de Private Cloud Match

Présentation de la mise en correspondance dans un cloud privé

Pour obtenir des insights publicitaires utiles, il est souvent nécessaire de regrouper des données provenant de plusieurs sources. Créer votre propre solution pour résoudre ce problème de pipeline de données nécessite un investissement important en temps et en ingénierie. La mise en correspondance Private Cloud dans Ads Data Hub simplifie ce processus en fournissant un modèle de requête Ads Data Hub pour créer une table de correspondance dans BigQuery. Celle-ci peut ensuite être utilisée dans vos requêtes Ads Data Hub pour mettre en correspondance vos données relatives aux annonces avec vos données first party. En enrichissant vos requêtes avec des données first party, vous pouvez proposer des expériences client plus riches et mieux vous adapter aux changements dans l'ensemble du secteur concernant le suivi des annonces.

La mise en correspondance des données fournies par l'utilisateur n'est disponible que sur l'inventaire détenu et géré par Google, pour les utilisateurs connectés. Elle n'est donc pas affectée par l'abandon à venir des cookies tiers. Comme elles résistent mieux aux évolutions du secteur que les données tierces, elles peuvent fournir des insights plus détaillés, ce qui peut se traduire par un meilleur engagement client.

Résumé du processus

1. Configuration de l'ingestion de données et de la mise en correspondance
   • Vous : assurez-vous que vos données first party se trouvent dans BigQuery et que votre compte de service dispose d'un accès en lecture à ces données. Consultez Configurer l'ingestion de données.
2. Ingestion et mise en correspondance des données first party
   • Vous mettez en forme et importez vos données first party dans votre ensemble de données BigQuery.
   • Vous lancez une requête de mise en correspondance des données en créant unerequête d'analyse Private Cloud Match et en définissant une planification.
   • Google associe les données de votre projet à celles appartenant à Google qui contiennent l'ID utilisateur Google et les données hachées fournies par l'utilisateur pour créer et mettre à jour les tables de correspondance.
   • Consultez Ingérer des données first party.
3. Requêtes en cours dans Ads Data Hub, basées sur les données mises en correspondance
   • Vous exécutez des requêtes sur les tables des correspondances de la même manière que vous exécutez des requêtes standards dans Ads Data Hub. Consultez Interroger les données correspondantes.

En savoir plus sur les exigences de confidentialité

Collecte des données client

Lorsque vous utilisez la mise en correspondance des données fournies par l'utilisateur, vous devez importer des données first party. Il peut s'agir d'informations que vous avez collectées à partir de vos sites Web, applications ou magasins physiques, ou de toute information qu'un client a partagée directement avec vous.

Vous devez respecter les points suivants :

• Vos règles de confidentialité doivent indiquer que vous partagez les données client avec des tiers pour qu'ils fournissent des services en votre nom. Vous devez également obtenir le consentement des utilisateurs concernés lorsque la législation l'impose.
• Vous ne devez utiliser que l'interface ou l'API approuvée de Google pour importer des données client.
• Respectez l'ensemble des lois et règlements applicables, y compris les consignes d'autorégulation ou normes sectorielles qui peuvent s'appliquer.

Confirmer l'obtention du consentement pour les données first party

Avertissement : Si vous ne confirmez pas l'obtention du consentement ou refusez de la confirmer, vous ne pourrez pas utiliser vos données first party dans Ads Data Hub. Par exemple, vous ne pourrez pas importer de nouvelles données first party ni joindre des données first party existantes à vos données associées relatives aux annonces. Tous les cas d'utilisation, tels que la mise en correspondance des données fournies par l'utilisateur et l'activation d'audience à l'aide des données first party, sont indisponibles. Cela inclut les importations planifiées de données first party.

Pour vous assurer de pouvoir utiliser vos données first party dans Ads Data Hub, vous devez confirmer avoir obtenu le consentement approprié pour transmettre à Google les données des utilisateurs finaux dans l'EEE conformément aux Règles relatives au consentement de l'utilisateur dans l'UE et aux Règles Ads Data Hub. Cette exigence s'applique à chaque compte Ads Data Hub et vous devez réeffectuer cette confirmation chaque fois que vous importez de nouvelles données first party. Tout utilisateur peut effectuer cette confirmation au nom de l'intégralité du compte.

Notez que les règles d'interrogation des services Google qui s'appliquent aux requêtes d'analyse s'appliquent aussi aux requêtes UPDM. Par exemple, vous ne pouvez pas exécuter de requêtes multiservices sur des utilisateurs dans l'EEE lorsque vous créez une table des correspondances.

Pour découvrir comment accuser réception du consentement dans Ads Data Hub, consultez Exigences concernant le consentement pour l'Espace économique européen.

Taille des données

Pour protéger la confidentialité des utilisateurs finaux, la mise en correspondance des données fournies par l'utilisateur applique les exigences suivantes concernant la taille de vos données :

• Vous devez importer au moins 1 000 enregistrements dans votre liste d'utilisateurs.

---

Configurer l'ingestion de données

Avant de commencer, vérifiez les points suivants :

• Vos données first party doivent se trouver dans BigQuery. Si vous disposez d'un périmètre VPC-SC, ces données first party doivent se trouver dans votre VPC-SC.
• Votre compte de service Ads Data Hub doit disposer d'un accès en lecture aux données first party.
• Vos données first party doivent être correctement formatées et hachées. Pour en savoir plus, consultez la section suivante.

Au-delà de cela, Private Cloud Match ne nécessite pas de processus d'intégration supplémentaire. Si vous pouvez exécuter une requête d'analyse, vous pouvez exécuter une requête Private Cloud Match.

Ingérer et mettre en correspondance des données first party

Remarque : Les connexions existantes de l'onglet Connexions sont transférées vers une interface Connexions améliorée. Accordez au compte de service affiché sous Paramètres > Détails > Compte de service (généralement service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) les rôles source et de destination requis, et convertissez les connexions qui utilisent des sources de données non compatibles, des chemins d'accès Cloud Storage avec des caractères génériques ou des types de champs non compatibles en connexions BigQuery ou Cloud Storage compatibles avant de les déplacer. Pour en savoir plus, consultez Migrer des connexions existantes.

Autorisations de la source et exigences de connexion

Les connexions Ads Data Hub utilisent le compte de service indiqué sous Paramètres > Détails > Compte de service (généralement service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com). Attribuez-lui les rôles suivants :

• Source BigQuery : roles/bigquery.dataViewer (Lecteur de données BigQuery) sur l'ensemble de données ou la table source.
• Source Cloud Storage : roles/storage.objectViewer (Lecteur des objets Storage) sur le bucket ou l'objet source.
• Destination d'importation des données first party : roles/bigquery.dataEditor (Éditeur de données BigQuery) sur l'ensemble de données de destination, si la table ne se trouve pas dans votre ensemble de données par défaut.

Exigences concernant les champs et les types de données

1. Mise en correspondance des données fournies par l'utilisateur (UPDM) :
   • Mappez user_id et au moins un champ d'informations permettant d'identifier personnellement l'utilisateur (email, phone ou l'adresse complète : first_name, last_name, country, zip_code).
   • user_id, country et zip_code : STRING en texte brut (non haché). Pour une source BigQuery, ces colonnes doivent déjà être de type STRING. Les autres types (par exemple, INT64) échouent lors de la création de la connexion. Connections convertit user_id en BYTES dans la table de correspondance. country doit être un code ISO 3166-1 alpha-2 à deux lettres.
   • email, phone, first_name et last_name : HASH (doit déjà être haché en SHA-256 et encodé en Base64 ; une valeur SHA-256 hexadécimale de 64 caractères est également acceptée). Connections ne hache pas les données. Les valeurs en texte brut ne sont pas détectées lors de la création de la connexion. Chaque exécution échoue alors avec ... must be encoded using TO_BASE64(SHA256(...)).
   • Les connexions de mise en correspondance des données fournies par l'utilisateur n'ont pas de table de destination. Toutes les requêtes d'un compte et les requêtes MCDFU exécutées manuellement écrivent dans les mêmes données de correspondance. Chaque exécution remplace donc la précédente. Une seule connexion UPDM par compte suffit.
   • Consultez Formater les données pour l'entrée pour connaître les règles par champ.
2. Importation de données first party :
   • Utilisez uniquement les types de données proposés dans l'interface utilisateur : INTEGER, STRING, HASH, DOUBLE, DATE et TIMESTAMP. Les autres types BigQuery ne sont pas acceptés.
   • Source BigQuery : le type mappé n'est pas appliqué. Chaque colonne de destination conserve le type de sa colonne source.
   • Source Cloud Storage : les colonnes sont lues en tant que STRING et castées vers le type mappé. Les valeurs qui ne peuvent pas être converties deviennent NULL sans que l'exécution échoue.
   • Chaque exécution remplace l'intégralité de la table de destination. Elle n'ajoute pas de données. Si la source ne contient aucune ligne, la destination devient vide. N'utilisez pas la table source ni une table dont vous devez conserver les données comme destination.

Exigences concernant les colonnes CSV Cloud Storage

• Incluez une ligne d'en-tête. La première ligne est ignorée. Les noms de ses colonnes ne sont pas utilisés.
• Le fichier doit contenir exactement les colonnes sources mappées, ni plus ni moins. Les colonnes supplémentaires entraînent l'échec de l'exécution.
• Importation de données first party : les colonnes doivent être dans le même ordre que les mappages de champs.
• Mise en correspondance des données fournies par l'utilisateur : les colonnes doivent être dans cet ordre, en ne conservant que les champs que vous mappez : user_id, email, phone, first_name, last_name, country, zip_code. L'ordre des lignes de mappage n'a pas d'importance.
• Un ordre de colonnes différent n'est pas détecté : les valeurs sont chargées dans les mauvais champs (ou les taux de correspondance diminuent) sans erreur.

Sources de données compatibles et limites de connexion

• Sources de données : seules les sources BigQuery et Cloud Storage sont acceptées.
• Noms des tables BigQuery : les tables BigQuery source et de destination nécessitent le nom project.dataset.table complet.
• Chemins d'accès aux fichiers Cloud Storage : fournissez un seul URI de fichier (par exemple, gs://bucket/path/file.csv). Les chemins d'accès avec des caractères génériques tels que * ou ? ne sont pas acceptés.
• Noms des connexions : chaque connexion d'un compte doit avoir un nom unique.

Mettre en forme les données pour l'entrée

Vos données doivent respecter les exigences de mise en forme suivantes pour être correctement mises en correspondance :

• Lorsque cela est indiqué dans les descriptions des champs de saisie suivantes, vous devez effectuer l'importation à l'aide du hachage SHA256.
• UPDM est compatible avec l'encodage en base64. Consultez TO_BASE64.
• Les champs de saisie doivent être au format chaîne. Par exemple, si vous utilisez la fonction de hachage SHA256 de BigQuery, utilisez la transformation suivante : TO_BASE64(SHA256(user_data)).

ID utilisateur

• Type de données : BYTES
• Hachage : aucun

E-mail

• Supprimez les espaces blancs de début et de fin.
• N'utilisez que des minuscules.
• Incluez un nom de domaine pour chaque adresse e-mail (par exemple, gmail.com ou hotmail.co.jp).
• Supprimez les accents (par exemple, remplacez è, é, ê ou ë par e).
• Supprimez tous les points (.) qui précèdent le nom de domaine des adresses e-mail gmail.com et googlemail.com.
• Hachage : SHA256 encodé en base64

Valide : TO_BASE64(SHA256("[e-mail]"))

Non valide : TO_BASE64(SHA256("JéffersonLô[e-mail]"))

Téléphone

• Supprimer les espaces blancs
• Format E.164 (par exemple, [phone] pour les États-Unis, [phone] pour le Royaume-Uni)
• Supprimez tous les caractères spéciaux, à l'exception du signe "+" avant l'indicatif du pays.
• Hachage : SHA256 encodé en base64

Valide : TO_BASE64(SHA256("[phone]"))

Non valide : TO_BASE64(SHA256("[phone]"))

Prénom

• Supprimer les espaces blancs
• N'utilisez que des minuscules.
• Supprimez tous les préfixes, par exemple "Mme", M., Mme, Dr.
• Ne supprimez pas les accents (par exemple, è, é, ê ou ë).
• Hachage : SHA256 encodé en base64

Valide : TO_BASE64(SHA256("daní"))

Non valide : TO_BASE64(SHA256("Daní"))

Nom

• Supprimer les espaces blancs
• N'utilisez que des minuscules.
• Supprimez tous les suffixes, par exemple "Jr", Sr., 2nd, 3rd, II, III, PHD, MD
• Ne supprimez pas les accents (par exemple, è, é, ê ou ë).
• Hachage : SHA256 encodé en base64

Valide : TO_BASE64(SHA256("délacruz"))

Non valide : TO_BASE64(SHA256("dé la Cruz, Jr."))

Pays

• Incluez le code pays même si toutes vos données client proviennent du même pays.
• Ne hachez pas les données de pays.
• Utilisez les codes pays ISO 3166-1 alpha-2.
• Hachage : aucun

Valide : US

Non valide : United States of America ou USA

Code postal

• Ne hachez pas les données de code postal.
• Les codes postaux internationaux et ceux des États-Unis sont acceptés.
• Pour les États-Unis :
  • Les codes à cinq chiffres sont acceptés (par exemple, 94043).
  • Les codes à cinq chiffres suivis d'une extension de quatre chiffres sont aussi autorisés (par exemple, 94043-1351 ou 940431351).
• Pour tous les autres pays :
  • Aucune mise en forme n'est nécessaire (pas besoin de mettre en minuscules, ni de supprimer les espaces et les caractères spéciaux).
  • N'indiquez pas l'extension de code postal.
• Hachage : aucun

Validation du hachage et encodage des données

Vous pouvez utiliser les scripts de validation de hachage suivants pour vous assurer que vos données sont correctement formatées.

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 [e-mail]:
    // h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    hash('[e-mail]').then(result => console.log(result));

    // Expected hash for [phone]:
    // YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    hash('[phone]').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 '[e-mail]': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '[phone]':   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(
        '[e-mail]', expected='h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=')
    print_hash(
        '[phone]', 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 '[e-mail]': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '[phone]':   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("[e-mail]")
    PrintHash("[phone]")
    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 '[e-mail]': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
  *   <li>Phone '[phone]': 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("[e-mail]");
    printHash("[phone]");
    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 '[e-mail]': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '[phone]':   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`;

Clés de jointure

Certaines combinaisons de données fournies par l'utilisateur sont plus efficaces que d'autres. Voici une liste de différentes combinaisons de données fournies par l'utilisateur, classées par efficacité relative. Si vous utilisez une adresse, vous devez inclure le prénom, le nom, le pays et le code postal.

1. Adresse e-mail, numéro de téléphone, adresse (le plus efficace)
2. Téléphone, adresse
3. Adresse e-mail, adresse postale
4. E-mail, téléphone
5. Adresse
6. Téléphone
7. E-mail (le moins sécurisé)

Créer une table de correspondance

1. Cliquez sur add Créer > Rapport.
2. Sélectionnez le modèle Génération d'une table des correspondances dans un cloud privé. Facultatif : Vous pouvez sélectionner Génération d'une table des correspondances dans un cloud privé (avec hachage) si vos données ne sont pas déjà hachées.
3. Cliquez sur Modifier la requête, puis remplacez les noms des paramètres par les noms de vos colonnes pour fournir un alias approprié.
4. Cliquez sur Définir la programmation pour définir la fréquence d'actualisation de votre table de correspondance. Chaque exécution écrasera la table de correspondance actuelle.

Migrer des connexions existantes

Les connexions existantes de l'onglet Connexions sont déplacées vers une nouvelle interface Connexions intégrée directement à Ads Data Hub. Les connexions mises à jour lisent les sources et écrivent les destinations à l'aide du compte de service indiqué sous Paramètres > Détails > Compte de service (généralement service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) au lieu des anciens comptes de service Data Fusion, Dataproc et UPDM.

Effectuez ces actions avant le déplacement de vos connexions :

1. Accorder des autorisations au compte de service : accordez au compte de service indiqué sous Paramètres > Détails > Compte de service (généralement service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) les rôles source et de destination requis (roles/bigquery.dataViewer, roles/storage.objectViewer et roles/bigquery.dataEditor sur les ensembles de données de destination non définis par défaut). Les connexions dont les sources sont illisibles, supprimées ou modifiées peuvent toujours être déplacées (en particulier les sources Cloud Storage, qui ne sont pas validées au moment du déplacement), mais les exécutions échouent tant que vous n'accordez pas l'accès ou que vous ne corrigez pas la source.
2. Convertir les connexions non compatibles : les connexions présentant les configurations suivantes ne seront pas migrées. Convertissez-les en connexions BigQuery ou Cloud Storage compatibles :
   • Autres sources de données (Amazon S3, Snowflake, MySQL, PostgreSQL, Amazon Redshift, sFTP ou Salesforce) : préparez d'abord les données dans BigQuery ou Cloud Storage, puis créez une connexion BigQuery ou Cloud Storage.
   • Mappages de champs ou types de données non compatibles : mettez à jour ou recréez la connexion pour répondre aux exigences concernant les champs et les types de données.
   • Chemins d'accès avec caractères génériques Cloud Storage (* ou ?) : remplacez l'URI avec caractère générique par un URI de fichier unique ou chargez d'abord les fichiers dans BigQuery.
   • Noms de connexion en double : renommez ou supprimez les connexions en double afin que chaque connexion du compte ait un nom unique.
3. Supprimer les connexions inutilisées : supprimez les connexions obsolètes dont vous n'avez plus besoin.

Interroger les données correspondantes

Interroger les tables des correspondances

Lorsque vos tables de correspondance contiennent suffisamment de données pour satisfaire aux contrôles de confidentialité, vous êtes prêt à exécuter des requêtes sur les tables.

La table d'origine des données first party (1PD) est représentée par my_data. Cela inclut les informations permettant d'identifier personnellement l'utilisateur et les informations ne permettant pas d'identifier personnellement l'utilisateur. L'utilisation de la table d'origine peut améliorer vos rapports en fournissant plus d'insights, car elle représente toutes les données first party incluses dans le champ d'application, par rapport à une table des correspondances.

Chaque table du schéma Ads Data Hub contenant un champ user_id est accompagnée d'une table de correspondance. Par exemple, pour la table adh.google_ads_impressions, Ads Data Hub génère également une table des correspondances appelée adh.google_ads_impressions_updm, qui contient vos ID utilisateur. Des tables des correspondances distinctes sont créées pour les tables de réseau isolées conformément au règlement. Par exemple, pour la table adh.google_ads_impressions_policy_isolated_network, Ads Data Hub génère également une table des correspondances appelée adh.google_ads_impressions_policy_isolated_network_updm qui contient vos ID utilisateur.

Avertissement : En raison de la réglementation de l'UE, l'UPDM n'est plus disponible pour les tables non réseau isolées par des règles, telles que adh.google_ads_impressions_policy_isolated_youtube. Pour continuer à exécuter ces requêtes, supprimez _policy_isolated_youtube afin de limiter les résultats aux utilisateurs ayant donné leur consentement.

Ces tables incluent un sous-ensemble des utilisateurs disponibles dans les tables d'origine, où il existe une correspondance avec le user_id. Par exemple, si la table d'origine contient des données pour les utilisateurs A et B, mais que seul l'utilisateur A correspond, l'utilisateur B ne figurera pas dans la table des correspondances.

Les tables des correspondances contiennent une colonne supplémentaire appelée customer_data_user_id, qui stocke l'identifiant utilisateur sous la forme d'OCTETS.

Il est important de prendre en compte le type de champ lorsque vous rédigez vos requêtes. Les opérateurs de comparaison SQL s'attendent à ce que les littéraux que vous comparez soient du même type. Selon la manière dont le user_id est stocké dans votre table de données first party, vous devrez peut-être encoder les valeurs dans la table avant de faire correspondre les données. Vous devez caster votre clé de jointure en OCTETS pour que la mise en correspondance fonctionne :

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

De plus, les comparaisons de chaînes en SQL sont sensibles à la casse. Par conséquent, vous devrez peut-être encoder les chaînes des deux côtés pour pouvoir les comparer avec précision.

Remarque : Les comparaisons entre les octets et les chaînes encodent implicitement des octets en Base64.

Exemples de requêtes

Compter les utilisateurs correspondants

Cette requête compte le nombre d'utilisateurs mis en correspondance dans votre table d'impressions Google Ads.

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

SELECT COUNT(DISTINCT user_id)
FROM adh.google_ads_impressions_updm

Calculer le taux de correspondance

Tous les utilisateurs ne sont pas éligibles à la mise en correspondance. Par exemple, les utilisateurs non connectés, les enfants et les utilisateurs n'ayant pas donné leur consentement ne sont pas mis en correspondance via l'UPDM. Vous pouvez utiliser le champ is_updm_eligible pour calculer des taux de correspondance plus précis pour la MCDFU. Notez que le champ is_updm_eligible est disponible depuis le 1er octobre 2024. Vous ne pouvez pas utiliser ce champ pour calculer les taux de correspondance avant cette date.

/* 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)

Associer des données first party et Google Ads

Cette requête vous montre comment joindre des données first party à des données 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

Questions fréquentes sur le MCDFU

Pour consulter les questions fréquentes sur l'UPDM, consultez Questions fréquentes sur l'UPDM.