Tre tipi di test, un editor visivo

Uno script nel head è tutta l’installazione, ed è l’unica modifica al vostro sito. Da lì una variante si costruisce puntando gli elementi sulle vostre pagine in produzione, quindi il primo test è limitato dal tempo che vi serve per decidere cosa testare e non da qualcosa da acquistare, costruire o pianificare. Nulla va in produzione per sbaglio mentre imparate: un test nuovo è una bozza finché non lo avvia.

Ogni sito riceve il proprio file compilato con i suoi test già dentro, così il runtime sa già cosa eseguire quando si carica e nulla attende una chiamata verso di noi prima che la pagina venga disegnata. La pagina è trattenuta per un istante mentre le modifiche vengono applicate, ed è questo che evita ai visitatori di vedere l’originale comparire prima del test, e viene rivelata da quattro percorsi di codice indipendenti, così un guasto mostra la pagina non modificata anziché una pagina bianca. Il tracciamento si carica per ultimo, dopo che la pagina è visibile, quindi la misurazione non ritarda mai il rendering.

Testo, stile, layout e posizione si modificano puntando, e le modifiche strutturali sono coperte da cinque posizionamenti HTML rispetto a un elemento che seleziona. Oltre quel punto si ferma con onestà e non male: tutto ciò che il pannello non riesce a esprimere lo scrive come CSS o JavaScript personalizzato sulla variante, il che significa che un test non è mai bloccato dallo strumento. Il limite vero è una modifica che avviene prima che la pagina esista: un ordinamento, una logica di prezzo, un modello di raccomandazione. Quelli sono test server-side, e richiedono i vostri sviluppatori.

Tanti quante sono le vostre idee, e questa è la risposta da confrontare con quello che usate oggi. Ogni test randomizza in modo indipendente, quindi un visitatore ammissibile entra in ogni test per cui si qualifica e ognuno misura sull’intero pubblico ammissibile. Qui la concorrenza non divide il campione, ed è per questo che la piattaforma verifica se due test interferirebbero invece di razionare quanti possono girare. Il ritmo è di solito la differenza fra un programma che si ripaga e uno che non lo fa.

I vincitori che avete fissato nel codice sono già nella vostra codebase e restano intatti, ed è proprio a questo che serve la coda di implementazione: elenca ogni vincitore ancora servito da noi e continua a segnalarlo finché i vostri sviluppatori non hanno spazio. I vincitori ancora serviti dalla piattaforma si fermano quando si ferma lei, come si ferma qualsiasi variante. I test, le ipotesi e la storia scritta restano nell’account e non in strumenti nostri.