Cele mai bune practici pentru a stabili o sursă unică de adevăr (SSOT) pentru testarea A/B

Testarea dvs. CX trăiește sau moare pe baza calității datelor dvs. Nu puteți formula ipoteze valide și testabile folosind date discutabile. Și nu poți avea încredere în rezultatele testelor tale dacă nu știi că te uiți la valori precise.

De aceea trebuie să vă construiți programul de testare în jurul unui set de date Single Source of Truth (SSOT). Dacă nu poți, chiar și cel mai simplu test A/B va lipsi de valoare. Acest articol explorează de ce este atât de importantă stabilirea unui SSOT și împărtășește câteva dintre cele mai bune practici testate pe teren pe care le-am dezvoltat pentru a face asta aici, la Kameleoon.

Ce este un SSOT

Luarea modernă a deciziilor în afaceri trebuie să fie bazată pe date. Menținerea unui SSOT înseamnă că pentru experimentarea CX sau orice altă funcție, standardizați pe o singură sursă de date ca „adevăr” definitiv în jurul căruia conduceți munca acelei echipe și informați deciziile companiei dumneavoastră.

Fără un SSOT, riscați ca datele dvs. să se fragmenteze în silozuri păzite de diferite echipe pentru diferite funcții. Nu există standardizare, nu există consens și nicio modalitate de a ști dacă cineva ia decizii bazate pe cele mai bune informații disponibile.

Un SSOT nu este o tehnologie sau un sistem anume. Este o practică de afaceri concepută pentru a obține rezultate optime din activitățile echipei tale. Unele companii au economisit milioane prin trecerea la o strategie de date SSOT fără să atingă măcar munca de bază.

Studiile au arătat că valorile de înaltă calitate ale comportamentului clienților rămân cele mai căutate date pentru informarea deciziilor strategice. De câțiva ani consecutiv, în sondajul anual al CEO-ului PricewaterhouseCoopers, directorii executivi consideră că este cea mai importantă măsură pe care o doresc pentru planificarea strategică.

Ce este testarea A/B

Testarea A/B este o metodă de experimentare cu site-uri web, aplicații mobile sau reclame prin compararea performanței unei versiuni originale - versiunea A sau versiunea de control - cu o versiune B modificată. Scopul este de a colecta date de performanță pentru fiecare, de a efectua analize statistice și de a determina, pe baza datelor, care versiune a avut cele mai bune rezultate.
Testarea A/B funcționează pentru a testa mai mult decât elementele unei pagini web. De exemplu, îl puteți folosi pentru a optimiza prețurile, pentru a valida caracteristicile produsului și pentru a personaliza site-urile web pentru diferite segmente de vizitatori. În plus, testele A/B sunt fundamentul multor alte tehnici de optimizare CX, inclusiv testarea multivariată, recomandarea de produse și direcționarea bazată pe profil.

Cine are nevoie de un SSOT pentru testare?

Echipele de experimentare înoată prin datele generate în platformele lor de analiză, CRM, platformele de testare și multe altele. Ei trebuie să stabilească un SSOT pentru testare pentru a clarifica ce vor echipele lor să facă. Să luăm în considerare un exemplu.

Unul dintre clienții Kameleoon a lansat o campanie de optimizare a funcției de căutare a site-ului său. Ei au efectuat teste pe partea de server care au implicat urmărirea traficului către o pagină de acces.

Dar au întâmpinat o problemă cu care se confruntă multe programe de experimentare: datele din Google Analytics au arătat un număr de vizite de pagină, iar instrumentul lor de experimentare a arătat altul. Diferența a fost de peste 9 la sută.

Fiind un site de comerț electronic cu peste un milion de vizitatori pe lună, decizia în care setul de date să aibă încredere a făcut o mare diferență în raportarea KPI a companiei. În timp ce unele mărci medii și întreprinderi pot ignora diferențele de până la 10% în statisticile vizitatorilor, o diferență de 9% în date a făcut nervoasă echipa de experimentare a acestei companii.

Această echipă a primit abia recent acceptarea programului lor de experimentare, inclusiv un buget pentru a investi în instrumente precum Kameleoon. Ei sperau la teste cu concluzii clare. În schimb, acuratețea datelor lor era pusă la îndoială. Aveau nevoie să înființeze un SSOT.

Am ajutat această companie să își curățeze urmărirea datelor vizitatorilor, să stabilească un SSOT și să obțină rezultatele testelor de care aveau nevoie pentru a crește. Pentru a face acest lucru, i-am ajutat să adopte șapte bune practici SSOT. Împărtășim aceste bune practici aici, deoarece orice echipă de CX care dorește să-și dispute datele de testare și să profite la maximum de programul lor de experimentare le poate folosi pentru a crește.

Cele mai bune practici pentru eliminarea discrepanțelor datelor de testare și stabilirea unui SSOT

1. Înainte de a face orice altceva, efectuați un test A/A

În timp ce un test A/B compară o versiune veche cu o versiune nouă a produsului sau a paginii dvs., un test A/A compară ca și cum ar fi. De ce ai vrea să faci asta? Astfel, puteți compara datele generate de fiecare platformă de monitorizare.

În testul A/A, ambele variante sunt aceleași, dar utilizatorii care le văd vor fi diferiți:

Cum să acționezi

Înainte de a efectua orice testare A/B serioasă sau de a lansa o nouă implementare în care veți dori să adunați date, rulați un test A/A pentru a calibra. Într-o lume perfectă, testul A/A va returna rezultate identice. În realitate, asta se întâmplă rar, dar vei afla totuși cât de multă discrepanță ai de-a face.

De exemplu, desfășurarea unui test A/A vă permite să vedeți ce valori primește Google Analytics în comparație cu instrumentul dvs. de testare pentru aceleași sesiuni, utilizatori, vizite, conversii sau orice valoare pe care doriți să o măsurați.

2. Urmăriți vizitatorii și vizitele în același mod în toate instrumentele dvs

Numărul de vizitatori sau vizite urmărite de instrumentele dvs. de analiză nu se va potrivi niciodată exact cu utilizatorii și sesiunile. Cu toate acestea, vă puteți asigura că vizitele sunt numărate în același mod în platformele dvs. de analiză și A/B pentru a reduce discrepanța.

În Google Analytics, există două moduri în care se încheie o vizită:

• Expirare în funcție de timp: aici, sesiunea expiră după 30 de minute de inactivitate sau la miezul nopții. În timp ce, de exemplu, în Kameleoon, este după 30 de minute de inactivitate.

• Modificarea campaniei : dacă același vizitator sosește printr-o campanie, pleacă după 2 minute și apoi revine printr-o campanie diferită 2 minute mai târziu, Google Analytics va număra două vizite. Unele instrumente de testare A/B îl vor vedea ca unul.

Cum să acționezi

Verificați cum sunt numărați vizitatorii și vizitele în instrumentul dvs. de analiză și asigurați-vă că este același lucru pentru instrumentul dvs. de testare. Sau că o poți schimba. La Kameleoon, vă recomandăm să utilizați platforma dvs. de analiză ca sursă unică de adevăr.

În GA, puteți modifica cât timp până când sesiunile și campaniile vor expira în Setări sesiuni.

De ce? SSOT-urile ar trebui definite la nivel organizațional. Prin urmare, chiar dacă echipa dvs. de testare își petrece întreaga zi lucrând cu date din platforma dvs. de testare, este posibil ca alte echipe să fie nevoite să facă referire la date de la GA în alte scopuri. Setați SSOT să fie setul de date la care face referire cea mai largă gamă de echipe din organizația dvs.

3. Creați filtre pentru browser și versiuni în instrumentul dvs. de analiză

Multe platforme de testare A/B nu rulează pe Internet Explorer, așa că orice vizite din acel browser sunt excluse automat din rapoartele de experiment. Dar IE ar putea provoca în continuare o discrepanță de date dacă vizați organizații mari, vechi care îl folosesc.

O altă problemă potențială de urmărire este că Google Analytics este compatibil cu toate versiunile de browser, în timp ce instrumentele de testare A/B mențin de obicei compatibilitatea deplină doar cu ultimele versiuni.

Cum să acționezi

În Google Analytics, creați filtre personalizate pe baza browserelor și a versiunilor de browser care vă interesează, astfel încât toate platformele să se potrivească. Faceți asta în

De exemplu, sub Vizualizare, iată cum ați exclude o versiune mai veche de Google Chrome:

4. Filtrați traficul problematic în toate instrumentele dvs

Păstrați setul de date SSOT cât mai curat posibil prin colectarea datelor numai de la membrii publicului legitim. Nu doriți să vă tulburați datele cu bot, troll, bug-uri de urmărire sau alt trafic excepțional. Nu-ți face griji cu privire la scăderile de volum, calitatea rezultatelor tale va crește.

Cum să acționezi

Instrumentele avansate de testare A/B oferă mai multe setări de filtrare pentru bot. De exemplu, pot elimina automat traficul din statisticile colectate dacă detectează un comportament aberant sau dacă sesiunea intră într-o stare de activitate suspectă.

Pe de altă parte, dacă utilizați GA, depinde de dvs. să decideți cum să detectați și să excludeți traficul bot din datele dvs. de analiză folosind filtre. Pentru referință, iată câteva condiții pe care poate doriți să le excludeți.

• Durata vizitei > 120 minute
• Durata vizitei < 100 milisecunde
• Număr de evenimente (conversii, clicuri, direcționare, produs, vizualizare de pagină etc.) > 10K

De asemenea, doriți să excludeți traficul intern din cadrul organizației dvs. Amintiți-vă, scopul în construirea acestui set de date SSOT este de a avea o sursă definitivă de date despre clienții dvs. reali, nu despre colegii dvs.

Pentru a filtra traficul intern în GA, accesați Panoul de administrare > Toate filtrele și creați un nou filtru. Setați tipul de filtru la „nedefinit”. Apoi, adăugați intervalele IP interne pe care doriți să le excludeți.

5. Evitați blocarea reclamelor

Mulți vizitatori folosesc agenți de blocare a reclamelor, cum ar fi Adblock, Ghostery și uBlock. Unii agenți de blocare a anunțurilor pot bloca, de asemenea, instrumentele de urmărire la nivel de client, inclusiv evenimentele de analiză din instrumentele de experimentare.

Dacă o parte semnificativă dintre vizitatorii dvs. au activate blocante de anunțuri în browser, există șanse mari ca numărul de vizite înregistrate să varieze între instrumentul dvs. de testare A/B și platforma dvs. de analiză.

Cum să acționezi

Unele platforme pot furniza adrese URL de solicitare de urmărire „on-premise” care le permit să evite blocarea de către agenții de blocare a anunțurilor. Aici, urmărirea are loc pe partea de server, astfel încât blocarea codului pe partea clientului, cum ar fi de la un adblocker, nu oprește urmărirea legitimă. Activați-l pe toate platformele posibile.

O altă modalitate de a înțelege mai bine discrepanța dintre platformele dvs. de analiză și cele de testare este să trimiteți un eveniment către platforma dvs. de analiză după ce instrumentul dvs. de testare s-a încărcat. Acest lucru ar trebui să vă ofere o idee clară despre procentul de vizitatori care folosesc blocuri de anunțuri care blochează instrumentul dvs. de testare A/B. Apoi va trebui să-ți filtrezi traficul pentru a exclude vizitatorii care folosesc agenți de blocare a reclamelor.

6. Instalați-vă instrumentele pe toate aceleași pagini

Plasarea fragmentului este o cauză comună a discrepanțelor de date, mai ales dacă doriți să desfășurați un experiment care vizează un întreg site. Motivul este că multe instrumente de experimentare tratează „întregul site” ca pe toate paginile care poartă fragmentul de cod. Din păcate, acesta ar putea include chiar și site-ul dvs. de organizare dacă aveți fragmente copiate acolo.

Cum să acționezi

Dacă nu ați făcut-o deja, acum este momentul potrivit pentru a rula acel test A/A pentru a vă calibra platformele. Apoi, asigurați-vă că toate instrumentele dvs. sunt implementate pe aceleași pagini.

O modalitate de a identifica dacă nu sunt acestea este să vă descompuneți datele după adresele URL ale paginilor vizitate. Aceasta vă va afișa toate adresele URL principale pe care a rulat experimentul, astfel încât să le puteți identifica pe acelea în care instrumentul dvs. de testare nu ar fi trebuit să se încarce. Iată cum arată această opțiune în Kameleoon:

Gânduri finale

După o analiză atentă, Kameleoon a stabilit că clientul cu o discrepanță a datelor a întâmpinat această ultimă problemă. Google Analytics și instrumentul lor de testare nu rulau pe aceleași pagini.

În timp ce GA a urmărit tot traficul care mergea către pagina cu rezultatele căutării, și-a configurat instrumentul de testare cu un parametru mai restrâns - experimentul a numărat vizitele către pagina de acces numai după o căutare în bara de căutare.

Deși ambele pagini arătau la fel, adresele URL erau diferite, creând o discrepanță între date. Cu toate acestea, odată rezolvate, aveau un SSOT de încredere pentru testarea datelor și urmau să genereze multe informații valoroase.

Recunoscând unde setările din instrumentul dvs. de testare nu se aliniază cu urmărirea dvs. de analiză, puteți decide ce număr de vizitatori să raportați sau cum să utilizați setările pentru a minimiza diferența.

Eliminați discrepanțele, stabiliți o singură sursă de adevăr și reuniți-vă echipele în jurul unui set comun de date. Stabilirea unui SSOT este primul pas către o testare mai bună, mai fiabilă și mai perspicace.