MQL e SQL: la stessa parola in tre sistemi e come farla tornare

In breve. MQL e SQL con definizioni diverse da sistema a sistema, deal vinti che non incontrano il fatturato, un picco di churn nato da una riclassifica di catalogo: i dati di marketing non tornano quasi mai per un bug, ma perché la stessa parola detta in sistemi diversi significa cose diverse. Episodi datati, raccontati con metodo e date.

Gli episodi vengono da uno strumento interno di analisi marketing e vendite che mi sono costruito. Il contesto generale è nella guida al marketing B2B; qui parlo solo di far tornare i dati.

MQL e SQL nei sistemi diversi

Il 22 maggio 2026 la regola diventa: stessa parola, definizioni diverse (21f4a5a). Raggruppare i contatti per data di creazione e contare gli stadi via marker è l'unico modo per far tornare il numero di riferimento del team. MQL e SQL detti in tre sistemi restano risposte diverse finché non decidi quale definizione conta.

Il caso SQL arriva l'8 settembre 2026 (09142c9): contare gli SQL accettati invece di quelli «entrati». «Entrato» conta un passaggio, «accettato» conta una decisione delle vendite: sono due numeri diversi con lo stesso nome, e il rapporto torna solo con il secondo.

Quando il vinto non incontra il fatturato

L'abbinamento tra deal vinto e booking passa per quattro versioni in due giorni (69a98d4, 7ed973c, 57ab4c1, 22-23 maggio 2026), tra partita IVA, nome normalizzato e fuzzy con confidenza dichiarata. La copertura resta bassa, e il commit la definisce «realistica». Abbinare CRM e fatturato è un'approssimazione da dichiarare, non un problema da chiudere.

Il churn che era una riclassifica

Il 22 settembre 2026 (2438d35, docs) un picco di churn si rivela per ciò che è: un articolo spostato da un cluster all'altro. Nessun cliente perso, nessun comportamento cambiato: solo il catalogo che si è mosso sotto i piedi della metrica. Da lì la regola: annotare subito, versionare poi, nessuna riscrittura silenziosa dello storico. La storia completa è in Il churn che era una riclassifica di catalogo.

Il sync fermato dalle date future

Il 28 luglio 2026 (4773b53) la causa è una data: righe con date future, fino al 2072, spingono il cutoff del sync incrementale oltre oggi, e diverse sorgenti smettono di aggiornarsi senza errori. Il silenzio è la parte peggiore: niente fallisce, i dati semplicemente invecchiano. La correzione è LEAST tra ultima data non futura e giorno dell'import.

La chiave di deduplica e lo stato

Il 24 giugno 2026 (1980e29) la lezione è una chiave: la chiave di deduplica deve includere lo stato, altrimenti due righe di segno opposto si fondono. Due movimenti veri in una riga sola: la dedup senza stato non pulisce, appiattisce.

Gli avvisi che nessuno leggeva

Il caso fuori dallo strumento interno arriva da Arvo, il personal trainer AI: dal 7 gennaio al 21 aprile 2026 gli NPS non partono mai, e gli errori finiscono in results.errors che nessuno legge (PR #143). Il 3 ottobre 2026 un batch riporta ok=3 failed=0 con un invio fallito dentro (corretto in #2277): il verde del batch nascondeva il rosso del singolo invio. La storia completa è in NPS mai inviati per tre mesi e mezzo: gli errori che nessuno leggeva.

La regola: definizioni prima dei numeri

I dati di marketing non tornano quasi mai per un bug, ma per definizioni diverse dette con la stessa parola. È la regola che applico da allora: prima decidi cosa significa la parola in ogni sistema, poi leggi i numeri. L'ordine inverso, leggere i numeri e litigare sulle definizioni dopo, è come ho perso tempo prima di capirlo.

Fatti e limiti

FACT. Il 22 maggio 2026: stessa parola, definizioni diverse — contatti raggruppati per data di creazione, stadi contati via marker, unico modo per far tornare il numero di riferimento (21f4a5a).

FACT. L'8 settembre 2026: contare gli SQL accettati, non quelli «entrati» (09142c9).

FACT. Il 22 e 23 maggio 2026: deal vinto e booking in quattro versioni (69a98d4, 7ed973c, 57ab4c1); copertura bassa, «realistica» nel commit.

FACT. Il 22 settembre 2026: picco di churn da articolo spostato di cluster; regola «annotare subito, versionare poi, nessuna riscrittura silenziosa dello storico» (docs, 2438d35).

FACT. Il 28 luglio 2026: date future fino al 2072 spingono il cutoff del sync oltre oggi, sorgenti ferme senza errori; fix LEAST tra ultima data non futura e giorno dell'import (4773b53).

FACT. Il 24 giugno 2026: chiave di deduplica con stato, o due righe opposte si fondono (1980e29).

FACT. Dal 7 gennaio al 21 aprile 2026 NPS mai inviati, errori in results.errors non letti (Arvo, PR #143); il 3 ottobre 2026 batch ok=3 failed=0 con un invio fallito (corretto in #2277).

INTERPRETATION. Dietro numeri che non tornano cerco prima le definizioni e poi il bug: è la mia tesi dopo questi episodi, non un dato misurato.

INTERPRETATION. La copertura «realistica» dell'abbinamento vale come regola generale: meglio un numero basso dichiarato che uno alto inventato.

Limiti: episodi da un solo strumento interno e un caso Arvo, non una statistica. Questo pezzo regge su metodo e date.

Domande frequenti

Perché MQL e SQL non tornano tra sistemi diversi?

Perché la stessa parola ha definizioni diverse: il 22 maggio 2026 (21f4a5a) l'unico modo per far tornare il numero di riferimento è raggruppare per data di creazione e contare gli stadi via marker. Prima allinei le definizioni, poi leggi i numeri.

Come si contano gli SQL?

Quelli accettati, non quelli «entrati»: la distinzione è dell'8 settembre 2026 (09142c9). «Entrato» è un passaggio, «accettato» è una decisione delle vendite.

Cosa fare quando un numero crolla o esplode da un giorno all'altro?

Annotare subito, versionare poi: il 22 settembre 2026 (2438d35) un picco di churn era un articolo spostato di cluster. Prima escludi che si sia mosso il catalogo, poi cerchi il fenomeno.