Il CRM ha tre pipeline diverse: devo creare tre conversioni nelle campagne?

Un’azienda usa una pipeline per i preventivi, una per le vendite dirette e una per i rinnovi. Ogni flusso ha nomi diversi: “Chiuso vinto”, “Contratto attivo”, “Ordine confermato”. Bisogna creare tre conversioni nelle piattaforme pubblicitarie?

Non necessariamente. Le pipeline descrivono come lavora l’azienda; le conversioni devono descrivere risultati comparabili. Prima di inviare qualsiasi evento, costruirei un livello di normalizzazione che traduca stati diversi in pochi esiti commerciali stabili.

La pipeline non è il dizionario delle campagne

Duplicare nelle piattaforme ogni fase del CRM sembra preciso, ma crea tre problemi:

• lo stesso risultato può essere contato più volte se un record passa tra pipeline;
• un cambio di nome nel CRM può interrompere il mapping;
• le campagne ricevono eventi troppo frammentati per essere letti e confrontati con chiarezza.

Terrei quindi separati stato operativo ed evento pubblicitario. Il primo può essere specifico per reparto; il secondo risponde a una definizione aziendale, per esempio qualified_lead, sale, renewal o cancellation.

Questa distinzione completa quanto spiegato nell’articolo su lead, qualificazione e contratto come obiettivi distinti: qui il problema non è scegliere il risultato giusto, ma riconoscerlo dentro processi commerciali diversi.

Prima crea una tabella di equivalenza

Per ogni pipeline documenterei:

• ID tecnico della fase, non soltanto l’etichetta visibile;
• evento canonico associato;
• condizioni aggiuntive, come valore positivo o contratto non annullato;
• momento reale dell’evento;
• ID univoco da usare per retry e deduplicazione;
• destinazioni autorizzate a riceverlo.

“Chiuso vinto”, “Ordine confermato” e “Contratto attivo” possono confluire in sale se rappresentano davvero lo stesso fatto economico. “Rinnovo completato” resta invece renewal, perché è una nuova transazione ma non una nuova acquisizione, come chiarito nella guida su rinnovi e ricavi ricorrenti.

Google riceve eventi verso azioni di conversione precise

Nella Data Manager API, la destinazione identifica sia l’account sia l’entità che riceve il dato; per Google Ads, il product destination ID è l’ID dell’azione di conversione. Non basta quindi inviare un generico “won”: il router deve sapere a quale azione è destinato. Fonte: Google Data Manager API, destinazioni.

Se una richiesta contiene eventi per più azioni, Google permette di collegare ogni evento al riferimento della destinazione corretta. Questo supporta una mappatura esplicita, ma non obbliga a creare un’azione per ogni pipeline. Fonte: Google Data Manager API, mapping dei campi.

Creerei azioni separate quando cambia il significato commerciale — per esempio lead qualificato e vendita — non quando cambia soltanto il reparto che ha lavorato il record.

LinkedIn distingue già diversi esiti del funnel

LinkedIn Conversions API richiede una regola per ogni tipo di conversione tracciato. Lo schema attuale include, tra gli altri, QUALIFIED_LEAD, MARKETING_QUALIFIED_LEAD, SALES_QUALIFIED_LEAD e PURCHASE; MQL e SQL sono disponibili dalle versioni API 202608. Fonte: LinkedIn Marketing API, schema Conversions API.

Questi tipi aiutano a rappresentare risultati diversi, non i nomi interni delle pipeline. Se due reparti producono entrambi un sales qualified lead secondo la stessa definizione, li invierei alla medesima regola, conservando la pipeline come dimensione del CRM.

Meta deve ricevere un nome evento coerente

Negli esempi ufficiali della Conversions API, l’evento server contiene event_name, momento, dati utente, origine e, quando pertinente, valore e valuta. L’SDK mostra per esempio un evento Purchase costruito dal server. Fonte: Meta Business SDK, Conversions API.

Non userei quindi “Pipeline A - Chiuso” e “Pipeline B - Confermato” come due acquisti diversi se descrivono la stessa vendita. Il nome canonico resta stabile; pipeline, reparto o prodotto possono viaggiare come metadati dove supportati e utili, senza trasformarsi automaticamente in nuove conversioni.

Dove entra il server-side tracking

Il server container può applicare la traduzione prima di distribuire l’evento. Il Data Tag di Stape consente eventi standard o personalizzati e il passaggio di event data verso server-side GTM; l’Event Generator può modificare e unificare i nomi nel container. Fonte: Stape, Data Tag.

Questa possibilità tecnica non sostituisce la tabella di equivalenza. Se la regola è sbagliata, il server la applicherà con grande efficienza a tutti gli eventi.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: l’azienda ha tre pipeline. Nella prima la vendita è “Contratto firmato”; nella seconda “Ordine confermato”; nella terza “Rinnovo attivo”.

Il mapping produce sale per i primi due stati, ma soltanto se esistono ID contratto, valore e data. Il terzo produce renewal. Se un’opportunità viene spostata dalla prima alla seconda pipeline, conserva lo stesso ID evento: il trasferimento non crea una nuova vendita.

Il router manda sale alle azioni di acquisizione previste e renewal soltanto alle destinazioni dedicate alla retention. Ogni invio mantiene uno stato distinto, seguendo l’architettura descritta nella guida su un evento CRM e più piattaforme.

Il test prima della pubblicazione

Simulerei almeno un record per pipeline, un trasferimento tra pipeline, un cambio di etichetta e un retry. Verificherei che il conteggio delle vendite non aumenti durante il trasferimento e che ogni evento raggiunga l’azione corretta. Aggiungerei infine una versione al mapping: quando cambia una regola, deve essere possibile capire quale logica ha prodotto gli eventi storici.

La struttura corretta non è “una pipeline, una conversione”. È “un significato commerciale, una definizione stabile”. Le pipeline possono moltiplicarsi; i segnali inviati alle campagne devono restare comprensibili, verificabili e coerenti con ciò che l’azienda considera davvero lead qualificato, vendita o rinnovo.

Fonti ufficiali consultate il 6 novembre 2026. L’esempio è ipotetico. Disponibilità degli eventi, requisiti e configurazioni dipendono dalla piattaforma e dall’account; questa architettura non garantisce risultati pubblicitari.