Quali dati deve conservare il CRM per rimandare le vendite a Google e Meta?

Il commerciale segna una trattativa come vinta. Da quel momento la vendita può diventare un segnale utile per le campagne, ma soltanto se il CRM conserva abbastanza informazioni per ricostruire il percorso. Un generico «cliente acquisito» non dice da quale annuncio è arrivato, quando ha convertito, quanto vale né se lo stesso evento è già stato inviato.

Il punto non è riempire il CRM di campi. È mantenere una catena minima e verificabile tra contatto, attività commerciale e piattaforma pubblicitaria. Ecco quali dati valuterei prima di costruire automazioni con Stape, API o connettori nativi.

1. Un identificativo interno stabile

Ogni contatto e ogni opportunità dovrebbero avere un identificativo che non cambi quando vengono aggiornati nome, email o stato. Serve per collegare record, gestire duplicati e capire se un invio è già partito. L’email non è un buon identificativo interno universale: può essere corretta, condivisa, assente o presente su più trattative.

Separerei almeno ID del contatto, ID dell’opportunità e, quando esiste, ID del contratto o dell’ordine. Una persona può avere più opportunità; una nuova vendita non deve sovrascrivere la storia precedente.

2. La fonte originale, non soltanto l’ultima visita

Conserva i parametri di campagna disponibili e gli identificativi pubblicitari raccolti nel rispetto delle scelte dell’utente: per esempio GCLID per Google e fbc/fbp nell’ecosistema Meta. Meta elenca fbc come click ID e fbp come browser ID tra i parametri utilizzabili dalla Conversions API; email e telefono richiedono hashing, mentre questi identificativi non vanno hashati. Fonte: Meta, parametri della Conversions API.

Non ridurre tutto a un campo «fonte = social». Mantieni i valori grezzi necessari e crea campi leggibili per i report. Così puoi correggere la classificazione senza perdere l’informazione originaria. Se un identificativo non è disponibile, il sistema deve accettarlo: non ogni vendita sarà attribuibile a una campagna.

3. Il dato di contatto usato per il collegamento

Google descrive le conversioni avanzate per i lead come un’evoluzione dell’import offline che usa dati proprietari forniti dall’utente, come email e telefono sottoposti ad hashing, per collegare gli esiti del CRM alle interazioni pubblicitarie. Dal 15 giugno 2026 Google indica Data Manager API come percorso per gli upload correnti e futuri, con limitazioni sull’accesso legacy tramite Google Ads API. Fonte: Google Ads, conversioni avanzate per i lead.

Nel CRM conserva il dato normalizzato in modo coerente e registra da dove proviene. L’hashing va applicato nel punto previsto dall’integrazione: non sostituisce qualità, consenso o sicurezza del dato. Una mail digitata male rimane inutilizzabile anche dopo una trasformazione crittografica.

4. Stato commerciale, data effettiva e valore

Tre campi devono restare distinti: stato, data dell’esito e valore. La data del contratto non è quella in cui il commerciale aggiorna il CRM. Il valore del preventivo non è automaticamente il valore firmato; il valore firmato non coincide sempre con l’incassato.

Esempio ipotetico: un lead entra il 3 settembre, firma il 21 e viene aggiornato nel CRM il 24. L’evento commerciale è del 21. Registrare soltanto l’ultima modifica sposta artificialmente la conversione e rende più difficile leggere i tempi reali del funnel.

Definisci anche valuta, annullamenti e rettifiche. Se una vendita viene revocata, deve esistere una procedura per correggere il dato nei report compatibili, non un secondo evento positivo.

5. Un registro degli invii

Per ogni piattaforma salverei almeno tipo di evento, momento dell’invio, esito tecnico, tentativi ed eventuale identificativo della risposta. Su Meta, quando lo stesso evento arriva dal browser e dal server, event_name ed event_id servono alla deduplicazione. Senza una chiave coerente, due copie dello stesso acquisto possono essere interpretate male. Fonte: Meta, deduplicazione degli eventi Pixel e server.

«Automazione eseguita» non significa «evento accettato». Il registro rende visibili scarti, duplicati e reinvii e permette di verificare un campione dal CRM fino alla piattaforma.

6. Consenso e regole d’uso del dato

Il server-side non rende invisibile il trattamento dei dati. Google richiede che l’uso dei dati dei clienti sia comunicato, per esempio nella privacy policy, e che venga raccolto il consenso dove richiesto; disciplina anche il ruolo di eventuali soggetti terzi che caricano dati per conto dell’inserzionista. Fonte: norme Google sui dati dei clienti.

Per l’integrazione Meta, la documentazione richiama avvisi adeguati e consenso secondo i Business Tools Terms. Fonte: Meta, prerequisiti della Conversions API. La configurazione concreta va valutata con chi segue la compliance dell’azienda: questo articolo non sostituisce una consulenza legale.

La verifica prima dell’automazione

• Prendi dieci opportunità vinte e ricostruisci manualmente fonte, data e valore.
• Controlla quanti record hanno identificativi pubblicitari o dati di contatto utilizzabili.
• Confronta la definizione degli stati tra commerciali diversi.
• Verifica duplicati, annullamenti e vendite aggiornate in ritardo.
• Decidi quali eventi osservare e quale, eventualmente, usare per l’ottimizzazione.

Solo dopo progetterei il flusso: campagna → identificativo persistito → CRM → esito commerciale → postback. Se uno degli anelli è ambiguo, automatizzare significa produrre più velocemente un dato sbagliato.

Puoi approfondire quale conversione dovrebbe guidare Google Ads e come leggere i ritardi tra lead e vendita. Per mappare il tuo flusso attuale, guarda il sistema completo oppure descrivimi campagne, CRM e processo commerciale.

Fonti ufficiali verificate il 29 settembre 2026. L’esempio è ipotetico. L’invio di segnali non garantisce risultati pubblicitari.