Come passare da zero a uno nel tuo percorso di sperimentazione lato server

Pensa al tuo viaggio come utente Netflix. Se sei come me, potresti guardare un documentario sulla fauna selvatica sul tuo telefono sorseggiando il tuo caffè mattutino. La cena potrebbe essere accompagnata da un favorito d'altri tempi come Forrest Gump sul laptop. Le notti del fine settimana verrebbero trascorse alternando il tuo profilo e quello dei tuoi figli, mentre provi nuovi programmi Netflix, preferibilmente su uno schermo più grande.

Ora supponiamo che Netflix stia conducendo una campagna di sconti specifica per paese. Se fai parte di questa campagna sperimentale gestita da Netflix, come fanno a garantire che tu faccia parte della stessa campagna ogni volta che accedi indipendentemente dal dispositivo e dal profilo che stai utilizzando e che vedi la stessa promozione ovunque? In che modo garantiscono che la tua esperienza con la variazione che ti viene offerta sia perfetta ogni volta e che il modo in cui interagisci con la variazione sia monitorato in modo coerente?

La risposta sta nella sperimentazione omnicanale, che è un tipico caso d'uso dei test lato server.

Dovresti preferire i test lato server rispetto al lato client?

L'esempio di Netflix sopra indicato sarebbe estremamente complicato da eseguire sul lato client e potrebbe ostacolare l'esperienza dell'utente. Sul lato server, è relativamente facile da eseguire e garantisce un'esperienza coerente per gli utenti. Garantisce inoltre un impatto minimo sulle prestazioni della pagina. Oltre a ciò, elimina qualsiasi problema relativo alla privacy perché non vi è alcuna attività sul browser in quanto tale.

Esistono altri casi d'uso in cui è consigliato il test lato server per la sua robustezza e flessibilità. Ne parleremo in questo articolo. Ma prima, cos'è esattamente il test lato server e, cosa più importante, a chi è rivolto?

Nel test lato server, le variazioni del test vengono elaborate sul server web. Quando un visitatore arriva su una pagina in fase di test, una variazione viene prelevata direttamente dal server e inviata al browser del visitatore. Nessuna modifica successiva avviene quindi sul front-end o sul browser. Contrariamente a ciò, nei test lato client, la pagina originale viene caricata prima nel browser del visitatore e la tua piattaforma di sperimentazione crea la variazione sul front-end stesso utilizzando JavaScript. Comprendiamo l'ambito di queste due forme di test con un esempio.

Immagina che Mike e Bob siano due amici che stanno cercando di sperimentare il funzionamento di una nuova macchina. Mike è al volante e ha accesso a freni, acceleratore, cruscotto e simili. Bob ha una visuale dei componenti interni come il motore, il radiatore, la batteria, ecc. Entrambi possono influenzare l'auto in modi diversi. Ciò che Bob fa con il suo accesso ai componenti dell'auto può riflettersi sull'esterno di Mike. Le modifiche che Mike testa si basano sulla sua visibilità dell'auto. Dal punto di vista dell'acquirente dell'auto, il risultato degli esperimenti condotti sia da Bob che da Mike può servire a scopi ugualmente importanti, ma diversi.

Pertanto, non è necessario scegliere una forma di test rispetto all'altra. I casi d'uso sono diversi e i team che utilizzano gli strumenti sono diversi. Il test lato server è una via di sperimentazione per sviluppatori e product manager, proprio come il test lato client viene utilizzato più spesso dai professionisti del marketing.

Quali problemi possono essere risolti con i test lato server?

I test lato server eseguiti dai team di prodotto risolvono problemi relativi a una miriade di settori, dall'e-commerce e SaaS alle banche e ai media. Di seguito sono descritti alcuni casi d'uso importanti in cui i test lato server sono consigliati rispetto ai test lato client in diversi settori:

Raccomandazione del prodotto

Quale insieme di prodotti consigliati invoglia i tuoi visitatori ad acquistare di più? Il test lato server consente di testare più algoritmi di raccomandazione del prodotto per determinare la selezione che porta a un aumento delle vendite e dei ricavi. Ad esempio, puoi verificare se un layout che promuove prodotti simili funziona meglio di un layout che promuove quelli più popolari. Puoi anche decidere se effettuare l'upsell o il cross-sell in base ai risultati dell'esperimento lato server.

Tassa di spedizione

Qual è il valore del carrello ideale che dovrebbe qualificare gli ordini per la spedizione gratuita? Puoi testare varie soglie per determinare quella che influenza positivamente le decisioni di acquisto dei clienti.

Algoritmi di ricerca

La sperimentazione con il tuo algoritmo di ricerca richiede la modifica del codice esistente e la flessibilità per eseguire test approfonditi. Vuoi che i tuoi visitatori siano in grado di trovare rapidamente ciò che stanno cercando e puoi testare il tuo algoritmo di ricerca sul lato server per raggiungere questo obiettivo.

Lunghezza del modulo

I moduli di richiesta di prova e demo gratuiti sono fondamentali per le aziende SaaS. Ma qual è la lunghezza del modulo ideale che garantisce minori drop-off e allo stesso tempo acquisisce tutte le informazioni richieste? Puoi testare i campi non obbligatori tramite test lato client. Se il tuo campo è obbligatorio, nascondere semplicemente il campo utilizzando JavaScript non funzionerà poiché la convalida del modulo utilizzando la logica lato server avrà esito negativo. Pertanto, si consiglia di eseguire test lato server per sperimentare campi obbligatori per ottimizzare la lunghezza e la complessità del modulo.

Offerte e sconti

Mentre lo stile, l'aspetto grafico e il posizionamento delle offerte sulla tua home page possono essere facilmente testati dal lato cliente, ci sono altri fattori importanti da considerare come il valore dello sconto, la sua durata o i criteri di idoneità. Puoi testare sul lato server per determinare il valore ottimale e assicurarti che siano coerenti tra i canali per un particolare visitatore.

Incentivi alla vendita

Il test di incentivi dinamici come offerte a periodo limitato o sdoganamenti delle scorte richiede la flessibilità del test lato server a causa della granularità coinvolta.

Flussi di abbonamento

Quanti passaggi dovrebbero idealmente essere coinvolti in un processo di abbonamento? Devono essere forniti gli accessi social? Sperimentare il flusso di sottoscrizione può aiutare a rispondere a queste domande.

Paywall

Il test lato server ti consente di testare varie configurazioni di paywall in modo infallibile. In qualità di editore, puoi eseguire test lato server per sperimentare i tuoi contenuti controllati e monetizzarli. Non è consigliabile eseguire lo stesso test sul lato client, perché i visitatori possono aggirare un paywall eliminando o disattivando i cookie.

Servizi bancari per smarthpone

Più elementi possono essere ottimizzati all'interno del processo di registrazione per un prestito o una carta di credito. Ma quando si tratta di mobile banking, la sicurezza dei dati diventa fondamentale. Con i test lato client, i dati sensibili raccolti da banche o istituti finanziari potrebbero essere a rischio di vulnerabilità. Per evitare questo rischio, gli esperimenti lato server sono generalmente consigliati per le applicazioni bancarie.

Cerchiamo ora di capire come eseguire i test delle funzionalità sul lato server e i vantaggi di farlo con VWO.

In che modo VWO semplifica i test lato server

Per i casi d'uso lato server descritti sopra, VWO ti offre la flessibilità di strutturare la tua campagna come test A/B o test delle funzionalità. I test delle funzionalità vengono utilizzati per convalidare i valori dei parametri delle funzionalità e fornire il controllo per configurare rapidamente una funzionalità, senza scrivere codice. In alcuni casi d'uso come testare quale algoritmo di ricerca è migliore, è possibile strutturare la campagna sia come test A/B che come test di funzionalità.

Ad esempio, supponiamo di voler valutare tre fornitori per l'algoritmo di ricerca che hanno creato per il tuo sito web.

Il test delle funzionalità consente a un product manager come te di testare e concludere rapidamente con la minima dipendenza dall'ingegneria e il massimo controllo della configurazione. Con le funzionalità di test delle funzionalità di VWO, ottieni un framework impostato in cui è necessario scrivere meno codice perché la piattaforma fa la maggior parte del lavoro pesante per te. Nel test delle funzionalità, l'algoritmo può essere definito come una variabile caratteristica ed essere configurato nel controllo e nella variazione di un esperimento dal flusso di configurazione della piattaforma stesso per testare quale algoritmo di ricerca è più efficiente.

Questo esperimento può essere eseguito anche tramite test A/B lato server. VWO facilita la distribuzione del traffico e la capacità del modello statistico di sperimentazione tramite i suoi SDK lato server. I team di ingegneri possono utilizzare lo stesso per inserire il codice degli algoritmi di ricerca e testare quello che è più impattante.

Ecco alcuni altri scenari in cui il test delle funzionalità è utile. Supponiamo che un fornitore di terze parti che gestisce le ricariche mobili voglia addebitare un importo nominale agli utenti per ogni ricarica. Vogliono testare l'importo appropriato per lo stesso. Oppure una società come Airbnb, in cui le spese di proprietà sono gestite dal proprietario, vuole aggiungere una tassa di pulizia e vedere se ciò influisce sul numero di prenotazioni. Questo è un tipico caso d'uso di sperimentazione per varie aziende per trovare il punto debole in cui è possibile inserire un costo del servizio senza influire sulla metrica della stella polare. Potrebbe essere sotto forma di una tassa di convenienza, una tassa di struttura, una tassa di covid, una tassa di imballaggio o qualcosa di simile.

Casi d'uso complessi come quello sopra descritto sono semplicissimi da testare in VWO. Ecco un video esplicativo che mostra come creare rapidamente una funzione di tariffa convenienza e assegnarle un valore (in questo caso l'importo della tariffa). Puoi collegare la tua ipotesi di identificare la tariffa che si aggiunge alle entrate senza influire sul numero di prenotazioni, scegliere l'ambiente su cui stai eseguendo il test e abilitare le tue variazioni. Una volta che lo fai, ti viene fornito un codice campagna che va sul tuo server. Non resta che definire gli obiettivi che desideri monitorare e segmentare il tuo pubblico se lo desideri: il gioco è fatto, la tua campagna è pronta.

Se sei un product manager e vedi sulla dashboard che la variazione 3 non funziona per gli utenti; ha un impatto negativo sulle entrate, puoi ucciderlo proprio lì semplicemente disabilitando la variazione in VWO. Come mostrato nello screenshot seguente, ciò non ha alcun impatto sul codice e non richiede al team di ingegneri di apportare modifiche. Devi disattivarlo, fare clic su "Salva" e la variante smette di ricevere traffico.

In sostanza, il codice deve essere implementato solo una volta per campagna.

Dovresti costruire o acquistare una piattaforma per eseguire test lato server?

Mettiamo fine al dibattito build vs buy. VWO non è solo un generatore di numeri casuali che mostra diverse variazioni a un pubblico diverso e cattura gli eventi di conversione. VWO è una piattaforma di sperimentazione completa con un modello statistico robusto. Per valutare se costruire internamente un meccanismo di test lato server o investire in una piattaforma come VWO, devi considerare tre fattori principali:

1. Costo di proprietà

Anche quando le aziende riescono a costruire internamente l'infrastruttura richiesta, devono comunque gestirla e ridimensionarla. Pagare i tuoi team di sviluppo per costruire e mantenere un motore di sperimentazione come VWO invece di concentrarsi sui loro lavori principali rischia di essere più dispendioso in termini di tempo e denaro rispetto all'investimento in VWO.

2. Facilità d'uso

Potresti creare una soluzione che mostri una certa variazione a un determinato pubblico, ma avresti un'interfaccia facile da usare che può essere controllata non solo dai team di progettazione ma anche dai product manager? In caso contrario, questo è un altro blocco per l'esecuzione di test lato server.

3. Reportistica intuitiva

In genere una soluzione interna ti fornisce elementi di base come il numero di visitatori e le conversioni provenienti da una particolare variazione. Ma quello che ti serve è un risultato statisticamente significativo. Hai bisogno che i tuoi rapporti siano alimentati da un motore di statistiche bayesiano come VWO SmartStats. Ecco dove sta il divario: puoi creare una soluzione di base difficile da mantenere e puoi dedicare tempo e risorse alla decifrazione dei valori p. Oppure puoi scegliere una soluzione come VWO in cui c'è un team dedicato alla manutenzione e al ridimensionamento e ha trascorso anni sull'algoritmo bayesiano per darti risultati facilmente interpretabili. La dashboard in-app in VWO consente anche ai membri del team non tecnici di comprendere i risultati; non hanno bisogno di fare affidamento sul team di Analytics per tenere traccia degli esperimenti o creare dashboard dei risultati, risparmiando così tempo e riducendo i costi della sperimentazione.

4. Meccanismo senza errori

La creazione interna di una soluzione di test lato server può essere soggetta a errori e, su tale scala, gli errori potrebbero non essere facilmente individuabili. Confrontalo con la qualità di una piattaforma utilizzata dai marchi globali e avrai la certezza che le possibilità che si insinuano errori sono minime. Eventuali errori, se non del tutto, vengono segnalati e corretti al più presto da un team di supporto competente a tua disposizione.

Inoltre, quando investi in una piattaforma gestita come VWO, importanti best practice sono integrate nel prodotto. Non devi preoccuparti di rimuovere i valori anomali dai risultati, visualizzare i dati o problemi derivanti dagli aggiornamenti della versione.

Funzionalità indispensabili per eseguire complessi test lato server con integrità

L'esecuzione di esperimenti lato server può essere molto fruttuosa se eseguita correttamente. Per fare ciò, è necessario disporre del giusto set di funzionalità. Alcuni di questi sono riportati di seguito:

1. Randomizzazione dei visitatori in ogni test : durante i test, quando stai raggruppando il tuo pubblico in campagne, la randomizzazione dei visitatori deve essere veramente casuale e non pseudo-casuale.
2. Esperienza omnicanale coerente : sebbene il bucket degli utenti debba essere casuale, devi anche assicurarti che un utente sperimenti la stessa variazione ogni volta che esegue l'accesso, indipendentemente dal dispositivo che sta utilizzando. L'esperimento dovrebbe andare avanti senza problemi.
3. Campagne che si escludono a vicenda: supponiamo che tu abbia tre fattori da considerare per determinare se un utente dovrebbe far parte del tuo test. Questi potrebbero essere la regolarità di utilizzo, la bassa probabilità di abbandono e il fuso orario. Oltre a prendere in considerazione queste variabili, devi anche determinare l'esclusività: quindi a quanti test può far parte l'utente che soddisfa queste condizioni? Questo deve essere determinato in un modo che non porti a dati distorti e ti permetta di attribuire il miglioramento del tasso di conversione alla campagna giusta senza pregiudizi.
4. Convenzione di denominazione standardizzata : indipendentemente dal fatto che tu stia configurando una nuova funzionalità da testare o un flag di funzionalità, devi seguire una convenzione di denominazione standard per evitare confusione e casi di inizializzazione delle funzionalità o dei test errati.
5. Identificatori di campagna univoci e senza problemi : è necessario utilizzare una chiave alfanumerica per identificare in modo univoco il test nel codice ed evitare problemi in una fase successiva.
6. Scelta dell'ambiente giusto : devi specificare l'ambiente in cui stai eseguendo il test, ad esempio puoi distribuire il test nell'ambiente di staging o QA affinché il tuo team QA convalidi l'esperimento. Un controllo di integrità del tuo test è fondamentale per il suo successo e dovresti avere la possibilità di scegliere l'ambiente giusto per esso.
7. Allocazione logica del traffico : quando stai eseguendo più campagne o quando hai un annuncio di un evento importante come una vendita della settimana nera, ad esempio, non è necessario includere l'intero set di visitatori che atterrano sulla tua pagina nel test. Dovresti scegliere la percentuale di traffico che vuoi includere nella tua campagna di prova e anche come vuoi distribuire questo traffico tra le varianti.
8. Calcolo del tempo per raggiungere la significatività statistica – Il tempo stimato per il raggiungimento della significatività statistica del test dovrebbe essere determinato dal tasso di conversione attuale dell'obiettivo principale e dal miglioramento minimo che si desidera ottenere attraverso le variazioni. Dovrebbe anche considerare una probabilità del 95% di battere il tasso di conversione di base.

Queste sono alcune delle migliori pratiche e delle funzionalità indispensabili dei test lato server: l'elenco effettivo è molto più lungo. Come accennato in precedenza, potresti creare queste funzionalità internamente o potresti utilizzare VWO dove facciamo il lavoro per te.

Insomma

Che tu sia uno sviluppatore o un product manager, non devi limitare le tue idee di test. Puoi eseguire test complessi senza temere problemi di prestazioni o privacy con i test lato server e risolvere i problemi reali affrontati dai tuoi clienti. Puoi ottimizzare ogni punto di contatto digitale in modo che i tuoi clienti sperimentino solo il meglio.

Se stai utilizzando una piattaforma come VWO, la complessità del test non ti travolgerà, perché ogni tuo input nella campagna è intuitivo e una buona pratica che alimenta il tuo test. Per saperne di più su come eseguire facilmente i test lato server utilizzando VWO, richiedi una demo con i nostri esperti di prodotto.