El hash de audiencias de Customer Match, explicado

Cuando los marketers suben listas de clientes a Meta, Google o TikTok, lo primero que se les dice para tranquilizarlos es: "no te preocupes, los datos van con hash". Es verdad, pero está incompleto en aspectos que importan: para el match rate, para el cumplimiento normativo y para la revisión que tu equipo de seguridad hace de cualquier proveedor que toque datos de clientes.

Este artículo es la explicación técnica que pueden leer tanto los equipos de seguridad como los de marketing. Explica qué es realmente el hash, el paso crítico de normalización que casi toda la documentación relega a una nota al pie, el flujo completo desde tu base de datos hasta una audiencia con coincidencias, y el matiz de privacidad honesto: "con hash" no significa lo que la mayoría cree.

Qué es el hash (y qué no es)

Una función hash toma una entrada de cualquier longitud y produce una salida de longitud fija, llamada resumen o hash. SHA-256 produce una salida de 256 bits (64 caracteres hexadecimales). La función es determinista (la misma entrada siempre produce la misma salida) y unidireccional: no se puede invertir el cálculo para recuperar la entrada original.

Para la cadena john.smith@example.com, SHA-256 produce:

e3d4f2b1a8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2e1

(Ilustrativo. El hash real depende de la normalización exacta).

Esto es útil para hacer coincidir audiencias porque permite que dos partes (tú y una plataforma publicitaria) comprueben si tienen datos de la misma persona sin que ninguna comparta con la otra el correo o el teléfono subyacente. Tú envías el hash. La plataforma lo compara con los hash de sus propios usuarios. Si coinciden, el usuario se añade a la audiencia. Ni el correo que enviaste ni el que tiene la plataforma quedan expuestos a la otra parte.

Esa es la teoría. En la práctica hay complicaciones.

El paso que todos se saltan: la normalización

SHA-256 es determinista. Es su propiedad más importante para las coincidencias y también su mayor riesgo operativo. La misma entrada siempre produce la misma salida, pero entradas distintas, aunque la diferencia sea mínima, producen salidas totalmente distintas.

john.smith@example.com y John.Smith@example.com son, a todos los efectos, la misma dirección de correo. Para SHA-256 son cadenas completamente distintas. Los hash no coincidirán.

Por eso, antes de aplicar cualquier función hash, tienes que normalizar tus datos a una forma canónica. Para las audiencias, las reglas de normalización son:

Direcciones de correo electrónico:

• Pasar a minúsculas
• Eliminar los espacios al principio y al final
• No eliminar los puntos en las direcciones de Gmail (al contrario de lo que decían algunas guías antiguas; el comportamiento varía según la plataforma)

Números de teléfono:

• Convertir al formato E.164: +[prefijo del país][número], solo dígitos, sin espacios, guiones ni paréntesis
• Ejemplo: 55 1234 5678 (Ciudad de México) → +525512345678

Nombres:

• Minúsculas
• Eliminar los espacios al principio y al final
• Algunas plataformas dan indicaciones adicionales sobre caracteres especiales y acentos (algo especialmente relevante en español)

Cada plataforma documenta estas reglas (Google, Meta y TikTok publican sus especificaciones de normalización), pero es fácil aplicarlas de forma inconsistente, sobre todo cuando los datos vienen de varios sistemas de origen. Un teléfono guardado en tu CRM como 55-1234-5678 producirá un hash distinto de +525512345678. El resultado es un fallo silencioso: ningún error, ningún aviso, solo un match rate más bajo que es realmente difícil de diagnosticar si no auditas directamente el paso de normalización.

La normalización no es un detalle técnico. Es la palanca con más impacto en la calidad de tu match rate, más que el número de campos que envías o la frescura de tus datos. Hacerla mal destruye en silencio el valor de toda tu inversión en activación. Si quieres mejorar el match rate de tus anuncios, la normalización es lo primero que debes auditar.

El flujo completo, de principio a fin

Esto es lo que ocurre realmente, paso a paso, cuando una lista de clientes va a una plataforma publicitaria.

1. Exportar desde tu sistema de referencia. Extraes un segmento de tu CRM, tu plataforma de automatización de marketing o tu data warehouse. El resultado es un conjunto de atributos de cliente: correo, teléfono, nombre, código postal, país.

2. Normalizar. Cada campo se convierte a su forma canónica: correo en minúsculas, teléfono en E.164, nombre en minúsculas y sin espacios sobrantes. Este paso tiene que ir antes del hash.

3. Aplicar el hash. Cada valor normalizado pasa por SHA-256. El resultado de cada campo es una cadena hexadecimal de longitud fija. Tu archivo contiene ahora valores con hash en lugar de atributos de cliente en texto claro.

4. Enviar a la API de la plataforma. Los valores con hash se envían a la API de audiencias de la plataforma: la Custom Audiences API de Meta, Customer Match de Google a través de la Data Manager API, la Custom Audience API de TikTok. La plataforma solo recibe los datos con hash.

5. La plataforma aplica el hash a sus propios datos de la misma forma. La plataforma aplica la misma normalización y el mismo hash SHA-256 a los correos y teléfonos de su propio grafo de identidades.

6. Comparar los hash. La plataforma compara tus hash con los suyos. Como ambas partes usaron la misma normalización y la misma función hash, los registros que coinciden producen hash idénticos. La comparación se hace siempre sobre los hash, nunca sobre el texto claro.

7. La plataforma descarta tu lista. Tras la comparación, la plataforma elimina los hash subidos. Lo que queda es un segmento de audiencia (un conjunto de IDs de usuario de la plataforma) sin ninguna referencia a tus datos de clientes.

8. La plataforma informa del match rate. Ves un porcentaje: la proporción de registros subidos que encontraron coincidencia en el grafo de identidades de la plataforma. El match rate depende únicamente del solapamiento entre tu base de clientes y los usuarios de la plataforma, más la calidad de tu normalización. No depende de tu herramienta de sincronización ni del método de subida.

El matiz de privacidad: el hash no es anonimización

Esto es lo más importante que tu equipo legal y de cumplimiento debe entender: los datos personales con hash siguen siendo datos personales.

El hash es seudonimización, no anonimización. Seudonimizar significa transformar los datos para que no puedan atribuirse a una persona concreta sin información adicional (en este caso, el valor original sin hash). Anonimizar significa que los datos no pueden volver a vincularse con una persona en ninguna circunstancia realista.

Un correo con hash no es anónimo porque:

1. Es determinista y vinculable. Cualquiera que tenga el correo original puede calcular su hash SHA-256 y confirmar la coincidencia. El hash no protege frente a quien ya tiene el correo; protege frente a quien no lo tiene.
2. Existen tablas arcoíris y bases de datos de hash precalculados. Para correos habituales (dominios grandes, patrones de nombre comunes), es computacionalmente viable tener correspondencias precalculadas entre hash y texto claro. El hash no impide revertir las entradas más probables.
3. Los reguladores lo consideran dato personal. Según el RGPD, la ICO británica y la mayoría de los marcos equivalentes, los datos seudónimos siguen dentro del ámbito de aplicación. Las obligaciones de consentimiento, los derechos de los interesados y las reglas de conservación se aplican a las listas de clientes con hash.

La consecuencia práctica: subir listas de clientes con hash no cambia tus obligaciones de consentimiento. Si un usuario no ha consentido que sus datos se usen para segmentación publicitaria, aplicar hash a su correo antes de enviarlo a Meta no hace lícito ese uso. El hash es una medida de seguridad, no un atajo legal.

Dónde se aplica el hash importa

No todos los hash son iguales, y esta es la pregunta que debes hacer a cualquier proveedor que maneje tus datos de clientes.

Hay dos arquitecturas:

Hash en el lado del cliente (en tu entorno). Tus datos se normalizan y se les aplica el hash antes de salir de tus sistemas. El proveedor o la API de la plataforma solo reciben valores con hash. Tus datos de clientes en texto claro nunca salen de tu perímetro.

Hash en el lado del servidor (en el entorno del proveedor). Envías datos de clientes en texto claro a los servidores del proveedor, y este les aplica el hash antes de reenviarlos a la plataforma publicitaria. Tus datos salen de tu perímetro en texto claro.

Ambos enfoques dan el mismo resultado final en la plataforma: hash SHA-256. Pero son radicalmente distintos desde el punto de vista de la seguridad y el cumplimiento. Si entregas correos en texto claro a un proveedor externo para que les aplique el hash, tus datos han salido de tu entorno sin protección. Has creado una relación de encargado del tratamiento que exige un contrato de encargo (DPA) según el RGPD, y has asumido un riesgo durante la transmisión y en la infraestructura del proveedor.

Preguntas que debes hacer a cualquier proveedor de sincronización de audiencias:

• ¿En qué momento se aplica el hash a los datos? ¿En nuestro sistema o en el vuestro?
• ¿Vuestra infraestructura almacena en algún momento identificadores de clientes en texto claro?
• Si el hash se aplica en vuestros servidores, ¿cuáles son vuestras políticas de conservación de datos?
• ¿Tenéis disponibles un contrato de encargo (DPA) y una lista de subencargados?

La respuesta sobre la arquitectura debería ser clara e inequívoca. Si el proveedor es impreciso sobre cuándo se aplica el hash, trátalo como una señal de alarma.

Varias claves, varios hash

El correo es el identificador que más se envía, pero no el único, y el match rate mejora sustancialmente cuando envías más. Cada clave adicional da a la plataforma otra oportunidad de encontrar al usuario en su grafo de identidades.

Los campos que admiten la mayoría de las plataformas:

A cada campo se le aplica el hash por separado y se envía en su propia columna. La lógica de coincidencia de la plataforma combina las señales: un registro que coincide en correo, teléfono y nombre es una coincidencia más fiable que una solo por correo.

La constante: la normalización de cada campo tiene que ser correcta, y cada campo tiene sus propias reglas. La del teléfono es la que más se hace mal.

Qué significa esto para tus herramientas de sincronización

Estos requisitos técnicos tienen consecuencias directas en cómo deberías evaluar cualquier herramienta que lleve datos de tus sistemas a las plataformas publicitarias.

La herramienta debe:

1. Aplicar las reglas de normalización correctas y específicas de cada plataforma antes del hash, no un simple "minúsculas y sin espacios" genérico
2. Aplicar el hash dentro de tu entorno, no en los servidores del proveedor
3. Enviar todos los identificadores disponibles, no solo el correo
4. Gestionar los cambios: altas de nuevos clientes, bajas de clientes perdidos, propagación de las bajas de consentimiento
5. Ofrecer un registro de auditoría de qué se envió, cuándo y a qué plataforma

Si una herramienta funciona con exportaciones CSV y subidas manuales, la consistencia de la normalización depende por completo de quien escribió la consulta de exportación. La propagación de bajas es manual y llega tarde. El riesgo de cumplimiento de gestionar audiencias con CSV (en inglés) merece una reflexión seria antes de estandarizar ese flujo.

Dónde encaja Cezium

Cezium Ads aplica el hash dentro de tu propia instancia de Salesforce Marketing Cloud. Cuando creas una audiencia, Cezium genera una automatización en tu entorno de Marketing Cloud que normaliza los identificadores y les aplica hash SHA-256 antes de que ningún dato salga de tus sistemas. No se envían datos de clientes en texto claro a la infraestructura de Cezium y no se almacena nada externamente. Las conexiones con las plataformas publicitarias usan OAuth 2.0, las controla tu equipo de IT, y las bajas y eliminaciones se propagan en cada ciclo de sincronización.

Para los equipos de SFMC que evalúan opciones tras Advertising Studio, la guía de migración de Google Customer Match para Advertising Studio (en inglés) cubre los cambios de API y de consentimiento que entraron en vigor en abril de 2026.

El hash es el mecanismo correcto para hacer coincidir audiencias, y SHA-256 es el algoritmo correcto. Pero los detalles de implementación (la normalización, dónde se aplica el hash, qué claves envías, cómo se propagan las bajas) determinan si tu programa de activación es seguro, cumple la normativa y es eficaz, o si simplemente lleva hash.

La palabra "hash" en la presentación de un proveedor es el punto de partida de las preguntas, no el final.

Mounir Nejjai es el fundador de Cezium.