Serversidestestning

Serversidestestning är experiment där varianttilldelning och variantrendering sker på servern innan svaret når webbläsaren. Besökaren får en fullständig markup för den version de tilldelades, utan att något klientsideskript skriver om sidan efter att den anlänt. Detta står i kontrast till klientsidestestning, där den ursprungliga sidan laddas först och ett testskript modifierar den i webbläsaren.

De tekniska fördelarna är betydande. Det finns inget flimmer eftersom besökaren aldrig ser originalet innan varianten visas. Det finns inget beroende av att JavaScript körs korrekt, så annonsblockerare, sekretessinställningar som blockerar skript och långsamma enheter förvränger inte exemplet. Det finns inget ytterligare renderingsblockerande skript, så experimentet försämrar inte sidhastigheten och stör därför inte sina egna resultat. Viktigast av allt är att varianten inte är begränsad till vad som kan manipuleras i DOM: serversidestester kan ändra prissättning, lagerlogik, sökrankning, rekommendationsmodeller, API-svar, affärsregler och allt annat som applikationen beräknar.

Kostnaderna är organisatoriska snarare än tekniska. Serversidestester kräver ingenjörskapacitet för att bygga varje variant, vilket innebär att experiment hamnar i utvecklingsbackloggen och konkurrerar med annat arbete. Vändtiden från idé till livetest mäts i sprintar snarare än timmar. Marknadsförings- och optimeringsteam förlorar den autonomi de har med visuella redigerare, och antalet experiment ett program kan köra under ett kvartal begränsas av teknisk dataflöde snarare än av trafik. Organisationer som byter till serversidestestning utan att justera sin planeringskadens ser vanligtvis att experimenthastigheten minskar kraftigt innan kvalitetsvinsterna blir synliga.

I praktiken kör mogna program båda. Klientsidestestning är fortfarande lämplig för text, layout, visuell hierarki och presentationsändringar som kan uttryckas säkert i webbläsaren och som marknadsföringsteam behöver iterera snabbt på. Serversidestestning är reserverad för allt som rör affärslogik, allt där flimmer skulle äventyra resultatet, allt på en högtrafikerad väg där prestandakostnaden för ett testskript är oacceptabel, och allt som behöver fungera konsekvent på webb, mobilapp och e-post. Att bestämma vilken kategori ett test tillhör är en del av experimentdesignen snarare än en plattformsomfattande policy.

Serversidestestning förändrar också vad analyslagret behöver göra. Eftersom tilldelning sker på servern måste variantidentifieraren skickas tillförlitligt till analys- och datalagerlagren för att göra analys möjlig, och den måste kopplas konsekvent till varje händelse nedströms, inklusive de som inträffar dagar senare i e-post eller i en mobilapp. Att få denna instrumentation rätt är vanligtvis den svåraste delen av migreringen, och att göra fel producerar experiment vars tilldelning är tekniskt sund men vars resultat inte kan rekonstrueras.

Tillvägagångssättet utvidgar också experiment bortom webbplatsen till ytor som klientbaserade verktyg inte kan nå alls. Mobilapplikationer kan inte modifieras efter lansering utan en inlämning från butiken, så all experimentverksamhet inom dem måste drivas av serverstyrd konfiguration. E-postinnehåll, transaktionsmeddelanden, prissättningslogik, sökrankning och rekommendationsmodeller bestäms på liknande sätt av servern. När tilldelningen sker centralt kan samma experiment omfatta webb, app och meddelanden med konsekvent bucketing, vilket gör det möjligt för ett företag att testa en förändring av en kundupplevelse som helhet snarare än en kanals rendering av den. För organisationer vars kunder rutinmässigt växlar mellan kanaler är denna konsekvens inte en förfining: ett experiment som tilldelar en person en variant på webbplatsen och en annan i appen mäter ingenting tolkningsbart.

Eftersom förändringen involverar både ingenjörsarkitektur och hur optimeringsfunktionen fungerar, hanteras den vanligtvis som en gemensam övning. Infrastrukturen sitter hos produktutveckling, mätlagret med uppgifter analytics, och experimentets design och prioritering med CRO-tjänst funktion. För organisationer som driver storskalig handel är det den här kombinationen som gör det möjligt att testa de delar av upplevelsen som faktiskt genererar intäkter, snarare än bara de delar som råkar vara redigerbara i en webbläsare.