Test lato client vs. Test lato server: entrambi vincono.

Quando si tratta di eseguire esperimenti, gli ottimizzatori possono scegliere tra test lato client e lato server.

Sebbene tu possa eseguire quasi tutti i test lato client sul lato server e alcuni esperimenti di back-end leggeri tramite test lato client (usando URL diviso o esperimenti di reindirizzamento), farlo non sarà fattibile o affidabile come te' mi piace… perché, per ogni ipotesi, solo una delle due funziona meglio .

E la scelta di quella giusta richiede un'attenta considerazione. Ci sono molti aspetti da soppesare quando si fa questa scelta. Osserva l'impatto della configurazione su velocità e SEO, lo sforzo e i requisiti di tempo per il ciclo di vita dell'esperimento, l'obiettivo dell'esperimento e altro ancora.

Esaminiamo questi fattori e vediamo in che modo i test lato client differiscono dai test lato server e i pro e i contro di ciascuno.

Test lato client vs. Test lato server

Tuttavia, ciò significherebbe scontare i test lato client.

I test lato client possono sembrare semplici, ma sono potenti.

È facile liquidare i test A/B lato client come i "test facili" che chiunque può eseguire. D'accordo: è facile da implementare. E a volte, può essere piccolo come testare un diverso colore o copia del pulsante CTA.

Ma che si tratti di questo o di qualcosa di grande come testare una riprogettazione o una pagina rinnovata, i test lato client influiscono sui profitti di un'azienda .

In questo caso di studio, una società SaaS ha utilizzato Convert Experiences come strumento di test A/B lato client per aumentare la crescita dei lead del 61% sulla propria home page:

Ecco un altro esperimento di test A/B che utilizza Convert Experiences come strumento di test lato client per la stessa azienda SaaS nella sua pagina dei prezzi che ha portato a un aumento del 57% dei lead:

La maggior parte delle storie di successo sull'ottimizzazione delle conversioni che vedi online sono test lato client che hanno ottimizzato con successo un'esperienza a livello di superficie e hanno vinto alla grande.

Ma i test lato server ti consentono davvero di testare di più.

Quando è necessario eseguire test più approfonditi rispetto al frontend, è necessario eseguire i test lato server.

Mettiamo questo in prospettiva con alcuni scenari.

Se fossi un'azienda di e-commerce, saresti in grado di utilizzare un esperimento di test A/B lato client per scoprire se una barra di ricerca ridisegnata potrebbe aumentare le tue ricerche in negozio (e comportare più vendite).

Ma se volessi testare un nuovo algoritmo di ricerca che potrebbe portare a risultati di ricerca più pertinenti (e che, a lungo termine, porterebbe a più vendite), dovresti eseguire un esperimento di test A/B lato server .

Se invece fossi un'azienda SaaS B2B, saresti in grado di eseguire un esperimento lato client per determinare se un determinato UVP funziona meglio sulla tua home page. O se una copia in formato lungo potesse battere una copia in formato breve.

Ma se si desidera testare un back-end più veloce e vedere se può migliorare la fidelizzazione o il coinvolgimento, è necessario eseguire un esperimento lato server. Se si desidera testare una nuova sequenza di onboarding, di nuovo, è necessario eseguire un esperimento lato server. Perché oltre a supportare il tuo nuovo flusso di lavoro di onboarding, i test lato server ti permetterebbero anche di orchestrare un esperimento multicanale che si estende su e-mail, SMS e altri che si svolgono su dispositivi diversi.

Allo stesso modo, se fossi un'azienda SaaS B2C, saresti in grado di eseguire un esperimento lato client per scoprire se un determinato piano tariffario potrebbe funzionare meglio degli altri.

Tuttavia, se si desidera testare un motore di raccomandazione migliore, è necessario eseguire il test lato server.

Come puoi capire dai diversi casi d'uso dei test lato server, è più orientato alla creazione di prodotti migliori piuttosto che all'ottenimento di conversioni immediate. A differenza degli esperimenti lato client che si concentrano su vendite o conversioni immediate, gli esperimenti lato server si concentrano sull'ottimizzazione del prodotto o della soluzione in modo che il valore per il cliente a vita aumenti.

Si potrebbe dire che se i test lato client sono per gli esperti di marketing, i test lato server sono principalmente per i team di prodotti e ingegneri. E gli strumenti di test A/B come Convert Experiences offrono test lato client e lato server per soddisfare sia i team di marketing che quelli di ingegneria.

Poiché testare modifiche così profonde a livello di prodotto richiede molto più della semplice manipolazione JS basata su browser, non può avvenire all'interno del browser e deve essere affrontato a livello di server.

Sebbene i test lato server abbiano i suoi casi d'uso unici, alcune aziende lo usano per eseguire anche i test estetici, test che verrebbero eseguiti perfettamente senza problemi anche sul lato client.

Spesso lo fanno per evitare il fenomeno dello "sfarfallio" o del "flash di contenuto originale". Lo sfarfallio si verifica quando lo strumento di sperimentazione modifica il contenuto originale servito dal server dopo che gli utenti finali lo hanno già visto. Immagina che i tuoi utenti vedano un determinato titolo e poi lo vedano cambiare in un lampo in un altro. (Sì, lo sfarfallio può compromettere seriamente l'esperienza dell'utente!)

Altre volte, lo fanno per migliorare la velocità. Sebbene il test non rallenti un sito Web o causi seri problemi di prestazioni, aggiunge un secondo o due all'esperienza di caricamento percepita di un sito Web. Il lato server può renderlo più veloce.

Occasionalmente, un'azienda potrebbe eseguire un esperimento lato server al posto di uno lato client a causa di problemi di privacy o sicurezza. Poiché il targeting dell'audience avviene sul server e il codice di sperimentazione risiede sul server durante i test lato server, le aziende ottengono un controllo migliore sui suoi aspetti di privacy e sicurezza.

Ma l'implementazione di un esperimento lato server non è sempre fattibile, specialmente quando un lato client farebbe altrettanto bene.

Implementazione di esperimenti lato server

Nei test lato client, hai solo bisogno di risorse di progettazione e sviluppo limitate per creare i tuoi esperimenti ed eseguirli. Non ti serviranno nemmeno se stai solo apportando modifiche al testo o cambiando il colore di un pulsante. Tutto quello che devi fare è:

1. Accedi a uno strumento come Converti.

2. Utilizzare l'editor WYSIWYG e creare le variazioni.

3. Configura l'esperimento (imposta le condizioni di targeting per pubblico, la durata dell'esperimento, la dimensione e la suddivisione del campione, il livello di confidenza, ecc.)

Prendi il codice JS e aggiungilo al tuo sito web.

E fatto.

Dovresti quindi cercare aiuto per lo sviluppo per implementare la versione vincente se il controllo dovesse perdere.

I test lato server, tuttavia, non sono così semplici.

Qui, dovrai:

1. Crea il tuo esperimento in Converti esperienze

2. Sviluppa e distribuisci tutte le varianti del tuo esperimento sul tuo server.

3. Mappa le tue esperienze distribuite sul server in Converti esperienze utilizzando codice personalizzato (usando l'ID dell'esperimento, gli ID delle variazioni impostati nello strumento di sperimentazione e altro).

In tali esperimenti lato server, il codice deve indicare al server quale variazione mostrare all'utente corrente. Potresti usare i cookie per facilitare questo. Ad esempio, per implementare un test lato server A/B con Convert, dovrai impostare un cookie con i seguenti dati:

Il server leggerà quindi il tuo cookie e
servire una versione (e tutte le sessioni successive) di conseguenza.

Poiché il tuo server determina quale versione inviare a un utente, il targeting avviene sul server (e non all'interno del browser come con i test lato client). La precisione del test dipenderà dalla capacità di codificare le condizioni di targeting sul server. Con i test lato client, tuttavia, puoi indirizzare il tuo pubblico a tutte le tue esperienze.

Inoltre, i test lato server possono diventare più complessi in una configurazione multi-server e anche quando è necessario integrare una CDN.

4. Eseguire l'esperimento.

5. Lancia la versione vincente e annulla i perdenti.

Potrebbe anche essere necessario ripulire i server, pubblicare il rollout/rollback finale.

Come puoi vedere, il ciclo di vita di un esperimento lato server è lungo e complesso a differenza di quello di un esperimento lato client. Ecco perché l'utilizzo dei test lato server richiede alcune riflessioni.

In generale, non eseguiresti un esperimento lato server se uno lato client lo facesse...

L'esecuzione anche di un singolo esperimento lato server è impegnativo perché lo sviluppo e l'implementazione sono un processo che richiede più tempo e risorse.

Inoltre, se si utilizza il test lato server per testare modifiche che possono essere facilmente convalidate lato client, sarà difficile raggiungere una buona velocità di test e un solido programma di sperimentazione.

Inoltre, per tali esperimenti, optare per la sperimentazione lato server quando disponi di alcuni ottimi strumenti di test A/B lato client che ti consentono di eseguirli senza sfarfallio senza influire sulla tua SEO o sulla velocità non promette il miglior uso dei tuoi test larghezza di banda.

Gli esperimenti lato server dovrebbero essere preferiti solo quando rappresentano una valida argomentazione per l'ipotesi data. E lo fanno parecchie volte perché molti esperimenti che incidono sui risultati economici di un'azienda possono avvenire solo sul lato server.

Quindi dicci... hai eseguito dei test lato server? Se sì, qual è stata la parte più difficile del processo? Oh, e se vuoi eseguire un test A/B lato server, dai un'occhiata a Converti (è gratuito per 15 giorni!)