Acconto e saldo: alle campagne invio una vendita o due conversioni?

Un cliente firma il contratto, paga un acconto e versa il saldo un mese dopo. Nel CRM compaiono due movimenti economici. Le campagne hanno generato una vendita oppure due conversioni?

Dipende da che cosa hai deciso di misurare, ma una regola resta valida: due pagamenti non sono automaticamente due nuovi clienti. Prima di costruire il webhook devi separare l’evento di acquisizione dal calendario degli incassi. Altrimenti il report pubblicitario premia tre volte lo stesso contratto: firma, acconto e saldo.

Prima scegli l’evento economico che vuoi rappresentare

Nel CRM terrei distinti almeno tre oggetti:

• opportunità o contratto: rappresenta l’acquisizione del cliente e il valore concordato;
• piano di pagamento: descrive scadenze e importi previsti;
• incasso: registra ogni movimento realmente ricevuto.

Se l’obiettivo della campagna è acquisire contratti, l’evento principale può essere “contratto firmato” una sola volta. Se vuoi analizzare anche la cassa, gli incassi possono diventare eventi separati, con un nome e una finalità diversi. Non li chiamerei tutti Purchase o “Vendita” per comodità.

La scelta del valore iniziale va documentata: totale contrattuale, ricavo atteso o altra misura coerente. Nell’articolo su vendita e valore del contratto spiego perché il numero inviato deve avere una definizione aziendale stabile.

Google: lo stesso transaction ID può aggiornare il valore

Nella Data Manager API di Google Ads, transactionId identifica l’evento e viene usato per la deduplicazione. Se lo stesso ID corrisponde a una conversione esistente nella medesima azione, un nuovo valore può sostituire quello registrato senza incrementare il conteggio; se l’ID non corrisponde, Google tratta l’invio come una nuova conversione. Fonte: Google Data Manager API, conversion adjustments.

Questo comportamento è utile quando il valore del contratto cambia, ma non significa che ogni rata debba sovrascrivere la vendita. Se invii prima 2.000 euro e poi, con lo stesso ID, 4.000 euro, il valore finale documentato è 4.000: non la somma automatica di 6.000. Per restituire il totale aggiornato dovresti inviare il totale previsto dalla procedura, non l’ultima rata isolata.

Se invece usi ID diversi per acconto e saldo, crei due eventi distinti. Può essere corretto per una specifica azione “incasso ricevuto”, ma sarebbe fuorviante se entrambi fossero presentati come nuove acquisizioni. Google raccomanda identificatori di transazione persistenti proprio per limitare duplicati e supportare le rettifiche. Fonte: Google Ads, ID transazione e duplicati.

Meta non conosce da sola il rapporto tra rata e contratto

Negli eventi Purchase di Conversions API, Meta prevede valore, valuta e un order_id per l’ordine. Il campione ufficiale per eventi offline mostra questi campi insieme al momento reale dell’evento. Fonte: Meta, esempio Conversions API per eventi offline.

event_id serve invece a riconoscere la stessa azione inviata, per esempio, sia dal browser sia dal server. Il Business SDK ufficiale lo usa con il nome dell’evento per stabilire se i due invii sono identici. Fonte: Meta Business SDK, event ID.

Né order_id né event_id spiegano però autonomamente che “rata 2” appartiene al contratto già acquisito. Questa relazione deve esistere nel CRM. Se mandi due Purchase con ID diversi, stai descrivendo due azioni distinte; assicurati che sia davvero il significato commerciale scelto.

LinkedIn: valore ed event ID non definiscono la tua contabilità

LinkedIn Conversions API accetta un conversionValue con importo e valuta e un eventId opzionale usato per la deduplicazione. Fonte: LinkedIn Marketing API, schema Conversions API.

Anche qui la deduplicazione evita di contare due volte lo stesso evento trasmesso da fonti ridondanti; non fonde automaticamente due rate con ID diversi. Se vuoi misurare il contratto, usa un evento stabile del contratto. Se vuoi misurare gli incassi, usa eventi e identificatori dei pagamenti, mantenendo separati i relativi report.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: un contratto da 6.000 euro prevede 2.000 euro alla firma e 4.000 al completamento.

Nel modello orientato all’acquisizione, il CRM genera una sola conversione contract_won con ID CTR-602 e valore 6.000 euro, se questa è la definizione approvata. Acconto e saldo aggiornano il piano finanziario, ma non producono altri due clienti. Se il contratto viene ridotto a 5.500 euro, il flusso applica una rettifica del valore dove supportata, come descritto nell’articolo su rettifiche e annullamenti.

Nel modello orientato alla cassa, il CRM può produrre anche payment_received con ID PAY-602-1 e PAY-602-2. Li terrei in un’azione o in un report separato, collegati entrambi a CTR-602. Non sommerei poi “contratti” e “incassi” per dichiarare il numero di vendite.

La struttura minima nel CRM

• un ID stabile del contratto;
• un ID distinto per ciascun pagamento;
• valore totale concordato, valore aggiornato e valuta;
• importo, scadenza e data di ogni incasso;
• tipo di evento inviato a ciascuna piattaforma;
• ID, valore e risposta di ogni trasmissione;
• regole per rettifiche, rimborsi e mancati pagamenti.

Nel router multipiattaforma manterrei questa logica centrale e lascerei agli adattatori soltanto la traduzione tecnica, seguendo l’architettura descritta nell’articolo su un evento CRM e tre destinazioni pubblicitarie.

Il test che evita di gonfiare il fatturato

Simula un contratto con acconto e saldo. Verifica che il conteggio clienti aumenti una sola volta, che gli incassi siano riconciliabili con il contratto e che un retry non generi un nuovo evento. Confronta poi il valore aziendale con ogni piattaforma: stesso numero di clienti non implica necessariamente lo stesso valore attribuito, perché finestre e modelli restano diversi.

La domanda decisiva non è “quante righe di pagamento abbiamo?”. È “quale fatto vogliamo insegnare alla campagna?”. La firma misura l’acquisizione; le rate misurano la cassa. Possono convivere, purché non vengano travestite da tre vendite dello stesso cliente.

Fonti ufficiali consultate il 2 novembre 2026. L’esempio è ipotetico. Definizione del valore, supporto alle rettifiche e trattamento dei dati dipendono dal processo e dalla piattaforma; questa struttura non garantisce risultati pubblicitari.