Ügyfélbiztos A/B tesztelési keretrendszer: 7 lépés, amely bármely ügyfélnél működik

Összefoglaló

Az ügynökségek szigorúbb feltételek között futtatnak A/B teszteket, mint az egytermékes csapatok: több ügyfél, szoros határidők és szétszórt mérőszámok. Ez a cikk egy ismételhető keretrendszert ad, amely bármely fiókon működik, kezdve egyetlen valódi konverziós cél meghatározásával. Megtanulod, hogyan találd meg a súrlódási pontokat ahelyett, hogy az érintettek véleményét kergetnéd, hogyan írj prediktív hipotéziseket, és hogyan válassz az univariáns, multivariáns és AI-alapú kísérletek között. Kitér a pragmatikus mintanagyság-tervezésre, arra, hogyan akadályozd meg az ügyfeleket a teszt korai leállításában, és hogyan olvasd az kétértelmű eredményeket, ahogy egy tanácsadó tenné. Az utolsó lépés, hogy minden sikert és kudarcot egy playbookba csomagolj, ami felgyorsítja a következő ügyfél tesztelési ciklusát. Használd ezt a struktúrát a pazarló hetek elkerülésére, és alakítsd a tesztelést az ügynökséged versenyelőnyévé. Ha a tesztelést rendszerként kezeled, nem pedig egyszeri kérések sorozataként, minden fióknál nem kell újra feltalálnod a spanyolviaszt.

Hétfő reggel 9:47. Egy ügyfél e-mailben kér egy „gyors A/B tesztet" az árazási oldalára. Három másik fiókod is futásban van, mindegyik más analitikai beállítással, más jóváhagyási lánccal és más „győzelem" definícióval. A gyors tesztnek három hét kell a statisztikai szignifikanciához. Ezt már tudod. Így megtoldod a határidőt, beállítod az elvárásokat, és lefuttatod a tesztet. Aztán a hét felét azzal töltöd, hogy megvéded.

Ez nem tesztelési probléma. Ez rendszerprobléma. Ha minden ügyfélnek újra kell feltalálnod a tesztelést, nem vagy optimalizációs partner – tesztvégrehajtó vagy. A következő egy hét lépésből álló keretrendszer, amely bármely ügyfélnél, bármilyen eszközzel, bármilyen forgalmi szinten működik. Használd gyorsabb, okosabb tesztciklusokhoz, amelyek fiókról fiókra halmozódnak.

1. Rögzíts egy siker-mutatót, mielőtt bármihez hozzányúlnál

Az A/B tesztelés az Optimizely szószedete szerint véletlenszerűen osztja szét a közönségedet, és minden csoportnak egy-egy másik oldalváltozatot mutat. Ez a véletlenszerű felosztás adatokat generál. De az adatok csak akkor jelentenek valamit, ha tudod, mit mérsz. A legtöbb ügyfél azt mondja, „több konverziót" szeretne – de a konverzió lehet regisztráció, vásárlás, demó-kérés, vagy akár a láblécig görgetés is. Ha nem rögzítesz egy metrikát, minden eredmény, amit visszahozol, újraértelmezhető lesz.

Minden együttműködést egy 15 perces cél-audittal kezdj. Kérdezd meg az ügyfelet: „Melyik egyetlen művelet, ha megduplázódna, sikeressé tenné ezt a negyedévet?" Ezután alakítsd ezt a választ elsődleges mutatóvá. Használd a teszt sikerességi kritériumaként. Minden más – visszafordulási arány, oldalon töltött idő, másodlagos kattintások – korlát-mutató lesz, amit figyelsz, de nem optimalizálsz rá.

Légy könyörtelenül konkrét. Ha az ügyfél azt mondja: „leadek", határozd meg, mit jelent a lead. A lead lehet űrlap beküldése, de lehet telefonhívás, élő chat vagy letöltés is. Minden definíció megváltoztatja, hogy melyik oldalelemet teszteld. Az űrlap-beküldési cél az űrlap hossza és a súrlódás felé mutat. A telefonhívás-cél az optimalizálást a hívásra kattintás elhelyezésére és a bizalmi jelekre összpontosítja. Ha ebben nem egyeztetek az elején, rossz oldalt fogsz optimalizálni.

Kidolgozott példa: Egy B2B ügyfél „több leadet" szeretne. Megkérdezed, mi a lead. Azt mondják: „minősített potenciális ügyfelek". Ez nem mérhető. Leszűkíted arra, hogy „üzleti e-mail címmel történő űrlapbeküldés". Most már van elsődleges mutatód. Amikor később egy új főcímet tesztelsz, csak e mutató alapján ítéled meg. Azt is elkapod, ha valaki a jobb visszafordulási arány alapján próbál győzelmet hirdetni. Ez a tisztaság óráknyi vitától kímél meg.

Ha megvan az elsődleges mutató, írd le a teszttervbe. A terv egy mondatban mondja ki: „Ezt a tesztet a [mutató] alapján ítéljük meg." Oszd meg minden érintettel. Amikor később egy VP azt mondja: „hát, az elköteleződés javult", mutass a tervre. Te nem mozdítottad a célvonalat. Megállapodtatok benne.

Ez az a pont is, ahol elválasztod a jelet a zajtól. Tudni, hogy mely tesztek számítanak a legjobban, a csata fele. A költségvetést a bevételt leginkább mozgató tesztekre költeni az teszi hatékonnyá az ügynökséget.

2. Súrlódást keress, ne preferenciákat

Az ügyfelek átadnak neked egy listát a „tesztekről, amelyeket le akarunk futtatni", amik valójában vélemények. „A gomb legyen zöld." „A címsor említse meg a díjunkat." Te nem futtatod ezeket. Olyan teszteket futtatsz, amelyek csökkentik a súrlódást vagy növelik a bizalmat. A CRO-playbookok ugyanazokra a karokra mutatnak: a hívásfelhívás (CTA) egyértelműsége, az űrlap hossza, az elrendezés tisztasága, a társas bizonyíték és a bizalmi jelek.

Ezeket a karokat úgy találod meg, hogy megnézed, hol lépnek ki a felhasználók az ügyfél oldalán. Állíts be munkamenet-rögzítést vagy alap eseménykövetést, ha még nincs. Figyelj meg legalább öt valós felhasználói munkamenetet ügyfelenként. Ne hagyatkozz az ügyfél véleményére arról, „mit fognak szeretni a felhasználók". Az adatok felülírják a véleményt.

Gyakori súrlódási források, amiket érdemes felülvizsgálni:

• Az űrlapok túl sok vagy túl kevés adatot kérnek
• A CTA-k nem mondják ki egyértelműen a következő lépést (pl. „Tudj meg többet" vs. „Indíts ingyenes próbaverziót")
• Hiányzó bizalmi jelek az elköteleződési pont közelében (referenciák, garanciák, pénzvisszafizetési ajánlatok)
• Oldalak, amelyek lassan töltődnek mobilon
• Olyan utak, amelyek meglepő extra lépést tartalmaznak (pl. „regisztráció" majd „e-mail megerősítése" figyelmeztetés nélkül)

Kidolgozott példa: Egy e-kereskedelmi ügyfél pénztárában van egy 6 mezőből álló űrlap plusz egy opcionális „fiók létrehozása" jelölőnégyzet. Beállítasz egy munkamenet-rögzítést, és megnézel öt felhasználót. Ketten megpróbálják törölni az előre kitöltött kuponkódot, mert azt hiszik, kedvezményt ad. Egy elhagyja az oldalt a telefonszám mezőnél. A súrlódás nem az űrlap hossza; hanem a zavaros kuponmező. A teszted nem nagyobb gombot csinál. A kuponmezőt az utolsó ellenőrzési lépéshez helyezi. Ez egy megfigyelésből született teszt, nem véleményből.

Ehhez a több ügyfélre kiterjedő munkához építs egy megosztott súrlódás-naplót. Amikor egy felhasználó elakad az egyik ügyfél oldalán, jegyzed fel a mintát. Három héttel később ugyanezt a súrlódást látod egy másik ügyfél oldalán. Ez az ügynökséged privát kutatási könyvtára. Ez egy erős ajánlat is új ügyfeleknek: „Pont ezt a problémát láttuk a piaci szegmensetekben."

Ne állj meg az oldalon belüli viselkedésnél. Nézd a kilépési útvonalakat, hőtérképeket és űrlapmező-analitikát. A cél, hogy találj egy egyértelmű pontot, ahol a felhasználók lemorzsolódnak. Ez a pont a tesztváltozód. Ha nem találsz egyértelmű lemorzsolódást, futtass diagnosztikai tesztet: próbálj ki egy drasztikusan eltérő CTA-t, egy sokkal rövidebb űrlapot vagy egy gyökeresen más értékajánlatot. Az eredmény, még ha null is, megmutatja, hol van a közönség valódi ellenállása.

Tartsd naprakészen a súrlódás-naplót. Ha ismétlődő mintát látsz, jegyzed fel egy képernyőképpel és egy egysoros magyarázattal. Néhány hónap múlva a felhasználói kifogások katalógusa lesz, amely minden ügyfeledre alkalmazható. Ez a katalógus eladási pont: „Ezt a pontos kifogást már teszteltük a ti iparágatokban. Íme, mit tanultunk."

3. Írj olyan hipotézist, amely megjósolja a „miértet", nem a „mit"

Egy jó teszt megválaszol egy kérdést: „Ha X-et teszünk, akkor Y fog történni, mert Z." A „mert Z" a hipotézis, és ez teszi átvihetővé az eredményt. „Miért" nélkül egy nyerő teszt semmit sem mond a következő ügyfélről.

Minden tesztet ezzel a „Ha... akkor... mert..." struktúrával fogalmazz meg. Ez arra kényszerít, hogy a mechanizmusról gondolkodj. „Rövidítsd le az űrlapot 5 mezőről 3-ra" átalakul így: „Ha lerövidítjük az űrlapot, akkor a kitöltési arány nőni fog, mert a felhasználók kevesebb erőfeszítést érzékelnek." Most már tudod, miért. Ezt a szabályt átviheted bármely ügyfélre, amelynek hosszú űrlapja van.

Most jön a fenntartás. Az általános bevett gyakorlat szerint egyszerre egy változót tesztelj. Ez a szabály jó okkal létezik: az izolált változók tiszta oksági magyarázatot adnak. De az ügynökségeknek ritkán van forgalmuk vagy idejük húsz különálló univariáns teszt futtatására. Az alacsony forgalmú fiókokhoz kompromisszum kell. Három lehetőséged van.

Megközelítés	Mikor a legjobb	Kompromisszum
Univariáns teszt	Nagy forgalmú oldal, egyetlen hipotézis, rendelkezésre álló idő	Legtisztább oksági történet, lassú
Multivariáns teszt	Közepes forgalom, több független változó	Gyorsabb, de összekeveredett interakciók
AI-alapú kísérlet	Alacsony forgalom, szoros határidő, gépi alkalmazkodás	Újabb eszközök, kisebb kontroll a variánsok felett

Ezt a harmadik opciót érdemes komolyan venni. Az Optimizely AI-kísérletekről szóló magyarázója olyan gépi tanulási rendszereket ír le, amelyek dinamikusan osztják el a forgalmat, és generálják helyetted a variánsokat. Ahelyett, hogy rögzített felosztást állítanál be és várnál, a rendszer megtanulja, melyik variáns nyer, és valós időben tereli rá a forgalmat. Ez két hét tesztet néhány napra tud összenyomni – némi módszertani tisztaság árán. Egy határidős ügynökségnek sokszor ez a fizetendő ár.

Nem biztos, melyik út illik az ügyfeledhez? A klasszikus és AI-vezérelt tesztelés közötti kompromisszumokat érdemes megérteni, mielőtt elkötelezed magad.

Így dönts: ha az ügyfélnek sok forgalma van és nyitott a határidő, használj univariáns tesztet. Ha közepes forgalma van és több lehetséges változtatás, futtass multivariáns tesztet a legígéretesebb kombinációkkal. Ha alacsony a forgalom és kemény határidő, válassz AI-alapú kísérletet, amely menet közben tud alkalmazkodni. Ne hagyd, hogy a „igazi tudomány" iránti preferencia elvakítson az ügyfél üzleti korlátaitól. A megfelelő teszt az, amelyik olyan döntést ad, amire a költségvetés elolvadása előtt tudsz lépni. Egy tökéletesen futtatott teszt, amely az ügyfél kampányának vége után ér véget, értéktelen.

Kidolgozott példa: Egy helyi szolgáltató ügyfél szerény napi forgalmat kap. Ha magad futtatnál egy univariáns tesztet, hónapokig tartana, amíg érdemi különbséget észlelnél. Írsz egy hipotézist, majd egy AI-kísérletet használsz, amely dinamikusan osztja el a forgalmat. Néhány nap múlva a rendszer azt mutatja, hogy az egyik variáns előrébb jár, és több forgalmat irányít rá. Választ kapsz az ügyfél kampányablakán belül. Elfogadod, hogy az eredmény kevésbé statisztikailag makulátlan, mint egy hathetes klasszikus teszt. Ez racionális csere, nem kompromisszum.

Vegyük észre azt is, hogy az „egyszerre egy változó" szabály lazítható, ha radikális új oldalszakaszt tesztelsz, nem pedig egyetlen gombot. Egy teljes oldal újratervezési tesztjében több elem is változhat, de a hipotézis akkor is koherens: „Az előnyfókuszú szövegre épülő elrendezés felülmúlja a jelenlegi funkciólista-elrendezést, mert a felhasználók kimenetek alapján döntenek." Amíg a hipotézis megnevezi a mechanizmust, tesztelhetsz egy csomó változtatást. Csak légy őszinte az ügyféllel, hogy nem fogod tudni, melyik elem okozta a növekedést.

4. Méretezd a tesztet az ügyfél naptárához, ne a statisztika-tankönyvedhez

A statisztikai szignifikancia nem egy varázsszám, amit a 21. napon nyitsz fel. Függ az alapkonverziós arányodtól, a minimális növekedéstől, amelyet látnod kell, és attól, hogy mennyi forgalmat tudsz a tesztre irányítani. Minden tesztelési útmutató ugyanazt a figyelmeztetést ismétli: fuss a teszttel addig, amíg elég mintanagyságod és időtartamod nincs, különben a következtetésed zaj.

Mielőtt ütemeznéd a tesztet, végezd el a matekot egyszerűen. Becsüld meg az ügyfél jelenlegi konverziós arányát és a legkisebb javulást, ami számít. Ezután becsüld meg, hány látogatóra lesz szükséged egy ésszerű megbízhatósági szinthez. Ha ez a szám nem lesz meg az ügyfél negyedéves felülvizsgálatáig, három lehetőséged van: szélesítsd a forgalmi felosztást, hogy több embert küldj a tesztre, fogadj el egy nagyobb minimálisan kimutatható hatást, amit a forgalmad elbír, vagy fordítsd a tesztet tanuló kísérletté, „nyerő" ígérete nélkül.

Ehhez nem kell PhD. Használj mintanagyság-kalkulátort. Írd be az alap arányt, a kimutatni kívánt hatást és a kívánt megbízhatóságot. Az eszköz megmondja, hány látogatóra van szükség variánsonként. Utána oszd el az ügyfél várható napi tesztforgalmával, hogy megkapd a szükséges futási időt. Ha ez a futási idő nem fér bele az ügyfél határidejébe, módosíts az egyik bemeneten, mielőtt egyáltalán elindítanád a tesztet. Ez a beszélgetés sokkal olcsóbb, mint egy elpazarolt háromhetes ciklus.

Kidolgozott példa: Egy SaaS-ügyfél próbaverziós regisztrációs oldala szerény, de folyamatos látogatóforgalmat kap. Érdemi javulást akarsz kimutatni, és a mintanagyság-becslésed azt mondja, hogy a teszt sokkal több látogatót igényelne, mint amennyit az ügyfél forgalma adni tud a rendelkezésre álló idő alatt. Az ügyfélnek hat héten belül kell választ adnia az igazgatótanácsi ülésre. Így szélesíted a felosztást 50/50-ről 90/10-re – de az még mindig nem elég. Ehelyett lejjebb viszed a minimálisan kimutatható hatást, hogy csak a nagy nyerőket fogd meg. Most már a teszt kivitelezhető az időkereten belül, és pontosan elmondtad az ügyfélnek, mit tud és mit nem tud a teszt kimutatni. Ez a profi húzás.

Szükséged van egy leállítási szabályra is. Döntsd el előre, meddig fut a teszt, és milyen szignifikancia-küszöböt használsz. Soha ne egy naptári dátum legyen az egyetlen ok a leállításra. Tudd, mikor állítsd le idő előtt a kísérletet, vagy hosszabbítsd meg – a te ítéleted, nem egy önkényes péntek döntse el.

5. Akadályozd meg, hogy az ügyfél idő előtt leállítsa a tesztet

Itt van egy jelenet, amit már átéltél: Kedd van, és az ügyfél azt írja: „A teszt ma reggel elindult. Most tegyük élesbe a nyertest." Van egy variáns, amely előrébb jár, de még csak a szükséges mintanagyság egy részét érted el. Az ügyfeled győzelmet lát. Te zajt látsz. Ez a leggyakoribb oka annak, hogy az ügynökségi tesztek kudarcot vallanak – nem a rossz matek, hanem a rossz érintett-menedzsment.

Határozd meg az alapszabályokat a teszt megkezdése előtt. Küldj egy egyoldalas teszttervet, amely tartalmazza: az elsődleges mutatót, a tervezett mintanagyságot, a legkorábbi dátumot, amikor megnézed az eredményeket, és hogy mit változtathatsz a futás során. Kérd az ügyfél jóváhagyását. Amikor „kukucskálnak", az egy elvárásszegés, amire hivatkozhatsz, nem pedig személyes elutasítás. Itt nem ellenségeskedésről van szó; a kísérlet integritásának védelméről.

Védd meg a tesztkörnyezetet is. Mondd meg az ügyfélnek, hogy a teszt futása alatt más oldalmódosítás ne kerüljön élesítésre. Egy kiesést bejelentő banner a tesztoldalon, egy másik szállító utolsó pillanatos dizájnmódosítása, vagy akár egy közösségimédia-kiugrás is beszennyezheti az adataidat. Abban a pillanatban, amikor valami változik a teszten kívül, az eredmény megkérdőjelezhető.

Kidolgozott példa: Az ügyfél fejlesztője egy új favicont tol élesítésre a teszt közepén. Nem szabadna számítania, de nem is szabadna megtörténnie. Naplózod, feljegyzed az időbélyeget, és megnézed, eltolódnak-e az eredmények azután a pont után. Ha igen, újraindítod a tesztet. Az ügyfelek gyakran nem értik, milyen törékeny ez. A te dolgod, hogy ezt egyértelművé tedd a teszttervben, hogy komolyan vegyék.

Egy másik gyakori ügyféllépés: „pénteken el kell indítanunk a kampányt, le tudod zárni idő előtt a tesztet?" Állj ellen, hacsak a kampány nem zavarja magát a tesztet. Ha idő előtt zárod le, rossz döntést kockáztatsz. Helyette nézd meg, hogy a kampány egy kicsit elhalasztható-e, vagy a teszt áthelyezhető-e egy olyan oldalra, amelyet a kampány nem érint. A tesztterved a tárgyalási eszközöd. Használd, hogy udvariasan, de határozottan nemet mondj.

Még egy szokás: soha ne nézd meg az eredményeket a teszt alatt, hacsak nem műszaki hibát keresel. Az emberi agy szörnyű a valószínűségben. Egy sor jó nap bizonyítéknak tűnhet, de gyakran csak zaj. Ha kísértést érzel, hogy kukucskálj, inkább nyisd meg a mintanagyság-kalkulátort. Emlékeztesd magad, mennyi adat még hiányzik.

6. Olvasd az eredményt történetként, ne ítéletként

A teszt véget ér. A variáns megint nyer. De az, hogy „melyik gomb nyert", a legkevésbé hasznos dolog, amit megtudtál. A hasznos kérdések: Miért nyert? Ez a magyarázat más oldalakra is érvényes? Mit fedeztünk fel erről a közönségről, amit korábban nem tudtunk?

Ez az a pont, ahol a legtöbb ügynökség megáll. Élesítik a nyertes variánst, elküldik az ügyfélnek a PDF-et, és továbblépnek. Ez egy elszalasztott lehetőség. A null eredmény – amikor a variáns nem győzte le a kontrollt – szintén eredmény. Megmondja, hogy a közönséget nem érdekli az a változó, vagy hogy az eredeti már eleve elég jó volt. Dokumentáld ezt a tanulságot, és alkalmazd a következő tesztben. A bevált gyakorlatok útmutatói következetesen hangsúlyozzák a tanulságok dokumentálását minden kísérlet után; ez az, ami a tesztelést egyszeri akciók sorozatából gyarapodó eszközzé változtatja.

Kidolgozott példa: Tesztelsz egy fotóval ellátott ajánlást egy egyszerű idézettel szemben. Az egyszerű idézet nyer. Ásva a miértekbe. A kép beállítottnak tűnik; az ügyfél közönsége szkeptikus. A tanulság nem az, hogy „az ajánlások nem működnek." Hanem: „ez a közönség hiteles, név nélküli bizonyítékot akar, nem kifényesített felvételeket." Jövő hónapban egy másik ügyfél a társas bizonyítékról kérdez. Már tudod, mit ne mutass nekik. Ez a történetként való eredményolvasás megtérülése (ROI).

Az eredmény értelmezése nem csak a p-érték ellenőrzése. Nézni kell az irányt, a nagyságot és a szegmensbeli különbségeket. Ha nem vagy biztos abban, hogy megbízhatsz-e abban, amit látsz, térj vissza az alapokhoz. Egy útmutató arról, hogyan értelmezd helyesen az A/B teszt eredményeit anélkül, hogy a zajnak bedőlnél, észben tart téged.

Vedd figyelembe a „na és" tesztet. Fordítsd le a mutatót az ügyfél nyelvére. Egy nagy relatív növekedés egy apró alapról szinte nulla bevételt jelenthet, míg egy kis növekedés egy nagy forgalmú oldalon óriási nyereséget. Ne hagyd, hogy a relatív változás elvakítson az abszolút értéktől. Az ügyfelet az alsó sorban lévő szám érdekli, nem a konfidencia-intervallum.

Amikor null eredményt mutatsz be, ne kérj elnézést. Keretezd adatpontként. „Megtanultuk, hogy a címsor hossza nem mozgatja a konverziót ennél a közönségnél. Ez megkímél minket attól, hogy újra lefuttassuk ezt a tesztet." A null eredmény egy kérdésre adott tiszta válasz. Nem kudarc.

7. Alakítsd át minden eredményt ismételhető szabállyá

Most jön az utolsó lépés, és az, amely megkülönbözteti azt az ügynökséget, amelyik tesztel, attól, amelyik fogad rá. Minden teszt után írj egy egyoldalas playbook-bejegyzést. Formázd következetesen: ügyféltípus, hipotézis, eredmény, ajánlás. Tárold olyan helyen, ahol mindenki tud keresni. Ezután, mielőtt bármilyen új tesztet futtatnál, keresd meg a playbookban a hasonló helyzetet. Gyakran azt fogod látni, hogy már megtanultad azt, amit éppen újra tanulnál.

Így válik a tesztelés az ügynökség versenyelőnyévé. Az A ügyfél „a kuponmező zavaró" megállapítása megkímél attól, hogy ugyanazt a hibás tesztet tervezd meg a B ügyfél pénztárához. A C ügyfél „az ajánlások nem mozgatják a mutatót" felszabadít arra, hogy mást tesztelj. A playbook az az eszköz, amit valójában eladsz, nem a riportok.

Playbook-bejegyzés ellenőrzőlistája:

• Ügyfél iparág és oldaltípus
• A tesztelt oldal és a változó, amit teszteltél
• A hipotézis „Ha... akkor... mert..." formában
• Az elsődleges mutató eredménye: győzelem, vereség vagy null
• A „miért" magyarázat, amelynél megállapodtál
• Egy művelet, amit egy új ügyfélnél megismételnél
• Egy művelet, amit soha többé nem próbálnál ki

Kidolgozott példa: Egy fitneszalkalmazás-ügyfél teszteli az ingyenes próbaverziós űrlapot egyetlen e-mail mezővel, szemben a keresztnév plusz e-mail formával. Az egy mezős verzió kis, de következetes győzelmet hoz. Megírod a playbook-bejegyzést: „Az impulzusalapú közönségeknél (fitnesz, étel) minimalizáld a kötelező mezőket az elején; a személyes adatokat később gyűjtsd." Hat héttel később egy ételcsomag-ügyfél kérdez a hosszadalmas regisztrációs űrlapjukról. Előveszed a playbook-bejegyzést, ugyanazt a rövidítést javaslod, és magabiztosan futtatod a tesztet, mert már ismered a várható eredményt. Ez a halmozódó hatás.

Végül tarts havi „tanulság-áttekintést" a csapatoddal. Nézd át, mit tanultatok minden ügyfélnél. Vond össze azokat a bejegyzéseket, amelyek ugyanarra az alapelvre mutatnak. Alakítsd ezeket az elveket jövőbeli tesztek irányelveivé. Például, ha két különböző ügyfél magasabb konverziót látott az egy mezős űrlapnál, az „kérj minimális adatot az elköteleződésig" elv valószínűleg igaz a szegmensükben. Ez az elv mostantól minden új ügyfél landing page-jének ajánlásába belejátszik, még mielőtt tesztet futtatnál.

A keretrendszer működik. De csak akkor működik, ha tényleg felépíted a rendszert. Kezdd egy ügyféllel. Alkalmazd mind a hét lépést. Aztán alkalmazd a következő ügyfélre, és hagyd, hogy a playbook egyre több munkát végezzen. Abbahagyod a „mit teszteljünk?" kérdést, és elkezded kérdezni: „melyik ismert szabály vonatkozik itt?" Ez a különbség az ügynökség között, amely teszteket futtat, és az között, amely jobb eredményeket szállít.