Posso inviare la stessa vendita a Google, Meta e LinkedIn con un solo webhook?

Il CRM registra una vendita. A quel punto Google, Meta e LinkedIn dovrebbero ricevere il segnale, così le campagne possono essere lette anche rispetto a ciò che accade dopo il lead. La tentazione è comprensibile: creare un webhook, spedire lo stesso JSON a tutti e considerare chiuso il lavoro.

La risposta breve è: un solo evento interno è una buona idea; un solo payload universale no. Ogni piattaforma richiede campi, identificatori e regole proprie. Il webhook centrale deve raccontare il fatto commerciale una volta sola; tre adattatori devono tradurlo senza cambiarne il significato.

Il CRM deve produrre un evento aziendale, non un evento pubblicitario

Partirei da una struttura indipendente dalle piattaforme. Quando una trattativa raggiunge lo stato scelto — per esempio contratto firmato o pagamento confermato — il CRM genera un evento stabile con:

• un ID interno univoco della vendita o dell’ordine;
• tipo di evento e stato commerciale;
• data e ora in cui il fatto è avvenuto, distinte dall’ora dell’ultimo aggiornamento;
• valore e valuta, se pertinenti e definitivi;
• ID di contatto, opportunità e ordine;
• campagna, click ID e identificatori utente effettivamente disponibili e utilizzabili;
• stato del consenso e regole applicabili alla condivisione.

Questo diventa il registro economico di riferimento. Non lo chiamerei “evento Meta” o “conversione Google”: se domani cambia una destinazione, la vendita resta la stessa. È la continuità già descritta nell’articolo sui dati che il CRM deve conservare per collegare campagne e vendite.

Google Ads vuole i riferimenti della propria conversione

Per un caricamento offline in Google Ads non basta l’importo. La documentazione richiede l’azione di conversione e data e ora della conversione, con fuso orario; valore e valuta sono raccomandati quando si misura il valore. Per associare l’evento possono servire gclid, gbraid o wbraid, oppure identificatori utente nel flusso previsto. Fonte: Google Ads API, caricamento delle conversioni offline.

Google raccomanda anche un order_id univoco per azione di conversione: aiuta a prevenire duplicati e permette di riferirsi all’evento nelle rettifiche successive. Non genererei quindi un nuovo ID a ogni tentativo di invio. Un retry deve riproporre la stessa vendita, non crearne una gemella.

Meta deve riconoscere evento, persona e possibile duplicato

Per Conversions API l’adattatore Meta prepara almeno nome e ora dell’evento, origine dell’azione, dati utente ammessi e gli altri parametri previsti dal caso. Se la stessa azione arriva sia dal Pixel sia dal server, event_name ed event_id coerenti consentono la deduplicazione. Fonte: Meta, parametri degli eventi server.

L’ID non va inventato dal connettore a ogni passaggio: deve derivare dall’azione reale ed essere riutilizzato quando browser e server descrivono la stessa conversione. Il meccanismo e i controlli sono approfonditi nell’articolo su Pixel, Conversions API e deduplicazione.

LinkedIn ha uno schema ancora diverso

LinkedIn Conversions API richiede il riferimento alla regola di conversione e almeno un identificatore utente. Lo schema prevede inoltre conversionHappenedAt in millisecondi Unix, un oggetto per valore e valuta quando utilizzato e un eventId che può servire alla deduplicazione. Fonte: LinkedIn Marketing API, schema Conversions API.

Tradurre “30 ottobre, ore 10:15, 4.000 euro” significa quindi produrre timestamp, valuta e riferimenti nel formato atteso da ciascuna API. Il payload universale è il coltellino svizzero che, al momento decisivo, scopri non avere la misura della vite.

Serve un registro degli invii per ogni destinazione

Tra CRM e piattaforme inserirei una coda o un registro che, per ogni ID interno, conservi separatamente:

• destinazione e azione di conversione configurata;
• ID usato per deduplicazione o rettifica;
• stato: da inviare, accettato, rifiutato oppure da ritentare;
• data del tentativo, risposta dell’API ed errore normalizzato;
• versione della trasformazione applicata.

Un errore su LinkedIn non deve bloccare Google. Un timeout non deve generare una nuova vendita. E una modifica del valore deve seguire la procedura supportata dalla singola piattaforma, non un secondo evento positivo. Per annullamenti e riduzioni trovi un approfondimento su come rettificare le conversioni dopo una variazione commerciale.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: il contratto CTR-2048 viene firmato alle 10:15 e il CRM genera l’evento interno sale-2048, con valore e valuta. Il router verifica quali identificatori pubblicitari sono disponibili e quali destinazioni sono configurate.

L’adattatore Google associa l’evento all’azione corretta e mantiene CTR-2048 come riferimento stabile. Quello Meta produce il nome evento previsto e un event_id coerente. Quello LinkedIn inserisce regola, timestamp in millisecondi e identificatori ammessi. Se Meta risponde con un errore temporaneo, il sistema ritenta lo stesso sale-2048; non crea sale-2048-bis.

Tre attribuzioni non fanno tre vendite

Google, Meta e LinkedIn possono attribuirsi la stessa vendita secondo finestre e modelli differenti. Non sommerei le conversioni dichiarate dalle piattaforme come se fossero clienti unici. Il CRM rimane la fonte del numero economico; i report pubblicitari spiegano come ciascun sistema collega quel risultato alle proprie interazioni. È lo stesso motivo per cui Google e Meta possono rivendicare la stessa vendita senza che il fatturato raddoppi.

Il collaudo minimo prima dell’uso

• Genera una vendita di prova riconoscibile e verifica un solo evento interno.
• Confronta orario reale, fuso, valore e valuta nei tre payload.
• Ripeti l’invio e controlla che non nasca una seconda conversione.
• Simula un errore temporaneo e verifica retry e registro delle risposte.
• Prova una variazione o un annullamento con il flusso previsto.
• Confronta infine piattaforme e CRM senza sommare attribuzioni incompatibili.

Un buon collegamento multipiattaforma non è un megafono che urla lo stesso JSON a tre API. È un traduttore con memoria: parte da un fatto commerciale stabile, conserva gli identificatori e parla correttamente con ogni destinazione. Così advertising, tracking e vendite possono confrontarsi senza trasformare tre report in tre versioni concorrenti della realtà.

Fonti ufficiali consultate il 30 ottobre 2026. L’esempio è ipotetico. Disponibilità delle funzioni, requisiti e trattamento dei dati vanno verificati per account e configurazione; l’invio di conversioni non garantisce risultati pubblicitari.