Ce este testarea A/B și cum construiești un test corect

Testarea A/B compară două experiențe afișate în același timp unor grupuri alocate aleatoriu. A este controlul, B este schimbarea, iar diferența dintre rezultate este evaluată cu o metodă statistică stabilită înainte de lansare. Ideea pare simplă. Totuși, un site poate împărți traficul 50/50 și să nu producă un experiment în care merită să ai încredere.

Un test se strică înainte de primul vizitator dacă ipoteza nu pornește dintr-o problemă observată, metrica nu reprezintă rezultatul urmărit sau efectul minim nu ar schimba decizia. Se strică în rulare când același utilizator vede ambele variante, când implementarea schimbă mai multe lucruri imposibil de interpretat ori când echipa oprește testul în prima zi în care dashboardul arată verde.

Ghidul de mai jos construiește protocolul înaintea platformei: ipoteză, variabilă, trafic, durată, criteriu de oprire și situația în care testul nu este instrumentul potrivit. Pentru definiția metricii, citește separat cum se calculează rata de conversie. Dacă evenimentul nu a fost reconciliat cu rezultatul comercial, rezolvă mai întâi măsurarea; randomizarea nu poate repara o conversie greșită.

Ce este un test A/B, pe o decizie concretă

Într-un A/B test, utilizatorii eligibili sunt distribuiți aleatoriu între control și variantă. Cele două experiențe rulează în aceeași perioadă, pentru ca ziua săptămânii, sezonul, campaniile și evenimentele externe să afecteze ambele grupuri cât mai comparabil. La final, nu compari doar două procente; estimezi efectul schimbării și incertitudinea lui.

Documentația Optimizely definește A/B testingul ca o comparație pe trafic live între versiunea A și versiunea B. Statsig descrie experimentele drept randomized controlled trials și pune unitatea de randomizare în centrul distribuirii. Furnizorii folosesc motoare statistice diferite, dar ambele definiții cer control, variantă și alocare randomizată.

Imaginează-ți o firmă de instalații care primește trafic plătit pe o pagină de serviciu. Interviurile cu vânzările arată că oamenii nu înțeleg dacă intervenția de urgență este disponibilă noaptea, iar înregistrările de sesiune arată reveniri repetate la zona de program. Echipa propune să mute programul și condițiile de urgență lângă primul CTA.

Un protocol interpretabil nu spune „testăm un hero nou”. Spune:

Exemplul este editorial, nu un caz Amplify și nu promite creștere. Rolul lui este să arate ce poate răspunde testul: efectul mutării informației pentru populația și metrica alese. Nu poate demonstra că informația este singurul motiv al tuturor abandonurilor și nu poate fi generalizat la orice serviciu local.

Testarea simultană diferă de „am schimbat pagina în iunie și am comparat cu mai”. Într-o comparație înainte/după, rezultatul poate veni din mixul canalelor, zile libere, concurență, preț sau disponibilitatea echipei. Un test randomizat încearcă să izoleze contribuția schimbării. Nu elimină orice eroare, dar construiește un contrafactual mai credibil: ce s-ar fi întâmplat în aceeași perioadă fără variantă.

Un A/A test folosește două experiențe identice. Optimizely îl numește test de calibrare: ar trebui să ajute la verificarea platformei și a capturării datelor, nu să descopere un „winner”. Dacă două variante identice produc sistematic o diferență mare, nu ai o idee genială; ai un motiv să investighezi alocarea, trackingul și populația.

Ipoteza leagă dovada de schimbare și de metrică

„Butonul verde va converti mai bine” este o predicție, nu o ipoteză completă. Nu spune ce problemă rezolvă, pentru cine, prin ce mecanism și ce rezultat ar trebui să se schimbe. Dacă B câștigă, echipa nu știe dacă motivul este culoarea, contrastul, textul, poziția sau o eroare de implementare. Dacă B pierde, nu știe ce a învățat.

O ipoteză utilă are cinci părți:

1. dovada problemei: analytics, feedback, interviuri, suport, vânzări, test funcțional ori observație comportamentală;
2. segmentul: utilizatorii pentru care problema este plauzibilă;
3. schimbarea: tratamentul suficient de specific pentru implementare;
4. mecanismul: motivul pentru care schimbarea ar modifica decizia;
5. rezultatul: metrica primară și guardrailurile.

Formatul poate fi: „Pentru [segment], am observat [problemă și dovadă]. Dacă [schimbare], atunci [metrica] se va modifica deoarece [mecanism], fără să deteriorăm [guardrail].” Nu este o formulă magică. Este o disciplină care permite unei alte persoane să conteste legătura înainte să consumi traficul.

Optimizely separă în pașii oficiali audiența, variațiile, evenimentele și verificarea experimentului. Aceste componente trebuie să reflecte ipoteza. Dacă problema apare numai pe mobil, includerea tuturor dispozitivelor diluează efectul. Dacă obiectivul este leadul calificat, clickul pe CTA poate fi o metrică diagnostică, nu verdictul.

Heatmaps și session recordings pot genera ipoteze. Microsoft Clarity descrie heatmaps și recordings ca instrumente pentru observarea interacțiunilor. Un click map poate arăta că oamenii apasă pe un element neinteractiv; un scroll map poate arăta că puțini ajung la o secțiune. Niciunul nu spune singur de ce se întâmplă și nici dacă schimbarea va crește rezultatul comercial. Folosește observația ca început al investigației, nu ca verdict.

Leagă metrica de decizie. O metrică primară ar trebui să fie sensibilă la tratament, măsurată fiabil și suficient de apropiată de valoare. Guardrailul protejează o consecință secundară: retururi, reclamații, latență, rata leadurilor acceptate, erori ori venit per utilizator. Dacă formularul scurt crește trimiterile, dar dublează cererile fără buget, nu ai câștigat.

În România, relatarea GPeC despre o prezentare de optimizare din 2024 spune explicit că A/B testingul nu funcționează fără o strategie care clarifică ce compari. Sursa oferă context local, nu standard statistic. Protocolul rămâne controlat prin documentația și cercetarea de experimentare, iar afirmațiile comerciale din eveniment nu sunt preluate.

Nu transforma ipoteza în pledoarie pentru B. Rezultatul negativ și rezultatul inconcludent sunt rezultate valide. Un test bun poate arăta că mecanismul presupus nu produce efectul relevant. Câștigul este că echipa evită o lansare riscantă și își actualizează înțelegerea, nu că fiecare experiment colorează dashboardul în verde.

Traficul minim vine din efectul care contează

Nu există răspunsul „ai nevoie de 10.000 de vizite” fără baseline, metrică, efect minim, alocare și parametri statistici. Același trafic poate fi suficient pentru a detecta o schimbare mare într-o acțiune frecventă și insuficient pentru o schimbare mică într-o comandă rară.

Cele patru intrări de bază sunt:

• baseline-ul: rata ori media metricii în control;
• minimum detectable effect (MDE): cea mai mică diferență pe care vrei să o poți detecta;
• nivelul de eroare acceptat: riscul deciziei fals pozitive și puterea dorită;
• designul: numărul de grupuri, alocarea și unitatea de randomizare.

Optimizely explică în documentația MDE că un efect mai mic cere, în general, un eșantion mai mare. Exemplul lor pornește de la o rată inițială de 15%, un MDE relativ de 10% și un nivel de semnificație de 95% și estimează aproximativ 8.000 de vizitatori pentru fiecare variație. Cifra nu este pragul unui site românesc. Ea este legată de parametri; schimbă baseline-ul sau efectul și necesarul se schimbă.

MDE trebuie ales economic, nu ca numărul care face calculatorul să accepte traficul disponibil. Dacă implementarea costă 20.000 de lei și o îmbunătățire relativă de 2% nu poate recupera costul într-un interval rezonabil, detectarea acelui efect nu schimbă decizia. Poate că ai nevoie de un tratament cu impact potențial mai mare, de o metrică mai apropiată de valoare sau de alt tip de cercetare.

Distinge efectul relativ de punctele procentuale. De la 10% la 11% înseamnă +1 punct procentual și +10% relativ. Confuzia intră direct în sample size. În dosarul experimentului, scrie ambele valori, nu doar „lift 10%”.

Un video educațional sau un calculator online poate ajuta la intuiție, dar decizia cu miză merită revizuită de cineva care înțelege motorul statistic ales. Platformele pot folosi fixed horizon, metode secvențiale, modele bayesiene și corecții diferite. Nu compara etichetele „95%” ca și cum ar fi aceeași procedură.

Înainte de lansare, fă o prognoză de recrutare. Dacă ai nevoie de 16.000 de utilizatori eligibili în total și recrutezi 500 pe săptămână, testul ar dura în jur de 32 de săptămâni înainte de ajustări pentru sezonalitate și întârzieri ale metricii. Într-un asemenea caz, răspunsul nu este să reduci arbitrar MDE-ul sau să oprești devreme. Reconsideră întrebarea, tratamentul, populația ori metoda.

Traficul eligibil nu este traficul total din Analytics. Exclude utilizatorii care nu pot vedea tratamentul, traficul intern, boturile și populațiile în afara ipotezei. Dacă randomizezi după utilizator, numără utilizatori eligibili, nu pageviews. Dacă rezultatul apare la 30 de zile după expunere, adaugă fereastra de maturizare; sample size atins azi nu înseamnă rezultat complet azi.

Schimbi o cauză interpretabilă și protejezi restul sistemului

Regula populară „schimbă un singur lucru” este utilă, dar prea rigidă. Poți testa un pachet coerent — mesaj, dovadă și CTA — dacă ipoteza este despre claritatea întregii propuneri. Ce trebuie evitat este varianta în care schimbi simultan oferta, prețul, layoutul, formularul și canalul, apoi atribui rezultatul unei culori.

Definește variabila la nivelul mecanismului. Dacă ipoteza este că oamenii nu înțeleg costul total, tratamentul poate include preț, taxe și condiții într-un singur bloc. Dacă ipoteza este despre contrastul CTA-ului, păstrează textul, poziția și fluxul. Un rezultat interpretabil îți spune ce mecanism merită păstrat, nu doar ce fișier a câștigat.

Unitatea de randomizare trebuie să prevină contaminarea. Același utilizator nu ar trebui să vadă A la prima vizită și B la a doua, dacă experiența anterioară îi influențează decizia. Pentru aplicații de echipă, randomizarea per cont sau companie poate fi mai potrivită decât per utilizator. Pentru oferte care se discută între colegi, contaminarea poate apărea chiar și cu ID-uri diferite.

Fă QA înainte de trafic real:

După lansare, verifică sample ratio mismatch. Statsig explică SRM drept un dezechilibru între unitățile observate și alocarea așteptată. Un 50/50 configurat nu garantează un 50/50 sănătos. Diferența poate veni din excluderi aplicate după randomizare, erori numai într-o variantă, caching, identificatori instabili ori pipeline de date. Nu interpreta impactul până nu înțelegi cauza.

Monitorizarea de siguranță este diferită de „peeking pentru winner”. Ai voie să urmărești dacă site-ul se strică, dacă venitul cade sever sau dacă apare o problemă legală. În protocol, definește praguri de oprire pentru daună și cine are autoritatea să oprească. Nu transforma orice fluctuație negativă de o zi într-un prag de panică.

Păstrează un changelog al experimentului. Dacă modifici varianta după lansare, notează momentul și decide dacă trebuie restartat. Dacă schimbi metrica primară fiindcă alta arată mai bine, testul devine exploratoriu. Dacă lansezi o campanie care afectează numai unul dintre grupuri, contrafactualul este compromis. Disciplina operațională contează la fel de mult ca formula.

Durata și oprirea se decid înainte de lansare

„Rulează două săptămâni” este o regulă de calendar, nu un design. Uneori două săptămâni acoperă două cicluri săptămânale și sample size-ul planificat. Alteori sunt prea puține sau inutil de multe. Durata vine din rata de recrutare, eșantionul necesar, ciclurile normale, fereastra metricii și metoda de analiză.

O cercetare despre durata experimentelor online leagă planul de lățimea intervalului de încredere necesară pentru efectul care contează și arată validarea pe experimente YouTube. Nu preluăm o durată standard din lucrare. Concluzia practică este că sample size și timpul nu sunt două reguli independente: ai nevoie de destule unități și de o perioadă care reprezintă comportamentul relevant.

Pentru un test fixed-horizon, stabilești sample size-ul și data țintă, apoi citești rezultatul la finalul planificat. Rezultatele intermediare pot fi urmărite pentru sănătate, nu folosite repetat pentru a alege prima fereastră favorabilă. Documentația Statsig despre sequential testing explică de ce „peekingul” într-un test tradițional crește riscul fals-pozitivelor și cum o metodă secvențială ajustează analizele intermediare.

Oprirea are trei familii:

• oprire planificată: sample size și durata/fereastra metricii au fost atinse;
• oprire de siguranță: există o regresie severă, o eroare, un risc legal sau operațional definit;
• oprire prin metodă secvențială: motorul și regula preînregistrată permit decizia intermediară cu ajustările necesare.

„A ajuns la 95% azi” nu este singur un criteriu dacă metoda nu permite citiri repetate. „A trecut o săptămână” nu este criteriu dacă recrutarea este sub plan. „B este cu 20% mai sus” nu este criteriu dacă sunt doar câteva conversii. Raportul trebuie să spună metoda și condiția, nu doar culoarea interfeței.

Nu prelungi testul la nesfârșit până apare semnificația. Dacă ai atins designul și intervalul include atât o pierdere relevantă, cât și un câștig relevant, rezultatul este inconcludent pentru decizia propusă. Poți proiecta un test nou, poți alege un tratament mai puternic sau poți accepta că efectul nu poate fi estimat cu resursele curente. Schimbarea regulii după ce vezi datele trebuie declarată exploratorie.

Include în raport: planul inițial, expunerile, eventualele excluderi, sănătatea alocării, efectul estimat, intervalul, guardrailurile și decizia. Nu reduce rezultatul la „A” sau „B”. Un rezultat negativ poate fi clar, un rezultat pozitiv poate fi inutil economic, iar un rezultat inconcludent poate proteja echipa de o certitudine inventată.

Când testarea A/B nu este instrumentul potrivit

Testarea A/B este puternică atunci când există incertitudine reală, trafic eligibil, implementare simultană și o decizie reversibilă. Nu este ritualul obligatoriu pentru orice schimbare.

Repară direct erorile evidente. Un formular care nu trimite, o eroare care nu poate fi înțeleasă, un contrast inaccesibil ori o pagină care cade pe mobil nu trebuie menținute pentru a afla dacă utilizatorii preferă varianta funcțională. Verifică remedierea și monitorizează impactul.

Respectă cerințele legale și de siguranță. Consimțământul, informația obligatorie, securitatea și accesibilitatea nu sunt opțiuni estetice puse la vot. Poți experimenta implementări conforme între ele, nu conformitatea însăși.

Nu forța un test subalimentat. Dacă efectul minim relevant cere ani de trafic, platforma nu creează informație din nimic. Folosește interviuri, usability testing, analytics, session recordings, feedback și lansare etapizată. Aceste metode nu demonstrează același efect cauzal, dar pot reduce incertitudinea potrivită situației.

Nu testa o decizie pe care nu o vei implementa. Dacă firma nu poate schimba prețul, nu are capacitate să preia cererile sau nu poate construi varianta câștigătoare, experimentul consumă utilizatori fără o decizie acționabilă.

Nu confunda explorarea cu validarea. Un heatmap sugerează o zonă problematică; un interviu explică un motiv; un prototip observă dacă oamenii înțeleg; un A/B test estimează efectul unei schimbări pe metrica și populația alese. Alege metoda după întrebarea pe care trebuie să o rezolvi.

O echipă fără trafic suficient poate îmbunătăți conversia. Poate remedia fricțiunea, clarifica oferta, controla măsurarea și testa calitativ un traseu. Ce nu poate face onest este să numească o fluctuație de șase conversii „winner statistic”. Programul de optimizare a conversiilor trebuie să includă și decizia de a nu experimenta încă.

Întrebări frecvente

De cât trafic am nevoie ca un test A/B să dea un rezultat credibil?

Traficul necesar se calculează din baseline, efectul minim detectabil, puterea și nivelul de eroare ales, numărul de variații, alocare și unitatea de randomizare. Folosește numai traficul eligibil. Un calculator poate estima eșantionul, dar verifică dacă MDE-ul este relevant economic și dacă fereastra rezultatului a avut timp să se maturizeze. Nu există un prag universal de sesiuni.

Cât timp las testul să ruleze înainte să decid?

Până atingi condiția preînregistrată: eșantionul țintă, ciclurile comportamentale relevante și fereastra metricii. Într-un fixed-horizon, nu opri la prima citire favorabilă. Dacă folosești o metodă secvențială, urmează regulile motorului. Oprește mai devreme numai pentru criteriile de siguranță definite, nu pentru a prinde un „winner”.

Protocolul vine înaintea platformei

Un test A/B credibil încape într-o fișă pe care o poți citi înainte de lansare. Scrie problema și dovada, ipoteza, populația și unitatea de randomizare, controlul și varianta, metrica primară și guardrailurile, baseline-ul și MDE-ul, eșantionul și durata, regula de oprire și decizia pentru fiecare rezultat posibil.

Dacă unul dintre câmpuri lipsește, platforma poate încă împărți traficul și produce un grafic. Nu înseamnă că graficul răspunde unei decizii. Dacă aceleași câmpuri rămân stabile, rezultatul pozitiv, negativ sau inconcludent devine o lecție reutilizabilă.

Scopul nu este să câștige B. Scopul este să reduci incertitudinea fără să schimbi regulile după ce vezi răspunsul. Începe cu protocolul, verifică implementarea, lasă metoda să decidă momentul citirii și păstrează impactul comercial lângă semnalul statistic.