¿Qué son los datos propios (first-party data)?

El adjetivo «propios» no se refiere a la propiedad legal del dato, sino al origen de la relación: la persona entrega la información en un canal que la empresa controla y en el que sabe con quién está tratando. Un formulario de presupuesto, un pedido en la tienda, la apertura de un boletín, una llamada al soporte o el recorrido de navegación medido en el propio dominio producen datos propios.

La distinción con los otros dos tipos es una cuestión de cadena de custodia. Los datos de segunda parte son datos propios de otra organización que esta cede o vende de forma acordada, por ejemplo cuando una cadena hotelera comparte segmentos con una aerolínea socia; siguen teniendo un origen identificable, pero la empresa que los usa no estuvo presente cuando se recogieron. Los datos de terceros proceden de intermediarios que los agregan desde muchas fuentes ajenas y los revenden empaquetados como audiencias; el usuario rara vez sabe qué empresa acabó teniendo su perfil.

Existe además una cuarta categoría que se menciona cada vez más: los datos declarados o zero-party data, que la persona facilita de forma consciente y voluntaria al responder una encuesta o al configurar sus preferencias. Técnicamente son un subconjunto de los datos propios, con la particularidad de que la intención está declarada y no inferida.

El mecanismo tiene tres piezas: un punto de captura, un identificador que permite unir las interacciones de la misma persona y un almacén donde el dato queda bajo control de la empresa. El punto de captura puede ser un formulario, un proceso de compra, un registro de cuenta, un sistema de reservas o la propia medición de la web. El identificador suele ser el correo electrónico normalizado, un número de cliente o un identificador de sesión propio. El almacén habitual es el CRM, un almacén de datos o una plataforma de datos de cliente.

El marco legal en la Unión Europea funciona en dos capas que conviene no mezclar. La directiva sobre la privacidad y las comunicaciones electrónicas, transpuesta en España en el artículo 22.2 de la LSSI, regula el hecho de almacenar información en el equipo del usuario o acceder a la que ya está almacenada: exige consentimiento informado previo y prevé una excepción cuando el almacenamiento o el acceso sirven únicamente para transmitir una comunicación por una red, o resultan estrictamente necesarios para prestar un servicio que la persona ha solicitado de forma expresa. Esa norma se refiere al equipo terminal con independencia de la tecnología empleada, de modo que alcanza también a las técnicas de huella digital del dispositivo.

La segunda capa es el RGPD, que regula qué ocurre después con los datos personales resultantes: exige una base jurídica, una finalidad determinada, información al interesado y límites de conservación. Que un dato sea propio no lo saca de ninguna de las dos capas.

La justificación más repetida para invertir en datos propios lleva años siendo falsa. El calendario de retirada de las cookies de terceros en Chrome se aplazó varias veces y terminó cancelándose: el 22 de abril de 2025 Google comunicó que mantenía su enfoque actual y que no lanzaría un aviso específico para que el usuario decidiera sobre las cookies de terceros, que siguen disponibles y se gestionan desde la configuración de privacidad del navegador. El 17 de octubre de 2025 Google fue más lejos y retiró diez tecnologías de Privacy Sandbox, entre ellas Topics, Protected Audience y Attribution Reporting, es decir, el conjunto que se había presentado como recambio. En agosto de 2026 ese sigue siendo el estado: Chrome no bloquea las cookies de terceros por defecto y el sustituto anunciado ya no existe.

La decisión que depende de los datos propios es otra, y esa no se ha movido. Safari y Firefox sí restringen las cookies de terceros por defecto, las tasas de aceptación en los avisos de consentimiento dejan sin medir una parte del tráfico, y la atribución basada en identificadores ajenos se degrada en cuanto el recorrido cruza dispositivos. Quien quiere saber cuánto vale de verdad un cliente, qué canal trae a los que repiten y a quién puede dirigirse sin depender de un intermediario, necesita un identificador propio y consentido.

• Define el identificador único antes de recoger nada, normalmente el correo normalizado o un número de cliente, y decide cómo se unen los sistemas que van a usarlo.
• Pide solo el dato que vas a utilizar. Cada campo adicional baja la tasa de cumplimentación y añade carga de cumplimiento normativo.
• Guarda junto al dato la finalidad, la fecha y la prueba del consentimiento, y haz que la retirada del consentimiento se propague a los sistemas conectados.
• Ofrece una contrapartida real por el registro: precio, disponibilidad, un configurador, un diagnóstico. El formulario sin contrapartida produce correos falsos.
• Mide la calidad y no el volumen: porcentaje de correos verificados, duplicados detectados, registros con al menos una compra atribuida.
• Fija plazos de conservación por finalidad y automatiza el borrado en lugar de dejarlo a una revisión manual anual.

• Llamar datos propios a una lista comprada. El origen no cambia de naturaleza por importarla al CRM.
• Tratar el consentimiento como un trámite de una sola vez. Si cambian las finalidades o los terceros implicados, la información sobre la que se prestó ya no describe lo que ocurre.
• Mantener silos separados de tienda, boletín, soporte y CRM sin clave común, con lo que la misma persona aparece como cuatro clientes distintos y todos los cálculos de valor salen bajos.
• Apoyar el proyecto en el argumento de la desaparición de las cookies y quedarse sin justificación en cuanto alguien comprueba que no ha ocurrido.
• Acumular campos que no alimentan ninguna decisión. Un dato que nadie usa es riesgo almacenado sin contrapartida.