NPS mai inviati per tre mesi e mezzo: gli errori che nessuno leggeva

In breve. Dal 7 gennaio al 21 aprile 2026 gli NPS non sono mai partiti: gli errori finivano in results.errors, la voce del risultato che raccoglie gli errori, e nessuno la leggeva. Il 3 ottobre 2026 un batch verde — ok=3 failed=0 — nascondeva un invio fallito. Lo stesso problema, non visto in due modi diversi.

Tre mesi e mezzo senza un invio

Dal 7 gennaio al 21 aprile 2026, tre mesi e mezzo, nessun NPS parte da Arvo, il personal trainer AI. Gli errori finiscono in results.errors e nessuno lo legge (PR #143).

Come si fa a non accorgersene per tre mesi e mezzo? L'errore veniva registrato dove nessuno guardava. Un errore registrato e mai letto non avvisa nessuno: è scritto, ma tace.

Sui limiti dell'NPS come metrica — cosa misura e cosa no — ho scritto in Net Promoter Score e oltre: lì parlo della misura, qui di quando la misura non parte proprio.

Il batch verde con un invio fallito dentro

Il 3 ottobre 2026 un batch riporta ok=3 failed=0 con un invio fallito dentro (corretto in #2277). Tre ok e zero falliti nel riepilogo, un invio fallito nel dettaglio: il contatore diceva verde mentre il singolo invio era fermo.

La trappola è il livello a cui guardi. Il batch riassume, il singolo invio racconta. Quando riepilogo e dettaglio dicono cose diverse, il riepilogo vince sempre: è quello che si legge.

Lo stesso silenzio, in un altro sistema

Non è un caso isolato. In uno strumento interno di analisi marketing e vendite che mi sono costruito, righe con date future — fino al 2072 — spingevano il cutoff del sync incrementale oltre oggi: diverse sorgenti avevano smesso di aggiornarsi senza errori. La correzione arriva il 28 luglio 2026 (4773b53).

Lì il silenzio era di un altro tipo: nessun errore registrato, solo dati fermi. Qui gli errori c'erano, ma in un campo che nessuno leggeva. Da una parte un segnale assente, dall'altra un segnale che nessuno ascoltava. Altri episodi di numeri che non tornano tra sistemi sono in MQL e SQL: la stessa parola in tre sistemi.

Cosa controllo adesso

Da questi episodi ho tratto una regola che applico ovunque: ogni posto dove finiscono errori deve avere un lettore. Non basta registrare: serve qualcuno, o qualcosa, che legga.

Seconda regola: i contatori di riepilogo devono tornare con i singoli casi. Un batch che dice ok=3 failed=0 mentre un invio è fallito ha il contatore rotto. Il verde stava nel riepilogo; la realtà era nel singolo invio.

Fatti e limiti

FACT. Dal 7 gennaio al 21 aprile 2026 gli NPS non sono mai partiti; gli errori finivano in results.errors, che nessuno leggeva (Arvo, PR #143).

FACT. Il 3 ottobre 2026 un batch riportava ok=3 failed=0 con un invio fallito dentro (corretto in #2277).

FACT. Il 28 luglio 2026 (4773b53): righe con date future fino al 2072 spingevano il cutoff del sync oltre oggi e diverse sorgenti avevano smesso di aggiornarsi senza errori.

INTERPRETATION. Un errore registrato dove nessuno guarda non avvisa nessuno: la registrazione senza lettore è la mia tesi dopo questi episodi, non un dato misurato.

INTERPRETATION. I riepiloghi vincono sui dettagli perché sono quelli che si leggono: quando i due divergono, guardo il dettaglio. Anche questa è una regola di lavoro, non una misura.

Limiti: un caso Arvo in due tempi e un episodio da uno strumento interno, non una statistica. Questo pezzo regge su date e casi.

Domande frequenti

Perché nessuno si è accorto che gli NPS non partivano?

Perché gli errori finivano in results.errors e nessuno lo leggeva (PR #143, gennaio-aprile 2026). L'errore era registrato: mancava il lettore.

Cosa significa un batch ok=3 failed=0 con un invio fallito dentro?

Che riepilogo e dettaglio dicevano cose diverse: tre ok e zero falliti nel riepilogo del 3 ottobre 2026, un invio fallito nel dettaglio (corretto in #2277). Il verde stava nel riepilogo.

Cos'è results.errors?

Dove finivano gli errori degli invii NPS, da gennaio ad aprile 2026. Raccoglieva errori che nessuno leggeva.