Testare la nivelul clientului vs. Testare pe server: Ambele câștigă.
Publicat: 2020-05-28
Când vine vorba de desfășurarea experimentelor, optimizatorii pot alege între testarea pe partea client și pe partea serverului.
Deși puteți rula aproape toate testele la nivelul clientului pe partea de server și câteva experimente backend ușoare prin testare la nivelul clientului (folosind URL-ul împărțit sau experimente de redirecționare), acest lucru nu va fi la fel de fezabil sau robust ca dvs. mi-ar place... pentru că, pentru orice ipoteză, doar una dintre cele două funcționează cel mai bine .
Și alegerea corectă necesită o analiză atentă. Există multe aspecte de cântărit atunci când faceți această alegere. Priviți impactul configurației asupra vitezei și SEO, efortul și cerințele de timp pentru ciclul de viață al experimentului, obiectivul experimentului și multe altele.
Să trecem peste acești factori și să vedem cum diferă testarea pe partea client de testarea pe partea serverului și avantajele și dezavantajele fiecăruia.
Testare la nivelul clientului vs. Testare pe server
Care este diferența dintre testarea pe partea client și testarea pe partea serverului?
În testarea la nivelul clientului, odată ce un utilizator solicită o pagină, serverul dvs. o livrează. DAR, în acest caz, instrumentul dvs. de experimentare implementează Javascript în browserul utilizatorului pentru a modifica conținutul livrat de server, astfel încât utilizatorul final să obțină variația corespunzătoare pe baza regulilor dvs. de direcționare. (Browserul este „clientul”).
În testarea serverului, pe de altă parte, odată ce un utilizator solicită o pagină, serverul dvs. determină versiunea de livrat și oferă exact asta. Instrumentul dvs. de experimentare funcționează pe server și nu în browserul utilizatorului.
Deoarece testarea la nivel de client are loc numai cu execuția JS la nivel de browser, puteți testa doar lucruri la nivel de suprafață, cum ar fi machetele, culorile și mesajele cu acesta. Unii optimizatori numesc astfel de teste drept teste „cosmetice”.
Cu toate acestea, aceasta ar reduce testarea clientului.
Testarea la nivelul clientului ar putea părea simplă, dar este puternică.
Este ușor să respingi testarea A/B la nivelul clientului drept „testarea ușoară” pe care o poate face oricine. De acord: este ușor de implementat. Și, uneori, poate fi la fel de mic ca testarea unei culori sau a unei copii diferite pentru butonul CTA.
Dar fie că este vorba despre aceasta sau despre ceva atât de mare precum testarea unei reproiectări sau a unei pagini reînnoite, testarea la nivelul clientului are un impact asupra profitului unei afaceri .
Ce este testarea la nivelul clientului?
Pe scurt: testarea la nivelul clientului înseamnă că optimizarea are loc la nivel de browser. Pe baza regulilor de direcționare pe care le-ați configurat, browserul vizitatorului va modifica conținutul pentru a livra versiunea dorită.
În acest studiu de caz, o companie SaaS a folosit Convert Experiences ca instrument de testare A/B la nivelul clientului pentru a crește creșterea clienților potențiali cu 61% pe pagina sa de pornire:
Iată un alt experiment de testare A/B care utilizează Convert Experiences ca instrument de testare la nivelul clientului pentru aceeași companie SaaS pe pagina sa de prețuri, care a condus la o creștere cu 57% a clienților potențiali:
Majoritatea poveștilor de succes în optimizarea conversiilor pe care le vedeți online sunt teste la nivelul clientului care au optimizat cu succes o experiență la nivel de suprafață și au câștigat mari.
Dar testarea pe server vă permite într-adevăr să testați mai mult.
Când trebuie să testați mai profund decât front-end, trebuie să treceți cu testarea pe server.
Ce este testarea pe server?
Testarea pe server este un tip de experiment în care serverul web determină versiunea conținutului de livrat. În testarea pe server, toată optimizarea este implementată direct în servere, mai degrabă decât în browserele vizitatorilor.
Să punem acest lucru în perspectivă cu câteva scenarii.
Dacă ați fi o afacere de comerț electronic, ați putea folosi un experiment de testare A/B la nivelul clientului pentru a afla dacă o bară de căutare reproiectată ar putea crește căutările dvs. în magazin (și ar putea duce la mai multe vânzări).
Dar dacă doriți să testați un nou algoritm de căutare care ar putea aduce rezultate de căutare mai relevante (și care, pe termen lung, ar duce la mai multe vânzări), ar trebui să rulați un experiment de testare A/B pe server. .
Dacă ați fi o afacere SaaS B2B, ați putea rula un experiment la nivelul clientului pentru a determina dacă un anumit UVP funcționează mai bine pe pagina dvs. de pornire. Sau dacă o copie lungă ar putea depăși pe una scurtă.
Dar dacă doriți să testați un backend mai rapid și să vedeți dacă ar putea îmbunătăți retenția sau implicarea, ar trebui să rulați un experiment pe server. Dacă doriți să testați o nouă secvență de integrare, din nou, ar trebui să faceți un experiment pe partea serverului. Pentru că, pe lângă sprijinirea noului flux de lucru de integrare, testarea pe server vă va permite, de asemenea, să orchestrați un experiment multicanal care se întinde pe e-mailuri, SMS-uri și altele care au loc pe diferite dispozitive.
De asemenea, dacă ați fi o afacere B2C SaaS, ați putea să rulați un experiment la nivelul clientului pentru a afla dacă un anumit plan de prețuri ar putea funcționa mai bine decât celelalte.
Cu toate acestea, dacă doriți să testați un motor de recomandare mai bun, ar trebui să mergeți la testarea serverului.
După cum puteți înțelege din diferitele cazuri de utilizare ale testării pe server, este orientată mai mult spre construirea de produse mai bune decât spre câștigarea de conversii imediate. Spre deosebire de experimentele la nivelul clientului care se concentrează pe vânzări sau conversii imediate, experimentele la nivelul serverului se concentrează pe optimizarea produsului sau soluției, astfel încât valoarea clientului pe durata de viață să crească.
Ați putea spune că, dacă testarea la nivelul clientului este pentru agenți de marketing, atunci testarea pe partea serverului este în primul rând pentru echipele de produse și de inginerie. Iar instrumentele de testare A/B precum Convert Experiences oferă atât testare pe partea client, cât și pe partea serverului, pentru a se adapta atât echipelor de marketing, cât și de inginerie.
Încercați-l gratuit timp de 15 zile!
Deoarece testarea unor astfel de modificări profunde la nivel de produs necesită mult mai mult decât o simplă manipulare JS bazată pe browser, aceasta nu se poate întâmpla în interiorul browserului și trebuie abordată la nivel de server.
În timp ce testarea pe server are cazurile sale de utilizare unice, unele companii o folosesc pentru a rula chiar și testele cosmetice - teste care ar rula perfect fără erori chiar și pe partea clientului.
Ei fac adesea acest lucru pentru a evita fenomenul de „pâlpâire” sau „Flash de conținut original”. Pâlpâirea are loc atunci când instrumentul de experimentare modifică conținutul original oferit de server după ce utilizatorii finali l-au văzut deja. Imaginați-vă că utilizatorii văd un anumit titlu și apoi văd cum se schimbă într-o clipită în altul. (Da, pâlpâirea poate compromite grav experiența unui utilizator!)
Alteori, o fac pentru o viteză îmbunătățită. Deși testarea nu încetinește un site web și nu cauzează probleme serioase de performanță, adaugă o secundă sau două experienței de încărcare percepută a unui site web. Partea server poate face acest lucru mai rapid.
Ocazional, o companie poate desfășura un experiment la nivelul serverului în locul unui experiment la nivelul clientului din cauza problemelor de confidențialitate sau securitate. Pe măsură ce direcționarea către public are loc la server și codul de experimentare se află pe server în cadrul testării pe server, companiile obțin un control mai bun asupra aspectelor sale de confidențialitate și securitate.
Dar implementarea unui experiment pe partea de server nu este întotdeauna fezabilă, mai ales când o parte a clientului s-ar descurca la fel de bine.
Implementarea experimentelor pe partea de server
În testarea la nivelul clientului, aveți nevoie doar de resurse limitate de proiectare și dezvoltare pentru a vă construi experimentele și a le executa. Nici măcar nu veți avea nevoie de acestea dacă faceți doar modificări de text sau schimbați culoarea unui buton. Tot ce trebuie să faci este:
1. Conectați-vă la un instrument precum Convert.
2. Utilizați editorul WYSIWYG și construiți variațiile.
3. Configurați experimentul (setați condițiile de direcționare către public, durata experimentului, dimensiunea și împărțirea eșantionului, nivelul de încredere etc.)
Luați codul JS și adăugați-l pe site-ul dvs. web.
Și gata.
Ați căuta apoi ajutor de dezvoltare pentru a lansa versiunea câștigătoare dacă controlul s-a întâmplat să piardă.
Testarea pe server, totuși, nu este atât de simplă.
Aici, va trebui să:
1. Creați experimentul în Conversia experiențe
2. Dezvoltați și implementați toate variantele experimentului dvs. pe serverul dvs.
3. Hartați experiențele dvs. implementate pe server în Conversie experiențe folosind cod personalizat (folosind ID-ul experimentului, ID-urile variațiilor așa cum sunt setate în instrumentul dvs. de experimentare și multe altele).
În astfel de experimente pe partea de server, codul dvs. trebuie să spună serverului ce variație să arate unui utilizator actual. Puteți utiliza cookie-uri pentru a facilita acest lucru. De exemplu, pentru a implementa un test pe server A/B cu Convert, va trebui să configurați un cookie cu următoarele date:
Serverul va citi apoi cookie-ul dvs. și
servi o versiune (și toate sesiunile ulterioare) în consecință.
Deoarece serverul dvs. determină ce versiune să trimită unui utilizator, direcționarea are loc la server (și nu în interiorul browserului, ca în cazul testării pe partea client). Precizia dvs. de testare va depinde de cât de bine vă puteți codifica condițiile de direcționare pe server. Cu toate acestea, cu testarea la nivelul clientului, puteți viza publicul dvs. pentru toate experiențele dvs.
De asemenea, testarea pe server poate deveni mai complexă într-o configurare cu mai multe servere și, de asemenea, atunci când un CDN trebuie integrat.
4. Rulați experimentul.
5. Lansați versiunea câștigătoare și derulați înapoi pe cei învinși.
De asemenea, s-ar putea să fie nevoie să vă curățați serverele, să postați lansarea finală/rollback-ul.
După cum puteți vedea, ciclul de viață al unui experiment pe partea de server este lung și complex, spre deosebire de cel al unui experiment pe partea client. De aceea, testarea pe server necesită o anumită deliberare.
În general, nu ați rula un experiment pe partea serverului dacă unul pe partea client ar face...
Rularea chiar și a unui singur experiment pe partea de server este o provocare, deoarece dezvoltarea și lansarea acestuia este un proces care consumă mai mult resurse și mai mult timp.
În plus, dacă utilizați testarea pe partea de server pentru a testa modificări care pot fi validate cu ușurință pe partea clientului, va fi dificil să atingeți o viteză bună de testare și un program robust de experimentare.
De asemenea, pentru astfel de experimente, optarea pentru experimentarea pe partea de server atunci când aveți câteva instrumente excelente de testare A/B la nivelul clientului care vă permit să le rulați fără pâlpâire, fără a vă afecta SEO sau viteza, nu promite cea mai bună utilizare a testării dvs. lățime de bandă.
Experimentele pe partea serverului ar trebui să fie preferate numai atunci când susțin argumente solide pentru ipoteza dată. Și o fac de câteva ori, deoarece multe experimente care influențează valorile finale ale unei companii pot avea loc numai pe partea de server.
Deci spuneți-ne... ați efectuat teste pe server? Dacă da, care a fost cea mai dificilă parte a procesului? Ah, și dacă doriți să rulați un test A/B pe partea de server, verificați Convertiți (este gratuit timp de 15 zile!)
