Il flusso di lavoro
- Esporta dal CRM: una riga per esito con l'ora dell'esito, gli identificatori di cui disponi (e-mail, telefono, click ID se salvato sul lead, ID ordine) e il valore.
- Invia le righe all'endpoint degli eventi server con una source key creata per il CRM. Ogni riga diventa un evento canonico (
qualified_lead,purchase,refund,subscribe) conprops.offline: true, il timestamp originale e lo stato del consenso che il tuo sistema ha registrato per quella persona. Basta un piccolo script o il webhook in uscita del CRM; l'endpoint accetta batch e risponde con il numero di eventi accettati oppure con un errore di validazione che indica il campo. - Normalizza e applica l'hash prima dell'invio: e-mail in minuscolo e senza spazi ai margini, numeri di telefono convertiti in E.164, poi SHA-256. Le righe che arrivano con identificatori in chiaro non superano la validazione; nulla viene sottoposto a hash al posto tuo.
- Instrada esattamente come gli eventi browser: il policy engine applica, destinazione per destinazione, lo stato del consenso trasportato dall'evento. Un evento senza informazioni sul consenso porta solo la finalità necessaria e non raggiunge nessuna destinazione pubblicitaria.
- Consegna tramite gli stessi connettori, con le varianti offline di ciascuna API.
L'Event Debugger mostra ogni evento importato con la sua sorgente e il monitor delle destinazioni mostra lo stato di consegna per destinazione.
Piattaforma per piattaforma
| Piattaforma | Meccanismo | Identificatore richiesto | Regole temporali |
|---|---|---|---|
| Google Ads | caricamento di conversioni da clic | gclid/gbraid/wbraid oppure e-mail/telefono con hash (Enhanced Conversions for Leads) | dopo il clic, entro la finestra; non più vecchia della finestra click-through dell'azione |
| Meta | Conversions API con action_source: physical_store o system_generated | e-mail/telefono con hash, external_id; fbc se salvato | entro 62 giorni |
| Conversions API | e-mail con hash o li_fat_id | entro 90 giorni | |
| TikTok | Events API con event_source: offline e l'ID di un set di eventi offline | e-mail/telefono con hash | entro 7 giorni per il web, più a lungo per i set offline |
| Microsoft | Conversions API | msclkid o e-mail/telefono con hash | entro la finestra dell'obiettivo |
| Reti di affiliazione | postback con il click ID salvato | click ID della rete | secondo il programma |
Il timestamp che carichi deve essere l'ora in cui l'esito si è verificato, non l'ora in cui hai esportato. Caricare le trattative di ieri con il timestamp di oggi sposta l'attribuzione e può portare le conversioni fuori dalla finestra di clic.
Salva il click ID sul lead
L'abbinamento tramite click ID è più affidabile di quello tramite e-mail con hash. Copia i parametri click ID dell'URL di atterraggio (gclid, msclkid, fbclid, li_fat_id, ttclid) in campi nascosti del form quando il consenso al marketing è stato prestato e salvali sul lead nel CRM. Più tardi, quando il lead si chiude, l'esportazione porta con sé il click ID e il caricamento viene abbinato in modo deterministico.
Valori: modellali o lasciali vuoti
Un lead qualificato non ha un valore d'ordine. Opzioni che restano oneste:
- Lascia il valore vuoto; l'ottimizzazione basata sul conteggio funziona comunque.
- Usa un valore atteso documentato per ogni fase del lead (per esempio valore medio della trattativa × tasso di chiusura), impostato come costante nella mappatura della destinazione e visibile nell'audit log.
- Carica il valore effettivo della trattativa quando si chiude, come conversione separata.
Ciò che Track non farà è inventare un valore: i valori non mappati restano null e una mappatura che fa riferimento a una proprietà mancante non supera la validazione invece di sostituirla con un valore predefinito.
Deduplicazione con gli eventi browser
Non inviare la riga «form inviato» del CRM come lo stesso evento che il browser ha già inviato: conteresti due volte, a meno che l'ID evento non viaggi insieme al lead. Invia gli esiti successivi (qualified_lead, purchase) come eventi propri, mappati su azioni di conversione o regole separate. Per gli acquisti che anche il browser ha visto, mantieni l'ID ordine su entrambi, così le piattaforme che deduplicano sull'ID ordine li uniscono.
Checklist
- Da fare: L'esportazione contiene l'ora dell'esito in ISO 8601 con fuso orario
- Da fare: Identificatori normalizzati prima dell'hashing; colonne già con hash contrassegnate come tali
- Da fare: Click ID salvati sul lead all'invio del form
- Da fare: Valori reali, costanti documentate oppure vuoti
- Da fare: Risposte dei batch controllate: righe rifiutate corrette, consegna per destinazione confermata nel monitor delle destinazioni