Transfer learning web: mutuato dalla mobilità urbana, ma restano dubbi sui criteri di similarità.
Una pagina di categoria con 1.800 sessioni al mese, un effetto atteso del 7% e una significatività al 95%: servono quasi quattro mesi per chiudere un singolo test. Nel frattempo la stagionalità cambia, il traffico si sposta, e il vincitore dichiarato è già un reperto. La scarsità di dati non riguarda solo l’e-commerce minore: colpisce qualsiasi pagina che non sia la home o una top category. E la soluzione, per assurdo, arriva da un ambito che non centra nulla con i test A/B: i luoghi fisici con poche visite.
Prima di capire come, serve un passaggio intermedio. Il riconoscimento che due frasi come “il gatto non sta bene” e “il felino è malato” non hanno quasi parole in comune, ma un modello addestrato le interpreta come la stessa informazione, non è un dettaglio semantico: è il fondamento dell’information gain. Se un sistema sa mappare equivalenze oltre la superficie lessicale, allora può trasferire conoscenza da una pagina all’altra, da un luogo all’altro.
La coda lunga dei negozi non si risolve aspettando più visite
Google Research ha affrontato il problema con un framework chiamato ME-POIs. L’approccio introduce un cambio di paradigma spostando la mobilità da output da prevedere a input che definisce il luogo: i dati di movimento diventano una caratteristica intrinseca del punto di interesse, non una sua conseguenza. Per realizzarlo, il sistema usa un approccio self-supervised che fonde descrizioni testuali e pattern di mobilità anonimizzati provenienti da benchmark pubblici. Poi costruisce, attraverso la visit alignment, un “centroide funzionale”: una firma multidimensionale che mappa i pattern aggregati di visite su un ciclo annuale e per giorni della settimana. Infine, applica un meccanismo di propagazione multiscala: guarda ai luoghi adiacenti su scala di strada, isolato e quartiere, e trasferisce statisticamente i pattern di visita da luoghi affollati a quelli con dati sparsi.
Il test chiave: il framework è stato addestrato su luoghi osservati e poi interrogato su attributi di luoghi completamente nuovi.
E il mondo della CRO non è rimasto fermo. Tra il 24 e il 31 luglio 2026, Optimizely ha pubblicato quattro video consecutivi sull’AI applicata alla sperimentazione: il video di Optimizely Bringing AI into CRO? Start here (31 luglio), il video di Optimizely Tech changes. Your testing mindset shouldn’t (29 luglio), il video di Optimizely How data teams should actually adopt AI (27 luglio), e il video di Optimizely Your experimentation program is TOO slow (24 luglio). Quattro uscite in otto giorni non sono una coincidenza: segnalano che il trasferimento di pattern da pagine ad alto traffico sta smettendo di essere un’idea da paper.
Il transfer learning sui test A/B non è più una promessa da convegno
Il principio è lo stesso: le pagine ad alto traffico generano abbastanza dati per capire quali varianti funzionano, quali messaggi tengono, quali attriti bloccano. Le pagine a basso traffico no. Ma se un modello può riconoscere che una pagina prodotto di nicchia condivide struttura semantica e intento con una top category, allora può propagare i pattern di comportamento appresi da quest’ultima. Non è magia: è la stessa logica della propagazione da luoghi affollati a luoghi sparsi, applicata alle visite web invece che a quelle fisiche. E i video di Optimizely lo confermano: l’AI non serve a sostituire i test, serve a farli partire da un priore migliore.
Cosa resta da testare prima di fidarsi senza riserve
Il transfer learning per la CRO ha ancora tre nodi aperti. Primo: quanto devono essere simili due pagine perché il trasferimento sia affidabile? Una scheda prodotto di elettronica ha poco da spartire con una landing di servizi, ma anche due categorie di abbigliamento possono differire per stagionalità, ticket medio e ruolo nel funnel. Secondo: quanto traffico serve sulla pagina sorgente per calibrare un modello che non sia solo rumore? Terzo: il trasferimento può ereditare anche bias, non solo pattern. Se la pagina ad alto traffico ha un difetto di usabilità non rilevato, trasferirlo alla coda lunga significherebbe diffondere l’errore. Testare questi limiti è il prossimo esperimento, non l’implementazione.
