I dati Customer non sono soltanto un elenco di nomi e indirizzi email. In uno store e-commerce costituiscono il livello dell’account che collega identità, indirizzi, storico Orders, idoneità ai prezzi, trattamento fiscale, stato marketing, contesto dell’assistenza, relazioni B2B e logiche di segmentazione.
Un record Customer può sembrare semplice nell’area amministrativa e, allo stesso tempo, avere diversi significati operativi. Una piattaforma può rappresentare il tipo di cliente attraverso un gruppo; un’altra può usare tag, attributi cliente, aziende, listini, segmenti, estensioni o un CRM esterno. Di conseguenza, lo stesso cliente può comportarsi in modo diverso dopo essere stato rappresentato su una nuova piattaforma anche quando i campi visibili del profilo sembrano completi.
La revisione tecnica deve partire dal modello Customer: come è strutturato, a cosa serve ogni campo e quali comportamenti dipendono da logiche native della piattaforma rispetto a quelle gestite da app, plugin, moduli o sistemi esterni.
I dati Customer costituiscono il livello di identità dell’account
Il profilo Customer è il centro visibile del modello, ma raramente ne rappresenta l’intera struttura. Il profilo identifica normalmente la persona o l’organizzazione, mentre i record collegati determinano come può acquistare, ricevere Orders, accedere a determinati prezzi, comunicare con lo store e comparire nei report.
| Livello dei dati | Informazioni comuni | Funzionamento interessato |
|---|---|---|
| Identità | nome, email, telefono, ID account, username, numero cliente | ricerca account, riconoscimento al login, assistenza, associazione Orders |
| Contatti | indirizzo di fatturazione e spedizione, telefono, azienda | processo di acquisto, consegna, fatturazione, imposte e comodità per il cliente |
| Stato account | attivo, disattivato, invitato, approvato, in attesa, bloccato | accesso, attivazione account e limitazioni di acquisto |
| Classificazione | gruppo, tag, livello, segmento, tipo cliente, ruolo aziendale | prezzi, visibilità catalogo, promozioni, imposte e processi B2B |
| Consenso e comunicazioni | opt-in marketing, consenso SMS, newsletter, stato di soppressione | campagne, creazione delle audience e comunicazioni sensibili alla conformità |
| Contesto operativo | note, attributi personalizzati, commerciale, account manager, ID esterno | assistenza, collegamento CRM, integrazioni ERP/POS e gestione B2B |
| Storico relazioni | Orders, resi, abbonamenti, rewards, reviews, ticket | assistenza, loyalty, reporting e analisi degli acquisti ripetuti |
Il profilo è quindi soltanto una parte della continuità del cliente. Un’importazione tecnicamente valida può comunque risultare insufficiente se le logiche account, le classificazioni o gli identificatori esterni non vengono rappresentati correttamente.
Campi del profilo e autenticazione sono strutture diverse
I dati del profilo e l’autenticazione devono essere considerati separatamente. Una piattaforma può consentire l’importazione di nome, email, telefono e indirizzi ma limitare il trattamento di password, hash, attivazione account o sessioni di login.
Le strutture di autenticazione possono includere:
- email o username usato per il login;
- hash e salt della password o formato proprietario della piattaforma;
- stato di attivazione dell’account;
- stato dell’invito;
- obbligo di reimpostazione password;
- collegamento con login social;
- stato dell’autenticazione a più fattori;
- stato di approvazione di un account B2B;
- account disattivato, bloccato o sospeso.
Questi elementi non funzionano come normali campi del profilo. I dati password sono spesso protetti dalle regole di sicurezza e molte piattaforme non li espongono in un formato riutilizzabile. Anche quando i record Customer vengono trasferiti correttamente, i clienti esistenti possono dover ricevere un invito, reimpostare la password o completare un nuovo primo accesso.
Gli indirizzi sono record dipendenti dal processo di acquisto
Gli indirizzi sono normalmente record figlio collegati all’account Customer. Possono essere memorizzati come un singolo indirizzo predefinito, una rubrica con più indirizzi, indirizzi separati di fatturazione e spedizione oppure snapshot registrati nei singoli Orders.
I campi più comuni comprendono:
- nome e cognome;
- azienda;
- righe dell’indirizzo;
- città;
- stato, provincia o regione;
- CAP;
- codice paese;
- numero di telefono;
- campi dell’indirizzo rilevanti per le imposte;
- indicatori di indirizzo predefinito per fatturazione o spedizione;
- ID indirizzo usati dalla piattaforma o dai sistemi collegati.
La complessità deriva dalle regole di validazione. Una piattaforma può accettare una regione come testo libero, mentre un’altra richiede un codice standardizzato. Alcune richiedono il telefono per la spedizione, altre no. Alcune mantengono più indirizzi salvati, mentre altre distinguono gli indirizzi usati di recente nel processo di acquisto da quelli della rubrica.
La struttura degli indirizzi influenza più della visualizzazione: può incidere su tariffe di spedizione, regole fiscali, controlli antifrode, fatturazione, sincronizzazione ERP e processi di assistenza.
La segmentazione attribuisce un comportamento commerciale ai Customer
La segmentazione trasforma la classificazione del cliente in regole operative. Un segmento, gruppo, tag, tipo cliente, ruolo aziendale o livello può determinare ciò che il cliente vede e quali regole si applicano durante navigazione, acquisto e comunicazione.
Può controllare:
- trattamento retail o wholesale;
- accesso B2B o company account;
- listini specifici;
- prezzi per gruppo cliente;
- visibilità di cataloghi o collezioni;
- accesso a Product limitati;
- esenzione fiscale o trattamento IVA;
- idoneità alle promozioni;
- metodi di spedizione disponibili;
- metodi di pagamento;
- livello loyalty o rewards;
- stato di abbonamento, membership o approvazione;
- selezione delle audience marketing;
- priorità dell’assistenza o titolarità dell’account.
L’etichetta e il comportamento non sono la stessa cosa. Un gruppo Wholesale migrato come valore non conserva automaticamente prezzi wholesale, limitazioni del catalogo, termini di pagamento, trattamento fiscale o stato di approvazione. Il gruppo può essere trasferito come campo, mentre il comportamento deve essere ricreato tramite le regole di prezzo, catalogo, B2B, promozione o estensione della piattaforma di destinazione.
Le piattaforme usano modelli diversi per classificare i Customer
| Modello | Come viene rappresentato il significato | Rischio tecnico |
|---|---|---|
| Gruppi cliente | Il cliente appartiene a uno o più gruppi predefiniti | Il nome può migrare senza trasferire automaticamente prezzi o imposte |
| Modello basato su tag | Tag liberi classificano il cliente per regole, filtri o app | I tag possono diventare incoerenti se sono insieme etichette e trigger operativi |
| Segmenti basati su regole | L’appartenenza viene calcolata da comportamento, storico Orders, area geografica, spesa o tag | Il segmento può dover essere ricalcolato anziché importato come valore statico |
| Modello B2B aziendale | Aziende con contatti, ruoli, sedi, permessi, listini o termini di pagamento | Il singolo record Customer non conserva da solo il comportamento aziendale |
| Modello ricco di attributi | Campi Customer personalizzati conservano dati operativi | Può servire creare schema, mapping o supporto di estensioni |
| Modello gestito da estensioni | App, plugin, moduli o integrazioni definiscono la logica Customer | I record core possono migrare mentre il comportamento resta fuori dall’export |
| Modello governato da sistemi esterni | CRM, ERP, POS, loyalty, subscription o supporto possiedono parte del significato | ID esterni e regole di sincronizzazione diventano centrali quanto i campi del profilo |
Una revisione solida deve identificare il modello della piattaforma di origine, quello supportato dalla piattaforma di destinazione e distinguere le classificazioni che sono semplici etichette da quelle che attivano effettivamente un comportamento.
Le strutture B2B sono spesso modelli di relazione
Nel B2B, un Customer può appartenere a un’azienda, filiale, sede, reparto, ruolo, processo di approvazione, flusso di preventivo, struttura dei termini di pagamento o listino.
Le strutture possono comprendere:
- company account;
- più buyer sotto la stessa azienda;
- ruoli e permessi dei buyer;
- sedi aziendali;
- account di fatturazione;
- limiti di acquisto;
- termini di pagamento;
- campi di esenzione fiscale;
- listini negoziati;
- permessi per preventivi;
- stato di approvazione dell’account;
- rappresentanti commerciali assegnati;
- ID Customer ERP;
- cataloghi limitati o assortimenti specifici per cliente.
Un’importazione piatta dei Customer non può rappresentare completamente questo modello se la piattaforma di destinazione richiede record azienda, assegnazioni di ruolo o relazioni con listini. La domanda tecnica è quindi se il modello di relazione possa essere ricostruito, non soltanto se i profili possano essere importati.
Consenso marketing e stato delle comunicazioni richiedono significati precisi
I dati di marketing e comunicazione non devono essere trattati come normali recapiti. Email, telefono e stato del consenso influenzano audience, soppressione delle campagne, messaggi transazionali, newsletter e fiducia del cliente.
Tra i campi comuni rientrano:
- indirizzo email;
- numero di telefono;
- consenso all’email marketing;
- consenso SMS;
- stato di iscrizione alla newsletter;
- stato di suppression o unsubscribe;
- timestamp del consenso;
- fonte del consenso;
- preferenza di lingua o locale;
- tag Customer usati per il targeting delle campagne;
- ID delle piattaforme marketing esterne.
La difficoltà è che piattaforme e sistemi marketing possono dare a questi campi significati diversi. Un sistema può memorizzare l’iscrizione alla newsletter come attributo Customer, un altro nel provider marketing e un altro ancora può distinguere il consenso promozionale dalle comunicazioni transazionali. Un’interpretazione errata può produrre targeting sbagliato o modificare involontariamente le comunicazioni dopo il lancio.
Lo storico del cliente spesso risiede fuori dal profilo
Lo storico Customer è distribuito tra più Data Types e record. Orders, rimborsi, resi, Reviews, rewards, abbonamenti, ticket di supporto e note CRM possono riferirsi al Customer senza appartenere al record del profilo.
Punti importanti:
- gli Orders devono restare associati all’account corretto;
- gli guest Orders possono non essere collegati automaticamente a un account;
- gli indirizzi storici possono risiedere negli Orders anziché nella rubrica Customer;
- i saldi loyalty possono appartenere a un sistema esterno;
- gli abbonamenti possono essere governati da un’app o dal provider di pagamento;
- ticket e attività CRM possono usare ID Customer esterni;
- le Reviews possono riferirsi a email, ID account, ID Product o ID del sistema di review.
Un profilo può quindi migrare mentre il contesto del cliente rimane frammentato. La revisione deve identificare quali record collegati devono rimanere associati e quali ricadono fuori dallo scope standard dei dati Customer.
I segmenti dinamici non equivalgono ai segmenti memorizzati
La classificazione può essere salvata oppure calcolata. Nel primo caso il record Customer contiene un gruppo, tag, livello o campo. Nel secondo, la piattaforma calcola l’appartenenza in base a regole come numero di Orders, spesa totale, località, Product acquistati, data dell’ultimo Order o comportamento marketing.
I segmenti dinamici possono dipendere da:
- disponibilità dello storico Orders;
- relazioni Product e Category;
- paese o regione dell’indirizzo Customer;
- tag Customer o campi personalizzati;
- customer lifetime value;
- frequenza di acquisto;
- carrelli abbandonati o comportamento di navigazione;
- stato loyalty o subscription;
- dati di engagement marketing.
In una migrazione, un segmento dinamico può non essere importabile come lista fissa. Può essere necessario ricreare la regola nella piattaforma di destinazione oppure nel sistema marketing, CRM o analytics collegato. Una lista statica conserva l’appartenenza in un preciso momento; la regola dinamica conserva il criterio con cui il segmento continua ad aggiornarsi.
Gli identificatori esterni mantengono le relazioni con gli altri sistemi
Molti store usano identificatori Customer rilevanti fuori dalla piattaforma e-commerce:
- numero Customer ERP;
- ID contatto CRM;
- ID Customer POS;
- numero account loyalty;
- ID Customer subscription;
- riferimento di validazione fiscale o IVA;
- ID del richiedente nel sistema di assistenza;
- ID company account;
- ID buyer marketplace;
- ID Customer legacy della piattaforma precedente.
Perdere questi identificatori, o modificarli senza una strategia, può interrompere riconciliazione, ricerca nell’assistenza, segmentazione automatica, report account e flussi di integrazione. La revisione deve stabilire dove sono salvati e se la piattaforma di destinazione offre una posizione sicura in cui conservarli.
L’impatto della migrazione dipende dal comportamento, non soltanto dai campi
La qualità non può essere valutata soltanto contando i record. È più utile verificare se ogni tipologia di Customer continua a funzionare correttamente nella piattaforma di destinazione.
| Scenario Customer | Cosa verificare |
|---|---|
| Cliente retail abituale | profilo, rubrica indirizzi, associazione Orders, primo accesso o reset password |
| Cliente con più indirizzi | indirizzo predefinito, usabilità nel processo di acquisto, distinzione fatturazione/spedizione |
| Cliente wholesale | gruppo o azienda, prezzi, accesso al catalogo e trattamento fiscale |
| Buyer B2B | relazione aziendale, permessi, accesso alle sedi e termini di pagamento |
| Iscritto marketing | consenso, inclusione nelle audience, suppression e idoneità alle comunicazioni |
| Cliente esente da imposte | campo di esenzione, calcolo fiscale ed eventuale documentazione |
| Cliente con ID esterno | associazione CRM/ERP/POS, continuità delle integrazioni e ricerca assistenza |
| Cliente con loyalty o subscription | record esterni collegati, stato e comportamento account dopo il lancio |
Quando il risultato dipende da campi Customer personalizzati, company structure, logica di estensioni, identificatori esterni o segmentazione non standard, può essere necessario un mapping più avanzato di campi o relazioni, una trasformazione dei valori, una configurazione della piattaforma di destinazione oppure una revisione di progettazione personalizzata. La decisione deve partire dal comportamento aziendale da mantenere, non dal semplice nome del campo.
Come esaminare i dati Customer prima della migrazione
Una verifica pratica deve separare completezza del profilo e comportamento dell’account. Bisogna controllare:
- campi richiesti dalla piattaforma di destinazione;
- email univoche, duplicate, mancanti o condivise;
- compatibilità di telefono e indirizzi con le regole target;
- gruppi, tag, livelli o segmenti che modificano il comportamento;
- segmentazione memorizzata, calcolata o gestita da estensioni;
- clienti che dipendono da B2B company structure o logiche wholesale;
- campi nativi rispetto a quelli personalizzati o gestiti da estensioni;
- identificatori esterni da mantenere;
- significato dei campi di consenso marketing;
- relazioni con Orders, Reviews, loyalty, subscription o supporto;
- tipologie Customer da includere nei campioni di validazione.
Il campione migliore comprende account retail ordinari, clienti con più indirizzi, account wholesale/B2B, clienti esenti da imposte, iscritti marketing, Customer con ID esterni e account il cui funzionamento dipende da app, plugin, moduli o sistemi esterni.
Conclusione
I modelli Customer definiscono come una piattaforma riconosce persone, aziende, permessi, indirizzi, preferenze di comunicazione, idoneità ai prezzi e relazioni commerciali. Il profilo visibile è soltanto il punto di partenza. Il lavoro tecnico consiste nel distinguere dati di identità, campi che guidano il comportamento, classificazioni dinamiche e significati posseduti da estensioni o sistemi esterni.
La revisione deve dimostrare che gli scenari di account importanti continuano a funzionare dopo la migrazione: i clienti esistenti devono essere riconoscibili, gli indirizzi utilizzabili, le relazioni B2B o wholesale correttamente rappresentate, il consenso interpretato con precisione e gli identificatori esterni mantenuti quando l’azienda ne dipende. Quando il comportamento si basa su campi personalizzati, segmentazione, company account o ID esterni, bisogna stabilire se il mapping diretto è sufficiente o se servono trasformazione, configurazione target o progettazione personalizzata.
Domande frequenti
Migrare il profilo Customer equivale a mantenere l’accesso dell’account?
No. Profilo e autenticazione sono livelli diversi. Nome, email, telefono e indirizzi possono essere migrati mentre password, attivazione o primo accesso devono rispettare le regole di sicurezza della piattaforma di destinazione.
Perché gruppi o tag possono migrare ma comportarsi in modo diverso?
Perché spesso sono soltanto classificazioni. Prezzi, visibilità catalogo, imposte, promozioni e accesso B2B possono dipendere da regole separate, listini, app, plugin, moduli o sistemi esterni.
Qual è la differenza tra segmentazione memorizzata e dinamica?
La segmentazione memorizzata è salvata direttamente sul Customer come gruppo, tag, livello o campo. Quella dinamica è calcolata da regole come storico Orders, spesa, località, Product acquistati o comportamento marketing. Le regole dinamiche possono dover essere ricostruite anziché importate come membership statica.
Perché gli ID Customer esterni sono importanti?
Perché collegano i Customer a ERP, CRM, POS, loyalty, subscription, marketing, sistemi fiscali e piattaforme di assistenza. Se vengono persi o modificati senza pianificazione, questi sistemi possono non riconoscere più il cliente corretto.
Quali Customer devono essere validati per primi?
Quelli con maggiore significato operativo: clienti abituali, account con più indirizzi, wholesale o B2B, esenti da imposte, iscritti marketing, Customer con ID esterni e clienti collegati a loyalty, subscription, membership o workflow di approvazione.