Correlación de datos proporcionados por el usuario

La correlación de datos proporcionados por el usuario (UPDM) une los datos de origen que recopilaste sobre un usuario (como la información proveniente de tus sitios web, apps o tiendas físicas) con la actividad que se registra en los datos de anuncios de Google para ese mismo usuario después de que accede a su cuenta, incluidos los datos de las propiedades de Google. Esto incluye los datos comprados a través de los productos de Google Marketing Platform (GMP), por ejemplo, YouTube comprado con Display & Video 360. No se admiten otros productos de GMP que no sean propiedad de Google ni estén operados por Google.

Para poder utilizar la correlación de datos proporcionados por el usuario, el evento de anuncio debe estar vinculado a un usuario que haya accedido a su cuenta y figure en los datos de anuncios de Google.

En este documento, se describe la función de correlación de datos proporcionados por el usuario y se proporcionan instrucciones para configurarla y usarla.

Descripción general de Private Cloud Match

Para obtener estadísticas valiosas sobre la publicidad, suele ser necesario unir datos de varias fuentes. Crear tu propia solución para este problema de canalización de datos requiere una inversión significativa de tiempo y de ingeniería. Private Cloud Match en el Centro de Datos de Anuncios optimiza este proceso, ya que proporciona una plantilla de consulta del Centro de Datos de Anuncios para crear una tabla de coincidencias en BigQuery que, luego, se puede usar en tus consultas del Centro de Datos de Anuncios para correlacionar tus datos de anuncios con tus datos de origen. Enriquecer tus consultas con datos de origen puede brindar experiencias del cliente más completas y es más resistente a los cambios en el seguimiento de anuncios en toda la industria.

Debido a que la correlación de datos proporcionados por el usuario solo está disponible en el inventario administrado y propiedad de Google para los usuarios que accedieron a sus cuentas, no se verá afectada por la próxima baja de las cookies de terceros. Como es más resistente a los cambios en el sector que los datos de terceros, puede proporcionar estadísticas más detalladas, lo que puede generar una mayor participación de los clientes.

Resumen del proceso

  1. Configuración de la transferencia y correlación de datos
    • Tú Asegúrate de que tus datos propios se encuentren en BigQuery y de que tu cuenta de servicio tenga acceso de lectura a ellos. Consulta Configura la transferencia de datos.
  2. Transferencia y correlación de datos de origen
    • Tú aplicas formato a tus datos propios y los subes a tu conjunto de datos de BigQuery.
    • Tú inicias una solicitud de coincidencia de datos creando una conexión denube privada Private Cloud Match analysis query y estableciendo una programación.
    • Google une los datos entre tu proyecto y los datos de Google que contienen el ID de usuario de Google y los datos proporcionados por el usuario con codificación hash para crear y actualizar las tablas de coincidencias.
    • Consulta Transfiere datos propios.
  3. Consultas continuas en el Centro de Datos de Anuncios, basadas en datos coincidentes
    • Tú ejecutas consultas en las tablas de coincidencias de la misma manera que ejecutas consultas normales en el Centro de Datos de Anuncios. Consulta Datos de coincidencias de consultas.

Más información sobre los requisitos de privacidad

Recopilación de datos de los clientes

Cuando utilices la correlación de datos proporcionados por el usuario, debes subir datos propios. Esta podría ser información que recopilaste de tus sitios web, apps, tiendas físicas o cualquier información que un cliente haya compartido contigo directamente.

Obligaciones:

  • Asegúrate de que tu política de privacidad divulgue que compartes los datos de clientes con terceros que realizan servicios en tu nombre y que obtienes el consentimiento para compartirlos cuando así lo exijan los requisitos legales.
  • Debe utilizar solo la interfaz o la API de Google aprobadas para subir los datos de clientes.
  • Debe satisfacer todas las leyes y reglamentaciones aplicables, incluido cualquier código autorregulatorio o de la industria que se pudiera aplicar.

Confirmación del consentimiento de origen

Para asegurarte de que puedes usar tus datos de origen en el Centro de Datos de Anuncios, debes confirmar que obtuviste el consentimiento adecuado para compartir datos de los usuarios finales del EEE con Google según la Política de Consentimiento de Usuarios de la UE y la política del Centro de Datos de Anuncios. Este requisito se aplica a cada cuenta del Centro de Datos de Anuncios y se debe actualizar cada vez que subas datos propios nuevos. Cualquier usuario puede realizar esta confirmación en nombre de toda la cuenta.

Ten en cuenta que las mismas reglas de consulta de servicios de Google que se aplican a las consultas de análisis también se aplican a las consultas de UPDM. Por ejemplo, no puedes ejecutar consultas entre servicios sobre usuarios del EEE cuando creas una tabla de coincidencias.

Para obtener información sobre cómo confirmar el consentimiento en el Centro de Datos de Anuncios, consulta los requisitos de consentimiento para el Espacio Económico Europeo.

Tamaño de los datos

Para proteger la privacidad del usuario final, la correlación de datos proporcionados por el usuario aplica estos requisitos relacionados con el tamaño de tus datos:

  • Debes subir, al menos, 1,000 registros en tu lista de usuarios.

Configura la transferencia de datos

Antes de comenzar, asegúrate de lo siguiente:

  • Tus datos propios deben estar en BigQuery. Si tienes un perímetro de VPC-SC, estos datos propios deben estar ubicados dentro de tu VPC-SC.
  • Tu cuenta de servicio del Centro de Datos de Anuncios debe tener acceso de lectura a los datos propios.
  • Tus datos propios deben tener el formato correcto y se debe generar un hash para ellos de forma adecuada. Consulta la siguiente sección para obtener más detalles.

Más allá de eso, Private Cloud Match no tiene un proceso de incorporación adicional. Si puedes ejecutar una consulta de análisis, puedes ejecutar una consulta de Private Cloud Match.

Transfiere y correlaciona datos propios

Permisos de origen y requisitos de conexión

Las conexiones del Centro de Datos de Anuncios usan la cuenta de servicio que se muestra en Configuración > Detalles > Cuenta de servicio (por lo general, service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com). Otórgale estos roles:

  • Fuente de BigQuery: roles/bigquery.dataViewer (Visualizador de datos de BigQuery) en el conjunto de datos o la tabla de origen.
  • Fuente de Cloud Storage: roles/storage.objectViewer (Visualizador de objetos de almacenamiento) en el bucket o el objeto de origen.
  • Destino de importación de datos propios: roles/bigquery.dataEditor (Editor de datos de BigQuery) en el conjunto de datos de destino, si la tabla no está en tu conjunto de datos predeterminado.

Requisitos de campos y tipos de datos

  1. Correlación de datos proporcionados por el usuario (UPDM):
    • Asigna user_id y, al menos, un campo de IIP (email, phone o la dirección completa: first_name, last_name, country, zip_code).
    • user_id, country y zip_code: STRING en texto sin formato (sin codificación hash). Para una fuente de BigQuery, estas columnas ya deben ser STRING; otros tipos (por ejemplo, INT64) fallan cuando se crea la conexión. Connections convierte user_id en BYTES en la tabla de coincidencias. country debe ser un código ISO 3166-1 alfa-2 de 2 letras.
    • email, phone, first_name y last_name: HASH, ya deben tener un hash SHA-256 y estar codificados en Base64 (también se acepta un valor SHA-256 hexadecimal de 64 caracteres). Connections no genera un hash de los datos. Los valores de texto sin formato no se detectan cuando se crea la conexión; cada ejecución falla con ... must be encoded using TO_BASE64(SHA256(...)).
    • Las conexiones de correlación de datos proporcionados por el usuario no tienen una tabla de destino. Todas las consultas de una cuenta y las consultas de UPDM que se ejecutan de forma manual escriben en los mismos datos de coincidencias, por lo que cada ejecución reemplaza a la anterior. Una conexión de UPDM por cuenta es suficiente.
    • Consulta Formatea los datos para la entrada para conocer las reglas por campo.
  2. Importación de datos propios:
    • Usa solo los tipos de datos que se ofrecen en la IU: INTEGER, STRING, HASH, DOUBLE, DATE y TIMESTAMP. No se admiten otros tipos de BigQuery.
    • Fuente de BigQuery: No se aplica el tipo asignado; cada columna de destino conserva el tipo de su columna de origen.
    • Fuente de Cloud Storage: Las columnas se leen como STRING y se convierten en el tipo asignado. Los valores que no se pueden convertir se transforman en NULL sin que falle la ejecución.
    • Cada ejecución reemplaza toda la tabla de destino, no se agrega. Si la fuente no tiene filas, el destino se vacía. No uses la tabla de origen ni una tabla cuyos datos debas conservar como destino.

Requisitos de las columnas del archivo CSV de Cloud Storage

  • Incluye una fila de encabezado. Se omite la primera línea y no se usan los nombres de sus columnas.
  • El archivo debe contener exactamente las columnas de origen asignadas, ni más ni menos. Las columnas adicionales hacen que falle la ejecución.
  • Importación de datos propios: Las columnas deben estar en el mismo orden que las asignaciones de campos.
  • Correlación de datos proporcionados por el usuario: Las columnas deben estar en este orden, conservando solo los campos que asignes: user_id, email, phone, first_name, last_name, country, zip_code. No importa el orden de las filas de asignación.
  • No se detecta un orden de columnas diferente: los valores se cargan en los campos incorrectos (o los porcentajes de coincidencias disminuyen) sin que se produzca un error.

Fuentes de datos compatibles y límites de conexión

  • Fuentes de datos: Solo se admiten las fuentes de BigQuery y Cloud Storage.
  • Nombres de tablas de BigQuery: Las tablas de BigQuery de origen y destino necesitan el nombre completo de project.dataset.table.
  • Rutas de acceso de archivos de Cloud Storage: Proporciona un solo URI de archivo (como gs://bucket/path/file.csv). No se admiten las rutas de acceso con comodines con * o ?.
  • Nombres de conexión: Cada conexión de una cuenta debe tener un nombre único.

Asigna un formato a los datos para la entrada

Tus datos deben cumplir con estos requisitos de formato para que coincidan correctamente:

  • Cuando se indique en las siguientes descripciones de los campos de entrada, debes subir los datos con el algoritmo hash SHA256.
  • UPDM admite la codificación Base64. Consulta TO_BASE64.
  • Los campos de entrada deben tener el formato de cadenas. Por ejemplo, si usas la función hash SHA256 de BigQuery, utiliza la siguiente transformación: TO_BASE64(SHA256(user_data)).

ID de usuario

  • Tipo de datos: BYTES
  • Hashing: Ninguno

Correo electrónico

  • Quita los espacios en blanco iniciales y finales.
  • Escribe todos los caracteres en minúscula.
  • Incluye un nombre de dominio para todas las direcciones de correo electrónico, como gmail.com o hotmail.co.jp.
  • Quita los acentos, por ejemplo, cambia è, é, ê o ë por e.
  • Quita todos los puntos (.) que anteceden al nombre de dominio en las direcciones de correo electrónico gmail.com y googlemail.com.
  • Hashing: SHA256 codificado en Base64

Válido: TO_BASE64(SHA256("jeffersonloveshiking@gmail.com"))

No válido: TO_BASE64(SHA256("JéffersonLôvesHiking@gmail.com"))

Teléfono

  • Quitar espacios en blanco
  • Utiliza el formato E.164. Por ejemplo, para EE.UU.: +14155552671; para el Reino Unido: +442071838750
  • Quita todos los caracteres especiales, excepto el signo "+" que antecede al código de país.
  • Hashing: SHA256 codificado en Base64

Válido: TO_BASE64(SHA256("+18005550101"))

No válido: TO_BASE64(SHA256("(800) 555-0101"))

Nombre

  • Quitar espacios en blanco
  • Escribe todos los caracteres en minúscula.
  • Quita todos los prefijos, por ejemplo, Sra., Sr., Sra., Dra.
  • No quites los acentos, por ejemplo, è, é, ê o ë.
  • Hashing: SHA256 codificado en Base64

Válido: TO_BASE64(SHA256("daní"))

No válido: TO_BASE64(SHA256("Daní"))

Apellido

  • Quitar espacios en blanco
  • Escribe todos los caracteres en minúscula.
  • Quita todos los sufijos, por ejemplo, Jr., Sr., 2º, 3º, II, III, PHD, MD
  • No quites los acentos, por ejemplo, è, é, ê o ë.
  • Hashing: SHA256 codificado en Base64

Válido: TO_BASE64(SHA256("délacruz"))

No válido: TO_BASE64(SHA256("dé la Cruz, Jr."))

País

  • Incluye el código del país, aun cuando todos los datos de tus clientes correspondan al mismo país.
  • No generes hash para los datos de país
  • Usa códigos de país ISO 3166-1 alfa-2
  • Hashing: Ninguno

Válido: US

No válido: United States of America o USA

Código postal

  • No generes hash para los datos de código postal
  • Se permite el uso tanto de códigos postales estadounidenses como internacionales.
  • Para EE.UU.:
    • Se permite el uso de códigos de 5 dígitos, por ejemplo, 94043.
    • También se permite el uso de códigos de 5 dígitos seguidos de una extensión de 4 dígitos, por ejemplo, 94043-1351 o 940431351.
  • Para todos los demás países:
    • No se necesita formato (no es necesario usar minúsculas ni quitar espacios y caracteres especiales)
    • Omita las extensiones de código postal.
  • Hashing: Ninguno

Validación de hash y codificación de datos

Puedes usar las siguientes secuencias de comandos de validación de hash para asegurarte de que tus datos tengan el formato correcto.

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`;

Claves de unión

Algunas combinaciones de datos proporcionados por el usuario son más eficaces que otras. A continuación, se muestra una lista de diferentes combinaciones de datos proporcionados por el usuario, clasificadas por su eficacia relativa. Si usas una dirección, debes incluir el nombre, el apellido, el país y el código postal.

  1. Correo electrónico, teléfono y dirección (la más sólida)
  2. Teléfono, dirección
  3. Correo electrónico, dirección
  4. Correo electrónico, teléfono
  5. Dirección
  6. Teléfono
  7. Correo electrónico (el más débil)

Crea una tabla de coincidencias

  1. Haz clic en add Crear > Informe.
  2. Selecciona la plantilla Private cloud match table generation. Opcional: Puedes seleccionar Generación de tablas de coincidencias de nube privada (con codificación hash) si tus datos aún no tienen codificación hash.
  3. Haz clic en Editar consulta y, luego, reemplaza los nombres de los parámetros por los nombres de tus columnas para proporcionar un alias adecuado.
  4. Haz clic en Establecer programa para establecer la frecuencia con la que deseas que se actualice tu tabla de coincidencias. Cada ejecución reemplazará la tabla de coincidencias actual.

Migra conexiones existentes

Las conexiones existentes en la pestaña Conexiones se trasladarán a una experiencia de Conexiones actualizada integrada directamente en el Centro de Datos de Anuncios. Las conexiones actualizadas leen fuentes y escriben destinos con la cuenta de servicio que se muestra en Configuración > Detalles > Cuenta de servicio (por lo general, service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) en lugar de las cuentas de servicio heredadas de Data Fusion, Dataproc y UPDM.

Completa estos elementos de acción antes de que se muevan tus conexiones:

  1. Otorga permisos a la cuenta de servicio: Otorga a la cuenta de servicio que se muestra en Configuración > Detalles > Cuenta de servicio (por lo general, service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) los roles de origen y destino necesarios (roles/bigquery.dataViewer, roles/storage.objectViewer y roles/bigquery.dataEditor en conjuntos de datos de destino no predeterminados). Las conexiones con fuentes ilegibles, borradas o modificadas se pueden mover (en especial, las fuentes de Cloud Storage, que no se validan en el momento de la transferencia), pero las ejecuciones fallan hasta que otorgues acceso o corrijas la fuente.
  2. Convierte las conexiones no compatibles: No se migrarán las conexiones con las siguientes configuraciones. Conviértelas en conexiones compatibles con BigQuery o Cloud Storage:
    • Otras fuentes de datos (Amazon S3, Snowflake, MySQL, PostgreSQL, Amazon Redshift, sFTP o Salesforce): Primero, almacena los datos en BigQuery o Cloud Storage y, luego, crea una conexión de BigQuery o Cloud Storage.
    • Asignaciones de campos o tipos de datos no compatibles: Actualiza o vuelve a crear la conexión para cumplir con los requisitos de campos y tipos de datos.
    • Rutas de acceso con comodines de Cloud Storage (* o ?): Reemplaza el URI con comodín por un URI de archivo único o carga los archivos en BigQuery primero.
    • Nombres de conexión duplicados: Cambia el nombre de las conexiones duplicadas o bórralas para que cada conexión de la cuenta tenga un nombre único.
  3. Borra las conexiones sin usar: Borra las conexiones obsoletas que ya no necesites.

Datos de coincidencias de consultas

Consulta las tablas de coincidencias

Cuando tus tablas de coincidencias contengan suficientes datos para satisfacer las verificaciones de privacidad, podrás ejecutar consultas en ellas.

La tabla original de los datos propios (1PD) se representa con my_data. Esto incluye tanto la información de identificación personal (PII) como los datos que no son de identificación personal. Usar la tabla original puede mejorar tus informes con más estadísticas, ya que representa todos los datos propios dentro del alcance, en comparación con una tabla de coincidencias.

Cada tabla del esquema del Centro de Datos de Anuncios que contiene un campo user_id está acompañada por una tabla de coincidencias. Por ejemplo, para la tabla adh.google_ads_impressions, el Centro de Datos de Anuncios también genera una tabla de coincidencias llamada adh.google_ads_impressions_updm que contiene tus IDs de usuario. Se crean tablas de coincidencias independientes para las tablas de red aisladas por políticas. Por ejemplo, para la tabla adh.google_ads_impressions_policy_isolated_network, el Centro de Datos de Anuncios también genera una tabla de coincidencias llamada adh.google_ads_impressions_policy_isolated_network_updm que contiene tus IDs de usuario.

Estas tablas contienen un subconjunto de los usuarios disponibles en las tablas originales, en las que hay una coincidencia en el user_id. Por ejemplo, si la tabla original contiene datos del usuario A y del usuario B, pero solo se encuentra una coincidencia para el usuario A, el usuario B no estará en la tabla de coincidencias.

Las tablas de coincidencias contienen una columna adicional llamada customer_data_user_id, que almacena el identificador de usuario como BYTES.

Es importante tener en cuenta el tipo de campo cuando escribes tus consultas. Los operadores de comparación de SQL esperan que los literales que comparas sean del mismo tipo. Según cómo se almacene el user_id en tu tabla de datos de origen, es posible que debas codificar los valores de la tabla antes de correlacionar los datos. Para que las coincidencias sean exitosas, debes convertir tu clave de unión en BYTES:

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

Además, las comparaciones de cadenas en SQL distinguen mayúsculas de minúsculas, por lo que es posible que debas codificar las cadenas en ambos lados de la comparación para asegurarte de que se puedan comparar con precisión.

Consultas de muestra

Recuento de usuarios correlacionados

Esta consulta cuenta la cantidad de usuarios que coinciden en tu tabla de impresiones de Google Ads.

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

SELECT COUNT(DISTINCT user_id)
FROM adh.google_ads_impressions_updm

Cómo calcular el porcentaje de coincidencias

No todos los usuarios son aptos para la coincidencia. Por ejemplo, los usuarios que no accedieron a sus cuentas, los niños y los usuarios que no dieron su consentimiento no se correlacionan a través de UPDM. Puedes usar el campo is_updm_eligible para calcular porcentajes de coincidencias de UPDM más precisos. Ten en cuenta que el campo is_updm_eligible está disponible desde el 1 de octubre de 2024. No puedes usar este campo para calcular los porcentajes de coincidencias antes de esa fecha.

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

Une los datos de origen y los datos de anuncios de Google

En esta consulta, se muestra cómo unir datos de origen con datos de 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

Preguntas frecuentes sobre el UPDM

Para obtener una lista de preguntas frecuentes relacionadas con la UPDM, consulta las Preguntas frecuentes sobre la UPDM.