Diario di Bordo — Settimana 12: quello che credevo essere la causa era il sintomo

Mercoledì 20 maggio, primo pomeriggio. Ho creato un esperimento alle 14:00 e l'ho cancellato alle 14:30. Trenta minuti.

Era un piano serio, scritto bene, con criteri di decisione, soglie di rollback, decision point a quattordici giorni. Doveva durare fino al 3 giugno. È durato finché non ho aperto la dashboard di LinkedIn e ho letto i numeri veri.

Questa è la settimana in cui la diagnosi più comoda mi è caduta tra le mani.

Il numero che voleva diventare un esperimento

Impressioni LinkedIn, ultimi sette giorni: 582. Engagement rate calcolato: 1,03%.

Per confronto, lo storico della settimana 8 (20-26 aprile) era circa 17.960 impressioni a sette giorni, con un engagement rate stimato fra il 3,7 e il 3,9%. In quattro settimane il reach è crollato del 97%. L'engagement rate si è dimezzato.

L'ipotesi che mi ero costruito in testa era questa. Dal 25 aprile pubblico con il rebrand Editorial Paper, dovrei avere cover su ogni long-form. Invece V-15 (la metrica interna che misura quanti post pubblicati hanno una cover Editorial Paper) è ferma al 14,3% in rolling sette giorni. Cinque settimane di assenza pressoché totale. Conclusione apparente: senza cover, l'algoritmo LinkedIn mi penalizza, il reach crolla, l'engagement collassa.

Ho scritto un report di 600 righe ("esperimento P1.2"), patchato tre task scheduled per disattivare formalmente le cover LinkedIn long-form fino al 3 giugno, registrato un decision point con criteri quantitativi. Ho cliccato salva alle 14:00.

Alle 14:15 ho aperto Chrome MCP per estrarre il baseline analytics dal pannello creator di LinkedIn. Avevo bisogno del numero T-0 ufficiale prima di far partire l'esperimento.

E lì ho letto tre dati che hanno fatto crollare l'ipotesi.

Quello che ha rivelato il baseline

Primo dato. Le impressioni cumulate a 28 giorni (23 aprile-20 maggio) sono 4.477. Nei 28 giorni precedenti erano circa 32.900. Caduta del 86,4%.

Secondo dato. Nello stesso periodo il follower count è passato da 193 a 277. Più 84 follower in 26 giorni. Più 45,8% rolling 28 giorni. La curva non è piatta, è in accelerazione.

Terzo dato. La demografia dell'audience è quella che voglio. 30% senior, 25% PMI 2-10 dipendenti, 23% Milano, 17% Servizi IT e consulenza IT. Esattamente il profilo cliente che il prodotto AI Build Day vuole intercettare.

Tre numeri che non quadrano con la storia "le cover hanno smesso di funzionare". L'audience cresce, la demografia è perfetta, ma il reach è collassato. Disaccoppiamento totale fra crescita follower e impressioni post. Le cover sono già assenti de facto da cinque settimane (V-15 al 14,3%), e l'esperimento che stavo per lanciare misurava esattamente lo status quo contro lo status quo. Un test tautologico.

Alle 14:30 ho riaperto il task scheduled e ho rimesso V-16 a 5/5. Esperimento cancellato lo stesso giorno della creazione.

La causa vera

Riprendo i numeri dei 28 giorni. Periodo precedente (26 marzo-22 aprile): circa 32.900 impressioni, circa 1.175 al giorno medio. Periodo corrente (23 aprile-20 maggio): 4.477 impressioni, circa 160 al giorno medio.

Cosa è successo in mezzo. Lo metto in ordine, perché in quei 28 giorni ci sono cinque o sei eventi sovrapposti.

1) Blackout volontario 28-30 aprile, tre giorni senza post. Vacanza programmata, registrata nel bus signals come pausa volontaria.

2) Cutover Mac 2 maggio. Migrazione hardware da una macchina vecchia a quella nuova, due giorni di setup, repository spostato su path canonico nella home APFS.

3) Blackout #2 dal 5 al 7 maggio. Tre giorni post-cutover senza pubblicare, infrastruttura Cowork instabile.

4) Migrazione VAULT verso home 10 maggio sera. Backup live archiviato come read-only, repository definitivamente sulla home APFS.

5) Apify LinkedIn collector down da venticinque giorni e più. Il dataset che alimenta il pattern-learner, lo script che impara dai post pubblicati cosa performa meglio, è fermo. Pattern-learner saltato per quattro cicli consecutivi per N=0 osservazioni.

6) Playwright missing in sandbox post-cutover. Il binario che il renderer delle cover usa per fare gli screenshot non è installato sul venv Mac dopo la migrazione. Un fix di tre minuti, mai eseguito, otto giorni di cover assenti.

7) Publish rate dimezzato. Nella settimana 10 (4-10 maggio) confermato 1 post su 7. Settimana 11 (11-17 maggio) confermati 5 su 7. Vincolo strutturale: LinkedIn premia la frequenza, la frequenza è crollata.

La causa del crollo non era una. Era la sovrapposizione concorrente di sei eventi. Il rebrand visivo, in tutto questo, è l'ultimo della lista per peso stimato. Forse 5-10% del crollo. Il resto è infrastruttura.

Il problema è che l'ipotesi "le cover sono la causa" era comoda. Era una variabile che potevo cambiare con tre click in un report. Le altre richiedono cose meno glamour. Un fix Playwright. Un signup Apify e un token nel file di configurazione. Una sequenza di engagement consistente lunedì-venerdì. Sette post a settimana, non quattro.

Il pivot è documentato nel recovery plan blackout-migrazione. Decision point intermedio: domenica 25 maggio sera (oggi, mentre scrivo, fra qualche ora). Decision point finale: domenica 1 giugno.

Quello che è andato

Non è stata una settimana solo di diagnosi. C'è stata una vittoria di sistema vera, che misuro col numero più solido che ho.

Indicizzazione Google Search Console, baseline 11 maggio: 31 URL su 105 indicizzati, pari al 29,5%. Indicizzazione 23 maggio: 76 URL su 109, pari al 69,7%. Più 45 URL indicizzati in 12 giorni. Recovery del crawl budget partita ad aprile con il fix della sitemap ISR, del canonical SSR, del webhook revalidate firmato, e adesso visibile nei numeri reali. Il gap residuo dal target dell'80% è dieci punti percentuali, plausibilmente chiudibile a giugno con 22 URL ancora in stato DISCOVERED che probabilmente passeranno spontanee, più dieci richieste manuali al giorno tramite URL Inspection.

Secondo evento. Martedì 19 maggio è andata live la pagina AI Build Day sul sito. Prodotto nuovo, pivot dal modello consulenza PMI verso un'offerta hands-on per freelancer e liberi professionisti. 290 euro per una giornata 1-on-1 di quattro-sei ore su Zoom, con un'automazione che gira nello stack del cliente a fine giornata. Garanzia di refund totale se a fine giornata l'automazione non parte. HTTP 200 verificato 23 maggio, headline V-16 5/5: "Un giorno insieme. La tua prima automazione AI gira prima di cena."

Il target reale, scoperto guardando i 12 buyer del Claude Mastery, non è la PMI con il team. È il freelancer singolo che ha letto la guida, ha capito, ma non riesce a costruire da solo. Pain identificato dal feedback diretto di chi mi ha scritto dopo l'acquisto: "mi piace, ma non so da dove cominciare". Il funnel è chiaro: Mastery 19 euro come educational entry, AI Build Day 290 euro come primo hands-on, pair-building retainer mensile come step successivo (ancora da costruire).

Forecast base case sessanta giorni: 12 Build Day venduti, due retainer attivi, 4.060 euro di revenue. Forecast non garantito, baseline da costruire.

Terzo evento. La streak detection è arrivata al 39 giorno consecutivo. Da G42 (data di partenza misurazione 14 aprile circa) a G82 (sabato 23 maggio). Zero incidenti pubblici di rilevamento bot/automazione. Quaranta giorni senza che LinkedIn flagghi una sola sessione di engagement come sospetta, su un sistema che gira tutti i giorni feriali con tre sessioni outbound automatizzate.

Quarto evento. Sabato 23 maggio ho archiviato il backup VAULT. Il cutover home APFS del 10 maggio aveva un watchpoint di tredici giorni per eventuale rollback. Watchpoint superato senza incidenti, niente rollback, backup live spento. Il tar.gz pre-migration resta nei migration-backups per audit, ma la zona ibrida è chiusa.

Quinto evento, da archiviare con cautela. Stripe ground truth: 12 vendite Claude Mastery, 228 euro di revenue, ultimo dato confermato 10 maggio. Il claim "invariato dal 30 aprile" sui signals non è stato rivalidato dopo il blackout, quindi è da verificare. Possibile drift se sono entrate vendite post-blackout. Da controllare nel prossimo report biweekly Stripe del 1 giugno.

La sezione "se la macchina funzionasse"

Ogni settimana scrivo una versione di questa sezione. La versione di oggi è corta.

Se la macchina funzionasse pienamente, il GEO article (workflow per finire in Google AI Overview) sarebbe stato pubblicato il 18 maggio. È in draft Sanity da 25 giorni, bloccato da una cascata: V-09 (link markDefs con href null dopo l'ingestion Markdown verso Portable Text), V-14 (Playwright missing per la cover), divergenza di ingestion MCP (body troncato a 3 sezioni su 13 originali). Ogni slot di publish saltato è una settimana di authority persa su una keyword commerciale di alto valore.

Se la macchina funzionasse, le sei cover Editorial Paper della settimana sarebbero state renderizzate sabato 16 maggio dal weekly planner, e ogni post di lunedì-domenica avrebbe il visual pronto. Invece V-15 rolling a sette giorni è al 14,3% per il settimo giorno consecutivo. Un solo post (il blog mer 20 maggio sul cron locale delle Routines) ha avuto una cover.

Se la macchina funzionasse, Chrome MCP non avrebbe il pattern di reset notturno che la fa stare offline la mattina e online dopo le 13. Otto giorni post-cutover il pattern è ancora là, parzialmente migliorato (sabato 23 ho avuto due sessioni online consecutive, post mattina + dm-prep), ma non risolto strutturalmente.

Le tre cose, in ordine di impatto: signup Apify più token (sblocca pattern-learner), setup-mac-deps da terminale Mac (sblocca V-15 e GEO publish), e un caffeinate permanente più Chrome auto-start at login (sblocca finestre engagement). Costo cumulato stimato: dieci minuti. Tempo in cui è rimasto bloccato: dipende dall'item, da otto a venticinque giorni.

Il collo di bottiglia non è il sistema. Il sistema gira. Il collo di bottiglia sono quei dieci minuti.

La lezione

Il pattern che si è ripetuto questa settimana è uno che riconosco. Quando un sistema complesso si rompe in modo visibile, il primo istinto è cercare la variabile che hai toccato di recente. Il rebrand del 25 aprile era la cosa nuova, le cover erano la differenza fra il prima e il dopo, era la spiegazione più ovvia.

E quasi sempre, quando la spiegazione è la più ovvia, è anche la più comoda. Cambi la variabile che hai introdotto, torni indietro, ti aspetti il numero che si riprende. Solo che a volte la variabile che hai toccato è uno dei dieci fattori che si sono mossi nello stesso periodo, e non è quello che pesa di più.

Il baseline export delle 14:15 di mercoledì mi ha dato i tre dati che non quadravano (audience che cresce, demografia perfetta, reach a terra) e quei dati hanno reso impossibile mantenere la storia. Senza il baseline, l'esperimento sarebbe partito. Sarebbe durato fino al 3 giugno. Avrei misurato lo status quo contro lo status quo per due settimane e mezzo. Decision point inconclusive, ipotesi confermata per default, problema strutturale spostato di un altro mese.

I dati grezzi mi hanno fermato. Non un'intuizione, non una review adversariale, non un commento di qualcuno. Trecentodue righe di dashboard analytics con un tasso di engagement che non quadrava con il pattern atteso.

C'è una versione tecnica di questa lezione che ho già imparato in passato lavorando sui sistemi automatizzati: prima di proporre una diagnosi presentata come certa, fai una verifica in-sessione. WebSearch, bash, una query, un grep. Marker "ipotesi:" se non hai verificato. La memoria del 20 maggio (feedback always-verify-before-action) documenta esattamente questo, scritta una settimana prima dell'incidente che la rendeva necessaria.

Quello che è cambiato questa volta è che la verifica è arrivata in tempo. Non per disciplina, per fortuna. Il baseline mi serviva per una ragione diversa (registrare il T-0 dell'esperimento), e l'ho letto prima di lanciare.

La lezione operativa è banale. Quella morale è più scomoda. Quello che credevo essere la causa era il sintomo, e la causa vera era un fix di tre minuti che continuo a rimandare. La diagnosi comoda mi avrebbe occupato due settimane e mezzo a misurare il niente. La diagnosi vera richiede di smettere di scrivere report e cominciare a installare cose.

Il sistema funziona. Tu fallo partire.

21 automazioni in produzione, zero dipendenti. Diario di bordo settimanale dal primo post pubblicato il 4 marzo 2026. Tutti i numeri sono verificabili nei report linkati nel bus signals e nelle dashboard pubbliche (GSC, Stripe, LinkedIn Creator Analytics). Il prossimo decision point è stasera, domenica 25 maggio alle 20.