Datos First-Party y Zero-Party: Una Base de Datos Real

Durante años se ha anunciado la muerte de las cookies de terceros — a veces como un escenario apocalíptico, otras veces como pánico sectorial exagerado. La realidad se sitúa sobriamente entre ambos extremos. Google ha retrasado la eliminación completa en Chrome en múltiples ocasiones, pero la dirección es irreversible. Safari y Firefox llevan años bloqueando las cookies de terceros. iOS 14.5 destruyó de facto la atribución basada en el IDFA. El panorama regulatorio en Europa, moldeado por el RGPD y la Directiva ePrivacy, convierte el seguimiento sin consentimiento activo en un riesgo legal que muchas empresas siguen subestimando.

Lo que estos desarrollos fuerzan colectivamente es un cambio de paradigma: alejarse de la adquisición pasiva de datos a través de terceros y avanzar hacia una infraestructura de datos activa que la propia empresa construye y controla. Este cambio de paradigma no es de naturaleza principalmente técnica. Es de naturaleza estratégica. Quienes lo tratan como un simple problema de sustitución de cookies pasan por alto la pregunta fundamental: ¿cómo se construye una base de datos que realmente permita actuar?

Trabajo a diario con empresas medianas y fundadores que o bien descubrieron demasiado tarde lo dependientes que eran de proveedores externos de seguimiento, o que ahora ven la oportunidad de hacer algo fundamentalmente diferente. Este artículo describe el marco estructural que encuentro útil en ese contexto — no un producto, no una recomendación de proveedor, sino un modelo de pensamiento.

Los dos términos se usan a menudo de forma intercambiable, pero se refieren a cosas conceptualmente diferentes. Los datos first-party son datos que una empresa recopila a través de interacciones directas con los usuarios: visitas al sitio web, uso de la aplicación, historial de compras, tasas de apertura de correos electrónicos, tickets de soporte. El usuario proporciona estos datos sin necesariamente hacerlo conscientemente. Surgen como subproducto de una acción.

Los datos zero-party, en cambio — un término acuñado por Forrester Research — son datos que un usuario comparte de forma proactiva e intencionada. Preferencias que especifica durante un proceso de incorporación. Intereses que selecciona en un centro de preferencias. Respuestas a una pregunta directa en una campaña de correo electrónico. La diferencia esencial no es técnica sino contextual: los datos zero-party surgen de un intercambio explícito — el usuario entrega algo porque espera o comprende el valor que recibe a cambio.

Esta distinción tiene consecuencias significativas para la calidad y fiabilidad de los datos. Los datos first-party son de naturaleza conductual y, por lo tanto, tienden a ser precisos, pero también requieren interpretación. Alguien que visita una página de producto tres veces puede estar listo para comprar — o puede estar investigando para un amigo. Los datos zero-party son de naturaleza declarativa: menor volumen, pero mayor densidad de intención. Un usuario que declara gastar 5.000 euros al mes en software de marketing es una base de datos cualitativamente diferente a alguien que simplemente visitó esa página de producto.

El error de concepción más común al construir una estrategia de datos first-party y zero-party es pensar que los datos deben recopilarse en un único momento — al rellenar un formulario, al realizar una compra, al suscribirse a un boletín. Este pensamiento lleva a formularios largos y poco atractivos, y a datos que quedan obsoletos en pocos meses.

El enfoque conceptualmente más sólido es el profiling progresivo: el enriquecimiento gradual de un perfil a lo largo de múltiples puntos de contacto. Un usuario que se suscribe a un boletín inicialmente solo proporciona su correo electrónico y nombre. En su segunda visita — si hace clic en un artículo específico — se le hace una pregunta contextualmente relevante. La siguiente interacción añade otra capa. Cada interacción es una oportunidad para profundizar el perfil sin interrumpir la experiencia.

Técnicamente, esto no es complicado. Requiere una capa de CRM o CDP que persista perfiles parciales y una capa lógica que decida qué pregunta tiene sentido en qué momento. Lo que realmente requiere es una decisión de contenido: ¿qué campos de datos son relevantes para qué casos de uso? Esta pregunta rara vez se plantea antes de la implementación técnica en la práctica — lo que hace que los sistemas terminen recopilando datos que nadie analiza jamás.

La gestión del consentimiento se trata como un problema de cumplimiento normativo en la mayoría de las organizaciones: se implementa un banner de consentimiento, se integra un proveedor, el tema se considera resuelto. Desde una perspectiva estratégica, esta visión es miope.

El consentimiento es la condición de entrada para toda actividad basada en datos. Si los datos pueden recopilarse, almacenarse y utilizarse, y en qué medida, depende directamente de qué consentimientos existen. Una capa de orquestación del consentimiento que gestione estos estados de consentimiento en todos los sistemas y los propague a todos los sistemas posteriores no es un complemento técnico agradable — es la base de una infraestructura de datos sólida.

Concretamente, esto significa: una Plataforma de Gestión del Consentimiento (CMP) no solo debe controlar el banner, sino transmitir los consentimientos de un usuario de forma estructurada al CRM, CDP, automatización de marketing y herramientas de análisis. Si un usuario retira el consentimiento para las cookies de análisis, ese estado debe actualizarse en todos los sistemas conectados — en tiempo real, no en el siguiente trabajo por lotes nocturno.

En el contexto DACH, este requisito no es una consideración académica. Las autoridades supervisoras han impuesto multas en repetidas ocasiones en los últimos años por prácticas de cookies que no cumplían el estado actual de la jurisprudencia — incluso contra empresas que formalmente usaban una CMP pero no propagaban correctamente las señales de consentimiento. La diligencia técnica tiene aquí relevancia jurídica.

Una Customer Data Platform no es un producto sino un principio arquitectónico. Se refiere a la idea de consolidar datos de clientes de diversas fuentes en un perfil persistente y unificado — uno que sea accesible y activable por otros sistemas. Esto distingue un CDP de un data warehouse (construido principalmente para análisis) y de un CRM (construido principalmente para flujos de trabajo de ventas).

Para las empresas medianas, la pregunta rara vez es qué software CDP utilizar. La pregunta es cómo implementar la lógica CDP con las herramientas disponibles — porque la mayoría de las empresas medianas no implementarán un CDP empresarial en el rango de seis cifras. Lo que pueden hacer es construir una arquitectura que implemente los principios fundamentales.

El primer principio es la resolución de identidades. El mismo usuario normalmente tiene múltiples puntos de datos en diferentes sistemas: una dirección de correo electrónico en el CRM, un ID de sesión anónimo en la herramienta de análisis, un número de cliente en la plataforma de comercio electrónico. Una arquitectura CDP vincula estos puntos de datos en un perfil coherente — en la medida en que esto sea legalmente permitido y técnicamente factible.

El segundo principio es la capa de activación. Los datos que duermen en un sistema no tienen valor. La pregunta es: ¿en qué sistema, en qué momento, basándose en qué puntos de datos, se desencadena qué acción? Esta lógica de activación — a menudo denominada construcción de audiencias o motor de segmentación — es el núcleo operativo de una arquitectura CDP.

El RGPD es un tema frecuentemente malentendido en los contextos B2B. La creencia generalizada de que la comunicación B2B — es decir, la comunicación entre empresas — está fundamentalmente menos regulada es, como afirmación general, incorrecta. Los datos personales siguen siendo datos personales incluso cuando se procesan en el contexto de una relación comercial. La dirección de correo electrónico de un responsable de compras es un dato personal.

Lo que realmente difiere en B2B: la base jurídica para el tratamiento puede diferir. Mientras que en los contextos B2C el consentimiento (Art. 6(1)(a) RGPD) y el cumplimiento del contrato (Art. 6(1)(b)) son las bases centrales, los contextos B2B recurren más frecuentemente al interés legítimo (Art. 6(1)(f)) — especialmente para comunicaciones de marketing a clientes existentes o a contactos conocidos en un contexto profesional.

El interés legítimo no es un permiso general. Requiere una ponderación de intereses documentada que demuestre que el interés de la empresa en la comunicación no prevalece sobre los intereses legítimos de los interesados. Esta ponderación debe repetirse cada vez que cambien los fines del tratamiento.

Para la infraestructura de datos, esto significa: cada punto de datos debe estar vinculado a una base jurídica. Los sistemas que no permiten la documentación de la procedencia de los datos recopilados son estructuralmente problemáticos bajo el RGPD — independientemente de cuán bien podrían utilizarse operativamente esos puntos de datos. La infraestructura técnica debe incorporar la documentación jurídica no como un apéndice sino como una función central.

Las siguientes fuentes son puntos de partida para una exploración más profunda de los temas tratados en este artículo. No constituyen una bibliografía exhaustiva, sino una selección de fuentes primarias y secundarias de reconocida solvencia.