Email e telefono dal CRM: vanno inviati in chiaro o con SHA-256?

Il CRM registra una vendita e l’automazione deve rimandarla alle piattaforme. Per associarla alle interazioni pubblicitarie, il sistema può usare email e telefono del cliente. Ma vanno inviati in chiaro, trasformati con SHA-256 oppure affidati al connettore?

La risposta corretta non è “hasha tutto”. Devi stabilire quale identificatore accetta ogni destinazione, chi lo normalizza e in quale punto viene trasformato. Un hash applicato male non protegge il processo e, molto più banalmente, può impedire qualsiasi corrispondenza.

Normalizzare viene prima di fare hashing

SHA-256 produce risultati diversi anche per piccole differenze nel valore di partenza. Mario@Esempio.it e mario@esempio.it generano due digest diversi; lo stesso vale per un telefono con o senza prefisso internazionale. Per questo le piattaforme definiscono regole di normalizzazione.

Nel flusso dal CRM separerei quattro passaggi:

• validare che email e telefono appartengano davvero al contatto associato alla vendita;
• normalizzare il valore secondo le regole della destinazione;
• applicare SHA-256 soltanto se l’API o il tag lo richiedono in quel punto;
• inviare l’identificatore nel campo corretto, insieme all’evento commerciale.

Questa pipeline completa il registro descritto nell’articolo su come distribuire una vendita a Google, Meta e LinkedIn: l’evento interno resta unico, mentre ogni adattatore prepara il proprio payload.

Google Ads: l’API offline si aspetta valori già trasformati

Per le conversioni offline con dati forniti dall’utente, Google Ads indica che email e telefono devono essere normalizzati e sottoposti ad hashing SHA-256 prima dell’importazione. L’email va ripulita dagli spazi esterni e convertita in minuscolo; il telefono va portato nel formato E.164 prima dell’hash. Nel flusso UploadClickConversions, gli identificatori supportati sono hashed_email e hashed_phone_number. Fonte: Google Ads API, conversioni offline.

Per Gmail e Googlemail, Google documenta anche la rimozione di punti e suffisso con “+” prima dell’hash. Userei quindi le regole del metodo scelto, non una funzione generica interna.

Meta: il Business SDK può normalizzare e fare hashing

Con Meta Conversions API il comportamento dipende anche dallo strumento usato. I Business SDK ufficiali accettano dati utente come email e telefono e possono normalizzarli e sottoporli automaticamente a SHA-256 tramite il Parameter Builder. Fonte: Meta Business SDK, Conversions API.

Non applicare quindi SHA-256 “per sicurezza” senza conoscere il componente: se l’SDK trasforma di nuovo un digest, ottieni l’hash dell’hash, inutile per il matching. Il contratto tecnico deve dichiarare se il campo entra come raw normalizzato o come SHA-256 esadecimale; i log di debug non dovrebbero conservare i valori personali in chiaro.

LinkedIn non accetta automaticamente gli stessi identificatori

LinkedIn Conversions API supporta, tra gli identificatori, SHA256_EMAIL e il click ID proprietario. La documentazione specifica che l’email viene trasformata con SHA-256 senza salt e raccomanda di convertirla in minuscolo prima dell’hashing. Richiede almeno un identificatore valido o una delle combinazioni alternative previste. Fonte: LinkedIn, Conversions API FAQ.

Il punto importante è ciò che non va dato per scontato: lo schema corrente non presenta il telefono come equivalente universale dell’email per questo flusso. Un CRM che conserva entrambi non deve spedirli indiscriminatamente a tutte le API. Il modello interno può essere ricco; l’adattatore deve inviare soltanto i campi ammessi e necessari.

Dove entra il server-side con Stape?

Un container server-side può diventare il punto nel quale controllare, rimuovere o trasformare i valori prima delle chiamate alle piattaforme. Il Data Tag di Stape, per esempio, prevede trasformazioni come minuscolo, eliminazione degli spazi e SHA-256 in diversi formati. Fonte: Stape, Data Tag.

La funzione non decide però dove usarla: CRM, middleware, server GTM o tag finale possono occuparsene. Assegna la trasformazione a un solo componente e documentala. Il server-side offre controllo sul payload, ma non recupera un consenso assente né amplia le finalità consentite, come spiego nell’articolo su che cosa può recuperare davvero il server-side tracking.

Un hash non rende automaticamente anonimo il cliente

Un digest deterministico dell’email è progettato proprio per consentire il confronto con un valore corrispondente. Non va quindi trattato come un lasciapassare privacy. L’European Data Protection Board chiarisce che i dati pseudonimizzati che possono essere ricollegati a una persona restano dati personali, anche quando le informazioni aggiuntive sono detenute da un’altra parte. Fonte: EDPB, linee guida sulla pseudonimizzazione.

Prima dell’invio servono quindi finalità definite, configurazioni coerenti con il consenso e la base applicabile, informativa e minimizzazione. L’hashing è una misura tecnica; non sostituisce la valutazione del trattamento. Per il comportamento dei tag quando l’utente rifiuta trovi un approfondimento su Consent Mode v2 e rifiuto dei cookie.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: il CRM chiude l’opportunità OP-731 e produce un evento vendita. Il record contiene un’email verificata e un telefono italiano.

Google riceve email e telefono normalizzati e trasformati come previsto. Il Business SDK di Meta esegue la trasformazione una volta; LinkedIn riceve l’email come SHA256_EMAIL, non anche il telefono soltanto perché disponibile. Il registro conserva stato e risposta delle API, senza stampare i valori personali nei log. Un test verifica che il digest sia stabile e non venga trasformato due volte.

La checklist prima di attivare gli invii

• Elenca gli identificatori accettati da ogni API e dal metodo realmente utilizzato.
• Definisci le regole di normalizzazione per email e telefono.
• Assegna a un solo componente la responsabilità dell’hashing.
• Controlla formato del digest, campi di destinazione e possibili doppi hash.
• Rimuovi i valori personali dai log non necessari.
• Testa consenso concesso e negato secondo la configurazione prevista.
• Verifica errori e qualità del matching senza trasformarli in promesse di risultato.

Il risultato utile non è “avere più hash”. È trasmettere meno dati, nel formato corretto, alla destinazione corretta e con una responsabilità tecnica chiara. La qualità del segnale nasce prima dell’algoritmo SHA-256: nasce da un CRM ordinato e da un’integrazione che sa esattamente perché sta usando ogni campo.

Fonti ufficiali consultate il 31 ottobre 2026. L’esempio è ipotetico. Requisiti delle piattaforme e valutazioni privacy dipendono dall’integrazione e dal caso concreto; questa configurazione non garantisce risultati pubblicitari.