Simone Bussoni — Idee

GA4 tre anni dopo: le 5 cose che continuo a vedere sbagliate

Simone Bussoni — Thu, 14 May 2026 00:00:00 GMT

TL;DR

Dopo tre anni di GA4 su progetti veri, gli errori ricorrenti non sono bug ma scelte: 1) misurare tutto senza sapere quale decisione servirà il dato; 2) fidarsi delle conversioni senza controllare come sono definite; 3) ignorare il consenso e poi stupirsi dei buchi nei dati; 4) confrontare GA4 e Universal come se fossero la stessa cosa; 5) fare report che nessuno usa. GA4 non è difficile: è onesto, e mostra quanto poco sapevamo prima.

GA4 si è preso una brutta fama, in parte meritata per l’interfaccia, in parte no. Dopo tre anni a usarlo sui progetti di clienti veri, ho notato che gli errori più costosi non sono tecnici. Sono di impostazione. Eccone cinque.

1. Misurare tutto, decidere niente

Il primo istinto con GA4 è tracciare ogni evento possibile. Poi ci si ritrova con duecento eventi e nessuna risposta. Un dato che non cambia una decisione è arredamento. Prima la domanda (“questo cambio di layout ha aiutato o no?”), poi la misura. Non il contrario.

2. Fidarsi delle conversioni senza guardarne la definizione

“Le conversioni sono calate” è una frase che vale zero finché non sai cosa conta come conversione. Spesso è un evento definito male: un click su un pulsante che non porta a nulla, un form che spara l’evento anche in caso di errore. Prima di allarmarti, apri la definizione.

3. Ignorare il consenso e poi stupirsi dei buchi

Con Consent Mode e il rifiuto di molti utenti, GA4 stima e modella parte dei dati. Chi non lo sa legge i numeri come assoluti e prende cantonate. I dati sono direzionali, non catastali. Sapere com’è configurato il consenso è metà dell’interpretazione.

4. Confrontare GA4 e Universal come se fossero gemelli

Modello di dati diverso, definizione di sessione diversa, attribuzione diversa. Confrontare i numeri di GA4 2024 con quelli di Universal 2022 e trarne trend è un errore di metodo. Sono due strumenti, non due versioni dello stesso righello.

5. Fare report che nessuno usa

Il report più bello è quello che qualcuno legge e usa per decidere. Molti dashboard esistono per rassicurare, non per informare. L’AI qui aiuta, ma non come pensano: non serve a scrivere più slide, serve a farsi domande migliori sui dati. Un buon report finisce con “quindi facciamo X”, non con un grafico in più.

La verità scomoda

GA4 non è difficile: è onesto. Mostra quanto poco sapevamo prima, quando Universal ci raccontava sessioni gonfiate e attribuzioni comode. Fastidioso? Sì. Ma un dato scomodo e vero vale più di uno comodo e falso.

Se ti interessa come uso i dati per decidere, è la mia pillar Strategia & Dati.

La scheda prodotto perfetta nel 2026

Simone Bussoni — Thu, 02 Apr 2026 00:00:00 GMT

TL;DR

La scheda prodotto è insieme la tua landing più importante e la fonte da cui le AI estraggono informazioni sul prodotto. Nel 2026 funziona quando fa tre cose: risponde alle obiezioni prima che diventino dubbi, è strutturata in modo estraibile (dati chiari, specifiche, FAQ, schema Product) ed è veloce. Non è copywriting decorativo: è togliere motivi per rimandare l’'acquisto. Un aggiornamento moderno di quello che raccontavo a #SEOCMS nel 2017.

Nel 2017, a #SEOCMS, raccontavo come ottimizzare categorie e schede prodotto in Magento. Le leggi di base non sono cambiate. Il contesto sì: oggi la scheda prodotto non la leggono solo i clienti e Google, la leggono anche le AI che rispondono “qual è il miglior X per Y?”. Aggiorniamola.

Perché è la pagina più importante

Su un ecommerce, la scheda prodotto è dove si decide l’acquisto. È la tua landing page più importante, moltiplicata per il numero di prodotti. Eppure spesso è la più trascurata: descrizioni copiate dal fornitore, foto a caso, specifiche incomplete.

Una conversione è una decisione. Il tuo lavoro sulla scheda è togliere i motivi per rimandarla.

Cosa la rende efficace oggi

1. Risponde alle obiezioni prima che diventino dubbi. Taglia? Compatibilità? Tempi di consegna? Reso? Se il cliente deve cercarlo altrove, l’hai già perso. Le domande frequenti non sono un accessorio: sono parte della vendita.

2. È strutturata per essere estratta. Specifiche in tabella, non in prosa. Un blocco FAQ reale. Schema Product con prezzo, disponibilità e recensioni. Questo serve a Google per i rich result e serve alle AI per capire e citare il prodotto senza inventarsi i dettagli. Se non glieli dai tu, li indovina — e indovina male.

3. È veloce. La velocità è una feature di vendita, non un tecnicismo. Ogni secondo di attesa su mobile è un carrello che si raffredda. LCP basso, immagini in formato moderno, niente script inutili.

4. Ha contenuto originale. La descrizione del fornitore ce l’hanno in cento. Il tuo valore è dire qualcosa che gli altri non dicono: come si usa davvero, per chi è, per chi non è. Anche l’AEO premia chi prende posizione.

L’equivalente in lead generation

Se non vendi prodotti ma servizi, la scheda prodotto ha un gemello: la landing. E la regola più tradita è la stessa — parla del problema del cliente, non di te. Una landing che elenca le tue qualità converte peggio di una che dimostra di aver capito il problema di chi legge.

In sintesi

La scheda prodotto perfetta nel 2026 non è più bella: è più utile. Risponde, si fa capire dalle macchine e carica in fretta. Il resto — il copy brillante — viene dopo, e conta meno di quanto pensi.

Se il tema ti riguarda, è parte di come intendo la CRO.

Cosa ho imparato sul prodotto costruendo un'app per il gelato

Simone Bussoni — Thu, 05 Mar 2026 00:00:00 GMT

TL;DR

Ho costruito Gelato AI per hobby, ma mi ha ricordato le regole della CRO meglio di qualunque caso studio. Una ricetta di gelato è un sistema con vincoli (PAC, POD, grassi, solidi) e semafori: cambi una variabile alla volta, misuri, iteri. Come una conversione. Le tre lezioni: definisci i vincoli prima di ottimizzare, un solo cambiamento per volta, e i semafori valgono più dei numeri grezzi perché guidano la decisione.

Gelato AI non doveva insegnarmi niente sul lavoro. È nato per hobby: volevo bilanciare le mie ricette senza rifare i conti a mano ogni volta. Poi, costruendolo, mi sono accorto che stavo riscrivendo le regole della CRO con parole diverse.

Una ricetta è un sistema con vincoli

Il gelato fatto in casa non è cucina, è chimica con la panna. Ogni miscela si regge su un equilibrio tra:

PAC — potere anticongelante: quanto resta morbido il gelato in freezer.
POD — potere dolcificante: quanto è percepito dolce, che non è quanto zucchero c’è.
Grassi e solidi — struttura, cremosità, corpo.

Ogni variabile spinge sulle altre. Aggiungi zucchero per la dolcezza e sposti il PAC. Togli grassi per alleggerire e perdi cremosità. Non esiste “il valore giusto” in astratto: esiste l’equilibrio dentro i tuoi vincoli — la tua gelatiera, il tuo gusto.

Ti ricorda qualcosa? È un funnel di conversione. Alzi la fiducia con più informazioni e allunghi la pagina. Semplifichi il form e perdi dati di qualificazione. Nessuna leva è gratis.

Lezione 1: definisci i vincoli prima di ottimizzare

La prima versione dell’app dava un punteggio “assoluto” alla ricetta. Inutile: un valore perfetto per un mantecatore professionale è sbagliato per una Ninja CREAMi. Ho dovuto far dichiarare prima la macchina e il livello, e solo dopo calcolare l’equilibrio.

Nel lavoro è identico. “Ottimizzare la conversione” senza definire il contesto — che traffico, che prodotto, che margine — produce numeri che sembrano giusti e decisioni sbagliate. I vincoli vengono prima dell’ottimizzazione.

Lezione 2: una variabile alla volta

Quando una miscela non stava in piedi, la tentazione era correggere tre cose insieme. Sbagliato: se poi funziona, non sai perché, e non puoi ripeterlo. Un cambiamento, un test, una lettura.

È la regola dell’A/B test detta con il cucchiaino. Un test senza ipotesi è una lotteria; un test con tre variabili insieme è una lotteria travestita da metodo.

Lezione 3: i semafori battono i numeri grezzi

La scelta che ha reso l’app usabile non è stata il motore di calcolo: sono stati i semafori. Verde, giallo, rosso invece di “PAC 28,4”. Perché un numero grezzo ti informa; un semaforo ti fa decidere.

Nei report di lavoro è la lezione più sottovalutata. Un dato che non cambia una decisione è arredamento. Il lavoro non è produrre più metriche: è tradurle in “cosa faccio adesso”. Un buon report è un semaforo con le fonti allegate.

La morale

Bilanciare PAC e POD e ottimizzare una conversione sono lo stesso mestiere: capisci i vincoli, cambi una cosa alla volta, misuri, e traduci il risultato in una decisione. L’ho imparato meglio da un’app sul gelato che da parecchi corsi.

Gelato AI è qui, con la storia dietro →

AEO, GEO, AIO: proviamo a fare ordine (e a farci trovare dalle AI)

Simone Bussoni — Tue, 10 Feb 2026 00:00:00 GMT

TL;DR

AEO (Answer Engine Optimization), GEO (Generative Engine Optimization) e AIO (AI Optimization) sono nomi diversi per la stessa transizione: si passa dall’‘ottimizzare per posizionarsi in una lista di link all’‘ottimizzare per essere capiti e citati dentro una risposta. Il lavoro concreto cambia poco nella tecnica e molto nella priorità: prima costruisci un’'entità credibile e contenuti citabili, poi pensi alle keyword. La SEO non muore, cambia destinatario.

Ogni pochi mesi esce una sigla nuova e qualcuno annuncia la morte della SEO. Facciamo ordine, perché sotto il rumore c’è un cambiamento vero — solo che non è quello del titolo clickbait.

Le tre sigle, in una riga ciascuna

AEO — Answer Engine Optimization: ottimizzare per i motori di risposta (i box “risposta diretta”, gli assistenti vocali). L’unità non è la pagina, è la risposta.
GEO — Generative Engine Optimization: ottimizzare per i motori generativi (ChatGPT, Perplexity, le AI Overview di Google). L’obiettivo è essere la fonte che il modello sceglie di citare.
AIO — AI Optimization: l’ombrello che tiene insieme tutto il resto, spesso usato come sinonimo di GEO.

Tre acronimi, una sola direzione: dal ranking alla citazione.

Cosa cambia davvero nel lavoro

Meno di quanto suggeriscono le sigle, in tecnica. Molto, nelle priorità.

1. Prima l’entità, poi le keyword. Un motore generativo cita fonti di cui si fida. La fiducia nasce dall’entità: chi sei, cosa dimostri di sapere, con quali fonti verificabili sei collegato. Dati strutturati coerenti, sameAs puliti, una biografia che coincide ovunque.

2. Contenuti citabili battono contenuti lunghi. Un modello estrae affermazioni nette, non paragrafi cauti. Un TL;DR in cima, una tesi chiara, esempi concreti. Se il tuo pezzo si può riassumere solo tradendolo, non verrà riassunto: verrà saltato.

3. La struttura conta più di prima. Heading in forma di domanda, risposta diretta nel primo paragrafo, liste e tabelle dove servono. Non per “piacere all’algoritmo”: per rendere il contenuto estraibile senza ambiguità.

4. Misura dove appari, non solo dove ranki. La metrica nuova non è la posizione media: è “quante volte vengo citato, e in che contesto, nelle risposte generative”. Gli strumenti stanno arrivando; intanto si controlla a mano, ponendo domande ai modelli.

Quello che NON cambia

La SEO tecnica resta igiene: sitemap, performance, crawlability, canonical. Necessaria, mai sufficiente — esattamente come prima. E resta vero che il contenuto deve servire a una persona: le AI sono addestrate su testo scritto per umani, non per algoritmi.

La sintesi che uso

La SEO non sta morendo: sta cambiando destinatario. Prima ottimizzavo per un motore che restituiva dieci link. Oggi ottimizzo anche per un sistema che restituisce una risposta e decide se dentro quella risposta c’è il mio nome. Il lavoro vero — costruire un’entità credibile e dire cose chiare — è lo stesso di sempre. Solo, adesso conta di più.

Se vuoi il quadro generale, è il cuore della mia pillar SEO & AI Search.

Ho rifatto il mio sito personale pensando alle AI: cosa ho scelto e perché

Simone Bussoni — Tue, 20 Jan 2026 00:00:00 GMT

TL;DR

Ho ricostruito simonebussoni.it partendo da una domanda: cosa serve perché un sistema — Google o un LLM — capisca chi sono e mi citi? Risposta: un’entità coerente (un solo nodo Person nel JSON-LD, referenziato ovunque via @id), contenuti citabili con un TL;DR in cima, un /llms.txt curato e una versione Markdown pulita di ogni pagina. Niente CMS, niente tracciamento prima del consenso, 100 di Lighthouse. Entity-first, non keyword-first.

Quando ho deciso di rifare il mio sito personale, la domanda di partenza non è stata “quali keyword voglio posizionare?”. È stata un’altra: cosa serve perché un sistema — Google, ChatGPT, Perplexity, Claude — capisca chi sono e decida di citarmi?

È una domanda diversa, e porta a scelte diverse. Le racconto qui, perché questo sito è il primo caso studio di sé stesso.

Entity-first, non keyword-first

La SEO che ho imparato nel 2008 partiva dalla pagina: una pagina, una keyword, un intento. Funziona ancora, ma è metà del lavoro. L’altra metà è l’entità: chi sei, cosa sai fare, con chi sei collegato, cosa hai fatto di verificabile.

I motori generativi non ragionano per pagine, ragionano per entità e relazioni. Se non sanno chi sei, non importa quanto è ottimizzata la singola pagina: non hanno un motivo per fidarsi di te abbastanza da citarti.

Così ho costruito il sito attorno a un’entità coerente prima ancora che attorno ai contenuti.

Un solo nodo Person, referenziato via @id

Ogni pagina emette un grafo JSON-LD, ma il nodo Person che mi descrive è definito una volta sola, con un @id stabile. Tutte le altre pagine — un post, la pagina di un progetto — non lo ridichiarano: lo referenziano via @id.

Il risultato è che un crawler che aggrega i miei dati non trova cinque versioni diverse di “Simone Bussoni” con dettagli leggermente diversi. Ne trova una, consistente, ovunque. La consistenza è fiducia, e la fiducia è ciò che fa la differenza tra essere indicizzati ed essere citati.

Nello stesso nodo ho messo geografia dettagliata (dove sono nato, dove vivo, dove lavoro), knowsAbout esplicito e un sameAs che è una whitelist: solo i profili che rappresentano davvero la mia identità professionale. Niente “per completezza”.

Contenuti citabili: il TL;DR in cima

Ogni post — questo compreso — inizia con un TL;DR. Non è pigrizia verso il lettore: è il blocco progettato per essere estratto. Le AI citano chi prende posizione con chiarezza in poche righe, non chi annega la tesi in tremila parole.

Se una macchina deve riassumere questo pezzo in due frasi, gliele ho già scritte io. Meglio che le scriva io.

/llms.txt e le versioni Markdown

Due dettagli tecnici che costano poco e dicono molto:

/llms.txt: un indice in Markdown, curato a mano, che spiega in tre righe chi sono e linka le pagine chiave. È il robots.txt dell’era degli LLM: un punto d’ingresso pensato per le macchine.
Versione Markdown di ogni pagina: accanto a ogni contenuto HTML c’è la stessa pagina in Markdown pulito, dichiarata nell’head con rel="alternate" type="text/markdown". Niente navigazione, niente rumore: solo il testo, come piace a un modello.

Nel robots.txt ho poi consentito esplicitamente GPTBot, ClaudeBot, PerplexityBot e Google-Extended. È una scelta deliberata: l’obiettivo non è difendersi dalle AI, è essere citati.

Le scelte “noiose” che rendono tutto più veloce

Niente CMS con database. I contenuti sono file nel repository. Meno superficie d’attacco, meno cose che si rompono, deploy statico.
Niente tracciamento prima del consenso. Consent Mode v2 con default denied: se non accetti, non parte nemmeno un cookie. Il sito funziona identico.
100 di Lighthouse come vincolo, non come obiettivo. Font self-hosted e in subset, zero JavaScript di framework, immagini responsive. La velocità è parte del messaggio: un sito lento su performance non è credibile quando parli di performance.

Perché raccontarlo

Perché è il modo più onesto di dimostrare una competenza: farla, e mostrare il dietro le quinte. Questo sito è la mia tesi sull’AI search scritta in HTML, JSON-LD e Markdown invece che in slide.

Se ti interessa il tema, ne parlo più in generale nella pillar SEO & AI Search.