Servizio · CRO e A/B testing

Un programma di ottimizzazione continua per l'ecommerce, misurato sul fatturato.

Behavioral analytics per trovare gli attriti, diagnosi con l'AI in minuti, ipotesi prioritizzate con criteri condivisi, A/B test senza flickering, impatto misurato dopo ogni rilascio. Analisi, design e codice della variante nascono insieme: quando il test vince, il system integrator la rilascia, non la riscrive.


01 / 05 · 01 · Cosa faccio

Un programma CRO senza il vuoto tra il test vinto e il codice

Diagnosi sui dati di comportamento, ipotesi prioritizzate con criteri condivisi, varianti progettate e sviluppate in codice, impatto misurato sul fatturato. Per brand fashion e luxury con un ecommerce proprio e un team interno.

  1. Brand fashion e luxury di media e grande dimensione, con un ecommerce su Salesforce Commerce Cloud, Shopify o headless, un team interno e un system integrator che rilascia.

    • Fashion e luxury
    • Team ecommerce interno
    • SFCC · Shopify · headless
    Il programma è adatto sePer chi
    • Ecommerce proprio e team internoDirezione ecommerce, UX, IT, system integrator
    • Traffico che permette di misurareO la volontà di partire da audit e behavioral analytics
    • Un system integrator che rilasciaE che oggi dal CRO riceve slide, non codice
    • Management che vuole l'impatto sul fatturatoNon il numero di test lanciati
    • Non è adatto seSi cerca una lista di best practice, o un tool che faccia il programma da solo
  2. Leggo il comportamento reale sull'ecommerce, non le opinioni: dove le persone si bloccano, quante sono, in quali mercati e dispositivi. Prima chi arriva, poi i numeri, poi i comportamenti, il perché alla fine.

    • Contentsquare
    • GA4
    • Session replay
    • Monitoraggio errori
    Dal listing all'ordine · mobileEsempio
    1. Listing100%
    2. Scheda prodotto62%
    3. Selettore taglia41%
    4. Aggiunta al carrello23%
    5. Carrello19%
    6. Ordine7%

    Rage click sulle taglie esaurite: il selettore non dice che la taglia manca finché non si prova ad aggiungerla.

  3. Ogni attrito diventa un'ipotesi scritta nello stesso formato e riceve un punteggio PXL con criteri uguali per tutti i team. Il backlog si ordina da solo.

    • Template di ipotesi
    • PXL
    • ICE
    • Backlog ordinato
    Punteggio PXL · backlog Q4Esempio
    Immagini indossate in PLPTaglia consigliata in PDPRiepilogo ordine compatto
    Above the fold110
    Visibile in 5 secondi101
    Aggiunge o toglie elementi011
    Supportato da dati di comportamento111
    Supportato da ricerca o benchmark100
    Pagine ad alto traffico110
    Facilità di sviluppo (0-2)212
    Punteggio755
  4. Disegno e sviluppo io la variante, sui componenti del design system del brand, con QA su dispositivi e browser reali, senza brief da tradurre né passaggi di consegne.

    • Design system del brand
    • Analisi, design e codice
    • QA multi-device
    Variante B · taglia consigliata in PDPA/B test
    Variante B

    La variante è costruita sui componenti esistenti: quella che vince è già il codice da rilasciare.

  5. Dopo ogni rilascio misuro l'effetto su conversione e fatturato, test o fix che sia. Quella misura ordina il ciclo successivo e riempie la pagina che legge il management.

    • Conversione
    • Fatturato
    • Prima e dopo
    Dopo il rilascio · checkout a passaggiGUESS
    Conversione al checkout+28%rispetto al checkout precedente
    Conversione da mobile+15%flusso mobile-first
    Ripensamenti al pagamentoin calorivelazione progressiva
    Bug post-rilasciochiusianalytics + session replay
A/B test condotti su un ecommerce con 60+ mercati, in dieci anni alla guida di UX e frontend
150+
di conversione al checkout dopo un redesign guidato dai dati, +15% da mobile
+28%
analisi, design e codice della variante, senza passaggi di consegne
1 flusso
Il caso: redesign del checkout GUESS →

02 / 05 · 02 · Il ciclo CRO

Il ciclo CRO: dal comportamento al fatturato

Un ciclo settimanale: si osserva, ogni attrito prende una strada, la diagnosi arriva in minuti con l'AI, ogni rilascio viene misurato.

  1. Funnel, heatmap, segnali di frustrazione, errori e registrazioni di sessione letti con cadenza fissa, non quando un KPI crolla. Nel primo mese bastano a trovare i tre interventi che valgono di più.

    • Cadenza settimanale
    • Heatmap
    • Frustration score
    • Errori tecnici
    Scheda prodotto → ordine · ultimi 7 giorniEsempio
    Scheda prodotto100%
    Aggiunta al carrello37%Rage click sul selettore taglia e zoom lento su iOS
    Carrello31%
    Ordine11%
  2. Ogni attrito entra in una dashboard CRO con la sua evidenza e prende una di due strade parallele: miglioramento UX da testare, oppure correzione tecnica da sviluppare.

    • Dashboard CRO
    • Due flussi
    • ClickUp o Jira
    • Priorità per impatto
    Dashboard CRO · settimana 42Esempio

    Segnali 3

    PDPRage click sulle taglie esaurite
    PDPZoom immagine lento su iOS
    CarrelloCodice promo perso al login

    Flusso UX 2

    IpotesiTaglia consigliata sotto il selettore
    IpotesiAvviso resi gratuiti in carrello

    Flusso sviluppo 2

    FixTaglie esaurite disabilitate
    FixPromo conservata al login

    Misurati 1

    + conversione PLPFiltri che restano al back
  3. L'AI collegata in sola lettura a Contentsquare e GA4: la diagnosi che richiedeva 2-4 ore arriva in meno di 5 minuti, con le sessioni da verificare. I ticket si aprono solo dopo una conferma.

    • Contentsquare + Claude via MCP
    • Domande standard
    • Conferma umana
    • DX Awards 2026
    AI · behavioral analyticsEsempio

    Sul percorso scheda prodotto → carrello da mobile, quali sono i tre attriti che costano di più questa settimana?

    Tre attriti, in ordine di sessioni perse

    1. Selettore taglia: rage click sulle taglie esaurite, in crescita da martedì. 12 sessioni allegate. Proposta: fix.
    2. Zoom immagine: lento solo su iOS, correlato alle uscite dalla scheda. 6 sessioni. Proposta: verifica tecnica.
    3. Carrello: il codice promo si perde al login. Proposta: fix, poi ipotesi UX sul riepilogo.
  4. Dopo il rilascio rileggo i dati nel punto corretto e calcolo quanto vale in conversione e fatturato. Quella misura, e non l'urgenza percepita, decide le priorità del ciclo successivo.

    • Impatto economico
    • Registro degli interventi
    • Report settimanale
    Prima e dopo il programmaGuess Europe
    • Una diagnosi2-4 ore< 5 min
    • Report giornalieromezza giornataautomatico
    • Interventi CRO al mese160 (15 a settimana)
    • Test al mese18

    primadopo

interventi CRO: da uno al mese a quindici a settimana, misurati dopo il rilascio
1 → 15
per una diagnosi che richiedeva 2-4 ore
< 5 min
iniziative CRO portate in produzione
80+
Il processo CRO continuo →

03 / 05 · 03 · Il programma di A/B test

Dall'ipotesi al codice in produzione

Un test vale quanto il processo che lo sceglie e quanto il codice che lo esegue: da un test al mese a otto, senza flickering, e quando vince non c'è niente da riscrivere.

  1. Una board unica per tutti i team: può proporre chiunque, ma nel formato del template. Problema osservato, dato che lo conferma, cambiamento proposto, metrica che deve muoversi.

    • Board unica
    • Template di ipotesi
    • Tutti i team
    Nuova ipotesi · immagini del listingTemplate
    • Problema osservatoNel listing si passa il cursore sulla seconda immagine e si clicca poco: la still life non basta a decidere
    • Dati a supportoHeatmap e scroll map del listing, benchmark su 30+ concorrenti
    • Cambiamento propostoImmagine indossata per prima, still life al passaggio
    • Metrica primariaClick-through verso la scheda prodotto; secondaria: aggiunte al carrello
    • QualificazioneIn attesa del punteggio
  2. ICE come primo filtro veloce, PXL per decidere l'ordine. L'approvazione diventa una lettura del punteggio, non un dibattito.

    • ICE
    • PXL
    • Criteri espliciti
    Primo filtro ICE · backlogEsempio · 1-10
    Immagini indossate in PLPBadge resi gratuitiCheckout come ospite
    Impatto atteso859
    Fiducia nei dati846
    Facilità di sviluppo993
    Punteggio251818
  3. Lo strumento di test scrive solo un cookie; il frontend applica le modifiche prima del primo rendering. Anche i test che cambiano immagini o layout girano senza flickering e senza passare dal server.

    • AB Tasty
    • Antiflickering
    • Codice sul design system
    • QA multi-device
    plp-images.variant.tsVariante B
    1import { ProductCard } from "@ds/organisms";23// AB Tasty scrive solo il cookie: le modifiche le applica il frontend4const variant = readCookie("abt_plp_images");5if (variant !== "B") exit("control");67// prima del primo render: nessuno vede l'immagine originale8ProductCard.configure({ primary: "on-model", hover: "still-life" });9track("ab_exposure", { test: "plp-images", variant });
  4. Ogni test chiude con una decisione documentata nella board, anche quando perde. Quando vince, la variante è già codice sul design system: il system integrator la rilascia, non la riscrive.

    • Archivio dei risultati
    • Decisione
    • Rilascio, non riscrittura
    Immagini del listing · risultatoEsempio
    ControlloStill life per prima
    VinceImmagine indossata per prima

    Più click verso la scheda prodotto: la variante entra in produzione così com'è, e la decisione resta nell'archivio insieme ai test persi.

test al mese, con lo stesso metodo per tutti i team
1 → 8
anche sui test che cambiano immagini o layout
0 flickering
la variante vincente è il codice che va in produzione
0 riscritture
Il programma di A/B test →

04 / 05 · 04 · Perché conviene

Rispetto a un'agenzia CRO o a un tool

Un'agenzia analizza e propone ma non sviluppa; un tool esegue ma non decide. Il lavoro si ferma tra la variante che ha vinto e il codice in produzione: qui quel passaggio non esiste.

  1. In un'agenzia sono tre persone e un brief; con un tool è l'editor visuale fuori dal design system. Qui diagnosi, design e codice nascono insieme, sui dati e sui componenti del brand.

    • Nessun handoff
    • Design system del brand
    Dalla diagnosi alla variante in testDue modi di arrivarci

    Agenzia CRO o tool

    1. Analista: slide con la diagnosi
    2. Designer: mockup fuori dal design system
    3. Brief allo sviluppo interno
    4. Sviluppo in uno sprint successivo
    5. Test, con flickering

    Programma gestito da me

    1. Diagnosi sui dati, con l'AI
    2. Variante disegnata e sviluppata sul design system
    3. Test senza flickering

    Il test parte prima ed è fedele al design system.

  2. Con un'agenzia la variante va riscritta per la produzione: secondo sviluppo, seconda QA, mesi dopo. Qui è già codice pronto: il system integrator la rilascia.

    • Variante già in codice
    • Rilascio, non riscrittura
    Dopo il test vintoCosa sparisce
    • Brief di riscrittura allo sviluppo1 sprint
    • Seconda QA su dispositivi e browsergiorni
    • Variante infedele al testrisultato non replicato
    • Rilascio del codice già testato1 PR
    • Dal test vinto alla produzionesettimane, non mesi
  3. Una board unica con template e punteggio PXL uguale per tutti i team, al posto della roadmap dell'agenzia o dell'idea di chi insiste di più.

    • PXL
    • Board unica
    • Criteri visibili a tutti
    Come si decide cosa testareConfronto
    Agenzia o toolProgramma
    Criteri scritti e uguali per tutti i team01
    Ogni ipotesi richiede un dato01
    Punteggio visibile nel backlog01
    Idee da tutti i team, non da un fornitore01
    Learning dei test chiusi riusati01
    Punteggio05
  4. Una pagina a settimana con impatto su conversione e fatturato, più report giornalieri e avvisi prodotti dagli agenti, al posto di decine di slide a trimestre.

    • Una pagina a settimana
    • Agenti per report e avvisi
    • Soglie sui KPI
    Report al management · il programmaGuess Europe
    Test al mese8prima 1
    Interventi CRO15 / settimanaprima 1 al mese
    Tempo di diagnosi< 5 minprima 2-4 ore
    Report giornalieroautomatico2,5 giorni a settimana risparmiati
Best Use of AI ai Digital Experience Awards 2026 (Contentsquare)
1° premio
risparmiati solo sui report giornalieri
2,5 giorni / settimana
dal test vinto alla produzione
mesi → settimane
Il workflow Contentsquare + Claude →

05 / 05 · 05 · Governance e strumenti

Il programma che resta al team

Un posto solo per le ipotesi, due flussi per gli attriti, gli strumenti già in uso nel brand e un team che a fine programma fa girare il ciclo da solo.

  1. Il programma vive nello strumento che il team usa già, ClickUp o Jira: idee, qualificazione, approvazione, test attivi, risultati. Template e questionario PXL sopra, archivio dei learning sotto.

    • ClickUp
    • Jira
    • Template
    • Archivio
    Il programma, a stratiNello strumento del team
    1. 01Template di ipotesi e questionario PXLLe stesse domande per ogni idea, da qualunque team arriviMetodo
    2. 02Board unicaIdee · qualificazione · approvazione · test attivi · risultatiClickUp o Jira
    3. 03Dashboard CROSegnali smistati tra flusso UX e flusso sviluppoDue flussi
    4. 04Archivio dei testAnalisi ed esito di ogni test chiuso, anche quando perdeLearning
  2. Ogni segnale diventa una card con la sua evidenza e viene classificato come tema UX o correzione tecnica. Le due code avanzano in parallelo e tornano in dashboard per la misura.

    • Criteri di smistamento
    • Flusso UX
    • Flusso sviluppo
    Da segnale a rilascioDue flussi
    1. Segnale dalla behavioral analytics, con evidenzaAutomatizzato
    2. Card nella dashboard CROAutomatizzato
    3. Tema UX o correzione tecnica?Decisione
    4. Flusso UX: ipotesi → PXL → test → decisioneAutomatizzato
    5. Flusso sviluppo: fix → QA → rilascioAutomatizzato
    6. Misura dell'impatto dopo il rilascioDecisione
  3. Lavoro con lo stack già in uso nel brand; se uno strumento manca, lo scelgo e lo configuro con il team. Il metodo è lo stesso con strumenti diversi.

    • Contentsquare
    • GA4
    • AB Tasty
    • SFCC · Shopify
    • Claude via MCP
    Lo stack del programmaAdattabile al brand
    1. Behavioral analyticsContentsquareSession replayMonitoraggio errori
    2. Web analyticsGoogle Analytics 4Looker Studio
    3. A/B testingAB TastyAntiflickering lato frontend
    4. PiattaformeSalesforce Commerce CloudShopifyHeadless
    5. GovernanceClickUpJiraFigmaStorybook
    6. AIClaude via MCPAgenti per report e avvisi
  4. Per partire servono traffico sufficiente a misurare, accessi in lettura agli strumenti e un referente nel team. A fine programma board, template, agenti e domande standard restano al brand.

    • Traffico
    • Accessi
    • Un referente
    • Formazione
    Per partire e per restareRequisiti
    • Traffico sufficienteAlcune migliaia di conversioni al mese sulla pagina testata; sotto, audit e misura prima/dopo
    • Accessi agli strumentiBehavioral e web analytics in lettura, strumento di test, repository o design system
    • Un referente nel teamPartecipa alla cadenza settimanale e conferma le priorità
    • FormazioneTemplate, PXL, domande standard per l'AI, criteri di smistamento
    • Cosa resta al teamBoard, dashboard, archivio, agenti configurati: il ciclo gira senza di me
per tutti i team, nello strumento che usano già
1 board
UX e sviluppo, in parallelo e misurati
2 flussi
a fine programma: metodo, strumenti e agenti restano al team
0 dipendenze
Vedi tutte le aree di intervento →

Formati

UX audit con piano di test

Mappa degli attriti ordinata per impatto e backlog di ipotesi già prioritizzate con PXL.

3-4 settimane

Programma trimestrale di CRO e A/B testing

Un mese di osservazione e backlog, due di test e rilasci, report d'impatto su conversione e fatturato.

Un trimestre, rinnovabile

Affiancamento fractional come CRO/UX lead

Dentro il team ecommerce: ciclo CRO, varianti in codice, formazione, report al management.

1-2 giorni a settimana

Casi

Vedi tutte le aree di intervento →

Domande frequenti

Quanto traffico serve per fare A/B test?

Come riferimento, alcune migliaia di conversioni al mese sulla pagina testata, per chiudere un test in due-quattro settimane. Sotto quella soglia si lavora con behavioral analytics, session replay e misura prima/dopo.

Con quali strumenti lavori?

Contentsquare, Google Analytics 4, AB Tasty, ClickUp o Jira, Figma e Storybook, con l'AI collegata via MCP a Contentsquare e GA4. Se lo stack del brand è diverso, lavoro con quello già in uso.

Quanto dura un programma?

Il formato principale è il trimestre rinnovabile: un mese di osservazione e backlog, due di test e rilasci. L'audit richiede tre-quattro settimane; l'affiancamento fractional segue il ritmo del team.

Chi sviluppa le varianti?

Io, sui componenti del design system del brand, con QA su dispositivi e browser reali. Quando il test vince la variante è già codice pronto per la produzione: il system integrator la rilascia, non la riscrive.

Come si evita il flickering?

Lo strumento di test scrive solo un cookie; il frontend lo legge e applica le modifiche prima del primo rendering. Funziona anche sui test che cambiano immagini o layout, senza passare dal server.

Come si decide quale test fare per primo?

Con ICE come primo filtro e PXL per l'ordine: domande sì o no uguali per ogni ipotesi, da qualunque team arrivi. Il punteggio ordina il backlog e l'approvazione diventa una lettura, non un dibattito.

Come si riporta al management?

Una pagina a settimana, sempre nello stesso formato: test chiusi, interventi rilasciati, impatto su conversione e fatturato. I report giornalieri e gli avvisi sui KPI li producono gli agenti.

Cosa succede se un test perde?

Si chiude con una decisione e si documenta nella board come un test vinto, con il learning che alimenta le ipotesi successive. Un test perso evita un rilascio che avrebbe peggiorato la conversione.

Si può fare senza AB Tasty?

Sì: board, template, PXL e misura dell'impatto funzionano con qualunque piattaforma di testing, e l'antiflickering si adatta a qualunque tool esponga la variante al frontend. Se manca uno strumento, lo scelgo e lo configuro con il team.

Come si integra con un redesign?

Prima del redesign il ciclo CRO dice quali sezioni perdono di più e i test validano le scelte una alla volta; dopo, il programma misura il rilascio e continua a ottimizzare sul nuovo design system.