A/B testing di sezione sulle landing di Fondazione Telethon

1. Cos'è un test A/B e perché in questo modo

1.1 Un test A/B mostra a persone diverse versioni diverse della stessa parte di una landing e misura quale porta più donazioni. Le versioni messe a confronto si chiamano varianti. La prima è il Controllo: la versione di riferimento, quella che la landing mostra già oggi.

1.2 Ogni visitatore riceve una sola variante e la ritrova quando torna. I visitatori sono divisi fra le varianti senza guardare chi sono, quindi i gruppi si somigliano in tutto tranne che in ciò che hanno visto. Se un gruppo dona di più, la differenza si può attribuire alla variante.

1.3 Qui si confrontano singole sezioni di una landing, non landing intere. L'editor sceglie una sezione, per esempio quella con il form di donazione, e ne prepara le varianti dentro la stessa landing. Il resto della landing è uguale per tutti. Il confronto fra le varianti di una landing si chiama esperimento.

1.4 L'esempio usato in tutto il documento è lo stesso della demo. Sulla landing «Natale, la gioia di donare» l'esperimento natale-importi confronta due versioni della sezione di donazione. Il Controllo propone la donazione mensile con 10, 20 e 30 €, con 20 € già scelti. La variante «Importi 15-25-40» propone 15, 25 e 40 €, con 15 € già scelti, e cambia il testo che spiega la donazione regolare. Il resto della sezione è identico.

1.5 Perché nessun servizio esterno. Molti strumenti di A/B testing sono servizi esterni: per funzionare ricevono dati su ogni visitatore. Fondazione Telethon ha posto vincoli GDPR che li escludono. Per questo l'esperimento funziona dentro l'infrastruttura che ospita le landing, su AWS, e nessun dato dei visitatori va a un fornitore di sperimentazione. Per scegliere la variante la piattaforma usa il metodo di calcolo di GrowthBook, uno strumento di A/B testing il cui codice è pubblico. È un metodo noto, che chiunque può verificare, riscritto dentro la piattaforma: non c'è un account GrowthBook né un server GrowthBook.

1.6 Perché la landing resta veloce. Una landing è preparata una volta sola, quando viene pubblicata. A ogni visita il visitatore la riceve già pronta, e per questo si carica in fretta. Durante un esperimento funziona allo stesso modo: anche ogni variante è preparata una volta sola. A ogni visita resta da decidere quale consegnare, con un calcolo così breve che il visitatore non lo percepisce.

1.7 Perché la landing non sfarfalla. Molti strumenti scelgono la variante nel browser, dopo che la landing è arrivata: il visitatore vede per un attimo il Controllo, che poi viene sostituito dalla variante. Questo salto visibile è lo sfarfallio. Qui la variante è scelta prima: il browser riceve solo quella e la mostra completa dal primo istante.

2. Preparazione

2.1 Un esperimento si crea nel pannello di amministrazione, che questo documento chiama Admin, dentro la collezione Esperimenti. Una collezione è un elenco di documenti dello stesso tipo: le altre sono Landing, Media e Utenti. Ogni esperimento appartiene a una sola landing, e una landing ha al massimo un esperimento non concluso alla volta (3.7).

2.2 Nel layout della landing l'editor aggiunge una Sezione A/B nel punto in cui vuole confrontare le varianti. Una Sezione A/B contiene una versione per ciascuna variante dell'esperimento, tutte dello stesso tipo di sezione: se il Controllo è una sezione di donazione, lo sono anche le altre varianti. Ogni versione ha tutti i campi del suo tipo di sezione, e l'editor può cambiarne uno solo o tutti. Le versioni possono differire nei contenuti, nel tema e nella combinazione di colori. Non serve duplicare la landing.

2.3 Quando si aggiunge una variante, la sua versione nasce come copia del Controllo nella stessa Sezione A/B. L'editor cambia solo ciò che vuole confrontare, nell'esempio gli importi e il testo della donazione regolare. Il resto resta identico, così una differenza nei risultati si può attribuire a quei cambiamenti.

2.4 Un esperimento ha da 2 a 4 varianti, Controllo compreso. Più sono le varianti, più piccoli sono i gruppi di visitatori e più tempo serve per vedere una differenza. L'Admin è costruito su Payload, un sistema di gestione dei contenuti: dove questo documento dice che Payload rifiuta qualcosa, l'Admin non lascia salvare e mostra il motivo. Payload rifiuta, per esempio, una Sezione A/B con versioni di tipi di sezione diversi.

2.5 Ogni variante ha un'etichetta leggibile, scelta da chi prepara l'esperimento, e un ID generato dal sistema, per esempio v_8f3k2. L'etichetta si può cambiare quando si vuole: i dati sono legati all'ID, che non cambia mai.

2.6 Il peso di una variante è la parte dei visitatori assegnati che la riceve. Nell'esempio i pesi sono 50 e 50: metà dei visitatori assegnati riceve il Controllo e metà «Importi 15-25-40». I pesi di tutte le varianti sommano a 100. Si impostano nell'esperimento e non nella Sezione A/B, perché una landing può avere più Sezioni A/B e tutte dividono i visitatori allo stesso modo (2.16).

2.7 La fascia di traffico decide chi può entrare nell'esperimento: tutto il traffico, solo chi arriva da campagne pubblicitarie (paid), solo chi arriva senza campagne pubblicitarie (organico), oppure solo chi arriva da un elenco di campagne scelte. Con la fascia paid, per esempio, l'esperimento riguarda solo chi arriva dalla pubblicità. La provenienza si ricava dall'indirizzo con cui il visitatore arriva la prima volta: i link delle campagne contengono codici che le identificano, come utm_campaign=natale-social. Chi è fuori fascia vede il Controllo senza partecipare. L'elenco di campagne ha un numero massimo di voci, e l'Admin avvisa se lo si supera.

2.8 La quota è la parte dei visitatori della fascia che entra nell'esperimento. Con quota 100% entrano tutti. Con quota 20% entra circa un visitatore su cinque, e gli altri vedono il Controllo senza partecipare. Una quota bassa serve a provare una variante nuova su poche persone. La quota non cambia i pesi: fra i visitatori che entrano la divisione resta quella scelta. Esempio con quota 20% e pesi 50 e 50: su 100 visitatori della fascia circa 80 restano fuori, circa 10 sono assegnati al Controllo e circa 10 alla variante.

2.9 L'esperimento può avere un avvio programmato e una fine programmata, per esempio le date di una campagna. L'intervallo fra le due si chiama finestra programmata. Prima dell'avvio e dopo la fine tutti vedono il Controllo. A quelle ore nessuno deve intervenire: a ogni visita la piattaforma controlla se l'ora cade dentro la finestra programmata.

2.10 Prima dell'avvio l'editor controlla ogni variante con la preview forzata: accanto a ogni versione della Sezione A/B c'è un link che apre la landing con quella variante. La preview forzata richiede l'accesso all'Admin e mostra sempre la variante richiesta, anche se all'editor, come visitatore, ne è toccata un'altra. Non conta come esposizione: i controlli dell'editor non entrano nei dati.

2.11 L'editor crea l'esperimento, che nasce in bozza. Finché resta in bozza l'editor prepara le Sezioni A/B e imposta varianti, pesi, fascia, quota e date. Avvio, fermo, conclusione e promozione spettano al responsabile esperimenti (capitolo 3).

Il simulatore di assegnazione

2.12 Il simulatore qui sotto fa arrivare visitatori immaginari su un esperimento e mostra come pesi, fascia di traffico e quota li distribuiscono. Usa lo stesso calcolo della piattaforma. La provenienza dei visitatori è fissa e serve solo all'esempio: 50% organico, 25% dalla campagna paid natale-social, 20% dalla campagna paid natale-search e 5% bot, cioè programmi automatici e non persone, che restano sempre fuori.

2.13 Con pochi visitatori la ripartizione osservata si allontana dai pesi: con 10 visitatori e pesi 50 e 50 può uscire 7 e 3. Con molti visitatori si avvicina, senza coincidere: su 10.000 la ripartizione osservata dista di solito qualche decimo di punto dal peso, per esempio 50,3% invece di 50%, e raramente più di un punto.

2.14 La vista del singolo visitatore, in fondo al simulatore, mostra il calcolo per un ID a scelta. I controlli sono tre, sempre in quest'ordine. Un bot resta fuori. Resta fuori chi arriva da una provenienza che la fascia di traffico non ammette. Per chi passa i primi due controlli, dall'ID esce un numero fra 0 e 1, e ogni variante occupa un intervallo largo quanto il suo peso: con pesi 50 e 50 il Controllo va da 0 a 0,5 e la seconda variante da 0,5 a 1. Un visitatore con numero 0,7585 riceve la seconda variante. Una quota sotto il 100% accorcia ogni intervallo nella stessa proporzione: con quota 20% il Controllo va da 0 a 0,1 e la seconda variante da 0,5 a 0,6, e lo stesso visitatore resta fuori quota. La vista dice a quale controllo il visitatore si ferma, perché, e che cosa cambiare per ottenere un altro esito.

Un caso più ampio: la landing Partner

2.15 Sulla landing «Partner, insieme la ricerca va più lontano», dedicata a un'azienda partner inventata, Vela Mobilità, l'esperimento partner-apertura ha due Sezioni A/B: l'apertura in cima e la sezione di donazione. Le varianti sono tre: Controllo, «titolo emotivo» e «titolo emotivo + importi più alti», con pesi 34, 33 e 33.

2.16 Ogni visitatore riceve la stessa variante in tutte e due le Sezioni A/B. Chi è assegnato a «titolo emotivo + importi più alti» vede il nuovo titolo nell'apertura e gli importi più alti nella sezione di donazione: non può capitare il titolo di una variante con gli importi di un'altra. Per questo i pesi stanno nell'esperimento: l'assegnazione è una sola per visitatore e vale per tutte le Sezioni A/B.

3. Avvio e ruoli

3.1 Chi usa l'Admin ha uno di tre ruoli:

• l'editor compone le landing e prepara le varianti, ma non avvia, ferma, conclude né promuove un esperimento;
• il responsabile esperimenti decide il ciclo di vita degli esperimenti: avvio, fermo, conclusione e promozione;
• l'amministratore gestisce gli utenti e i loro ruoli e ha tutti i permessi degli altri due.

3.2 I permessi non dipendono solo dai pulsanti che l'Admin mostra. Payload controlla il ruolo a ogni operazione, anche quando la richiesta arriva da un programma invece che dall'interfaccia.

3.3 Solo un amministratore cambia i ruoli, quindi nessuno può darsi da solo un ruolo con più permessi. Quando i ruoli entreranno in funzione, chi ha già un accesso all'Admin diventerà amministratore: così nessuno perde ciò che può fare oggi.

3.4 Il responsabile esperimenti avvia l'esperimento con il pulsante Avvia. Le varianti vanno online senza che GAG debba intervenire o pubblicare una nuova versione del software.

3.5 Prima di avviare, la piattaforma controlla che la landing sia pubblicata, che ogni Sezione A/B abbia una versione per ogni variante, che i pesi sommino a 100 e che la configurazione non sia troppo grande, per esempio per un elenco di campagne troppo lungo. Se un controllo fallisce, l'esperimento non parte e l'Admin dice cosa correggere, per esempio «La landing non è pubblicata: pubblicala prima di avviare l'esperimento».

3.6 Dall'avvio non si possono più cambiare il numero e l'elenco delle varianti, i pesi, la fascia di traffico, la quota e l'avvio programmato. Se queste regole cambiassero a metà, una parte dei visitatori passerebbe a un'altra variante e i dati raccolti prima e dopo non si potrebbero confrontare. Restano modificabili due cose: il contenuto delle varianti (capitolo 6) e la fine programmata, per esempio per prolungare un esperimento che ha ancora pochi visitatori.

3.7 Una landing ha al massimo un esperimento non concluso. Con due esperimenti insieme sulla stessa landing ogni visitatore vedrebbe una variante dell'uno e una dell'altro, e non si potrebbe dire quale dei due ha prodotto una differenza nelle donazioni.

3.8 Un esperimento può trovarsi in sei stati. In bozza si prepara e i visitatori non lo vedono. È programmato quando il responsabile lo ha avviato ma l'ora dell'avvio programmato non è ancora arrivata. In corso assegna i visitatori. Fermo è sospeso: tutti vedono il Controllo e al riavvio le assegnazioni restano le stesse. È terminato quando la fine programmata è passata: non assegna più visitatori ma non è chiuso. Concluso è chiuso in modo definitivo, con o senza promozione. Programmato e terminato non si impostano a mano: dipendono solo dalle date.

3.9 Nell'interattivo qui sotto si sceglie un ruolo e si provano le azioni. Le azioni non ammesse per quel ruolo o in quello stato restano grigie e spiegano il motivo. Nell'Admin vero chi non ha il ruolo non vede proprio quei pulsanti (figura 7.b).

4. Cosa vede il visitatore

4.1 Quando un visitatore apre la landing durante un esperimento in corso, la piattaforma decide la sua variante prima di inviargli la landing. Questa decisione si chiama assegnazione. È un calcolo, non un'estrazione a sorte: dall'ID del visitatore (4.3) e da un codice fisso dell'esperimento esce un numero fra 0 e 1, e la variante è quella nel cui intervallo cade il numero (2.14). Lo stesso ID dà sempre lo stesso numero, quindi la stessa variante.

4.2 Nella barra del browser il visitatore vede sempre lo stesso indirizzo, quello della landing pubblica, qualunque variante riceva. A quell'indirizzo la piattaforma gli consegna la pagina di variante che gli è stata assegnata, preparata in anticipo.

4.3 Alla prima visita la piattaforma salva nel browser il cookie di assegnazione. Contiene due informazioni: un ID casuale e la fascia di traffico. Dura 90 giorni, lo può leggere solo il sito delle landing e non contiene dati personali. La variante non è scritta nel cookie: si ricalcola a ogni visita dall'ID.

4.4 Chi torna entro 90 giorni con lo stesso browser ha lo stesso ID e vede la stessa variante. La landing non cambia fra una visita e l'altra.

4.5 Chi cancella i cookie, usa un altro dispositivo o un altro browser, o torna dopo 90 giorni, riceve un ID nuovo ed è trattato come un visitatore nuovo: la variante si ricalcola e può essere diversa. La piattaforma non ha modo di sapere che è la stessa persona.

4.6 Un visitatore escluso vede il Controllo senza partecipare all'esperimento e non entra nei suoi dati. Succede per quattro motivi: è un bot, è fuori dalla fascia di traffico, è fuori quota, oppure la visita cade fuori dalla finestra programmata. Tutti gli altri sono visitatori assegnati, anche quelli a cui è toccato il Controllo.

4.7 I motori di ricerca ricevono sempre il Controllo, senza cookie. Le pagine di variante non sono indicizzate e non si raggiungono con un indirizzo proprio: i risultati di ricerca mostrano solo la landing pubblica. Così il posizionamento della landing nei risultati di ricerca non dipende dall'esperimento.

4.8 La landing si carica veloce come oggi e non sfarfalla, perché la variante è già scelta quando la landing parte verso il browser (1.6).

4.9 Nell'interattivo qui sotto lo stesso visitatore torna sulla landing «Natale, la gioia di donare» in situazioni diverse. Il calcolo è lo stesso del simulatore, con pesi 50 e 50, tutto il traffico e quota 100%.

5. Misura

5.1 Un esperimento confronta le conversioni delle varianti: inizio del form, invio del form e donazione completata. Ogni conversione produce un evento, cioè un messaggio che segnala agli analytics che cosa è successo. Gli analytics di Fondazione Telethon sono Google Analytics 4 (GA4). Gli eventi hanno gli stessi nomi e gli stessi parametri che usa già il contenitore di Google Tag Manager (GTM) di Telethon, cioè la configurazione che oggi raccoglie gli eventi delle landing e li passa a GA4. Per questo i report esistenti continuano a funzionare.

5.2 Oltre alle conversioni si contano le esposizioni. C'è un'esposizione quando un visitatore assegnato carica una pagina di variante, e un'altra quando una Sezione A/B gli compare sullo schermo. Le esposizioni dicono quante persone hanno davvero visto ciò che si confronta: le conversioni di una variante si rapportano a questo numero. Gli eventi sono due: experience_impression quando la pagina di variante si carica, e experiment_section_view la prima volta che una Sezione A/B entra nello schermo, una volta per ciascuna Sezione A/B. Il secondo serve perché chi non scorre la landing può non arrivare mai a una Sezione A/B che sta in basso.

5.3 Ogni evento di un visitatore assegnato porta la stringa di variante, nel parametro exp_variant_string. Per esempio natale-importi:r1:v_8f3k2 contiene, separati da due punti, la chiave dell'esperimento (natale-importi), la revisione (r1) e l'ID della variante (v_8f3k2, cioè «Importi 15-25-40»).

5.4 Se durante l'esperimento si conferma una modifica a una variante (capitolo 6), la revisione sale e la stringa diventa natale-importi:r2:v_8f3k2. I dati raccolti prima e dopo la modifica restano separabili.

5.5 I visitatori esclusi non producono esposizioni, e i loro eventi partono senza stringa di variante. Le loro conversioni restano nei report generali ma non contano per nessuna variante.

5.6 experience_impression, experiment_section_view e form_start partono dal browser e vanno nel dataLayer, l'elenco in cui la landing mette gli eventi perché il contenitore GTM di Telethon li legga. form_submit e donazione partono dal server della piattaforma, che riceve il form e lo inoltra a Direct Channel, il sistema che registra le donazioni. Gli eventi dal server non passano dal browser, quindi non li fermano gli ad blocker, cioè le estensioni del browser che bloccano pubblicità e tracciamento.

5.7 Con la donazione la piattaforma invia a Direct Channel anche l'esperimento e la variante. Così una donazione si collega alla sua variante anche nei sistemi di Direct Channel. Il campo che li riceve va concordato con Direct Channel.

5.8 donazione parte dal server solo dopo che Direct Channel ha accettato il versamento. Se l'invio agli analytics fallisce, la donazione va comunque a buon fine: il tracciamento non blocca mai una donazione.

5.9 Un solo invio di donazione. Sulle nuove landing donazione parte dal server (5.6). Il contenitore GTM non deve inviare lo stesso evento anche dal browser sulle nuove landing. Se lo facesse, ogni donazione arriverebbe a GA4 due volte e il numero delle donazioni nei report raddoppierebbe.

5.10 Nell'interattivo qui sotto un visitatore assegnato a «Importi 15-25-40» fa una donazione mensile di 15 €. Ogni passo mostra gli eventi che partono, da dove e con quali parametri. I valori dei parametri sono dimostrativi.

6. Modifiche durante l'esperimento

6.1 Durante l'esperimento il contenuto delle varianti resta modificabile: un refuso si corregge senza fermare nulla.

6.2 Quando l'editor pubblica la landing con una modifica a una variante di un esperimento in corso o fermo, Payload blocca la pubblicazione e mostra un avviso. Per pubblicare bisogna spuntare una conferma esplicita, perché la modifica cambia ciò che vede una parte dei visitatori mentre i dati si stanno raccogliendo. La conferma vale per quella pubblicazione: la modifica successiva la chiede di nuovo.

6.3 Dopo la pubblicazione confermata la revisione dell'esperimento sale di 1. I visitatori restano nella loro variante. Cambia la stringa di variante dei loro eventi, da …:r1:… a …:r2:…, così i dati prima e dopo la modifica si possono separare. Cambiare il tema o la combinazione di una variante è una modifica come le altre: chiede la stessa conferma e fa salire la revisione.

6.4 Le modifiche alle sezioni fuori dalle Sezioni A/B non toccano l'esperimento: non chiedono conferma e non cambiano la revisione. Valgono per tutti i visitatori, perché quelle sezioni sono uguali in tutte le varianti.

6.5 Dall'avvio Payload rifiuta i cambiamenti che renderebbero impossibile confrontare i dati raccolti: aggiungere o togliere varianti, cambiare il tipo di sezione di una Sezione A/B, aggiungere o togliere una Sezione A/B dell'esperimento. Con una variante in più, per esempio, i visitatori si dividerebbero in modo diverso da prima. Per fare questi cambiamenti si conclude l'esperimento e se ne prepara uno nuovo.

7. Fine e promozione

7.1 Il responsabile esperimenti può fermare un esperimento in corso, per esempio per indagare su un problema. Mentre è fermo tutti vedono il Controllo e non partono esposizioni.

7.2 Al riavvio le assegnazioni restano le stesse: chi vedeva una variante la rivede, e la revisione non cambia. Un esperimento si può quindi sospendere senza che i visitatori cambino variante.

7.3 Quando passa la fine programmata, l'esperimento è terminato: non assegna più visitatori e tutti vedono il Controllo, ma non è chiuso. Il responsabile può spostare la fine più avanti, concludere l'esperimento o promuovere una variante.

7.4 Concludere chiude l'esperimento in modo definitivo. Un esperimento concluso non riparte.

7.5 Con la promozione il responsabile sceglie la variante vincente e la applica con un'unica azione. Ogni Sezione A/B dell'esperimento viene sostituita, nella stessa posizione, dalla versione della variante scelta. Le altre sezioni restano dove sono. La landing viene pubblicata e l'esperimento risulta concluso con la variante promossa. Da quel momento tutti vedono la variante scelta sulla landing pubblica.

7.6 Si può promuovere una sola volta, quando l'esperimento è in corso, fermo, terminato o concluso. La scelta della variante spetta al responsabile, che decide sui risultati letti in GA4: la piattaforma non dichiara un vincitore (9.2). L'interattivo del capitolo 3 (Ciclo di vita dell'esperimento) mostra fermo, riavvio, conclusione e promozione.

8. Privacy e consenso

8.1 Il cookie di assegnazione contiene solo un ID casuale e la fascia di traffico in cui il visitatore è arrivato. Dura 90 giorni, lo può leggere solo il sito delle landing e non contiene dati personali né la variante.

8.2 Un cookie tecnico è un cookie necessario al funzionamento di un sito, che si può impostare senza chiedere il consenso. Il cookie di assegnazione serve solo a mostrare a ogni visitatore la stessa variante a ogni visita. Per questo è pensato come cookie tecnico e si imposta prima che il visitatore scelga nel banner del consenso. La classificazione spetta alla privacy di Fondazione Telethon.

8.3 L'ID del cookie di assegnazione non diventa mai un identificativo degli analytics: non arriva a GA4, al tagging server (il server di Telethon che riceve gli eventi e li passa a GA4) né a Direct Channel. Se servisse a riconoscere il visitatore nei report, il cookie diventerebbe uno strumento di tracciamento e non potrebbe più essere classificato come tecnico. Per riconoscere il visitatore gli eventi dal server usano l'identificativo di Google Analytics già presente nel browser.

8.4 Gli eventi dal server seguono la scelta sugli analytics che il visitatore fa in Didomi, il banner del consenso delle landing. Prima di una scelta vale l'impostazione predefinita del contenitore GTM di Telethon, che oggi concede gli analytics. Dopo un rifiuto dal server non parte nessun evento. Gli eventi dal browser vanno comunque nel dataLayer: è il contenitore di Telethon a decidere, come fa oggi, se passarli agli analytics secondo il consenso. L'interattivo «Flusso degli eventi» del capitolo 5 (5.10) mostra i tre casi.

8.5 Email e numero di telefono. Oggi il contenitore GTM di Telethon invia a GA4 l'email e il numero di telefono del donatore, nei parametri email e phone_number degli eventi del form e della donazione. La nuova piattaforma non li invia mai agli analytics. Email e telefono vanno solo a Direct Channel, che li riceve per registrare la donazione. Gli analytics servono a contare e confrontare le donazioni; per farlo non serve sapere chi è il donatore.

8.6 La piattaforma non conserva assegnazioni, esposizioni, eventi né dati dei donatori. Payload conserva soltanto i contenuti delle landing, le loro versioni, gli esperimenti con le loro regole e il loro stato, i media e gli account dell'Admin. Le donazioni sono registrate da Direct Channel; gli eventi arrivano a GA4.

9. Limiti

9.1 La soluzione non usa nessun servizio esterno di sperimentazione, per i vincoli GDPR di Fondazione Telethon (1.5).

9.2 Quei servizi di solito fanno anche il calcolo statistico che dice se una differenza fra varianti è reale o dovuta al caso, e quindi quale variante ha vinto. Senza di loro questo calcolo non c'è. L'Admin non mostra risultati: mostra lo stato degli esperimenti. I risultati si leggono in GA4, e la scelta della variante da promuovere spetta al responsabile esperimenti.

9.3 La piattaforma non conserva assegnazioni, esposizioni, eventi né dati dei donatori (8.6). Chi ha visto quale variante si ricostruisce solo dagli eventi arrivati a GA4.

10. Glossario

Questi sono i termini usati nel documento e nell'Admin. Accanto a ogni voce ci sono l'equivalente inglese più diffuso nel settore e le parole che evitiamo perché indicano anche altro.