Los datos de clientes no son únicamente una lista de nombres y direcciones de email. En una tienda de comercio electrónico forman la capa de cuenta que conecta identidad, direcciones, historial de Orders, elegibilidad de precios, tratamiento fiscal, estado de marketing, contexto de soporte, relaciones B2B y lógica de segmentación.
Un registro de cliente puede parecer sencillo en el panel administrativo y contener varios significados operativos en segundo plano. Una plataforma puede guardar el tipo de cliente como group. Otra puede utilizar etiquetas, customer atributos, companies, listas de precios, customer segments, extensiones o un CRM externo. Por eso, el mismo cliente puede comportarse de forma distinta cuando se representa en otra plataforma aunque los campos visibles del perfil parezcan completos.
La revisión técnica debe empezar por comprender cómo está estructurado el modelo de cliente, para qué utiliza la tienda cada campo y qué comportamientos dependen de la lógica nativa de la plataforma frente a aplicaciones, plugins, módulos o sistemas externos.
Los datos de clientes actúan como capa de identidad de cuenta
El perfil es el centro visible del modelo, pero rara vez representa todo. Normalmente identifica a la persona u organización, mientras que registros relacionados determinan cómo puede comprar, recibir pedidos, acceder a precios, comunicarse con la tienda y aparecer en informes.
Un modelo típico puede incluir:
| Capa de datos | Información habitual | Funcionamiento afectado |
|---|---|---|
| Identidad | nombre, email, teléfono, account ID, username, customer number | búsqueda de cuenta, reconocimiento de login, soporte y asociación con Orders |
| Datos de contacto | dirección de facturación, envío, teléfono, empresa | proceso de compra, entrega, facturación, impuestos y comodidad del cliente |
| Estado de cuenta | active, disabled, invited, aplicaciónroved, pending, locked | acceso, activación y restricciones de compra |
| Clasificación | group, etiqueta, tier, segment, customer type, company role | precios, visibilidad de catálogo, promociones, impuestos y B2B |
| Consentimiento y comunicación | marketing opt-in, SMS consent, newsletter status, suppression state | campañas, audiences y comunicación sensible a cumplimiento |
| Contexto operativo | notas, custom atributos, sales rep, account manager, identificador externo | soporte, CRM, ERP/POS y gestión B2B |
| Historial de relaciones | Orders, returns, suscripciones, rewards, reseñas, tickets | servicio al cliente, fidelización, informes y repetición de compra |
El perfil es solo una parte de la continuidad. Una importación técnicamente válida puede fallar si la lógica relacionada, los datos de clasificación o identificadores externos no se representan correctamente.
Los campos de perfil y la autenticación son estructuras distintas
Los datos de perfil y la autenticación deben tratarse como capas separadas. Una plataforma puede permitir importar nombres, emails, teléfonos y direcciones mientras restringe passwords, password hashes, activación de cuenta o sesiones.
Estructuras habituales de autenticación:
- email o username utilizado para iniciar sesión;
- password hash, salt o formato específico de contraseña;
- estado de activación;
- invitation status;
- requisito de password reset;
- social-login connection;
- multi-factor authentication status;
- estado de aprobación B2B;
- estado disabled, locked o suspended.
Estos campos no se comportan como datos ordinarios de perfil. Las contraseñas suelen estar protegidas por reglas de seguridad y muchas plataformas no las exponen en un formato reutilizable. Incluso con registros migrados correctamente, los clientes recurrentes pueden necesitar una invitación, restablecer la contraseña o completar un primer acceso.
Las direcciones son registros hijos con dependencias de proceso de compra
Las direcciones suelen ser registros dependientes asociados a la cuenta. Pueden almacenarse como una dirección predeterminada, múltiples entradas, direcciones separadas de billing/envío o snapshots a nivel de Order.
Suelen contener:
- nombre y apellidos;
- empresa;
- líneas de calle;
- ciudad;
- estado, provincia o región;
- código postal;
- country code;
- teléfono;
- campos fiscales de dirección;
- marcadores de billing o envío por defecto;
- IDs de dirección utilizados por la plataforma o sistemas conectados.
La complejidad proviene de las reglas de validación. Una plataforma puede aceptar regiones de texto libre y otra exigir un código normalizado. Algunas requieren teléfono para envío y otras no. Algunas permiten múltiples direcciones guardadas; otras diferencian las recientes usadas en proceso de compra de las del address book.
El modelo de direcciones afecta a mucho más que la visualización: puede influir en envío-rate calculation, impuestos, comprobaciones antifraude, facturación, sincronización con ERP y flujos de trabajo de atención.
La segmentación da comportamiento comercial a los registros de clientes
La segmentación convierte datos de clientes en lógica empresarial. Un segment, group, etiqueta, customer type, company role o tier puede determinar qué ve el cliente y qué reglas se aplican al navegar, comprar o recibir comunicaciones.
Puede controlar:
- tratamiento retail frente a mayorista;
- acceso B2B o company-account;
- listas de precios específicas;
- customer-group precios;
- visibilidad de catálogos o colecciones;
- acceso restringido a productos;
- tax exemption o VAT tratamiento;
- elegibilidad de promociones;
- métodos de envío disponibles;
- métodos de pago;
- fidelización tier o rewards status;
- suscripción, membership o aprobación status;
- selección de marketing audiences;
- prioridad de soporte o propiedad de cuenta.
El detalle clave es que la etiqueta y el comportamiento no son lo mismo. Migrar un group llamado mayorista no conserva automáticamente precios mayoristas, restricciones de catálogo, pago terms, tratamiento fiscal o estado de aprobación. El group puede moverse como campo y el comportamiento tener que reconstruirse mediante precios, catálogo, B2B, promociones o extensiones de la plataforma de destino.
Las plataformas utilizan modelos diferentes de clasificación de clientes
La clasificación varía mucho. Algunas plataformas utilizan grupos fijos. Otras etiquetas flexibles. Otras segmentos dinámicos calculados mediante reglas. Algunas representan B2B mediante cuentas de empresa y contactos. Otras dependen de extensiones o sistemas externos.
| Modelo | Cómo se representa el significado | Riesgo técnico |
|---|---|---|
| Customer group | Clientes en grupos predefinidos | El nombre puede migrar y las reglas de precio/impuestos no seguir automáticamente |
| Tag-based | Tags libres para reglas, filtros o aplicaciones | Pueden volverse inconsistentes si sirven a la vez como etiquetas y activadores operativos |
| Rule-based segment | Segmentos calculados desde comportamiento, Orders, ubicación, gasto o etiquetas | La pertenencia puede necesitar recalcularse en vez de importarse estáticamente |
| B2B company modelo | Companies con contactos, roles, locations, permissions, listas de precios o pago terms | El registro individual no preserva por sí solo el comportamiento de empresa |
| Basado intensivamente en atributos | Custom customer campos almacenan datos operativos | Puede requerir crear esquema, mapeo o soporte de extensión |
| Extension-driven | Apps, plugins, módulos o integraciones definen lógica | El registro core puede moverse y el comportamiento quedar fuera del export |
| External-system | CRM, ERP, POS, fidelización, suscripción o soporte poseen parte del significado | External IDs y reglas de sincronización se vuelven tan importantes como el perfil |
Una revisión sólida debe identificar qué modelo utiliza origen, cuál admite destino y qué clasificaciones son simples etiquetas frente a verdaderos drivers de comportamiento.
Las estructuras B2B suelen ser modelos relacionales
Los datos B2B suelen ir más allá de cuentas individuales. Un comprador puede pertenecer a company, branch, location, department, role, aprobación flujo de trabajo, proceso de cotización, pago terms o price-list assignment.
Pueden incluir:
- cuentas de empresa;
- varios compradores bajo una empresa;
- buyer roles y permissions;
- company locations;
- billing accounts;
- purchase limits;
- pago terms;
- campos de tax exemption;
- negotiated listas de precios;
- quote permissions;
- aprobación status;
- sales representatives asignados;
- ERP customer IDs;
- catálogos restringidos o assortments específicos.
Una importación plana no puede representar completamente esta estructura si la plataforma de destino espera registros de empresa, roles o relaciones de listas de precios. La pregunta técnica no es solo si pueden importarse perfiles, sino si el modelo relacional puede representarse.
El consentimiento de marketing y el estado de comunicación necesitan significado preciso
Los datos de marketing y comunicación no deben tratarse como información de contacto ordinaria. Email, teléfono y consent status afectan audience building, suppression, mensajes transaccionales, newsletters y confianza.
Campos habituales:
- email;
- teléfono;
- email marketing consent;
- SMS consent;
- newsletter suscripción status;
- suppression o unsubscribe status;
- consent timestamp;
- consent origen;
- preferencia de idioma o locale;
- customer etiquetas para targeting;
- IDs de plataformas externas de marketing.
El reto es que plataformas y sistemas de marketing pueden definirlos de forma distinta. Un sistema puede guardar el newsletter status como atributo de cliente. Otro guardar el consentimiento en una plataforma de marketing. Otro separar comunicación transaccional y promocional. Una interpretación incorrecta puede generar targeting deficiente o cambios accidentales después del lanzamiento.
El historial del cliente suele vivir fuera del perfil
El historial suele distribuirse entre Data Types y registros relacionados. Order history, refunds, returns, reseñas, reward points, suscripciones, support tickets y CRM notes pueden referenciar al cliente sin vivir dentro del perfil.
Puntos importantes:
- Orders deben seguir asociados a la cuenta correcta;
- guest orders pueden no asociarse automáticamente;
- direcciones históricas pueden existir en Orders y no en el address book;
- fidelización balances pueden pertenecer a un sistema de fidelización;
- suscripción status puede estar controlado por una aplicación o pago proveedor;
- tickets y CRM activities pueden usar IDs externos;
- reseñas pueden referenciar email, account ID, product ID o reseña-system IDs.
Por eso, un perfil puede migrar y el contexto quedar fragmentado. La revisión debe identificar qué registros vinculados necesitan conservar conexión y cuáles quedan fuera del alcance estándar de customer data.
Los segmentos dinámicos no son lo mismo que los segmentos almacenados
La segmentación puede almacenarse o calcularse. Una clasificación almacenada guarda un group, etiqueta, tier o campo. La dinámica calcula pertenencia según reglas como número de Orders, gasto total, ubicación, producto comprado, fecha del último pedido o comportamiento de marketing.
Puede depender de:
- disponibilidad del historial de Orders;
- relaciones de productos y categorías;
- país o región de la dirección;
- etiquetas o campos personalizados;
- customer lifetime value;
- frecuencia de compra;
- abandoned-cart o browsing behavior;
- fidelización o suscripción status;
- marketing engagement.
Al cambiar de plataforma, un segmento dinámico puede no poder importarse como lista fija. Puede necesitar reconstruirse como regla en la plataforma de destino o en un sistema conectado de marketing, CRM o analítica. Los etiquetas estáticos conservan pertenencia en un momento; las reglas dinámicas conservan la lógica que mantiene el segmento actualizado.
Los identificadores externos protegen relaciones entre sistemas
Muchas tiendas utilizan identificadores que importan fuera de la plataforma: ERP, CRM, POS, help desk, marketing, tax, fidelización o suscripción.
Pueden incluir:
- ERP customer number;
- CRM contact ID;
- POS customer ID;
- fidelización account number;
- suscripción customer ID;
- tax o VAT validation reference;
- support-desk requester ID;
- cuenta de empresa ID;
- marketplace buyer ID;
- legacy platform customer ID.
Perder o remapear mal estos identificadores puede romper reconciliación, búsquedas de soporte, segmentación automática, informes e integraciones. La revisión debe determinar dónde se almacenan y si el destino dispone de un lugar seguro para preservarlos.
El impacto de la migración depende del comportamiento, no solo de los campos
La calidad no puede medirse únicamente por recuentos. Una pregunta más útil es si cada tipo de cliente sigue comportándose correctamente en la plataforma de destino.
| Escenario | Qué verificar |
|---|---|
| Returning retail customer | perfil, address book, asociación de Orders y first-login/password reset |
| Cliente con varias direcciones | funcionamiento de las direcciones predeterminadas, proceso de compra y separación billing/envío |
| mayorista customer | asignación de group/company, visibilidad de precios, acceso de catálogo y tax treatment |
| B2B company buyer | relación con company, role permissions, locations y pago terms |
| Marketing subscriber | consent status, audience inclusion, suppression y elegibilidad de comunicación |
| Tax-exempt customer | exemption campo, cálculo fiscal y documentación si aplica |
| Cliente con identificador externo | correspondencia CRM/ERP/POS, integraciones y lookup de soporte |
| Cliente con fidelización o suscripción history | registros externos vinculados, interpretación de estado y comportamiento post-launch |
Cuando el resultado depende de custom customer campos, company structures, extensión-driven lógica, identificadores de sistemas externos o segmentación no estándar, puede ser necesario advanced campo/relationship mapeo, transformación de valores, ajustes de configuración o revisión de diseño personalizado. La revisión debe centrarse en el comportamiento que debe sobrevivir, no solo en el nombre del campo.
Cómo inspeccionar customer data antes de la migración
Una auditoría práctica debe separar completitud del perfil y comportamiento de cuenta.
Antes de migrar, revisa:
- qué campos exige la plataforma de destino;
- si los emails son únicos, duplicados, ausentes o compartidos;
- si teléfonos y direcciones cumplen las reglas del destino;
- qué grupos, etiquetas, tiers o segments afectan a comportamiento;
- si la segmentación es almacenada, rule-based o extensión-driven;
- qué clientes dependen de B2B companies o mayorista lógica;
- qué campos son nativos y cuáles custom o de extensiones;
- qué identificadores externos deben seguir disponibles;
- si los campos de consentimiento tienen significado claro;
- si Order history, reseñas, fidelización, suscripciones o soporte deben seguir conectados;
- qué tipos de cliente deben incluirse en representative validation.
La mejor muestra incluye cuentas retail normales, clientes con varias direcciones, cuentas mayorista o B2B, tax-exempt customers, marketing subscribers, clientes con identificadores externos y clientes cuyo comportamiento depende de aplicaciones, plugins, módulos o sistemas externos.
Conclusión
Los modelos de customer data definen cómo una plataforma reconoce personas, empresas, permisos, direcciones, preferencias de comunicación, elegibilidad de precios y relaciones. El perfil visible es solo el punto de partida. El trabajo técnico más profundo consiste en entender qué campos son identidad, cuáles controlan comportamiento, qué clasificaciones son reglas dinámicas y qué significados pertenecen a extensiones o sistemas externos.
La revisión debe demostrar que los escenarios importantes siguen funcionando: los clientes recurrentes pueden ser reconocidos, las direcciones son utilizables, las relaciones B2B o mayorista están correctamente representadas, los consentimientos se interpretan con precisión y los identificadores externos permanecen conectados donde el negocio depende de ellos. Si el comportamiento depende de campos personalizados, segmentación, cuentas de empresa o IDs externos, determina si basta el mapeo directo o si se necesita transformación, configuración de destino o diseño personalizado.
Preguntas frecuentes
¿Migrar el perfil del cliente es lo mismo que preservar el acceso de login?
No. Perfil y autenticación son capas diferentes. Nombres, emails, teléfonos y direcciones pueden migrarse mientras passwords, activación o first-login deben seguir las reglas de seguridad del destino.
¿Por qué pueden migrarse grupos de clientes o etiquetas y comportarse distinto?
Porque un group o etiqueta suele ser solo una etiqueta. Precios, visibilidad de catálogo, impuestos, promociones y acceso B2B pueden depender de reglas, listas de precios, aplicaciones, plugins, módulos o sistemas externos separados.
¿Cuál es la diferencia entre segmentación almacenada y dinámica?
La almacenada se guarda directamente en el registro como group, etiqueta, tier o campo. La dinámica se calcula mediante reglas como historial de Orders, gasto, ubicación, productos comprados o marketing behavior. Las reglas dinámicas pueden necesitar reconstruirse en vez de importarse como membership estático.
¿Por qué son importantes los external customer IDs?
Conectan los registros con ERP, CRM, POS, fidelización, suscripción, marketing, tax y soporte. Si se pierden o cambian sin planificación, los sistemas conectados pueden dejar de hacer correspondencia correcto.
¿Qué registros de clientes deben validarse primero?
Prioriza aquellos con significado operativo: repeat buyers, clientes con varias direcciones, mayorista/B2B, tax-exempt, marketing subscribers, clientes con identificadores externos y cuentas ligadas a fidelización, suscripción, membership o aprobación flujos de trabajo.