Leer esto de llevara más o menos... 16 minutos
by APFerrer
Share
Arquitectura de datos: Cada cosa en su lugar
Hablemos de como almacenas la información de tus clientes… Dime una cosa: ¿Cuánto tiempo te llevaría decirme cuántos de los clientes con los que has trabajado en los últimos años han cambiado de proveedor? ¿Y si, además, te pido los motivos? O mejor aún, ¿Cuántos de ellos te han traído nuevos clientes por boca a boca?
Probablemente no puedas responder ahora mismo, o necesitarías un rato para buscar esa información. No pasa nada; te he cogido con el pie cambiado, mea culpa.
Para que no te sientas mal, te diré que es una pregunta que muy pocos pueden responder de inmediato. Y si pueden hacerlo, claramente no necesitan mi ayuda… al menos para ese tipo de procesos.
Cada acción de tu marca genera un rastro de datos. Estos rastros, si se acomodan bien, crean una estructura orgánica de datos que está viva. Tus datos crecen, se reproducen y, algunos de ellos, mueren.
La última vez te expliqué cómo crear una estructura de datos básica. Hoy quiero hablarte de uno de los enfoques más naturales para la creación y el mantenimiento de datos: Data Mesh.
Esto es algo que, de alguna manera, ya estás haciendo; solo que todavía no lo sabes…
Sobre el rastro de datos
Cada interacción que un cliente tiene con tu marca, por pequeña que sea, deja un rastro de datos. Cuando navega en tu web, visita tu tienda física, abre un email, o incluso decide ignorarlo, deja señales. Cada clic, cada llamada y cada tiempo de espera en la página es una pequeña huella que cuenta algo. Aunque no lo parezca, hasta las acciones más pasivas son parte de esta historia: cuánto tiempo pasa mirando un producto o cuántas veces vuelve a una página antes de comprar.
Imagina todo este rastro como un mapa que muestra por dónde han pasado, qué les ha interesado y qué dudas han tenido antes de tomar una decisión. Así, los datos no son solo números o registros en una base de datos; son pistas, pequeñas piezas de información que pueden revelarte patrones en el comportamiento de tus clientes y ayudarte a entenderlos mejor. Este rastro de datos, si se organiza de forma inteligente, puede convertirse en un recurso esencial para mejorar cada interacción y ofrecerles justo lo que necesitan, incluso antes de que lo pidan.
Seguir el rastro de todo, es muy difícil
Cada individuo que interactúa con tu marca deja un camino que podrías seguir. El problema viene cuando tienes mil accesos a tu casa, y la gente entra y sale como Pedro por su casa.
Sigues los clics con Analytics, pero eso requiere configurarlo bien… Las llamadas podrías rastrearlas con una centralita digital… espera, no, de eso no tienes. Las visitas a la tienda… tampoco haces seguimiento de eso. Luego tienes consultas en la web mediante formulario que… tampoco analizas. Bien, vayamos al archivo de emails, ¿qué quieres decir con que “eliminas” los emails? Oh… bueno… a ver qué podemos hacer…
Así que aquí el problema no es solo la cantidad de información, sino cómo la tratamos. Rastrearlo todo es complicado, primero porque no todo el mundo tiene los medios técnicos, y segundo, porque si nadie te ha dicho qué deberías seguir, ¿cómo vas a hacerlo?
No pasa nada, para eso estamos aquí hoy.
Lo primero es lo primero: ¿Cuál es la teoría del data mesh?
Imagina todos esos rastros de datos como un conjunto de piezas. Cada pieza se une a otras para formar una estructura, y esas estructuras se combinan para construir algo completo.
Data Mesh nos dice que cada estructura debe estar gestionada por una sección distinta de la empresa o, como ellos llaman, un dominio.
Para que quede claro, los dominios habituales incluyen compras, ventas, postventa, marketing, finanzas, entre otros. Es decir, esto ya lo tienes: el comercial trabaja con sus clientes, el equipo de ventas se ocupa de los proveedores, cada uno con su información específica y su propio enfoque.
Ahora bien, Data Mesh lleva esto más allá: hace realmente responsables a los dominios. No se trata solo de recopilar datos, sino de trabajarlos de forma que sean útiles para el conjunto de la empresa, es decir, para tu marca. Los datos de cada dominio deben ser conectables entre sí, para que el puzzle completo tenga sentido. Esto implica trabajar bajo patrones de contexto, donde cada dominio debe pensar en cómo sus piezas se integran con el resto.
Pero eso ya lo hacemos…¿no?
No. No lo estáis haciendo, y es lo normal. Cuando empezamos a trabajar, anotamos datos sueltos, luego hacemos la web, luego contratamos a gente, luego abrimos más líneas de negocio, luego… luego… luego…
Para que el Data Mesh sea real, debe estructurarse de manera piramidal, generando derivaciones estructurales desde el momento cero. Estandarizar todos los patrones de datos, los campos, los procesos… Eso nunca puede hacerse al iniciar un proyecto empresarial porque hasta que no te ves con todo el equipo no te das cuenta de lo que vas a necesitar.
Herramientas
A medida que las necesidades de la marca van cambiando vamos integrando distintas herramientas, cada cual de su padre y de su madre. Cada cual con su propia arquitectura.
Si la teoría del Data Mesh nos dice que los datos asumidos por los dominios deben ser practicables globalmente, debemos ser conscientes de que debemos «convertir» la información exógena en información que se adapte a nuestro mapa de datos.
Esto implica la integración de transformadores de datos que conviertan la información desconectada en información adaptada al entorno.
Es decir, cogemos los rastros que nos van dejando las herramientas que usamos (plataformas analíticas, de email, afiliados… etc.) y las convertimos al idioma de nuestro ecosistema.
Por lo que, debemos tener en cuenta que nuestro ecosistema, que como he dicho, está vivo, debe ser capaz de crecer de forma lógica. Y para eso… debemos tener un plan.
Entonces, ¿Cómo lo hacemos?
Ahora que más o menos tu proyecto avanza, debes hacer la primera (de muchas) adaptación al nuevo ecosistema de datos.
Lo primero que harás será analizar todos tus datos, su estructura, sus campos, sus acciones, sus fuentes de actualización, etc. Después, deberás analizar todas las fuentes externas desde las que recoges datos (analítica, reputación, email, CRM, ventas, facturación… todo).
Buscarás los campos coincidentes, los campos que no tienen vinculaciones, y crearás una lista de valores que puedan reproducirse y sean comprensibles.
Sé que la teoría es compleja, pero no te preocupes, que vamos a verlo paso a paso…
Ahora sí, ¡Manos a la obra!
Vamos a meternos de lleno para que aprendas practicando.
Primero, revisa todo lo que tienes en tu ecosistema de datos. Haz un inventario de todas tus fuentes: ¿De dónde vienen tus datos? Puede ser de formularios web, emails, ventas, reputación online o cualquier otra herramienta. Tómate tiempo para identificar cada fuente y asegúrate de entender qué tipo de información recoge cada una y en qué formato. Este paso inicial es clave para ver el punto de partida y entender la complejidad de tus datos y sus posibles conexiones.
Paso 1: Etiqueta y agrupa la información
A continuación, pon etiquetas y agrupa la información que tiene sentido manejar en conjunto. Por ejemplo, si tanto en la plataforma de ventas como en el sistema de facturación tienes un campo para “Cliente”, revisa si el formato es el mismo y si pueden conectarse sin modificaciones. Este ejercicio te permitirá detectar ajustes necesarios para crear un “lenguaje” común en todo tu ecosistema.
Paso 2: Crear un plan de transformación de datos
Con esta primera clasificación, vamos a crear un plan de transformación de datos. Este plan no solo te ayudará a conectar los datos de cada dominio, sino a entender cómo fluyen entre áreas y a definir un camino para cada dato en su ciclo de vida. Piensa en este plan como el esqueleto de tu Data Mesh: es lo que permitirá que los datos de cada dominio sean accesibles, consistentes y útiles para toda la organización.
Ejemplo práctico: La estructura de la hoja de cálculo
Paso a Paso en la Hoja de Cálculo
-
Abre una hoja de cálculo nueva y crea las siguientes columnas:
- Dominio: Áreas como Ventas, Marketing, Soporte al Cliente, etc.
- Subdominio: El origen específico del dato, como Tienda Online, Mailing, Atención en Línea.
- Campo: Qué tipo de dato es (por ejemplo, Nombre, Apellido, Email, ID).
- Label: Cómo se llama el campo en la herramienta (por ejemplo,
id_cliente_ventas
,email_user_id
). - Valor: El dato real en cada sistema (por ejemplo, el ID específico del cliente en esa plataforma, su nombre, etc.).
Ejemplo Detallado
Vamos a ver esto más cuidadosamente. Tenemos múltiples entradas de datos, debemos estandarizarlas.
Dominio | Subdominio | Campo | Label | Valor |
---|---|---|---|---|
Ventas | Tienda Online | ID | id_cliente_ventas | 12345 |
Ventas | Tienda Online | Nombre | fname | Juan |
Ventas | Tienda Online | Apellido | lname | Gómez |
Ventas | Tienda Online | user_email | juan.gomez@email.com | |
Marketing | Mailing | ID | email_user_id | MKT_56789 |
Marketing | Mailing | Nombre | name | Juan |
Marketing | Mailing | Apellido | lastname | Gómez |
Marketing | Mailing | email_address | juan.gomez@email.com | |
Soporte al Cliente | Atención en Línea | ID | support_id | SUP_98765 |
Soporte al Cliente | Atención en Línea | Nombre | nombre | Juan |
Soporte al Cliente | Atención en Línea | Apellido | apellido | Gómez |
Soporte al Cliente | Atención en Línea | juan.gomez@email.com | ||
Redes Sociales | ID | ig_user_id | IG_23456 | |
Redes Sociales | Nombre | first_name | Juan | |
Redes Sociales | Apellido | last_name | Gómez | |
Redes Sociales | contact_email | juan.gomez@email.com | ||
Analítica Web | Google Analytics | ID | analytics_user_id | ANL_34567 |
Analítica Web | Google Analytics | Nombre | visitor_name | Juan |
Analítica Web | Google Analytics | Apellido | visitor_surname | Gómez |
Analítica Web | Google Analytics | email_contact | juan.gomez@email.com |
Te lo explico
Cada plataforma tiene su propio ID de cliente. En Ventas aparece como id_cliente_ventas
, en Mailing como email_user_id
, en Soporte al Cliente como support_id
, y así sucesivamente. Esta hoja de cálculo te permite ver todos estos IDs y campos en una única vista para poder identificar de manera consistente al mismo cliente en cada plataforma. Lo mismo pasa con los demás campos, así que debemos encontrar un formato que convierta toda esa información diseminada en un modelo unificado.
Conectar y Estandarizar el ID de Cliente
Para unificar la información, se puede elegir uno de los IDs como ID de referencia, o crear un nuevo campo en la hoja donde se pueda vincular cada ID de la herramienta a un cliente específico. Esto simplifica la tarea de reconocer al mismo cliente a través de distintas plataformas sin depender de un único ID centralizado. Vamos a ello.
Paso 2: Estandarización de Datos y Campos con Sufijos por Dominio y Uso de Claves Foráneas
En este paso, estandarizamos los datos de cada dominio usando una nomenclatura con sufijos y claves foráneas para conectar los datos de diferentes fuentes de forma clara y consistente. Este método te permitirá identificar y conectar datos que se repiten en distintas áreas sin perder contexto ni coherencia.
Define un Sufijo de Dominio para Cada Área
Asignamos un sufijo único a cada dominio. Esto permite identificar cada dato en función de su origen. En este ejemplo:
- Ventas tiene el sufijo VEN_.
- Marketing usa el sufijo MAR_.
- Soporte al Cliente utiliza SUP_.
- Redes Sociales utiliza RS_.
- Analítica Web utiliza AW_.
Estandariza Cada Campo con el Sufijo del Dominio
Para cada dato, se usa el sufijo de su dominio. Así, el ID de cada dominio tendrá su propio prefijo, pero también podrá conectarse mediante una clave foránea a otros dominios.
-
- ID de Cliente en Ventas: El ID primario de cada cliente es VEN_ID en el dominio de Ventas.
- Claves Foráneas en Otros Dominios: Los ID de cliente en otros dominios (Marketing, Soporte al Cliente, etc.) se refieren al VEN_ID de Ventas como su clave foránea. Esto permite que todos los datos vinculados a un cliente en cada dominio se conecten mediante esta clave.
Ejemplo de Estandarización
Aquí tienes una tabla completa con la nomenclatura y las claves foráneas para los diferentes dominios:
Dominio | Subdominio | Campo | Label | Valor | Nomenclatura Estandarizada |
---|---|---|---|---|---|
Ventas | Tienda Online | ID | id_cliente_ventas | 12345 | VEN_ID |
Ventas | Tienda Online | Nombre | fname | Juan | VEN_NAME |
Ventas | Tienda Online | Apellido 1 | lname | Gómez | VEN_LASTNAME1 |
Ventas | Tienda Online | Apellido 2 | null | – | VEN_LASTNAME2 |
Ventas | Tienda Online | user_email | juan.gomez@email.com | VEN_EMAIL | |
Marketing | Base de datos | ID | mar_id | 12345 | MAR_ID (clave foránea: VEN_ID) |
Marketing | Mailing | ID | email_user_id | MKT_56789 | MAR_EMAIL_ID |
Marketing | Mailing | Nombre | name | Juan | MAR_NAME (clave foránea: VEN_NAME) |
Marketing | Mailing | Apellido | lastname | Gómez | MAR_LASTNAME1 (clave foránea: VEN_LASTNAME1) |
Marketing | Mailing | email_address | juan.gomez@email.com | MAR_EMAIL | |
Marketing | Mailing | ID Email Plat. | email_platform_id | EML12345 | MAR_EMAIL_ID |
Soporte al Cliente | Base de datos | ID | sup_id | 12345 | SUP_ID (clave foránea: VEN_ID) |
Soporte al Cliente | Atención en Línea | ID | support_id | SUP_98765 | SUP_SUP_ID |
Soporte al Cliente | Atención en Línea | Nombre | nombre | Juan | SUP_NAME (clave foránea: VEN_NAME) |
Soporte al Cliente | Atención en Línea | Apellido | apellido | Gómez | SUP_LASTNAME1 (clave foránea: VEN_LASTNAME1) |
Redes Sociales | Base de datos | ID | rs_id | 12345 | RS_ID (clave foránea: VEN_ID) |
Redes Sociales | ID | ig_user_id | IG_23456 | RS_IG_ID | |
Redes Sociales | Nombre | first_name | Juan | RS_NAME (clave foránea: VEN_NAME) | |
Redes Sociales | Apellido | last_name | Gómez | RS_LASTNAME1 (clave foránea: VEN_LASTNAME1) | |
Redes Sociales | contact_email | juan.gomez@email.com | RS_EMAIL |
Este enfoque permite que los datos de cada dominio mantengan su propia estructura, mientras que la clave foránea (VEN_ID) conecta toda la información de manera unificada.
En términos generales, no aconsejamos tener el email como clave foránea, ya que un mismo usuario puede tener distintos email para distintas situaciones (sobre todo cuando trabajamos B2B)
Paso 3: Implementación de Transformadores de Datos para un Data Mesh Consistente
El objetivo del transformador de datos es recoger información en su formato original desde cada fuente externa (Ventas, Marketing, Soporte al Cliente, etc.) y convertirla en el formato de los campos valor estandarizados que hemos definido en la hoja de cálculo. Así, aseguramos que cada dato, independientemente de su origen, se almacene de manera uniforme en nuestro sistema.
Cómo Funciona el Transformador de Datos
- Recogida de Datos Externos: El transformador accede a cada fuente de datos externa (por ejemplo, el sistema de ventas, la plataforma de mailing, o el CRM de soporte).
- Conversión a Campos Valor: Cada dato externo es transformado para que coincida con el campo valor y formato estándar que definimos en la hoja de cálculo. Esto incluye:
- Asignación del sufijo de dominio.
- Adaptación de los valores al formato común (fechas, nombres, etiquetas).
- Almacenamiento en Campos Valor Estandarizados: Los datos convertidos se almacenan bajo los nombres y formatos de los campos valor que establecimos, creando una estructura coherente.
Ejemplo Práctico de Transformación de Datos
Supongamos que el transformador de datos está configurado para convertir los datos de Ventas y Marketing en los campos valor estandarizados. Vamos a ver cómo lo haría:
Datos de Ventas en su Formato Original
Label | Valor Original |
---|---|
id_cliente_ventas | 12345 |
fname | JUAN |
lname | GÓMEZ |
reg_date | 2023-05-12 |
user_email | juan.gomez@email.com |
Datos de Marketing en su Formato Original
Label | Valor Original |
---|---|
email_user_id | MKT_56789 |
name | Juan |
lastname | Gómez |
subscription_date | 12-05-2023 |
email_address | juan.gomez@email.com |
email_platform_id | EML12345 |
Transformación a Campos Valor Estandarizados
Después de pasar por el transformador de datos, los valores de cada fuente externa se convierten y almacenan en los campos valor que hemos definido. Así quedaría la estructura final:
Dominio | Campo | Campo Valor Estandarizado | Valor Transformado |
---|---|---|---|
Ventas | ID | VEN_ID | 12345 |
Ventas | Nombre | VEN_NAME | Juan |
Ventas | Apellido 1 | VEN_LASTNAME1 | Gómez |
Ventas | VEN_EMAIL | juan.gomez@email.com | |
Marketing | ID | MAR_ID | 12345 |
Marketing | Nombre | MAR_NAME | Juan |
Marketing | Apellido | MAR_LASTNAME1 | Gómez |
Marketing | MAR_EMAIL | juan.gomez@email.com | |
Marketing | ID Email Plat. | MAR_EMAIL_ID | EML12345 |
Leyenda de los Campos Valor
- VEN_ID, VEN_NAME, VEN_LASTNAME1: Campos valor de Ventas.
- MAR_ID, MAR_NAME, MAR_LASTNAME1: Campos valor de Marketing.
El transformador de datos toma la información en bruto de cada fuente externa y la convierte en los campos valor que definimos. Esta conversión asegura que los datos estén alineados, independientemente de su origen. Cada vez que un dato nuevo ingresa al sistema, el transformador lo adapta automáticamente, creando consistencia en todo el Data Mesh.
Conclusiones
Vale, hasta aquí hemos hecho un recorrido por el Data Mesh y cómo organizar los datos para que tu empresa deje de ser un caos de hojas de cálculo sin fin. Ya tienes una base teórica para entender cómo hacer que todo esto cobre sentido en la práctica.
¿Es fácil de implementar? La verdad es que no. Esto es un marco teórico y una buena base, pero llevarlo a la realidad implica meterse en herramientas, configuraciones y algún que otro quebradero de cabeza. Es como aprender las reglas del ajedrez: fácil de decir, pero otra historia cuando estás en pleno juego.
¿Te ha picado la curiosidad y quieres realmente dominar el arte de la arquitectura de datos? Entonces, no te pierdas nuestro curso de Arquitectura de Datos. En él, desmenuzamos cada concepto, te enseñamos a usar herramientas y, sobre todo, te ayudamos a evitar esas trampas de novato que todos hemos pisado.