Resumen: Prepara tus datos fuente para maximizar las tasas de coincidencia entre los conjuntos de datos de los colaboradores y optimizar los resultados de la colaboración.
Acerca de la preparación de datos
La Plataforma de Colaboración de Datos (DCP) de AppsFlyer está diseñada para ingerir y procesar datos transaccionales a gran escala, datos a nivel de usuario o una combinación de ambos de varios colaboradores. Una vez ingeridos los datos, la DCP puede hacer coincidir usuarios entre conjuntos de datos mediante identificadores compartidos (por ejemplo, correo electrónico con hash o teléfono con hash) y habilitar flujos de trabajo de colaboración basados en esos datos.
En este artículo se explica lo siguiente:
- Los tipos de datos que la DCP puede procesar (transaccionales, a nivel de usuario o una combinación de ambos)
- Cómo estructurar los datos para maximizar las tasas de coincidencia entre colaboradores y lograr una coincidencia óptima por parte de los partners de activación
- Qué estructuras de datos se recomiendan y cuáles no
- Cómo gestionar identificadores con varios valores al usar archivos CSV
Comprender los tipos de datos
La mayoría de las fuentes utilizadas en las colaboraciones incluyen uno o ambos de los siguientes tipos de datos:
-
Datos a nivel de usuario (identidad)
- Objetivo: representar a cada usuario y los identificadores utilizados para la coincidencia
- Estructura recomendada: una fila por usuario
-
Datos transaccionales (eventos)
- Objetivo: representar las acciones de los usuarios (compras, visitas, transacciones)
- Estructura habitual: varias filas por usuario (porque un usuario puede tener muchas transacciones)
Directrices para estructurar los datos
En esta sección se describen las directrices y mejores prácticas para estructurar datos en la DCP.
Estructuras de datos recomendadas
Para estructurar tus datos fuente para una ingestión óptima y maximizar los resultados en la DCP:
- Asegúrate de que cumple los requisitos de formato de los datos fuente.
- Para obtener los mejores resultados, estructura los datos de identidad con una fila por usuario e incluye todos los identificadores disponibles de ese usuario. Consulta Estructuras de identificadores recomendadas.
- Si los usuarios tienen varias direcciones de correo electrónico o números de teléfono, usa formatos basados en matrices (como Parquet, BigQuery o Snowflake).
- Comprueba que se sigan las directrices de Hashing.
- Para los conjuntos de datos transaccionales (y otros tipos de datos, cuando corresponda), usa la herramienta DCP Data View para crear un subconjunto de tus datos orientado al negocio, seguro en términos de privacidad y optimizado para la colaboración, y compártelo en lugar de las tablas sin procesar. Por qué se recomiendan las Data Views.
Aunque se pueden usar otras estructuras, puede que no sean las más adecuadas para sacar el máximo partido a DCP. Consulta Estructuras de datos no recomendadas.
Estructuras de identificadores recomendadas
Para maximizar las tasas de coincidencia, se recomienda enviar los datos de identidad a nivel de usuario en una sola fila por usuario siempre que sea posible e incluir todos los identificadores disponibles en una estructura que refleje con precisión cómo se representa a los usuarios.
Opción 1: Una fila por usuario y un valor por tipo de identificador
Sencillo y eficaz.
Usa esta opción cuando cada usuario tenga como máximo una dirección de correo electrónico con Hashing, un número de teléfono con Hashing, etc.
Ejemplo
| ID de usuario | Correo electrónico con Hashing | Teléfono con Hashing |
|---|---|---|
| 123 | 5d41402 | 152d234b70 |
| 456 | 7d793037 | |
| 789 | 0e6e5414 |
Por qué se recomienda
- Es lo más sencillo de preparar e ingerir
- Fácil de validar y solucionar problemas
- Buen rendimiento de coincidencia cuando los identificadores están completos y son coherentes (para la coincidencia con conjuntos de datos de colaboradores y la coincidencia de Partners de medios para la activación)
Más adecuado para
- Ideal para cargas basadas en CSV
- También funciona bien en Parquet / BigQuery / Snowflake
Opción 2: Matrices (listas) de identificadores para campos con varios valores
La mejor opción para mantener la precisión cuando los usuarios tienen varios correos electrónicos y teléfonos.
Utiliza esta opción cuando un usuario puede tener varios valores del mismo tipo de identificador, como:
- Varios correos electrónicos con hash
- Varios teléfonos con hash
Esta estructura debe representarse como matrices nativas.
Ejemplo
| ID de usuario | Correos electrónicos con hash | Teléfonos con hash | MAID |
|---|---|---|---|
| u_0001 | [a1b2 · c3d4 · e5f6] | [p1q2 · r3s4] | m001 |
| u_0002 | [z9y8 · x7w6] | m002 | |
| u_0003 | [t1u2 · v3w4 · x5y6] |
Por qué se prefiere esta opción
- Refleja cómo suelen almacenarse internamente los datos de identidad
- No hace falta adivinar cuántas «columnas de correo electrónico» pueden hacer falta
- Evita cambios continuos en el esquema
- Maximiza el potencial de coincidencia (para conjuntos de datos de colaboradores y para la coincidencia de partners de medios de activación) al permitir varios identificadores por usuario
La mejor opción
- Parquet (S3/GCS)
- BigQuery
- Snowflake
Lista de comprobación práctica para estructurar datos
Lista de comprobación del conjunto de datos de identidad (a nivel de usuario)
- Una fila representa a un usuario.
- Incluye todos los identificadores disponibles (correo electrónico con hash, teléfono con hash, MAID, etc.).
- Si existen varios valores (por ejemplo, varios correos electrónicos), usa arrays nativos siempre que sea posible.
- Evita las listas en las celdas, evita «correo electrónico_1/correo electrónico_2/correo electrónico_3» y evita las estructuras de identidad de varias filas.
Lista de comprobación del conjunto de datos transaccionales (eventos)
- Mantén las filas de eventos/transacciones tal cual. Consulta los ejemplos de datos transaccionales
- Usa las Data Views para crear resúmenes a nivel de usuario listos para la colaboración cuando corresponda.
Lista de comprobación de Data Views
- Crea Data Views orientadas al negocio (listas para audiencias, resumidas y estandarizadas).
- Comparte Data Views en lugar de tablas sensibles sin procesar siempre que sea posible.
- Minimiza los campos compartidos a solo lo necesario (por privacidad y protección del negocio).
- Considera usar agregaciones para reducir el acceso a datos sensibles y mejorar la eficiencia.
Servicios y formatos de ingesta en la nube compatibles
El DCP permite la ingesta a través de varios servicios en la nube, como:
- AWS S3
- GCS (Google Cloud Storage)
- BigQuery
- Snowflake
Guía de formatos
- Usa CSV (separado por comas) cuando cada usuario tenga un valor por tipo de identificador (un correo electrónico, un teléfono, etc.).
- Cuando los usuarios puedan tener varios valores del mismo tipo de identificador (por ejemplo, varios correos electrónicos con hash), prioriza los formatos compatibles con matrices:
- Parquet (habitual en big data)
- BigQuery (los arrays están integrados)
- Snowflake (los arrays están integrados)
Notas:
- «Arrays» simplemente significa «una lista de valores».
- Parquet y los arrays en BigQuery/Snowflake son estándar, y la mayoría de los equipos de datos pueden dar soporte a esto de forma natural.
Consulta activos de ejemplo específicos del conector (AWS S3, GCS, BigQuery, Snowflake).
Estructuras de datos no recomendadas
Algunos tipos de estructuración de datos son idóneos para la ingesta en DCP, y otros no. A continuación se muestra una lista de estructuras de datos que no se recomiendan:
Evita: varias columnas para el mismo tipo de identificador
No se recomiendan ejemplos como «correo electrónico principal/secundario/terciario».
Ejemplo que debes evitar
| ID de usuario | Hash de correo electrónico 1 | Hash de correo electrónico 2 | Hash de correo electrónico 3 |
|---|---|---|---|
| 123 | a1b2 | c3d4 | |
| 456 | z9y8 |
Por qué debes evitarlo
- El número de valores por usuario es impredecible
- Provoca proliferación de columnas y problemas de mantenimiento del esquema
Evita: «Listas dentro de una sola celda» (texto libre)
Aunque parezca práctico, es propenso a errores.
Ejemplo que debes evitar
| ID de usuario | Correos electrónicos con hash (texto) |
|---|---|
| 123 | a1b2 · c3d4 · e5f6 |
Por qué debes evitarlo
- No es un tipo de array real
- Los problemas de formato/escape son habituales
- Las pequeñas incoherencias pueden interrumpir la ingesta de datos
Evita: varias filas por usuario para los identificadores (cuando tu objetivo es una tabla de identidad de usuario)
No dividas los datos de identidad entre varias filas cuando puedas mantener una fila por usuario.
Ejemplo que debes evitar
| ID de usuario | Tipo de identificador | Valor del identificador |
|---|---|---|
| 123 | hashed_email | a1b2 |
| 123 | hashed_email | c3d4 |
Por qué debes evitarlo
- Requiere procesamiento adicional para reconstruir usuarios
- Mayor riesgo de duplicados e incoherencias
- Menos eficiente a escala
Nota: Varias filas por usuario son normales en las tablas transaccionales, pero no son lo ideal para la tabla de identidad (a nivel de usuario) que se usa para la coincidencia.
Información adicional
Esta sección proporciona información adicional y detallada sobre temas relevantes.
Ejemplos de datos transaccionales
Los datos transaccionales/de evento pueden tener varias filas por usuario:
| ID de la transacción | ID de usuario | Fecha de la transacción | Cantidad | Categoría |
|---|---|---|---|---|
| t_001 | 123 | 01-12-2025 | 120.00 | Alimentación |
| t_002 | 123 | 12-15-2025 | 45.00 | Farmacia |
| t_003 | 456 | 12-20-2025 | 300.00 | Electrónica |
Recomendado
- Ingiere los datos transaccionales en su estructura natural
- Usa la herramienta Data View para generar una vista a nivel de usuario lista para colaborar (por ejemplo, gasto en los últimos 30 días, afinidad por categorías y resúmenes de antigüedad/frecuencia)
Recursos de ejemplo específicos del conector (AWS S3, GCS, BigQuery, Snowflake)
¿Qué significa «array/lista de identificadores»?
A veces, un solo usuario puede tener más de un correo electrónico o teléfono (por ejemplo, un correo electrónico personal y otro del trabajo). En lugar de forzarlos en columnas adicionales o en campos de texto desordenados, los representamos como una lista de valores.
| ID de usuario | Correos electrónicos con Hashing (lista) |
|---|---|
| u_0001 | [a1b2 · c3d4 · e5f6] |
| u_0002 | [z9y8 · x7w6] |
1. Conector de AWS S3 y GCS (Parquet)
Qué debe contener la muestra de identidad (esquema)
| Campo | Tipo de valor esperado | Notas |
|---|---|---|
| user_id | string | Una fila por usuario |
| hashed_emails | Matriz de cadenas | Identificador multivalor (recomendado) |
| hashed_phones | Matriz de cadenas | Identificador multivalor (recomendado) |
| maid | string | Identificador adicional opcional |
Parquet ofrece soporte nativo para listas, por lo que se recomienda cuando los usuarios tienen varios correos electrónicos o teléfonos.
2. Conector de BigQuery (vista previa de la tabla y captura de pantalla del esquema)
Esquema de identidad de ejemplo (BigQuery)
| Campo | Tipo de valor esperado | Modo |
|---|---|---|
| user_id | STRING | NULLABLE |
| hashed_emails | CADENA | REPETIDO (ARRAY) |
| hashed_phones | CADENA | REPETIDO (ARRAY) |
| maid | CADENA | ADMITE NULOS |
Las matrices son nativas en BigQuery (campos REPEATED). Este es el enfoque recomendado cuando existen varios correos electrónicos o teléfonos.
3. Conector de Snowflake (vista previa de la tabla y captura de pantalla del esquema)
Esquema de identidad de ejemplo (Snowflake)
| Campo | Tipo de valor esperado | Notas |
|---|---|---|
| ID_USUARIO | VARCHAR | Una fila por usuario |
| CORREOS_ELECTRÓNICOS_HASHEADOS | ARRAY | Identificador multivalor |
| TELÉFONOS_HASHEADOS | ARRAY | Identificador multivalor |
| MAID | VARCHAR | Opcional |
Snowflake admite campos de tipo lista (arrays). Esto se prefiere a crear columnas email_1/email_2/email_3.
Por qué se recomiendan las Data Views
Las Data views son subconjuntos personalizados de tus fuentes de datos existentes que puedes crear sin modificar el conjunto de datos original. Te permiten ejecutar funciones que modifican, refinan y resumen los datos para que puedas compartir en las colaboraciones solo lo que es relevante, manteniendo los datos que compartes claros y enfocados, y todos los demás datos privados y seguros. Utiliza Data Views en las colaboraciones porque:
Están orientadas al negocio y facilitan la colaboración
- Data Views te permiten presentar los datos en una estructura clara y orientada al negocio (por ejemplo, «Vista de identidad del cliente», «Vista de audiencia apta», «Vista de resumen de compras») en lugar de registros sin procesar o esquemas transaccionales complejos.
- Ayudan a estandarizar definiciones (por ejemplo, «cliente activo», «gasto total de los últimos 30 días») para que ambas partes estén alineadas y utilicen la misma lógica.
Son más seguras para la privacidad por diseño
- Data Views permiten la minimización de datos: puedes compartir solo los campos y las filas necesarios para la colaboración, en lugar de exponer conjuntos completos de raw data.
- Reducen el riesgo para la privacidad al permitirte:
- Excluir atributos innecesarios
- Limitar la granularidad (por ejemplo, compartir métricas agregadas en lugar de transacciones a nivel de línea)
- Compartir solo los identificadores necesarios para la coincidencia (y no columnas sensibles adicionales)
Protegen los datos empresariales sensibles
- Las tablas transaccionales sin procesar pueden contener señales empresariales muy sensibles (por ejemplo, comportamiento de compra detallado, patrones de precios, relaciones con comercios, IDs internos).
- Data Views te permiten compartir solo lo necesario para la colaboración:
- Ejemplo: comparte agregados a nivel de categoría en lugar de detalles a nivel de artículo
- Ejemplo: comparte buckets de gasto o métricas de resumen en lugar de elementos de línea exactos
- Esto reduce el riesgo de revelar sin querer información competitiva o propietaria.
Pueden hacer que tus datos sean más rentables y tengan mejor rendimiento
Data Views pueden estructurarse para ser más ligeras y eficientes, lo que a menudo reduce:
- Datos analizados
- Tiempo de procesamiento
- Costos de computación
Estructurar previamente una vista lista para la colaboración (especialmente vistas agregadas) puede hacer que la colaboración sea más rápida y operativamente más predecible.
Comportamiento de carga y coincidencia de varios ID/claves por plataforma
Carga de identificadores de DCP
| Partner/plataforma | Tipos de identificador admitidos | Modo de carga | Comportamiento de la carga | Prioridad de identificadores (para partners de un solo tipo) |
|---|---|---|---|---|
| Meta | Correo electrónico, teléfono, IDFA, GAID, ID de Android, nombre, apellidos, fecha de nacimiento, ciudad, provincia, código postal, país | Todos los tipos admitidos | Carga todos los tipos de identificador admitidos | No aplica: los carga todos |
| Correo electrónico, teléfono, IDFA, GAID, ID de Android, ID de cliente | Un solo tipo | Carga un tipo de identificador por audiencia | 1. Email 2. Teléfono 3. IDs móviles 4. ID de cliente | |
| TikTok | Correo electrónico, teléfono, IDFA, GAID, ID de Android | Todos los tipos admitidos | Carga todos los tipos de identificador admitidos | No aplica: los carga todos |
| Correo electrónico, teléfono, IDFA, GAID | Un solo tipo | Carga un tipo de identificador por audiencia | 1. Email 2. Teléfono 3. IDs móviles | |
| Infillion | Correo electrónico, teléfono, IDFA, GAID, MM-UUID | Todos los tipos admitidos | Carga todos los tipos admitidos agrupados en hasta 3 archivos | N/A: los carga todos |
| TheTradeDesk | Correo electrónico, teléfono | Un solo tipo | Carga un tipo de identificador por audiencia | 1. Email 2. Teléfono |
| AppsFlyer Data Locker | Todos los identificadores disponibles | Todos los tipos combinados | Entrega todos los identificadores en un único archivo combinado | N/A: los entrega todos |
| Destino de engagement | ¿Puedes enviar varios ID por usuario? | ¿Pueden hacer coincidir cualquiera de ellos? | ¿Pueden combinar varios ID? | Modelo de coincidencia (práctico) | Notas |
|---|---|---|---|---|---|
| Meta | Sí | Sí | Sí | Determinista, cualquier ID / combinación | Se evalúan correo electrónico, teléfono, MAID y fbp/fbc; comportamiento de «cualquiera de ellos» más sólido |
| Sí | Limitado | No | Determinista, priorizado | Un ID resuelve al usuario; los ID no se combinan para formar una coincidencia | |
| TikTok | Sí | Sí | Sí | Determinista, cualquier ID / combinación | Muy similar a Meta; ttclid es potente para eventos |
| Sí | Parcial | Limitado | Determinista, centrado en ID | Principalmente correo electrónico + MAID; refuerzo cruzado entre ID limitado | |
| The Trade Desk (TTD) | Sí | A través de un grafo de ID | Sí (a través del grafo) | Determinístico a través del grafo de identidad | UID2 + MAID + cookies resueltos a través del grafo EUID/UID2 |
| Infillion | Sí | A través del grafo de ID | Sí (a través del grafo) | Determinístico a través del grafo de Partners | Se basa en OmniID o en la resolución de identidad de Partners |
Conclusiones para la planificación de la activación
-
Meta y TikTok
- Envía todo lo que tengas
- Verdadero comportamiento de «cualquier ID»
- Las mejores plataformas para la activación en clean rooms con muchas identidades
-
Google
- Envía varios ID para ampliar la cobertura
- No esperes refuerzo entre ID diferentes
- El predominio del correo electrónico/teléfono es real
-
TTD e Infillion
- La calidad de la coincidencia depende más de la participación en el grafo de identidad
- La cobertura de UID2/OmniID importa más que el número bruto de identificadores
-
Pinterest
- Su comportamiento se parece más al de Google que al de Meta
- Ventaja limitada más allá de correo electrónico + MAID
TL;DR
- Solo Meta y TikTok realizan de forma nativa coincidencias de «cualquiera de ellos»
- Google es determinístico, pero se resuelve con un único ID
- Las plataformas de la web abierta establecen coincidencias mediante grafos de identidad, no mediante ID sin procesar
Directrices de formato de datos con hash por Partners de medios
Reglas de normalización universales:
Antes de aplicar hash a cualquier dato, casi todas las plataformas exigen los siguientes pasos de normalización para garantizar la precisión de la coincidencia:
- Texto: Convierte el texto a minúsculas y recorta todos los espacios en blanco iniciales y finales.
- Teléfono: conviértelo al formato E.164 (p. ej., +15551234567)
- Hashing: SHA-256 es el estándar de la industria, aunque algunas plataformas aceptan MD5 o SHA-1.
| Partner de medio | Pautas de correo electrónico | Pautas del número de teléfono | Pautas del ID móvil (MAID) | Matices específicos de la plataforma & lógica de coincidencia | Referencia relevante |
|---|---|---|---|---|---|
| Google Ads / DV360 | Formato: minúsculas, recorta los espacios en blanco. Incluye el dominio. Regla de Gmail: para @gmail.com / @googlemail.com, elimina los puntos (.) antes de la "@" y los sufijos después del (+). Hashing: SHA-256 (codificación hexadecimal). | Formato: E.164 (p. ej., +16505551212). Debe incluir el código de país. Hashing: SHA-256. | Formato: IDFA (iOS) o GAID (Android). Hashing: no aplicar hash. | Prioridad de coincidencia: determinista y priorizada (1. Correo electrónico, 2. Teléfono, 3. ID móviles). No combina varios ID para formar una coincidencia (resolución de un solo ID). DV360 PAIR: DV360 también da soporte al protocolo PAIR para la conciliación segura entre publisher y anunciante. | Primeros pasos con Customer Match (API de Google Ads) |
| Meta (Facebook/ Instagram) |
Formato: en minúsculas, recorta los espacios en blanco. Hashing: SHA-256 obligatorio. Nota: Meta no elimina los puntos de las direcciones de correo electrónico como parte de la normalización del Hashing. Antes del Hashing para Meta, solo se deben aplicar las minúsculas y el recorte de espacios en blanco. Enviar un correo electrónico con Hashing sin puntos («Hashed email (no dots)» en la asignación de fuente de DCP) no coincidirá con el hash propio de Meta y dará como resultado tasas de coincidencia más bajas para usuarios de dominios de correo electrónico. Esta variante de ID está pensada para partners que sí requieren eliminar los puntos (p. ej., Google Ads) y no debe usarse para activaciones de Meta/Facebook. |
Formato: elimina símbolos, letras y ceros iniciales. Incluye el código de país (p. ej., 16505551212). Hashing: SHA-256. | Formato: IDFA o GAID. Hashing: no aplicar hash. En minúsculas, conserva los guiones. |
Lógica de coincidencia: usa una lógica de «cualquiera de ellos»; combina varios ID (correo electrónico, teléfono, MAID, etc.) para resolver un usuario, lo que proporciona una sólida consolidación entre ID. CAPI: requiere client_ip_address y client_user_agent sin hash para la coincidencia en navegador. |
Parámetros de información del cliente - Conversions API |
| TikTok | Formato: en minúsculas, elimina todos los espacios. Hashing: SHA-256. | Formato: E.164 (+[código de país][número]). También se acepta sin +. Hashing: SHA-256. | Formato: GAID (Android) o IDFA (iOS). Caso: todo en mayúsculas o todo en minúsculas. Hashing: SHA-256 o MD5. |
Lógica de coincidencia: al igual que Meta, usa una lógica de coincidencia determinista de «cualquiera de ellos», en la que basta con cualquier ID válido individual. Tamaño de la audiencia: se requiere un mínimo de 1.000 usuarios coincidentes para activar una audiencia personalizada. |
Cómo crear una audiencia personalizada con un archivo de clientes |
| The Trade Desk (UID2) | Formato: la misma «regla de Gmail» que Google (eliminar puntos/signo +). Codificación: codifica en Base64 los bytes sin procesar (el resultado tiene 44 caracteres). | Formato: E.164. Hashing: SHA-256. Codificación: codifica en Base64 los bytes sin procesar. | Formato: AAID (en minúsculas) / IDFA (en mayúsculas). Hashing: SHA-256, MD5 o SHA-1. |
Lógica de coincidencia: determinista mediante el grafo de identidad. La coincidencia depende de la participación en el grafo, en lugar de la cobertura bruta de ID. Matiz crítico: debes codificar en Base64 los bytes sin procesar del hash. La codificación de la cadena hexadecimal fallará. |
|
| Formato: debe incluir «@». Hashing: SHA-256, MD5 o SHA-1. | Formato: E.164. Elimina los caracteres especiales (espacios, guiones). Hashing: SHA-256, MD5 o SHA-1. | Formato: IDFA o GAID. Hashing: SHA-256, MD5 o SHA-1. | Lógica de coincidencia: «centrada en el ID». La coincidencia se basa principalmente en el correo electrónico y el MAID. Aportar otros ID tiene un «beneficio limitado», ya que el refuerzo cruzado entre ID es débil en comparación con Meta. Comportamiento de carga: carga un tipo de identificador por audiencia. | Directrices para la ingesta y estructuración de datos del DCP |
This article was translated automatically and may contain errors. The English version is the most accurate - use the language selector below to switch.