Kliendikindel A/B-testimise raamistik: 7 sammu, mis töötavad igal kontol

Kokkuvõte

Agentuurid teevad A/B-teste karmimates tingimustes kui ühe tootega meeskonnad: mitu klienti, tihedad tähtajad ja hajutatud mõõdikud. See artikkel annab teile korratava raamistiku, mis töötab igal kontol, alustades ühe tõelise konversioonieesmärgi määratlemisest. Saate teada, kuidas leida hõõrdepunkte selle asemel, et ajada taga sidusrühmade arvamusi, kirjutada ennustavaid hüpoteese ning valida ühe muutuja, mitme muutuja ja AI-põhiste eksperimentide vahel. See hõlmab pragmaatilist valimisuuruse planeerimist, kuidas hoida kliendid testi varakult lõpetamast ja kuidas lugeda mitmetähenduslikke tulemusi nagu konsultant. Viimane samm on pakkida iga võit ja ebaõnnestumine mänguraamatusse, mis muudab järgmise kliendi testimistsükli kiiremaks. Kasutage seda struktuuri, et lõigata raisatud nädalaid ja muuta testimine oma agentuuri konkurentsieeliseks. Kui kohtlete testimist süsteemina, mitte ühekordsete päringute jadana, lõpetate iga konto puhul ratta uuesti leiutamise.

Esmaspäev, kell 9:47. Klient saadab e-kirja, küsides "kiiret A/B-testi" oma hinnalehel. Teil on pooleli veel kolm kontot, igal ühel erinev analüütikaseadistus, erinev kinnituste ahel ja erinev "võidu" määratlus. Kiire test võtab statistilise olulisuse saavutamiseks kolm nädalat. Te teate seda juba. Nii et venitate ajakava, seate ootused ja viite testi läbi. Seejärel kulutate pool nädalat selle kaitsmisele.

See ei ole testimise probleem. See on süsteemi probleem. Kui peate iga kliendi jaoks uuesti leiutama, kuidas testida, pole te optimeerimispartner – olete testide täitja. Järgnev on seitsmeastmeline raamistik, mis töötab iga kliendi, iga tööriista ja iga liiklustaseme korral. Kasutage seda kiiremate ja targemate testitsüklite saamiseks, mis kuhjuvad kontolt kontole.

1. Määrake edumõõdik enne muutujasse puutumist

A/B-testimine, nagu seda määratleb Optimizely sõnastik, jagab teie vaatajaskonna juhuslikult ja näitab igale rühmale lehe erinevat versiooni. See juhuslik jaotus genereerib andmeid. Kuid andmed tähendavad midagi ainult siis, kui teate, mida mõõdate. Enamik kliente ütleb, et nad tahavad "rohkem konversioone" – kuid konversioonid võivad olla registreerumised, ostud, demotaotlused või isegi kerimine lehe jalusele. Kui te ei kinnita ühte mõõdikut, on iga tulemus, mille tagasi toote, avatud ümbertõlgendamisele.

Alustage iga koostööd 15-minutilise eesmärgiauditiga. Küsige kliendilt: "Milline üks tegevus, kui see kahekordistuks, teeks selle kvartali edukaks?" Seejärel muutke see vastus peamiseks mõõdikuks. Kasutage seda testi õnnestumiskriteeriumina. Kõik muu – põrkemäär, lehel viibitud aeg, sekundaarsed klikid – muutub kaitsepiirde mõõdikuks, mida jälgite, kuid mille jaoks te ei optimeeri.

Olge halastamatult konkreetne. Kui klient ütleb "müügivihjed", määratlege, mis on müügivihje. Müügivihje võib olla vormi esitamine, kuid see võib olla ka telefonikõne, reaalajas vestlus või allalaadimine. Iga määratlus muudab seda, millist lehe elementi peaksite testima. Vormi esitamise eesmärk suunab teid vormi pikkuse ja hõõrdumise juurde. Telefonikõne eesmärk muudab teie optimeerimise täielikult "kliki-helistamise" asetuse ja usaldussignaalide teemaks. Kui te ei lepi seda alguses kokku, optimeerite valet lehte.

Töötatud näide: B2B klient soovib "rohkem müügivihjeid". Küsite, mis on müügivihje. Nad ütlevad "kvalifitseeritud potentsiaalsed kliendid". See ei ole jälgitav. Kitsendate selle "vormi esitamiseks ettevõtte e-posti aadressiga". Nüüd on teil peamine mõõdik. Kui hiljem testite uut pealkirja, hindate seda ainult selle mõõdiku põhjal. Samuti märkate katseid kuulutada võitu parema põrkemäära põhjal. See selgus säästab teid tundidepikkustest vaidlustest.

Kui teil on peamine mõõdik, kirjutage see testi lühikirjeldusse. Lühikirjeldus peaks ütlema ühe lausega: "Seda testi hinnatakse [mõõdiku] alusel." Jagage seda iga sidusrühmaga. Kui asepresident hiljem soovitab, et "noh, kaasatus paranes", osutate lühikirjeldusele. Te ei nihutanud väravaposte. Leppisite need kokku.

See on ka koht, kus eraldate signaali mürast. Teadmine, millised testid kõige rohkem loevad, on pool võitu. Oma eelarve kulutamine testidele, mis kõige tõenäolisemalt tulu toovad on see, mis teeb agentuuri tõhusaks.

2. Otsige hõõrdumist, mitte eelistusi

Kliendid annavad teile nimekirja "testid, mida tahame teha", mis on tegelikult arvamused. "Nupp peaks olema roheline." "Pealkiri peaks mainima meie auhinda." Neid te ei tee. Teete teste, mis vähendavad hõõrdumist või suurendavad usaldust. Kõik CRO mänguraamatud osutavad samadele hoobadele: tegevuskutse selgus, vormi pikkus, paigutuse selgus, sotsiaalne tõendus ja usaldussignaalid.

Leidke need hoovad, vaadates, kus teie kliendi kasutajad loobuvad. Seadistage seansisalvestused või põhiline sündmuste jälgimine, kui neil seda juba pole. Vaadake vähemalt viit päris kasutajaseanssi kliendi kohta. Ärge lootke kliendi arvamusele selle kohta, "mis kasutajatele meeldib". Andmed võidavad arvamust.

Levinud hõõrdumise allikad, mida auditeerida:

• Vormid, mis küsivad liiga palju või liiga vähe infot
• Tegevuskutsed, mis ei ütle järgmist tegevust selgelt (nt "Lisateave" vs. "Alusta tasuta prooviversiooni")
• Usaldussignaalide puudumine kohustumise punkti lähedal (soovitused, garantiid, raha tagasi pakkumised)
• Lehed, mis laadivad mobiilis aeglaselt
• Teekonnad, millel on üllatav lisasamm (nt "registreerimine" ja seejärel "e-posti kinnitamine" ilma hoiatuseta)

Töötatud näide: E-kaubanduse kliendi kassas on 6 väljaga vorm pluss valikuline "loo konto" märkeruut. Seadistate seansisalvestuse ja vaatate viit kasutajat. Kaks proovivad kustutada eel täidetud kupongikoodi, sest arvavad, et see rakendab allahindlust. Üks loobub telefoninumbri väljal. Hõõrdumine ei ole vormi pikkus; see on segadust tekitav kupongiväli. Teie test ei muuda nuppu suuremaks. See liigutab kupongivälja viimasesse ülevaatusetappi. See on vaatlusest, mitte arvamusest sündinud test.

Selle tegemiseks mitme kliendi lõikes looge ühine hõõrdumiste logi. Alati, kui kasutaja jääb ühe kliendi saidil jänni, märkige muster. Näete sama hõõrdumist kolm nädalat hiljem teise kliendi saidil. See on teie agentuuri privaatne uurimisraamatukogu. See on ka võimas müügiargument uuele kliendile: "Oleme näinud seda täpset probleemi teie turusegmendis."

Ärge peatuge saidisisese käitumise juures. Uurige väljumisteid, kuumakaarte ja vormiväljade analüütikat. Eesmärk on leida üks selge punkt, kus kasutajad ära langevad. See punkt on teie testi muutuja. Kui te ei leia selget languspunkti, viige läbi diagnostiline test: proovige drastiliselt erinevat tegevuskutset, palju lühemat vormi või radikaalselt erinevat väärtuspakkumist. Tulemus, isegi nulltulemus, näitab teile, kus on publiku tõeline vastupanu.

Hoidke hõõrdumiste logi ajakohasena. Kui märkate korduvat mustrit, märkige see logisse koos ekraanipildi ja üherealine selgitusega. Mõne kuu pärast on teil kasutaja vastuväidete kataloog, mis kehtib iga teie teenindatava kliendi kohta. See kataloog on müügiargument: "Oleme seda täpset vastuväidet juba teie valdkonnas testinud. Siin on, mida õppisime."

3. Kirjutage hüpotees, mis ennustab miks, mitte mida

Hea test vastab küsimusele: "Kui me teeme X, siis juhtub Y, sest Z." "Sest Z" on hüpotees ja see teeb tulemuse ülekantavaks. Ilma "miksita" ei räägi võitnud test teile järgmise kliendi kohta midagi.

Sõnastage iga test selle "Kui... siis... sest..." struktuuriga. See sunnib mõtlema mehhanismi peale. "Lühendage vormi 5 väljalt 3-le" muutub "Kui me lühendame vormi, siis täitmismäär tõuseb, sest kasutajad tajuvad vähem pingutust." Nüüd teate, miks. Saate selle reegli üle kanda igale kliendile, kellel on pikk vorm.

Nüüd hoiatus. Tavaline hea tava ütleb, et testige korraga ühte muutujat. See reegel on olemas hea põhjusega: isoleeritud muutujad annavad puhta põhjusliku seletuse. Kuid agentuuridel on harva piisavalt liiklust või kuid, et teha kakskümmend eraldi ühe muutuja testi. Madala liiklusega kontode puhul vajate kompromissi. Teil on kolm võimalust.

Lähenemine	Parim, kui	Kompromiss
Ühe muutuja test	Kõrge liiklusega leht, üks hüpotees, aega on	Kõige puhtam põhjuslik lugu, aeglane
Mitme muutuja test	Keskmine liiklus, mitu sõltumatut muutujat	Kiirem, kuid segavad vastastikmõjud
AI-põhine eksperiment	Madal liiklus, tihe tähtaeg, tahad masinat kohanduda	Uuem tööriistastik, vähem kontrolli variantide üle

See kolmas võimalus väärib tõsist kaalumist. Optimizely AI-eksperimentide selgitus kirjeldab masinõppesüsteeme, mis jaotavad liiklust dünaamiliselt ja genereerivad teie jaoks variante. Selle asemel, et määrata fikseeritud jaotus ja oodata, õpib süsteem, milline variant võidab, ja suunab liiklust reaalajas sinna. See võib kokku suruda kahenädalase testi mõneks päevaks – mõningase metoodilise puhtuse hinnaga. Tähtajaga agentuuri jaoks on see sageli õige hind.

Pole kindel, milline tee teie kliendile sobib? Enne otsustamist tasub mõista klassikalise ja AI-põhise testimise kompromisse.

Siin on, kuidas otsustada: kui kliendil on palju liiklust ja avatud ajakava, kasutage ühe muutuja testi. Kui neil on keskmine liiklus ja mitu võimalikku muudatust, viige läbi mitme muutuja test kõige lootustandvamate kombinatsioonidega. Kui neil on madal liiklus ja kindel tähtaeg, valige AI-põhine eksperiment, mis suudab lennu ajal kohaneda. Ärge laske eelistusel "päris teaduse" vastu pimestada teid kliendi äripiirangute ees. Õige test on see, mis toodab otsuse, mille järgi saate tegutseda enne, kui eelarve aurustub. Täiusliku statistilise võimsusega test, mis lõpeb pärast kliendi kampaania lõppu, on väärtusetu.

Töötatud näide: Kohalik teenuseklient saab mõõdukat igapäevast liiklust. Ühe muutuja testi tegemine omal käel võtaks kuude kaupa, et tuvastada oluline erinevus. Kirjutate hüpoteesi ja kasutate seejärel AI-eksperimenti, mis jaotab liiklust dünaamiliselt. Mõne päeva pärast näitab süsteem, et üks variant on ees, ja suunab rohkem liiklust sinna. Saate vastuse kliendi kampaania akna jooksul. Nõustute sellega, et tulemus on statistiliselt vähem puhas kui kuuenädalane klassikaline test. See on ratsionaalne vahetus, mitte kompromiss.

Pange tähele ka seda, et "üks muutuja korraga" reeglit saab lõdvendada, kui testite radikaalselt uut lehe sektsiooni, mitte ühte nuppu. Tervet lehte hõlmav ümberkujundustest võib muuta mitut elementi, kuid hüpotees on siiski sidus: "Kasudest lähtuva tekstiga üles ehitatud paigutus edestab praegust funktsioonide loendi paigutust, sest kasutajad valivad tulemuste põhjal." Kuni hüpotees nimetab mehhanismi, saate testida muudatuste kimpu. Olge lihtsalt kliendiga aus, et te ei tea, milline element tõusu põhjustas.

4. Kohandage test kliendi kalendri, mitte statistikaraamatu järgi

Statistiline olulisus ei ole maagiline number, mille avate 21. päeval. See sõltub teie algtaseme konversioonimäärast, minimaalsest tõusust, mida peate nägema, ja liikluse hulgast, mida saate testi suunata. Iga selle valdkonna testimise juhend kordab sama hoiatus: viige test läbi, kuni teil on piisav valimi suurus ja kestus, vastasel juhul on teie järeldus müra.

Enne testi ajastamist tehke arvutus lihtsas keeles. Hinnake kliendi praegust konversioonimäära ja kõige väiksemat paranemist, mis teile oluline on. Seejärel hinnake, kui palju külastajaid vajate mõistliku usaldusnivoo jaoks. Kui seda arvu ei saavutata enne kliendi kvartaliülevaadet, on teil kolm valikut: laiendage liikluse jaotust, et saata rohkem inimesi testi, aktsepteerige suuremat minimaalset tuvastatavat efekti, mida teie liiklus toetab, või muutke test õppimiskatsetuseks ilma lubatud "võitjata".

Selleks ei pea olema doktorikraad. Kasutage valimi suuruse kalkulaatorit. Sisestage algtase, efekt, mida soovite tuvastada, ja soovitud usaldusnivoo. Tööriist ütleb teile, kui palju külastajaid variandi kohta vajate. Seejärel jagage see kliendi eeldatava testiliiklusega päevas, et saada vajalik kestus. Kui see kestus ei mahu kliendi tähtajasse, kohandage ühte sisendit enne testi käivitamist. See vestlus on palju odavam kui raisatud kolmenädalane tsükkel.

Töötatud näide: SaaS-kliendi prooviversiooni registreerimise leht saab mõõdukat, kuid ühtlast külastajate voogu. Soovite tuvastada olulist paranemist ja teie valimi suuruse hinnang ütleb, et test vajab palju rohkem külastajaid, kui kliendi liiklus saadaoleva aja jooksul annab. Klient vajab vastust kuue nädala pärast oma juhatuse koosolekuks. Seega laiendate jaotust 50/50-lt 90/10-le – kuid sellest ei piisa. Selle asemel alandate minimaalset tuvastatavat efekti, et püüda ainult suuri võite. Nüüd on test ajakava piires teostatav ja olete kliendile öelnud täpselt, mida test suudab ja ei suuda tabada. See on professionaalne käik.

Te vajate ka lõpetamise reeglit. Otsustage ette, kui kaua test kestab ja millist olulisuse läve kasutate. Ärge kunagi laske kalendrikuupäeval olla ainus põhjus lõpetamiseks. Teadke, millal katse varakult lõpetada või seda pikendada – teie otsus, mitte suvaline reede, peaks seda tegema.

5. Hoidke klienti testi varakult lõpetamast

Siin on stseen, mida olete elanud: on teisipäev ja klient kirjutab: "Test on täna hommikul üleval. Avaldame võitja kohe." Teil on üks variant, mis on ees, kuid olete alles jõudnud nõutava valimi suuruseni. Teie klient näeb võitu. Teie näete müra. See on kõige levinum põhjus, miks agentuuride testid ebaõnnestuvad – mitte halb matemaatika, vaid halb sidusrühmade juhtimine.

Seadke reeglid enne testi algust. Saatke üheleheküljeline testi lühikirjeldus, mis märgib: peamise mõõdiku, kavandatud valimi suuruse, varaseima kuupäeva, millal tulemusi vaatate, ja mida tohib muuta katse ajal. Laske kliendil see heaks kiita. Kui nad piiluvad, muutub see ootuste rikkumiseks, millele saate osutada, mitte isiklikuks tagasilükkamiseks. See ei ole vaenulik olemine; see on katse terviklikkuse kaitsmine.

Samuti kaitske testikeskkonda. Öelge kliendile, et testi ajal ei tohi saidile muud muudatusi välja tulla. Tõrkest teatav bänner testlehel, viimase hetke kujundusmuudatus mõnelt teiselt müüjalt või isegi sotsiaalmeedia hüpe võivad teie andmeid saastada. Hetkel, kui midagi muutub väljaspool teie testi, on tulemused kahtlased.

Töötatud näide: Kliendi arendaja lükkab testi keskel välja uue faviconi. See ei tohiks mõjutada, kuid see ei tohiks ka juhtuda. Logite selle, märgite ajatempli ja kontrollite, kas tulemused pärast seda punkti nihkuvad. Kui nihkuvad, alustate testi uuesti. Kliendid ei saa sageli aru, kui habras see on. Teie töö on muuta see testi lühikirjelduses selgesõnaliseks, et nad võtaksid seda tõsiselt.

Teine levinud kliendi käik on "peame kampaaniat reedel käivitama, kas saate testi varakult lõpetada?" Pange vastu, välja arvatud juhul, kui kampaania segab testi ennast. Kui lõpetate varakult, riskite vale otsuse tegemisega. Selle asemel vaadake, kas kampaaniat saab veidi edasi lükata või viia test lehele, mida kampaania ei mõjuta. Teie testi lühikirjeldus on teie läbirääkimistööriist. Kasutage seda viisakalt, kuid kindlalt keeldumiseks.

Veel üks harjumus: ärge kunagi kontrollige tulemusi testi ajal, välja arvatud juhul, kui otsite tehnilist riket. Inimese aju on tõenäosuse osas kohutav. Rida häid päevi tundub tõestusena, kuid sageli on see lihtsalt müra. Kui teil on kiusatus piiluda, avage selle asemel valimi suuruse kalkulaator. Tuletage endale meelde, kui palju andmeid veel puudub.

6. Lugege tulemust kui lugu, mitte otsust

Test lõpeb. Variant võidab jälle. Kuid "milline nupp võitis" on kõige vähem kasulik asi, mida õppisite. Kasulikud küsimused on: Miks see võitis? Kas see seletus kehtib ka teiste lehtede puhul? Mida avastasime selle publiku kohta, mida me varem ei teadnud?

See on koht, kus enamik agentuure peatub. Nad lasevad võitva variandi välja, saadavad kliendile PDF-i ja liiguvad edasi. See on kasutamata võimalus. Nulltulemus – kus variant ei alistanud kontrolli – on ikkagi tulemus. See ütleb teile, et publik ei hooli sellest muutujast või et originaal oli juba piisavalt hea. Dokumenteerige see õppetund ja rakendage seda järgmises testis. Hea tava juhendid rõhutavad järjekindlalt õppimiste dokumenteerimist pärast iga katset; see muudab testimise ühekordsete sündmuste seeriast kuhjuvaks varaks.

Töötatud näide: Testite fotoga soovitust vs. tavalist tsitaati. Tavaline tsitaat võidab. Uurite, miks. Pilt näeb lavastatud välja; kliendi publik on skeptiline. Õppetund ei ole "soovitused ei tööta". See on "see publik tahab autentset, omistamata tõendust, mitte lihvitud fotosid." Järgmisel kuul küsib teine klient sotsiaalse tõenduse kohta. Te juba teate, mida neile mitte näidata. See on lugude lugemise ROI.

Tulemuse tõlgendamine ei ole ainult p-väärtuse kontrollimine. See on suuna, suuruse ja segmentide erinevuste uurimine. Kui te pole kindel, kas usaldada seda, mida näete, vaadake uuesti põhitõdesid. Juhend, kuidas õigesti tõlgendada A/B testi tulemusi ilma müra alla sattumata, hoiab teid ausana.

Arvestage ka "mis siis" testiga. Tõlkige mõõdik kliendi keelde. Suur suhteline tõus väiksel algtasemel võib tähendada peaaegu mitte mingit tulu, samas kui väike tõus suure liiklusega lehel võib tähendada tohutut kasu. Ärge laske suhtelisel muutusel pimestada absoluutse väärtuse ees. Klienti huvitab lõpptulemus, mitte usaldusvahemik.

Nulltulemuse esitamisel ärge vabandage. Raamige see andmepunktina. "Saime teada, et pealkirja pikkus ei mõjuta selle publiku konversiooni. See säästab meid selle testi uuesti tegemast." Nulltulemus on selge vastus küsimusele. See ei ole ebaõnnestumine.

7. Muutke iga tulemus korratavaks reegliks

Nüüd viimane samm, mis eristab agentuuri, mis teeb testimist, agentuurist, mis panustab sellele. Pärast iga testi kirjutage üheleheküljeline mänguraamatu sissekanne. Vormindage see järjekindlalt: kliendi tüüp, hüpotees, tulemus, soovitus. Salvestage see kohta, kus kõik saavad otsida. Seejärel enne uue testi käivitamist otsige mänguraamatust sarnast olukorda. Sageli avastate, et olete juba õppinud seda, mida kavatsete uuesti õppida.

Nii muutub testimine agentuuri konkurentsieeliseks. Kliendi A leid "kupongiväli on segane" säästab teid sama vigase testi kujundamisest kliendi B kassas. Kliendi C "soovitused ei liiguta nõela" vabastab teid millegi muu testimiseks. Mänguraamat on vara, mida te tegelikult müüte, mitte aruanded.

Mänguraamatu sissekande kontrollnimekiri:

• Kliendi valdkond ja saidi tüüp
• Testi leht ja testitud muutuja
• Hüpotees "Kui... siis... sest..." kujul
• Peamise mõõdiku tulemus: võit, kaotus või null
• Selgitus "miks", millele jäite
• Üks tegevus, mida kordaksite uue kliendi juures
• Üks tegevus, mida te enam kunagi ei prooviks

Töötatud näide: Fitnessirakenduse klient testib tasuta prooviversiooni vormi ühe e-posti väljaga versus eesnime-pluss-e-posti vorm. Ühe väljaga versioon annab väikese, kuid järjekindla võidu. Kirjutate mänguraamatu sissekande: "Impulssostude puhul (fitness, toit) minimeerige nõutavad väljad varakult; koguge isikuandmeid hiljem." Kuus nädalat hiljem küsib einekomplekti klient oma pika registreerimisvormi kohta. Tõmbate mänguraamatu sissekande, soovitate sama lühendamist ja viite testi läbi enesekindlalt, sest teate juba tõenäolist tulemust. See on kuhjuv efekt.

Lõpuks pidage meeskonnaga igakuine "õppimiste ülevaade". Vaadake üle, mida olete kõigi klientide juures õppinud. Ühendage sissekanded, mis osutavad samale aluspõhimõttele. Muutke need põhimõtted tulevaste testide juhisteks. Näiteks kui kaks erinevat klienti nägid ühe väljaga vormi puhul suuremat konversiooni, on põhimõte "küsige minimaalset infot kuni kohustumiseni" tõenäoliselt tõene nende segmentide lõikes. See põhimõte mõjutab nüüd iga uue kliendi sihtlehe soovitust juba enne testi tegemist.

Raamistik töötab. Kuid see töötab ainult siis, kui te süsteemi tegelikult üles ehitate. Alustage ühe kliendiga. Rakendage kõiki seitset sammu. Seejärel rakendage neid järgmise kliendi juures ja laske mänguraamatul teha üha rohkem tööd. Lõpetate küsimuse "mida peaksime testima?" ja hakkate küsima "milline teadaolev reegel kehtib siin?" See on erinevus agentuuri vahel, mis teeb teste, ja agentuuri vahel, mis toob paremaid tulemusi.