Server-side testning

Server-side testning er eksperimentering, hvor både varianttildeling og variantgengivelse sker på serveren, før svaret når browseren. Den besøgende modtager fuldt udformet markup for den version, de blev tildelt, uden at et klient-side script omskriver siden, efter den ankommer. Dette står i kontrast til klient-side testning, hvor den originale side indlæses først, og et testscript ændrer den i browseren.

De tekniske fordele er betydelige. Der er ingen flimmer, fordi den besøgende aldrig ser originalen, før varianten vises. Der er ingen afhængighed af, at JavaScript udføres korrekt, så annonceblokkere, script-blokerende privatlivsindstillinger og langsomme enheder forvrænger ikke eksemplet. Der er intet yderligere gengivelsesblokerende script, så eksperimentet forringer ikke sidens hastighed og forvirrer derfor ikke sine egne resultater. Vigtigst af alt er varianten ikke begrænset til, hvad der kan manipuleres i DOM'en: server-side tests kan ændre prisfastsættelse, lagerlogik, søgerangering, anbefalingsmodeller, API-svar, forretningsregler og alt andet, som applikationen beregner.

Omkostningerne er organisatoriske snarere end tekniske. Server-side test kræver teknisk kapacitet til at bygge hver variant, hvilket betyder, at eksperimenter indgår i udviklingsefterslæbet og konkurrerer med andet arbejde. Omdrejningspunktet fra idé til live test måles i sprints snarere end timer. Marketing- og optimeringsteams mister den autonomi, de har med visuelle editorer, og antallet af eksperimenter, et program kan køre i et kvartal, er begrænset af teknisk gennemløb snarere end af trafik. Organisationer, der skifter til server-side test uden at justere deres planlægningskadence, ser normalt, at eksperimenthastigheden falder kraftigt, før kvalitetsforbedringer bliver synlige.

I praksis kører modne programmer begge dele. Klientsidetestning er fortsat passende til ændringer i tekst, layout, visuelt hierarki og præsentation, der kan udtrykkes sikkert i browseren, og som marketingteams skal iterere hurtigt på. Serversidetestning er forbeholdt alt, der berører forretningslogik, alt, hvor flicker ville kompromittere resultatet, alt på en sti med høj trafik, hvor performanceomkostningerne for et testscript er uacceptable, og alt, der skal fungere ensartet på tværs af web, mobilapp og e-mail. At beslutte, hvilken kategori en test tilhører, er en del af eksperimentdesign snarere end en platformomfattende politik.

Server-side test ændrer også, hvad analyselaget skal gøre. Fordi tildelingen sker på serveren, skal variant-id'et sendes pålideligt til analyse- og data warehouse-lagene for at muliggøre analyse, og det skal vedhæftes konsekvent til alle downstream-hændelser, inklusive dem, der forekommer dage senere i e-mail eller i en mobilapp. At få denne instrumentering rigtigt er normalt den sværeste del af migreringen, og at få den forkert producerer eksperimenter, hvis tildeling er teknisk forsvarlig, men hvis resultater ikke kan rekonstrueres.

Tilgangen udvider også eksperimentering ud over hjemmesiden til overflader, som klientsideværktøjer slet ikke kan nå. Mobilapplikationer kan ikke ændres efter udgivelsen uden en indsendelse fra butikken, så enhver eksperimentering i dem skal drives af serverstyret konfiguration. E-mailindhold, transaktionel beskedgivning, prislogik, søgerangering og anbefalingsmodeller bestemmes ligeledes af serveren. Når tildelingen sker centralt, kan det samme eksperiment spænde over web, app og beskeder med ensartet bucketing, hvilket giver en virksomhed mulighed for at teste en ændring af en kundeoplevelse som helhed i stedet for én kanals gengivelse af den. For organisationer, hvis kunder rutinemæssigt skifter mellem kanaler, er denne konsistens ikke en forfining: et eksperiment, der tildeler en person til én variant på hjemmesiden, og en anden i appen, måler intet fortolkeligt.

Fordi skiftet involverer både ingeniørarkitektur og hvordan optimeringsfunktionen fungerer, gribes det normalt an som en fælles øvelse. Infrastrukturen sidder sammen med produktudvikling, målelaget med dataanalyseog eksperimentdesignet og prioriteringen med CRO-tjeneste funktion. For organisationer, der driver handel i stor skala, er det denne kombination, der gør det muligt at teste de dele af oplevelsen, der rent faktisk genererer omsætning, i stedet for kun de dele, der tilfældigvis kan redigeres i en browser.