Vs lato client Strumenti di test A / B lato server: qual è la differenza?

Lato client, lato server: qual è la differenza?

Ecco la differenza di base tra gli strumenti di test lato client e lato server:

Gli strumenti lato client creano una variante della tua pagina di test facendo manipolazioni sul tuo browser tramite JavaScript intelligente. Il tuo server web invia la stessa versione della pagina, l'impostazione predefinita, come farebbe normalmente. Tutte le varianti sono riflesse dal browser del visitatore. Poiché le modifiche non vengono apportate sul tuo server e si trovano invece sul browser del visitatore, vengono chiamate "strumenti lato client".

Gli strumenti lato server sono diversi in quanto non si verificano modifiche a livello di browser. Quando il visitatore arriva sulla tua pagina, una versione del tuo test scelta casualmente viene inviata direttamente dal tuo server. Sì, questo significa che devi coinvolgere i tuoi sviluppatori nei test, ma ti dà anche robustezza e flessibilità.

Tim Ash è stato citato in un rapporto TrustRadius, riassumendo molto bene la differenza tra i due tipi di strumenti:

Tim Ash:

“Con gli strumenti lato server, i sistemi di gestione dei contenuti si stanno sviluppando in fase di test, mantenendo più versioni del contenuto e servendole in base alla segmentazione. Offre il controllo sulla distribuzione indipendentemente dai problemi del browser. Gli strumenti lato client sono generalmente più facili per il marketing. Hanno editor WYSIWYG e rendono semplice apportare modifiche al livello della superficie senza bisogno dell'IT, il che è un grosso problema. È difficile usarli per ristrutturare il percorso di registrazione o il checkout, tuttavia, perché toccherai il CMS ".

Esiste anche un terzo tipo di strumento, strettamente correlato alle funzionalità lato server. C'è solo una società che conosco che utilizza questo metodo (SiteSpect), quindi non è super comune. Quello che usano è qualcosa chiamato server proxy o metodo di intercettazione.

Fondamentalmente, lo strumento funge da server proxy tra il browser del visitatore e il tuo server. Controlla il contenuto del sito che viene presentato al visitatore, quindi elimina la maggior parte dei problemi che si verificano con gli strumenti lato client, pur mantenendo la solidità degli strumenti lato server.

Pianificazione test A / B: come costruire un processo che funzioni

Di Jaan Matti-Saul

Un forte piano di test A / B ti consentirà di aumentare le tue entrate e apprendere preziose informazioni sui tuoi clienti.

Va bene, ma quando dovrei usare quale?

Come Paras Chopra di VWO ha detto in un post sul blog, i due non sono in opposizione. Strumenti diversi per esigenze e obiettivi diversi:

Paras Chopra:

"Perché supportiamo i framework di test lato server? Non sono in competizione con noi? Non proprio! Il nostro obiettivo con Visual Website Optimizer è di semplificare i test A / B e multivariati eliminando le problematiche tecniche. Infatti, idealmente, vogliamo che i nostri utenti non tocchino mai alcun codice (sia esso HTML, JavaScript, CSS o PHP). Quindi, VWO è adatto a persone che non vogliono fare affidamento su sviluppatori o team IT per eseguire anche il tipo più semplice di test (allungando così il tempo necessario per avviare il test). "

Gli strumenti lato client offrono facilità d'uso, esecuzione più rapida e un editor WYSIWYG. Non devi necessariamente impiegare il tempo del tuo team di sviluppo per far funzionare gli esperimenti.

Detto questo, anche gli strumenti lato server hanno dei vantaggi. Un articolo di Google affermava che le implementazioni lato server offrono una maggiore flessibilità nel fare cose come:

• Esegui esperimenti per siti Web con contenuti dinamici.
• Prova le modifiche non UI che hanno ancora un effetto sul tuo obiettivo. Ad esempio, un set di risultati della query del database restituito a un utente.
• Integra esperimenti di Google Analytics con il tuo servizio (ad es. Fornitore di gestione dei contenuti).
• Gestisci gli esperimenti utilizzando la tua piattaforma di ottimizzazione.

In sintesi, offrono maggiore flessibilità. Inoltre, tendono ad essere più robusti ed eliminano alcune debolezze degli strumenti lato client. Alcune di queste potenziali debolezze includono l'effetto di sfarfallio (di cui parleremo di seguito), velocità di caricamento e flessibilità.

Come Chris Goward di WiderFunnel ha detto in un rapporto TrustRadius, l'approccio JavaScript (ovvero lato client) ha molti vantaggi, ma anche alcuni aspetti negativi:

Chris Goward:

"Hanno risolto il problema più grande, ovvero gli ostacoli tecnici ai test. L'aspetto negativo è il tempo di caricamento e la velocità del sito e la mancanza di flessibilità di ciò che è possibile manipolare. Ci sono casi in cui avrà uno sfarfallio o si carica più del necessario. Altri approcci potrebbero consentire maggiore flessibilità e velocità. Non credo che abbiamo ancora trovato la soluzione migliore come industria ".

Pete Koomen, co-fondatore di Optimizely, lo ha riassunto bene:

Pete Koomen:
“Il vantaggio dei test sul lato client è la velocità e la semplicità. Puoi testare molte modifiche rapidamente senza molto investimento iniziale. D'altra parte, testare sul lato server è sia più lavoro che generalmente più potente. "

Tuttavia, come altro modo per esaminarlo, Nate Weiss (CTO di Conductrics) afferma che il vantaggio di "saltare l'IT" degli strumenti lato client potrebbe avere un costo per alcune aziende. Lui spiega:

Nate Weiss:

"Per le aziende che hanno un rigoroso QA e un processo di approvazione per i loro contenuti web in generale (al di fuori dei test), il vantaggio di" saltare l'IT "degli strumenti lato client ha un costo: diventa un" backdoor "dove i soliti processi di approvazione e così via finiscono per essere ignorati, perché lo strumento di test non è a conoscenza dei flussi di lavoro interni che portano alla pubblicazione di contenuti normali. È quindi molto difficile, se fatto, mantenere sincronizzati questi due "target mobili" (modifiche apportate normalmente e modifiche apportate tramite lo strumento di test) ".

In sintesi, utilizzare strumenti diversi per usi e obiettivi diversi.

L'effetto sfarfallio

Come accennato in precedenza, uno dei punti deboli degli strumenti lato client può essere l'effetto sfarfallio. Che cos'è?

Fondamentalmente, è quando, per pochissimo tempo, il visitatore del tuo sito web vede la pagina predefinita prima che la variazione venga caricata. È anche noto come "Flash di contenuti originali".

Questo generalmente accade a causa di uno script asincrono con lo strumento di test. Sebbene abbia il vantaggio di non rallentare la pagina, questo tipo di script può causare uno sfarfallio di tanto in tanto.

Ciò è importante perché l'occhio umano rileva e cambiamo il nostro comportamento quando sappiamo di essere parte di un esperimento. Tuttavia, c'è l'occasione sorprendente (fluke) che aiuta un test. Prendi questo esempio da un post di blog Unbounce:

Come ha affermato David Hauser, co-fondatore di Grasshopper nell'articolo:

David Hauser:

"Il nostro strumento di test A / B aveva un bug che ritardava la cancellazione della quota di attivazione di $ 25 fino a pochi secondi dopo il caricamento della pagina.

Questo errore ha finito per creare un sollevamento molto più grande rispetto a quando è stato eliminato con un caricamento, quando il bug è stato corretto.

Il risultato ora è che la quota di attivazione mostra e quindi viene cancellata dopo pochi secondi. "

La maggior parte delle volte, tuttavia, l'effetto sfarfallio provoca differenze statisticamente significative nei risultati del test. Ciò influisce totalmente sul test e può distorcere il risultato. L'obiettivo è ridurre lo sfarfallio a 0,0001 secondi in modo che le persone non vedano nulla.

Quindi, ho detto che l'effetto sfarfallio è davvero solo un problema con gli strumenti lato client. Quali sono alcuni modi, se ce ne sono, che possiamo mitigare questo?

Script sincroni vs. asincroni

Gli strumenti lato client possono caricare gli script in due modi distinti: in modo sincrono e asincrono. Qual è la differenza?

Script sincroni

Il caricamento sincrono avviene quando lo script di uno strumento di test viene caricato completamente prima che la pagina inizi a caricarsi. Richiama il server e attende una risposta. Detto in altro modo, gli script vengono caricati in sequenza a partire dal tag.

Ad esempio, utilizza in modo ottimale uno snippet sincrono per evitare l'effetto sfarfallio e un sistema CDN bilanciato per garantire che l'impatto sulla pagina sia ridotto al minimo.

Sincrono:

Script asincroni

Asincrono è quando alcuni script possono essere caricati contemporaneamente. Si caricano durante l'esecuzione dello script di test, causando probabilmente un effetto sfarfallio se il contenuto originale carica una sezione divisa prima della variazione.

asincrono:

Puoi eseguire strumenti lato client come VWO e Optimizely in entrambi i modi. In generale, la velocità di caricamento della pagina è importante, quindi di solito è preferito il codice asincrono. Gli script in batch consentono il caricamento più veloce delle pagine e in genere è possibile prevenire l'effetto sfarfallio con alcune misure.

Come ha detto Paras Chopra in un thread di GrowthHackers:

Paras Chopra:

"Generalmente con il codice asincrono di VWO, non dovrebbe esserci sfarfallio. In casi limite o nei casi in cui non hai inserito codice asincrono nella parte superiore della pagina, potrebbe verificarsi uno sfarfallio. Abbiamo creato il nostro codice asincrono in modo tale che la pagina originale sia nascosta fino al caricamento delle impostazioni. (La pagina viene caricata in parallelo ed è per questo che è asincrona ma non viene visualizzata).

Per quanto riguarda il codice sincrono di VWO (o di qualsiasi altro strumento), non lo consiglierei in generale a meno che non ci siano casi specifici che non possono essere risolti. Sincrono rallenta la velocità della pagina. "

Alhan Keser anche da WiderFunnel ha espresso un sentimento simile. A meno che tu non stia gestendo un sito enorme con tonnellate di visitatori, la velocità della pagina è di primaria importanza:

Alhan Keser:

"Il caricamento asincrono risolve un problema separato: aiutare con la velocità complessiva del sito, non con FOOC [flash of original content]. Data la velocità dei moderni CDN, il caricamento dei frammenti in modo sincrono dovrebbe essere l'ultimo dei tuoi dubbi. Ma, se sei come i nostri vicini qui a Vancouver, PlentyOfFish, con un bajillion di utenti che colpiscono il loro sito allo stesso tempo, potresti voler considerare cosa e come le cose si caricano sulle tue pagine ".

Altri suggerimenti per prevenire l'effetto sfarfallio

Un modo per prevenire l'effetto sfarfallio delineato in modo ottimale è quello di aggiungere un timeout su script asincroni. La loro impostazione predefinita è un secondo. Ciò significa che se lo script di test A / B non viene caricato in quel momento, l'A / B non verrà eseguito. Se il visitatore ha una connessione lenta, quel visitatore non verrà incluso nel test.

Alcuni altri modi per prevenire l'effetto sfarfallio:

• Ottimizza il tuo sito per la velocità. Assicurati che tutto, in particolare le immagini, si carichi velocemente. Sposta il tuo sito su un host web veloce. Utilizza la compressione, le immagini ottimizzate e le reti di distribuzione dei contenuti.
• Estrai il tuo script dello strumento di test A / B dal gestore tag (se ne usi uno, come Google Tag Manager).
• Se puoi, esegui invece il test degli URL divisi.
• Presta attenzione agli elementi HTML che modifichi. Se hai apportato modifiche alla pagina stessa (invece di eseguire il test degli URL divisi), la cosa fondamentale da tenere a mente è la quantità di codice che è stata modificata. Se hai modificato migliaia di righe, è molto più probabile che si verifichi un effetto sfarfallio rispetto alla modifica della copia dei pulsanti. Quindi l'ambito dei cambiamenti influenza tutto.

Quali strumenti lato client fanno bene

Gli strumenti lato client consentono ai marketer di eseguire test con precisione senza l'aiuto degli sviluppatori.

Non è un piccolo risultato. Le risorse di sviluppo sono costose, in termini di tempo e denaro, quindi è efficiente consentire test indipendenti dallo sviluppo del prodotto. Detto in modo ottimale:

"Quando è il momento di agire e apportare modifiche al tuo sito, non vi è alcuna sostituzione per risorse tecniche dedicate: nella maggior parte delle organizzazioni, queste risorse sono difficili da trovare e in genere richiedono un'attesa in linea".

Prova più velocemente

Sean Ellis ha introdotto l'idea di test ad alta velocità come meccanismo chiave per la crescita.

La premessa di base è che più veloce ed efficiente è possibile eseguire i test, più è possibile eseguirli e più velocemente è possibile crescere. Sebbene i loro colli di bottiglia fossero principalmente a livello di ideazione e organizzazione, molti ottimizzatori trovano colli di bottiglia a livello di sviluppo e implementazione. Gli strumenti lato client che utilizzano editor visivi risolvono questo problema.

In un pezzo precedente, Andrew Anderson ha scritto sull'importanza della velocità negli strumenti di test. Fornisce anche alcuni esempi di strumenti:

Andrew Anderson:

“Quando si pensa alla velocità, ci sono due diversi fattori che contano. Il primo è dopo la distribuzione e l'installazione iniziali, quanto velocemente è possibile ottenere un test dal concept all'esecuzione per vivere? L'obiettivo di qualsiasi programma è ottenere la maggior parte dei test con almeno cinque esperienze attraverso questo concetto in 30 minuti o meno. Questo è un obiettivo difficile da raggiungere, ma esprime quanto sia importante dare priorità alla velocità nei test e alla necessità di una conoscenza generale di CSS, HTML e JavaScript da parte dell'operatore.

Ciò significa che elementi come regole templatizzate, interazione semplice con il sito, interfaccia semplice e navigazione semplice sono fondamentali. Significa anche che gli strumenti che richiedono regole di targeting URL complesse, una distribuzione IT costante o che richiedono la configurazione manuale di jQuery dovrebbero essere ridotti sulla scala di priorità.

Un esempio di uno strumento che per lo più fa questo è ottimale, mentre un esempio di quelli che non lo fanno è SiteSpect ".

Andrew ha anche osservato che, mentre molti strumenti forniscono interfacce visive facili da usare per creare trattamenti, il codice jQuery creato automaticamente è spesso piuttosto male. Ciò comporta problemi di compatibilità tra browser diversi e lentezza. Chiedi sempre agli sviluppatori di controllare e migliorare il codice o impara jQuery. Aiuterà davvero.

Strumenti lato server: quando utilizzare?

Come ho già detto, un enorme vantaggio per gli strumenti lato client è la velocità e la facilità d'uso per le persone non super tecniche. Quindi quali sono i vantaggi degli strumenti lato server? Perché le aziende dovrebbero usarli?

Come Matt Gershoff, spiega l'amministratore delegato di Conductrics, anche gli strumenti lato server presentano i loro vantaggi. Ecco cosa ha detto su di loro:

Matt Gershoff:

"I principali vantaggi del lato server saranno:

• Maggiore flessibilità e controllo. Utilizza test e targeting per il targeting di test non visivi (call center, sistemi CMS) e una stretta integrazione nello stack tecnologico di marketing per singolo flusso di lavoro (CMS, database, server Web e così via).
• Privacy. Mantieni tutte le decisioni di test / targeting interne.
• Sicurezza. Ridurre la superficie di attacco.
• Per le app Web, riduci la necessità di pagine "pesanti" ".

Gli strumenti lato server possono anche essere migliori per i siti mobili che offrono contenuti dinamici perché, come afferma Nate Weiss, CTO di Conductrics, “le connessioni più lente e i browser meno potenti in molti telefoni significano che gli approcci JavaScript sul lato client sono più di uno svantaggio sul cellulare. "

Continua a parlare dell'applicabilità alle applicazioni mobili native:

Nate Weiss:

"Alcuni verticali continuano a spostarsi verso le app mobili native per il coinvolgimento. Se la tua azienda ha un'app mobile nativa o prevede di farlo in futuro, selezionare uno strumento che supporta i test lato server ora significa che sarai pronto per iniziare a utilizzare gli stessi strumenti per i test nelle tue app (con il coinvolgimento degli sviluppatori) ".

Un altro argomento di meno conversazioni che Nate mi ha fatto capire è che, a seconda della natura del tuo sito e dei test che prevedi di eseguire, potrebbe essere più rispettoso per i tuoi visitatori utilizzare gli strumenti lato server.

Come ha detto Nate, "considera quale è più importante: la tua comodità durante l'impostazione dei test o l'esperienza dell'utente del visitatore (e l'impatto sui loro piani di dati mobili)".

Inoltre, gli strumenti lato server ampliano le tue capacità di ottimizzazione oltre i problemi di presentazione visiva basata sul web, in un certo senso. Quello che fanno è permetterti di pensare un po 'diversamente sull'ottimizzazione, più verso l'ottimizzazione dei tuoi sforzi di marketing transazionale.

Con gli strumenti lato client, l'argomento principale della discussione riguarda l'effetto sfarfallio. Questo è un problema, ma non è l'unico o il più grande problema da discutere con gli strumenti. Cose come la flessibilità, il controllo e la privacy influenzano l'ottimizzazione tanto quanto più dello sfarfallio, specialmente se prendi le precauzioni per mitigare quel rischio.

Di che tipo è il tuo strumento?

Ecco un grafico che classifica rapidamente gli strumenti più diffusi. Facci sapere se ci manca qualcosa o ci sbagliamo: