First-Party Data: Arquitectura de Datos Propios

Un dato propio es el que recoges tú en la relación directa con la persona: el formulario de tu web, el pedido, el ticket de soporte, la ficha del CRM. No lo es lo que te presta una plataforma publicitaria ni lo que compras a un tercero. Esa diferencia manda sobre lo que puedes medir y activar. La arquitectura la montamos en los trabajos de datos y arquitectura de Codezone.

Sin esa capa cada equipo trabaja con su copia: marketing exporta de la herramienta de email, ventas mira el CRM, administración factura desde el ERP. Cuando llega una supresión hay que buscarla a mano en cinco sitios, y esas horas salen de alguien que debería vender.

Al terminar sabrás qué cuatro tablas necesitas y quién manda sobre cada campo; la medición vive en el recorrido hasta la venta cerrada.

Qué es una arquitectura de datos propios

Es el conjunto de tablas, identificadores y reglas que reúnen en un solo almacén lo que tu empresa sabe de cada persona, con su base legal y su finalidad anotadas en la misma fila. Deja de ser un montón de exportaciones y pasa a ser una fuente que cualquier sistema consulta sin pedir permiso.

Dónde vive hoy el dato y qué falta

El inventario suele dar cuatro orígenes: la web aporta formularios y navegación, el CRM la oportunidad y el motivo de pérdida, el ERP los pedidos y los plazos de pago reales, soporte las incidencias.

Lo que falta no es un origen más, es el identificador que los une. Mientras el ERP indexe por NIF, el CRM por email y la web por cookie, tienes cuatro listas.

Cuatro cables de fibra luminosa que salen de iconos holográficos de distintas fuentes y se trenzan en un único conector — Cuatro orígenes, un solo punto de unión.

El identificador común y la tabla de identidad

La decisión que ordena el resto: un identificador interno opaco, generado por ti, que no sea el email ni el NIF. El email cambia y el NIF no existe para un particular extranjero.

Alrededor va una tabla de identidad con los alias de la persona, cada uno con su origen y su fecha: email, teléfono normalizado, cliente del ERP, visitante web. Así el cruce es una consulta, no un proyecto.

El modelo mínimo: cuatro tablas y nada más

Identidad: el identificador interno y sus alias, con origen y fecha. Responde a quién es.
Consentimiento: finalidad, base legal, cuándo, por qué canal y si está revocado. No se actualiza una fila, se añade una nueva.
Eventos: qué hizo esa persona y cuándo, con el tipo normalizado. La tabla que crece.
Transacciones: pedidos y facturas con importe y estado, del ERP. La única que da dinero.

Si arranca con más de cuatro tablas, dedicarás los primeros meses a mantenerlo en lugar de a usarlo.

La gobernanza que lo hace legal y usable

El RGPD limita finalidad y plazo de conservación en su artículo 5 y exige en el artículo 30 un registro de las actividades de tratamiento con los fines, las categorías de interesados y de datos, los destinatarios, los plazos de supresión y las medidas de seguridad, según el texto consolidado del Reglamento General de Protección de Datos. El artículo 32 nombra la seudonimización y el cifrado.

Eso son columnas que ya tienes en el modelo: con la finalidad y el plazo en la fila, el registro de actividades se genera consultando tu almacén.

CodeZone Pro Tip: separa identidad, consentimiento y eventos en tres tablas con el identificador interno como clave, y añade el índice por persona y fecha antes de meter el primer millón de filas.

-- Identidad: una fila por persona real, mas sus alias conocidos.
CREATE TABLE persona (
  persona_id   UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  creado_en    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE alias (
  persona_id   UUID NOT NULL REFERENCES persona(persona_id),
  tipo         TEXT NOT NULL,   -- email, telefono_e164, erp_cliente, web_uuid
  valor        TEXT NOT NULL,
  origen       TEXT NOT NULL,
  -- Un mismo email no puede apuntar a dos personas: aqui se corta el duplicado.
  PRIMARY KEY (tipo, valor)
);
CREATE INDEX alias_por_persona ON alias (persona_id);

-- Consentimiento: historico inmutable. Nunca se hace UPDATE sobre una fila.
CREATE TABLE consentimiento (
  id           BIGSERIAL PRIMARY KEY,
  persona_id   UUID NOT NULL REFERENCES persona(persona_id),
  finalidad    TEXT NOT NULL,   -- comercial_email, perfilado, remarketing
  base_legal   TEXT NOT NULL,   -- consentimiento, contrato, interes_legitimo
  otorgado     BOOLEAN NOT NULL,
  ocurrido_en  TIMESTAMPTZ NOT NULL
);
-- DESC en la fecha: la consulta real es "cual es el ultimo estado".
CREATE INDEX consentimiento_vigente
  ON consentimiento (persona_id, finalidad, ocurrido_en DESC);

CREATE TABLE evento (
  persona_id   UUID NOT NULL REFERENCES persona(persona_id),
  tipo         TEXT NOT NULL,
  ocurrido_en  TIMESTAMPTZ NOT NULL
);
CREATE INDEX evento_por_persona_fecha ON evento (persona_id, ocurrido_en DESC);

Con ese esquema, responder a una supresión es una consulta por `persona_id` en lugar de una búsqueda por departamento. Y comprobar si puedes mandar un email deja de ser una conversación y pasa a ser una condición en la consulta.

Tres plataformas holográficas de cristal apiladas y unidas por haces de luz, con un escudo flotando junto a la superior — Tres tablas sostienen el resto del modelo.

Qué Se Rompe Cuando Falta Esta Capa

Sin almacén propio, medición y activación se sostienen sobre exportaciones. La medición falla porque el identificador no viaja hasta la venta. La activación falla porque subes listas sin saber qué finalidad tenía cada consentimiento.

El coste aparece tarde: al cambiar de herramienta de email y ver que el histórico de bajas no es exportable, o al querer alimentar la integración de IA en Madrid con su capa de seguridad y coste sin tener de dónde leer. La prioridad del lead se decide en la priorización de leads por señales de compra y el envío en la activación de los datos desde el CRM.

Tubería holográfica de datos que se rompe en el centro con fragmentos de cristal rojo y partículas que se pierden — Cuando el identificador no viaja, el histórico no se recupera.

El Orden en que Conviene Construirlo

Primero el identificador y la identidad, porque todo cuelga de ahí. Después el consentimiento, que bloquea el uso. Luego los eventos y al final las transacciones del ERP, que exigen acordar qué datos sincronizar y quién manda sobre cada campo.

Ese orden evita empezar por el volcado masivo: si traes el histórico antes del identificador, lo traes dos veces, así que plantéalo como un plan de migración de datos ordenado. Lo que se consulta encima ya es otra pieza, como dashboards centralizados sobre una sola fuente o la conexión de Shopify con el ERP y el almacén.

Escalera holográfica de cuatro bloques de datos que se iluminan de forma progresiva en una sala oscura — El orden de construcción decide si hay que repetir la carga.

Decide hoy quién es el dueño del identificador interno y en qué sistema se crea. Esa decisión determina si dentro de un año tienes un almacén o cuatro listas, y sale más barata ahora.

Si tus datos están repartidos entre el ERP, el CRM y la web, revisamos qué datos propios tienes ya y te decimos qué falta.