Asiakasvarma A/B-testauskehys: 7 vaihetta, jotka toimivat millä tahansa asiakastilillä

Yhteenveto

Toimistot suorittavat A/B-testejä ankarammissa olosuhteissa kuin yksittäisten tuotteiden tiimit: useita asiakkaita, tiukat aikataulut ja hajallaan olevat mittarit. Tämä artikkeli antaa sinulle toistettavan kehyksen, joka toimii millä tahansa tilillä, alkaen yhden todellisen konversiotavoitteen määrittelystä. Opit löytämään kitkapisteet sen sijaan, että jahtaisit sidosryhmien mielipiteitä, kirjoittamaan ennustavia hypoteeseja ja valitsemaan yksimuuttuja-, monimuuttuja- ja tekoälypohjaisten kokeiden välillä. Se kattaa käytännöllisen otoskoon suunnittelun, miten estää asiakkaita tappamasta testiä ennenaikaisesti, ja miten lukea epäselviä tuloksia kuin konsultti. Viimeinen vaihe on pakata jokainen voitto ja epäonnistuminen pelikirjaksi, joka nopeuttaa seuraavan asiakkaan testaussykliä. Käytä tätä rakennetta leikataksesi hukkaan heitetyt viikot ja muuttaaksesi testauksen kilpailueduksi toimistollesi. Kun käsittelet testausta järjestelmänä eikä sarjana kertaluonteisia pyyntöjä, lopetat pyörän keksimisen uudelleen joka tilillä.

Maanantai kello 9.47. Asiakas lähettää sähköpostia ja pyytää "nopeaa A/B-testiä" hinnoittelusivulleen. Sinulla on kolme muuta tiliä käynnissä, jokaisella erilainen analytiikka-asetus, erilainen hyväksyntäketju ja erilainen määritelmä "voittamisesta". Nopea testi vie kolme viikkoa saavuttaakseen tilastollisen merkitsevyyden. Tiedät tämän jo. Joten pidennät aikataulua, asetat odotukset ja ajat testin. Sitten käytät puolet viikostasi sen puolustamiseen.

Tämä ei ole testausongelma. Se on järjestelmäongelma. Jos joudut keksimään testaustavan uudelleen jokaiselle asiakkaalle, et ole optimointikumppani – olet testien suorittaja. Seuraavassa on seitsemän vaiheen kehys, joka toimii millä tahansa asiakkaalla, työkalulla ja liikennemäärällä. Käytä sitä saadaksesi nopeampia ja älykkäämpiä testisyklejä, jotka kasvavat kumulatiivisesti tililtä toiselle.

1. Kiinnitä menestysmittari ennen kuin kosket muuttujaan

A/B-testaus, kuten Optimizelyn sanastossa määritellään, jakaa yleisösi satunnaisesti ja näyttää kullekin ryhmälle eri version sivusta. Tämä satunnainen jako tuottaa dataa. Mutta data merkitsee jotain vain, jos tiedät mitä mittaat. Useimmat asiakkaat sanovat haluavansa "enemmän konversioita" – mutta konversiot voivat olla rekisteröitymisiä, ostoksia, demopyyntöjä tai jopa sivun alareunaan vierittämistä. Jos et kiinnitä yhtä mittaria, jokainen tuomasi tulos on avoin uudelleentulkinnalle.

Aloita jokainen toimeksianto 15 minuutin tavoitekatselmuksella. Kysy asiakkaalta: "Mikä yksittäinen toiminto, jos se kaksinkertaistuisi, tekisi tästä vuosineljänneksestä menestyksen?" Muuta sitten vastaus ensisijaiseksi mittariksi. Käytä sitä testin onnistumiskriteerinä. Kaikki muu – poistumisprosentti, sivulla vietetty aika, toissijaiset klikkaukset – muuttuu suojakaiteen mittariksi, jota seuraat mutta jota et optimoi.

Ole armottoman tarkka. Jos asiakas sanoo "liidit", määrittele mikä on liidi. Liidi voi olla lomakkeen lähetys, mutta se voi olla myös puhelu, live-chat tai lataus. Jokainen määritelmä muuttaa, mitä sivun elementtiä sinun tulisi testata. Lomakkeen lähetystavoite ohjaa sinut lomakkeen pituuteen ja kitkaan. Puhelutavoite tekee optimoinnistasi klikkaa ja soita -sijoittelua ja luottamussignaaleja. Jos et sovi tästä alussa, optimoit väärän sivun.

Toimiva esimerkki: B2B-asiakas haluaa "enemmän liidejä". Kysyt mitä liidi on. He sanovat "kelpoisia prospekteja". Se ei ole seurattavissa. Tarkennat sen "lomakkeen lähetyksiin, joissa on yrityksen sähköpostiosoite". Nyt sinulla on ensisijainen mittari. Kun myöhemmin testaat uutta hero-otsikkoa, arvioit sitä yksinomaan tämän mittarin perusteella. Huomaat myös yritykset julistaa voitto paremman poistumisprosentin perusteella. Tämä selkeys säästää sinut tuntien väittelyltä.

Kun sinulla on ensisijainen mittari, kirjoita se testibriefiin. Briefin tulisi sanoa yhdellä lauseella: "Tätä testiä arvioidaan [mittarin] perusteella." Jaa se kaikille sidosryhmille. Kun varatoimitusjohtaja myöhemmin ehdottaa, että "no, sitoutuminen parani", osoitat briefiin. Et siirtänyt maalitolppia. Sovitte niistä yhdessä.

Tässä myös erotat signaalin kohinasta. Sen tietäminen, mitkä testit ovat tärkeimpiä, on puoli voittoa. Budjetin käyttäminen testeihin, jotka todennäköisimmin siirtävät tulosta tekee toimistosta tehokkaan.

2. Etsi kitkaa, älä mieltymyksiä

Asiakkaat antavat sinulle listan "testejä, joita haluamme ajaa", jotka ovat todellisuudessa mielipiteitä. "Napin pitäisi olla vihreä." "Otsikon pitäisi mainita palkintomme." Et aja niitä. Ajat testejä, jotka vähentävät kitkaa tai lisäävät luottamusta. CRO-pelikirjat osoittavat samoihin vipuihin: toimintakehotuksen selkeys, lomakkeen pituus, asettelun selkeys, sosiaalinen todiste ja luottamussignaalit.

Löydä nämä vivut katsomalla, missä asiakkaidesi käyttäjät lopettavat. Ota käyttöön istuntotallenteet tai perustapahtumaseuranta, jos niitä ei vielä ole. Katso vähintään viisi oikeaa käyttäjäistuntoa per asiakas. Älä luota asiakkaan mielipiteeseen "siitä, mistä käyttäjät pitävät". Data voittaa mielipiteen.

Yleisiä kitkan lähteitä, joita kannattaa tarkastaa:

• Lomakkeet, jotka kysyvät liikaa tai liian vähän tietoa
• Toimintakehotukset, jotka eivät kerro seuraavaa vaihetta selkeästi (esim. "Lue lisää" vs. "Aloita ilmainen kokeilu")
• Puuttuvat luottamusvihjeet sitoutumispisteen lähellä (suosittelijat, takuut, rahat takaisin -tarjoukset)
• Sivut, jotka latautuvat hitaasti mobiilissa
• Matkat, joissa on yllättävä lisävaihe (esim. "rekisteröidy" ja sitten "vahvista sähköposti" ilman varoitusta)

Toimiva esimerkki: Verkkokauppa-asiakkaan kassalla on 6-kenttäinen lomake sekä valinnainen "Luo tili" -valintaruutu. Otat käyttöön istuntotallenteen ja katsot viittä käyttäjää. Kaksi yrittää poistaa esitäytetyn alennuskoodin, koska he luulevat sen aktivoivan alennuksen. Yksi keskeyttää puhelinnumerokentässä. Kitka ei ole lomakkeen pituus; se on hämmentävä alennuskoodikenttä. Testisi ei tee napista isompaa. Se siirtää alennuskoodikentän viimeiseen tarkistusvaiheeseen. Tämä on testi, joka on syntynyt havainnoista, ei mielipiteestä.

Tehdäksesi tämän useiden asiakkaiden kanssa, rakenna jaettu kitkaloki. Aina kun käyttäjä jää jumiin yhden asiakkaan sivustolla, huomioi kaava. Näet saman kitkan toisen asiakkaan sivustolla kolme viikkoa myöhemmin. Se on toimistosi yksityinen tutkimuskirjasto. Se on myös vahva myyntipuhe uudelle asiakkaalle: "Olemme nähneet tämän täsmälleen saman ongelman sinun markkinasegmentissäsi."

Älä pysähdy sivuston käyttäytymiseen. Tutki poistumisreittejä, lämpökarttoja ja lomakekenttäanalytiikkaa. Tavoitteena on löytää yksi selkeä kohta, jossa käyttäjät tippuvat pois. Tämä kohta on testimuuttujasi. Jos et löydä selkeää pudotuskohtaa, aja diagnostinen testi: kokeile täysin erilaista toimintakehotusta, paljon lyhyempää lomaketta tai radikaalisti erilaista arvolupausta. Tulos, jopa nolla, kertoo, missä yleisön todellinen vastus on.

Pidä kitkaloki ajan tasalla. Kun huomaat toistuvan kaavan, merkitse se lokiin kuvakaappauksen ja yhden rivin selityksen kanssa. Muutaman kuukauden kuluttua sinulla on luettelo käyttäjien vastaväitteistä, joka soveltuu jokaiseen palvelemaasi asiakkaaseen. Tämä luettelo on myyntivaltti: "Olemme jo testanneet tämän tarkalleen vastaväitteen toimialallasi. Tässä mitä opimme."

3. Kirjoita hypoteesi, joka ennustaa miksi, ei mitä

Hyvä testi vastaa kysymykseen: "Jos teemme X:n, niin Y tapahtuu, koska Z." "Koska Z" on hypoteesi, ja se tekee tuloksesta siirrettävän. Ilman "miksi"-osaa voittava testi ei kerro sinulle mitään seuraavasta asiakkaasta.

Muotoile jokainen testi tähän "Jos... niin... koska..." -rakenteeseen. Se pakottaa sinut ajattelemaan mekanismia. "Lyhennä lomake viidestä kentästä kolmeen" muuttuu muotoon "Jos lyhennämme lomaketta, niin suoritusprosentti nousee, koska käyttäjät kokevat vähemmän vaivaa." Nyt tiedät miksi. Voit siirtää tämän säännön mille tahansa asiakkaalle, jolla on pitkä lomake.

Nyt varoitus. Yleinen käytäntö sanoo, että testaa yhtä muuttujaa kerrallaan. Tämä sääntö on olemassa hyvästä syystä: eristetyt muuttujat antavat puhtaita kausaalisia selityksiä. Mutta toimistoilla on harvoin liikennettä tai kuukausia ajaakseen kahtakymmentä erillistä yksimuuttujatestiä. Matalan liikenteen tileille tarvitset kompromissin. Sinulla on kolme vaihtoehtoa.

Lähestymistapa	Paras, kun	Kompromissi
Yksimuuttujatesti	Korkean liikenteen sivu, yksittäinen hypoteesi, aikaa käytettävissä	Puhtain kausaalitarina, hidas
Monimuuttujatesti	Keskitasoinen liikenne, useita riippumattomia muuttujia	Nopeampi, mutta sekoittuneet vuorovaikutukset
Tekoälypohjainen kokeilu	Matala liikenne, tiukka määräaika, haluat koneen sopeutuvan	Uudempi työkalu, vähemmän hallintaa varianteista

Tätä kolmatta vaihtoehtoa kannattaa harkita vakavasti. Optimizelyn tekoälykokeiden selitys kuvaa koneoppimisjärjestelmiä, jotka jakavat liikenteen dynaamisesti ja luovat variantteja puolestasi. Sen sijaan, että asetat kiinteän jaon ja odotat, järjestelmä oppii, mikä variantti on voittamassa, ja siirtää liikennettä sille reaaliajassa. Tämä voi tiivistää kahden viikon testin muutamaan päivään – metodologisen puhtauden kustannuksella. Toimistolle, jolla on määräaika, se on usein oikea hinta maksettavaksi.

Etkö ole varma, mikä reitti sopii asiakkaallesi? Klassisen ja tekoälypohjaisen testauksen väliset kompromissit kannattaa ymmärtää ennen sitoutumista.

Näin päätät: jos asiakkaalla on runsaasti liikennettä ja avoin aikataulu, käytä yksimuuttujatestiä. Jos heillä on keskitasoinen liikenne ja useita ehdokasmuutoksia, aja monimuuttujatesti lupaavimmilla yhdistelmillä. Jos heillä on vähän liikennettä ja kova määräaika, valitse tekoälypohjainen kokeilu, joka voi sopeutua lennossa. Älä anna mieltymyksen "oikeaan tieteeseen" sokeuttaa sinua asiakkaan liiketoiminnan rajoitteille. Oikea testi on sellainen, joka tuottaa päätöksen, jonka voit panna täytäntöön ennen kuin budjetti loppuu. Täydellisesti mitoitettu testi, joka päättyy asiakkaan kampanjan jälkeen, on arvoton.

Toimiva esimerkki: Paikallisen palvelun asiakas saa vaatimatonta päivittäistä liikennettä. Yksimuuttujatestin ajaminen omin avuin veisi kuukausia merkityksellisen eron havaitsemiseen. Kirjoitat hypoteesin ja käytät tekoälykokeilua, joka jakaa liikenteen dynaamisesti. Muutaman päivän kuluttua järjestelmä näyttää yhden variantin karkaavan edelle ja ohjaa sille enemmän liikennettä. Saat vastauksen asiakkaan kampanjaikkunan sisällä. Hyväksyt, että tulos on vähemmän tilastollisesti puhdas kuin kuuden viikon klassinen testi. Tämä on järkevä kompromissi, ei myönnytys.

Huomaa myös, että "yksi muuttuja kerrallaan" -sääntöä voidaan löysätä, jos testaat radikaalisti uutta sivun osaa yhden napin sijaan. Koko sivun uudelleensuunnittelutesti voi muuttaa useita elementtejä, mutta hypoteesi on silti johdonmukainen: "Asettelu, joka on rakennettu hyötyjen ympärille, päihittää nykyisen ominaisuuslistan asettelun, koska käyttäjät valitsevat tulosten perusteella." Niin kauan kuin hypoteesi nimeää mekanismin, voit testata muutospaketin. Ole vain rehellinen asiakkaalle, ettet tule tietämään, mikä elementti aiheutti nousun.

4. Mitoita testi asiakkaan kalenterin mukaan, älä tilasto-oppikirjasi mukaan

Tilastollinen merkitsevyys ei ole maaginen numero, jonka avaat päivänä 21. Se riippuu perustason konversioprosentistasi, pienimmästä noususta, jonka sinun on nähtävä, ja liikennemäärästä, jonka voit ohjata testiin. Jokainen testausopas tässä aiheessa toistaa saman varoituksen: aja testiä, kunnes sinulla on riittävä otoskoko ja kesto, tai johtopäätöksesi on kohinaa.

Ennen kuin ajoitat testin, tee matematiikka selkokielellä. Arvioi asiakkaan nykyinen konversioprosentti ja pienin parannus, josta välität. Arvioi sitten, kuinka monta kävijää tarvitset kohtuulliseen luottamustasoon. Jos tämä määrä ei täyty ennen asiakkaan neljännesvuosikatsausta, sinulla on kolme vaihtoehtoa: leveämpi liikenteen jako, jotta saat enemmän ihmisiä testiin, hyväksy suurempi minimivaikutus, jonka liikenteesi voi tukea, tai muuta testi oppimiskokeeksi ilman luvattua "voittajaa".

Et tarvitse tohtorintutkintoa tähän. Käytä otoskokolaskuria. Syötä perustason prosenttiosuus, havaittava vaikutus ja haluamasi luottamus. Työkalu kertoo, kuinka monta kävijää tarvitset jokaista varianttia kohden. Jaa sitten asiakkaan odotetulla testiliikenteellä päivässä saadaksesi tarvittavan keston. Jos kesto ei sovi asiakkaan määräaikaan, säädä yhtä syötettä ennen kuin koskaan käynnistät testin. Tämä keskustelu on paljon halvempi kuin hukkaan heitetty kolmen viikon sykli.

Toimiva esimerkki: SaaS-asiakkaan ilmaisen kokeilun rekisteröitymissivu saa vaatimatonta mutta tasaista kävijävirtaa. Haluat havaita merkityksellisen parannuksen, ja otoskokoarvio näyttää, että testi tarvitsee paljon enemmän kävijöitä kuin asiakkaan liikenne tarjoaa käytettävissä olevassa ajassa. Asiakas tarvitsee vastauksen kuudessa viikossa hallituksen kokoukseen. Joten levennät jakoa 50/50:stä 90/10:een – mutta sekään ei vielä riitä. Sen sijaan lasket pienintä havaittavaa vaikutusta niin, että huomaat vain suuret voitot. Nyt testi on toteutettavissa aikataulussa, ja olet kertonut asiakkaalle tarkalleen, minkä testi voi ja ei voi havaita. Se on ammattilaisen liike.

Tarvitset myös lopetussäännön. Päätä etukäteen, kuinka kauan testi kestää ja mitä merkitsevyyskynnystä käytät. Älä koskaan anna kalenteripäivän olla ainoa syys lopettaa. Tiedä, milloin lopettaa kokeilu aikaisin tai pidentää sitä – harkintasi, ei mielivaltainen perjantai, saa tehdä päätöksen.

5. Estä asiakasta tappamasta testiä ennenaikaisesti

Tässä on tilanne, jonka olet elänyt: On tiistai, ja asiakas viestittää: "Testi on ollut aamulla. Julkaistaan voittaja nyt." Sinulla on yksi variantti, joka on edellä, mutta olet vasta saavuttanut vaaditun otoskoon. Asiakkaasi näkee voiton. Sinä näet kohinaa. Tämä on yleisin syy toimistojen testien epäonnistumiseen – ei huono matematiikka, vaan huono sidosryhmien hallinta.

Aseta pelisäännöt ennen testin alkua. Lähetä yhden sivun testibrief, jossa kerrotaan: ensisijainen mittari, suunniteltu otoskoko, aikaisin päivämäärä, jolloin katsot tuloksia, ja mitä sinulla on lupa muuttaa testin aikana. Pyydä asiakkaan hyväksyntä. Kun he kurkkivat, siitä tulee odotusten rikkomus, johon voit viitata, ei henkilökohtainen hylkäys. Tässä ei olla vastakkainasettelussa; kyse on kokeen eheyden suojelemisesta.

Suojaa myös testiympäristö. Kerro asiakkaalle, että muita sivuston muutoksia ei saa julkaista testin aikana. Mainospalkki, joka ilmoittaa käyttökatkoksesta testisivulla, viime hetken muutossuunnitelma toiselta toimittajalta tai jopa sosiaalisen median piikki voivat saastuttaa datasi. Heti kun jotain muuttuu testisi ulkopuolella, tulos on epäilyttävä.

Toimiva esimerkki: Asiakkaan kehittäjä julkaisee uuden faviconin testin puolivälissä. Sillä ei pitäisi olla väliä, mutta sen ei myöskään pitäisi tapahtua. Kirjaat sen ylös, merkitset aikaleiman ja tarkistat, muuttuvatko tulokset sen jälkeen. Jos muuttuvat, käynnistät testin uudelleen. Asiakkaat eivät usein ymmärrä, kuinka hauras tämä on. Sinun tehtäväsi on tehdä se selväksi testibriefissä, jotta he ottavat sen vakavasti.

Toinen yleinen asiakkaan liike on "meidän on käynnistettävä kampanja perjantaina, voitko lopettaa testin aikaisin?" Vastusta, ellei kampanja häiritse itse testiä. Jos lopetat aikaisin, saatat tehdä väärän päätöksen. Katso sen sijaan, voidaanko kampanjaa siirtää hieman tai testi siirtää sivulle, johon kampanja ei vaikuta. Testibriefisi on neuvottelutyökalusi. Käytä sitä kieltäytyäksesi kohteliaasti mutta lujasti.

Vielä yksi tapa: älä koskaan tarkista tuloksia testin aikana, ellet etsi teknistä vikaa. Ihmisaivot ovat huonoja todennäköisyyden kanssa. Sarja hyviä päiviä tuntuu todisteelta, mutta se on usein vain kohinaa. Jos sinua houkuttaa kurkistaa, avaa otoskokolaskuri. Muistuta itseäsi, kuinka paljon dataa vielä puuttuu.

6. Lue tulos tarinana, ei tuomiona

Testi päättyy. Variantti voittaa jälleen. Mutta "mikä nappi voitti" on vähiten hyödyllinen asia, jonka opit. Hyödylliset kysymykset ovat: Miksi se voitti? Päteekö selitys muihin sivuihin? Mitä opimme tästä yleisöstä, mitä emme tienneet aiemmin?

Tässä kohdassa useimmat toimistot pysähtyvät. He julkaisevat voittavan variantin, lähettävät asiakkaalle PDF:n ja siirtyvät eteenpäin. Se on menetetty mahdollisuus. Nolla tulos – kun variantti ei päihittänyt kontrollia – on silti tulos. Se kertoo, että yleisö ei välitä muuttujasta tai että alkuperäinen oli jo tarpeeksi hyvä. Dokumentoi oppiminen ja sovella sitä seuraavaan testiin. Parhaiden käytäntöjen oppaat korostavat jatkuvasti oppimisen dokumentointia jokaisen kokeen jälkeen; se muuttaa testauksen sarjasta kertaluonteisia projekteja kasvavaksi omaisuudeksi.

Toimiva esimerkki: Testaat suosituksen kuvan kanssa tavallista lainausta vastaan. Tavallinen lainaus voittaa. Tutkit miksi. Kuva näyttää lavastetulta; asiakkaan yleisö on skeptinen. Oppi ei ole "suosittelut eivät toimi". Se on "tämä yleisö haluaa aitoa, nimeämätöntä todistetta, ei viimeisteltyjä kuvia." Ensi kuussa toinen asiakas kysyy sosiaalisesta todisteesta. Tiedät jo, mitä heille ei pidä näyttää. Tämä on tarinana lukemisen ROI.

Tuloksen tulkinta ei ole vain p-arvon tarkistamista. Se on suunnan, suuruuden ja segmenttierojen tarkastelua. Jos et ole varma, voitko luottaa näkemääsi, palaa perusteisiin. Opas siitä, miten tulkita A/B-testituloksia oikein putoamatta kohinaan, pitää sinut rehellisenä.

Harkitse myös "mitä sitten" -testiä. Käännä mittari asiakkaan kielelle. Suuri suhteellinen nousu pienellä perustasolla voi tarkoittaa lähes olematonta liikevaihtoa, kun taas pieni nousu suuren liikenteen sivulla voi tarkoittaa suuria voittoja. Älä anna suhteellisen muutoksen sokaista sinua absoluuttiselta arvolta. Asiakasta kiinnostaa alimmalla rivillä oleva luku, ei luottamusväli.

Kun esität nollatuloksen, älä pyytele anteeksi. Esitä se datapisteenä. "Opimme, että otsikon pituus ei muuta konversiota tälle yleisölle. Se säästää meidät ajamasta tätä testiä uudelleen." Nollatulos on selkeä vastaus kysymykseen. Se ei ole epäonnistuminen.

7. Muuta jokainen tulos toistettavaksi säännöksi

Nyt viimeinen vaihe, ja se, joka erottaa testausta tekevän toimiston toimistosta, joka lyö vetoa sen puolesta. Kirjoita jokaisen testin jälkeen yhden sivun pelikirjamerkintä. Muotoile se johdonmukaisesti: asiakastyyppi, hypoteesi, tulos, suositus. Tallenna se paikkaan, josta jokainen voi hakea. Ennen kuin ajat uuden testin, hae pelikirjasta samankaltaista tilannetta. Huomaat usein, että olet jo oppinut sen, mitä olet oppimassa uudelleen.

Näin testauksesta tulee toimiston kilpailuetu. Asiakkaan A "alennuskenttä on hämmentävä" -löydös säästää sinut suunnittelemasta samaa virheellistä testiä asiakkaan B kassalle. Asiakkaan C "suosittelut eivät liikuta neulaa" vapauttaa sinut testaamaan jotain muuta. Pelikirja on omaisuus, jota todella myyt, et raportteja.

Tarkistuslista pelikirjamerkintää varten:

• Asiakkaan toimiala ja sivustotyyppi
• Testisivu ja testattu muuttuja
• Hypoteesi "Jos... niin... koska..." -muodossa
• Ensisijaisen mittarin tulos: voitto, tappio tai nolla
• "Miksi"-selitys, johon päädyit
• Yksi toimenpide, jonka toistaisit uudella asiakkaalla
• Yksi toimenpide, jota et koskaan kokeilisi uudelleen

Toimiva esimerkki: Kuntosovellusasiakas testaa ilmaisen kokeilun lomaketta, jossa on vain sähköpostikenttä, verrattuna lomakkeeseen, jossa on etunimi ja sähköposti. Yhden kentän versio tuottaa pienen mutta tasaisen voiton. Kirjoitat pelikirjamerkinnän: "Impulssivetoisten yleisöjen (kunto, ruoka) kohdalla minimoi pakolliset kentät alussa; kerää henkilötiedot myöhemmin." Kuusi viikkoa myöhemmin ateriapakettiasiakas kysyy pitkästä rekisteröitymislomakkeestaan. Haet pelikirjamerkinnän, suosittelet samaa vähennystä ja ajat testin luottavaisesti, koska tiedät todennäköisen lopputuloksen. Tämä on kasautuva vaikutus.

Lopuksi pidä kuukausittainen "oppimiskatsaus" tiimisi kanssa. Käy läpi, mitä olet oppinut kaikilta asiakkailta. Yhdistä merkinnät, jotka viittaavat samaan perusperiaatteeseen. Muuta nämä periaatteet tulevien testien ohjeiksi. Esimerkiksi, jos kaksi eri asiakasta näki korkeamman konversion yhden kentän lomakkeella, periaate "kysy mahdollisimman vähän tietoa ennen sitoutumista" on todennäköisesti totta heidän segmenteissään. Tämä periaate ohjaa nyt jokaisen uuden asiakkaan laskeutumissivusuositusta jo ennen testin ajamista.

Kehys toimii. Mutta se toimii vain, jos todella rakennat järjestelmän. Aloita yhdestä asiakkaasta. Sovella kaikki seitsemän vaihetta. Sovella niitä sitten seuraavaan asiakkaaseen ja anna pelikirjan tehdä yhä enemmän työtä. Lopetat kysymästä "mitä meidän pitäisi testata?" ja alat kysyä "mikä tunnettu sääntö pätee tässä?" Se on ero toimiston välillä, joka ajaa testejä, ja toimiston, joka toimittaa parempia tuloksia.