Szerveroldali tesztelés

A szerveroldali tesztelés olyan kísérletezés, amelyben a variánsok hozzárendelése és a variánsok megjelenítése is a szerveren történik, mielőtt a válasz elérné a böngészőt. A látogató teljes körűen kidolgozott jelölést kap a hozzárendelt verzióhoz, anélkül, hogy kliensoldali szkript írná át az oldalt a megérkezése után. Ez ellentétben áll a kliensoldali teszteléssel, ahol az eredeti oldal először betöltődik, és egy tesztszkript módosítja azt a böngészőben.

A technikai előnyök jelentősek. Nincs villódzás, mivel a látogató soha nem látja az eredetit, mielőtt megjelenik a variáns. Nincs függőség a JavaScript sikeres végrehajtásától, így a hirdetésblokkolók, a szkripteket blokkoló adatvédelmi beállítások és a lassú eszközök nem torzítják a mintát. Nincs további renderelést blokkoló szkript, így a kísérlet nem rontja az oldal betöltési sebességét, és így nem zavarja meg a saját eredményeit. A legfontosabb, hogy a variáns nem korlátozódik arra, hogy mit lehet manipulálni a DOM-ban: a szerveroldali tesztek megváltoztathatják az árazást, a készletlogikát, a keresési rangsorolást, az ajánlási modelleket, az API-válaszokat, az üzleti szabályokat és bármi mást, amit az alkalmazás kiszámít.

A költségek inkább szervezési, mint technikai jellegűek. A szerveroldali tesztek minden egyes variáns elkészítéséhez mérnöki kapacitást igényelnek, ami azt jelenti, hogy a kísérletek bekerülnek a fejlesztési várólistába, és versenyeznek más munkákkal. Az ötlettől az éles tesztig tartó átfutási időt inkább sprintekben, mint órákban mérik. A marketing- és optimalizálási csapatok elveszítik a vizuális szerkesztőkkel kapcsolatos autonómiájukat, és a program által egy negyedévben futtatható kísérletek számát a mérnöki áteresztőképesség, nem pedig a forgalom korlátozza. Azok a szervezetek, amelyek a tervezési ütem módosítása nélkül térnek át a szerveroldali tesztelésre, általában azt tapasztalják, hogy a kísérletek sebessége meredeken csökken, mielőtt a minőségbeli javulás láthatóvá válna.

A gyakorlatban az érett programok mindkettőt futtatják. A kliensoldali tesztelés továbbra is megfelelő a szöveg, az elrendezés, a vizuális hierarchia és a megjelenítési változtatások esetében, amelyek biztonságosan kifejezhetők a böngészőben, és amelyeket a marketingcsapatoknak gyorsan iterálniuk kell. A szerveroldali tesztelés minden olyan dologra van fenntartva, ami az üzleti logikát érinti, bármire, ahol a villogás veszélyeztetné az eredményt, bármire egy nagy forgalmú útvonalon, ahol a tesztelési szkript teljesítményköltsége elfogadhatatlan, és bármire, aminek konzisztensen kell működnie weben, mobilalkalmazásban és e-mailben. Annak eldöntése, hogy egy teszt melyik kategóriába tartozik, a kísérlettervezés része, nem pedig platformszintű szabályzat.

A szerveroldali tesztelés az analitikai réteg feladatait is megváltoztatja. Mivel a hozzárendelés a szerveren történik, a variánsazonosítót megbízhatóan át kell adni az analitikai és adattárház rétegekbe az elemzés lehetővé tétele érdekében, és azt minden további eseményhez következetesen csatolni kell, beleértve azokat is, amelyek napokkal később e-mailben vagy mobilalkalmazásban történnek. Ennek az eszköznek a helyes beállítása általában a migráció legnehezebb része, és a rossz hozzárendelés olyan kísérleteket eredményez, amelyek hozzárendelése technikailag megalapozott, de eredményei nem rekonstruálhatók.

A megközelítés a weboldalon túlra is kiterjeszti a kísérletezést olyan felületekre, amelyeket a kliensoldali eszközök egyáltalán nem érnek el. A mobilalkalmazások a megjelenés után nem módosíthatók áruházi beküldés nélkül, így a bennük végzett kísérleteket szerver által vezérelt konfigurációnak kell vezérelnie. Az e-mail tartalmat, a tranzakciós üzenetküldést, az árképzési logikát, a keresési rangsorolást és az ajánlási modelleket hasonlóan a szerver határozza meg. Miután a hozzárendelés központilag megtörténik, ugyanaz a kísérlet kiterjedhet a webre, az alkalmazásra és az üzenetküldésre is konzisztens csoportosítással, ami lehetővé teszi a vállalkozások számára, hogy az ügyfélélmény egészének változását teszteljék, ne pedig egyetlen csatorna megjelenítését. Azoknál a szervezeteknél, amelyek ügyfelei rutinszerűen váltanak a csatornák között, ez az állandóság nem finomítás: egy olyan kísérlet, amely egy személyt az egyik változathoz rendel a weboldalon, a másikhoz pedig az alkalmazásban, nem mér semmi értelmezhetőt.

Mivel a váltás mind a mérnöki architektúrát, mind az optimalizálási funkció működését érinti, általában közös feladatként közelítik meg. Az infrastruktúra a következővel van összekötve: termékfejlesztés, a mérési réteg a következővel: adatelemzés, valamint a kísérlet tervezése és rangsorolása a CRO szolgáltatás függvény. A nagymértékű kereskedelmet futtató szervezetek számára ez a kombináció teszi lehetővé a felhasználói élmény azon részeinek tesztelését, amelyek ténylegesen bevételt generálnak, ahelyett, hogy csak azokat a részeket tesztelnék, amelyek történetesen böngészőben szerkeszthetők.