Il venditore aggiorna il CRM giorni dopo: quale data deve ricevere la piattaforma?

Il contratto viene firmato venerdì, ma il commerciale aggiorna il CRM lunedì. L’automazione parte subito e rimanda la vendita alle piattaforme. Quale data deve inviare: venerdì, lunedì oppure l’istante in cui il webhook viene elaborato?

La risposta è la data in cui è avvenuto il fatto commerciale. L’aggiornamento del record e la trasmissione sono attività tecniche successive. Se le confondi, una vendita reale viene spostata nel tempo e il report può collegarla a finestre, giorni o campagne sbagliati.

Una vendita può avere quattro timestamp diversi

Nel CRM distinguerei almeno:

• occurred_at: quando il contratto è stato firmato, il pagamento confermato o la fase definita è stata raggiunta;
• recorded_at: quando l’informazione è entrata nel sistema;
• updated_at: l’ultima modifica del record, che può riguardare anche una nota irrilevante;
• sent_at: quando l’evento è stato trasmesso a una destinazione.

Solo il primo descrive la conversione. Gli altri servono per audit, controllo dei ritardi e retry. Questa separazione completa l’architettura dell’articolo su come distribuire una vendita dal CRM a più piattaforme.

Google Ads richiede data, ora e fuso della conversione

Per le conversioni offline, Google Ads richiede conversion_date_time: deve essere successivo al clic e includere l’offset del fuso orario. La documentazione consiglia di usare lo stesso fuso dell’account se vuoi confrontare più facilmente i conteggi dell’interfaccia. Fonte: Google Ads API, conversioni offline.

Il momento del caricamento non sostituisce quello della vendita. Google precisa inoltre che le conversioni importate vengono riportate sulla data dell’impressione del clic originale, non sulla data della richiesta di importazione. Perciò un invio effettuato lunedì non dovrebbe trasformare automaticamente in “vendita del lunedì” un contratto firmato venerdì.

Conserverei il timestamp originale con il relativo offset e non lo ricostruirei dal campo generico “ultima modifica”. Se l’azienda registra soltanto la data, senza ora, stabilirei una regola esplicita e la documenterei: inventare le 00:00 in silenzio produce una precisione che il CRM non possiede.

Meta vuole l’ora dell’evento, non quella del processo

Conversions API usa event_time in secondi Unix. Un connettore ufficiale pubblicato da Meta descrive il campo come il momento in cui è avvenuto l’evento reale; anche i Business SDK includono esplicitamente event_time nell’evento server. Fonte: Meta, connettore di esempio per Conversions API.

Gli esempi software spesso impostano l’ora corrente perché simulano un acquisto che avviene in quel momento. Copiare quella logica in un flusso CRM ritardato è un errore: Date.now() descriverebbe il webhook, non la firma. Anche in caso di retry manterrei lo stesso event_time e lo stesso ID dell’evento; cambierebbe soltanto il timestamp tecnico del tentativo.

LinkedIn separa chiaramente evento e invio

LinkedIn richiede conversionHappenedAt, timestamp in millisecondi dell’istante in cui la conversione è avvenuta. Il valore deve rientrare negli ultimi 90 giorni; un tempo non valido genera un errore. Fonte: LinkedIn Marketing API, Conversions API.

La FAQ ufficiale raccomanda di condividere gli eventi in tempo reale, o idealmente entro un giorno, perché siano freschi per attribuzione e utilizzo nelle campagne. Fonte: LinkedIn, Conversions API FAQ. La raccomandazione riguarda la rapidità dell’invio: non autorizza a sostituire la data originale con “adesso”.

Il CRM deve conservare il fatto, non solo lo stato corrente

Un campo “Vinto” sovrascritto non basta. Quando l’opportunità cambia fase, registrerei un evento immutabile con ID, stato raggiunto, occurred_at, valore, valuta e autore o processo che ha confermato il passaggio. Se l’operatore inserisce la data manualmente, aggiungerei una validazione per impedire valori futuri o precedenti alla nascita dell’opportunità senza una motivazione.

Misurerei anche il ritardo tra occurred_at e recorded_at. Non è soltanto un problema di tracking: se le vendite arrivano nel CRM una settimana dopo, anche dashboard e segnali di ottimizzazione lavorano su informazioni vecchie. È collegato al tema già affrontato su tempi commerciali e responsabilità delle campagne.

Il server-side deve mappare il campo giusto

Che l’evento passi da un middleware, da server GTM o da Stape, la trasformazione dovrebbe usare occurred_at come sorgente e produrre il formato richiesto da ogni API: stringa con offset per Google, secondi Unix per Meta, millisecondi per LinkedIn.

Durante il collaudo, i log di Stape possono mostrare richieste in entrata e in uscita e il payload inviato alle destinazioni. Fonte: Stape, Logs. Li userei per confrontare i tre timestamp, limitando però dati personali e durata dei log a ciò che serve davvero.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: il contratto CTR-811 viene firmato il 23 ottobre alle 17:40. Il commerciale lo segna “vinto” il 28 ottobre alle 09:10 e l’automazione lo invia il 1° novembre alle 08:05.

L’evento commerciale conserva il 23 ottobre alle 17:40 con l’offset valido per quel momento. Google riceve quella data nel proprio formato; Meta riceve l’equivalente in secondi Unix; LinkedIn in millisecondi. Il registro tecnico conserva separatamente 28 ottobre come data di registrazione e 1° novembre come data di invio.

Se l’API risponde con un errore temporaneo, il secondo tentativo non cambia la data della conversione. Se invece il contratto viene annullato, si applica un flusso di rettifica come quello descritto nell’articolo su come correggere una vendita già inviata.

Il controllo prima di usare il segnale

• Verifica che il CRM conservi la data reale dell’esito, non soltanto updated_at.
• Salva UTC e informazioni di fuso sufficienti a ricostruire l’ora locale.
• Controlla secondi, millisecondi e formato con offset per ogni destinazione.
• Ripeti l’invio e verifica che evento e timestamp restino identici.
• Confronta payload, risposta API e record CRM su un campione di prova.
• Misura quanti eventi vengono registrati in ritardo e perché.

Una conversione non diventa più recente perché qualcuno apre il CRM tardi. Conservare l’istante reale permette a advertising, vendite e reporting di parlare dello stesso evento; recorded_at e sent_at raccontano invece quanto è efficiente il processo che lo trasporta.

Fonti ufficiali consultate il 1° novembre 2026. L’esempio è ipotetico. Requisiti e finestre dipendono dalla piattaforma e dall’integrazione utilizzata; la corretta gestione dei timestamp non garantisce risultati pubblicitari.