Oavsett om du precis ska börja med A/B-testning eller vill hitta ett verktyg som bättre matchar dina behov så finns det några överväganden du behöver ta hänsyn till när du börjar jämföra alternativ. Vi har tidigare skrivit om hur man bör tänka när man väljer ett verktyg här: Vilket A/B-testverktyg är bäst – för dig?
Men en av de huvudsakliga anledningarna till att vi blir involverade i att hjälpa till att utvärdera A/B-testverktyg är tekniska frågor, eller tekniska problem. Det kan finnas funderingar kring hur ett visst verktyg fungerar med ett visst ramverk, eller så har ett verktyg redan implementerats men fungerar inte som förväntat. Detta inlägg är en översikt över de vanligaste tekniska miljöerna som kan kräva särskild hänsyn vid val av verktyg.
Jag vill ha ett client-side-verktyg, behöver jag bry mig om den tekniska miljön?
En vanlig missuppfattning är att ett webb-experimentverktyg, eller client-sideverktyg, kommer att fungera oavsett miljö. Men det är också vanligt att man tror att en viss miljö kommer att göra det omöjligt att över huvud taget A/B-testa.
I grunden handlar det om att veta vilka resurser du kommer att behöva, och hur du hittar och implementerar ett verktyg som funkar.
Det där med Client-side och Server-side…
När man pratar om olika typer av A/B-testverktyg brukar man prata om att det finns två olika typer av verktyg, client-side och server-side. Dessa termer kan vara lite missvisande, eftersom client-side och server-side vanligtvis används för att beskriva var webbsidan eller applikationen renderas, dvs. var webbplatsens kod omvandlas till den visuella upplevelse man sedan ser på sidan, inte var A/B-testverktyget implementeras.
I detta blogginlägg kommer jag att använda Webb och Feature Experimentation för att beskriva de olika typerna av testverktyg, där webb-experimentverktyg refererar till verktyg som implementeras via en javascript-snippet och har en visuell editor där användare kan göra ändringar utan kod, medan Feature Experimentation används för att beskriva verktyg som implementeras i webbplatsens källkod – backend – och kräver utvecklingsresurser för att sätta upp tester.
Hur A/B-testverktyg for Web Experimentering funkar
Ett webb-experimentverktyg implementeras genom att man lägger till en JavaScript-snippet så högt upp i koden på varje sida som möjligt. När en sida sedan laddas i webbläsaren körs A/B-testverktygets kod, som då kontrollerar om det finns några aktiva experiment på den aktuella sidan. Det kollar också huruvida besökaren har en kaka med information om vilken version den sett vid eventuella tidigare besök. Om besökaren tidigare har sett en specifik version laddar verktyget samma variant som besökaren har sett tidigare.
Om besökaren inte har sett testet tidigare, tilldelar verktyget slumpmässigt en variant och utför testets ändringar på sidan. Ändringarna görs i webbläsaren med hjälp av JavaScript, som ändrar det befintliga innehållet eller injicerar nytt innehåll.
Verktyget måste anropas varje gång det behöver göra en ny utvärdering, vilket vanligtvis är vid varje ny sidladdning. Innehållet på sidan måste också vara tillgängligt för att ändras med JavaScript vid tidpunkten då verktyget kör testkoden. Det är på grund av detta som vissa av de nedanstående miljöerna kan innebära problem.
Fyra miljöer som kan vara problematiska
Här är några miljöer som kan påverka din möjlighet att använda ett webb-experimentverktyg, och vad du kan göra åt det.
- Single Page Applications (SPA)
- CSS-ramverk med dynamisk namngivning
- Static site generators / CDN Cachning
- Shadow DOM
Single Page Applications (SPA)
En Single Page Application är en webbapplikation eller webbplats som dynamiskt skriver om den aktuella sidan i webbläsaren istället för att hämta helt nya sidor från servern.
Eftersom webb-experimentverktyg vanligtvis körs varje gång en ny sida laddas in i webbläsaren innebär detta att verktyget kanske inte triggas igen när sidan uppdateras ifall det inte sker någon ”hård sidladdning”. Då kommer inga experimentändringar att läggas till eller tas bort.
De flesta webb-experimentverktyg har någon form av inbyggt stöd för SPA:er, många kan till exempel automatiskt upptäcka ifall URL:en uppdateras, även när det inte sker en hård sidladdning. Men om det inte sker någon ändring av URL:en när en ny sida eller sidvy laddas på din sajt, så behöver du titta på vad verktyget har för stöd för detta. En del verktyg har funktionalitet för att aktivt lyssna efter förändringar på sidan, andra har specifika aktiveringsevent som du behöver implementera för att trigga verktyget vid varje virtuell sidvisning.
SPA:er kan också påverka möjligheten att använda en visuell editor. För att undvika flicker (d.v.s. när användaren hinner se originalinnehållet blinka till innan varianten laddas), behöver verktyget laddas in på sidan så tidigt som möjligt, bland det första som laddas. Samtidigt behöver de element som du vill ändra på ha laddats in i webbläsaren när verktyget genomför teständringarna. I Single Page Applications är det vanligt att innehåll laddas dynamiskt, ibland efter att verktyget redan har försökt utföra alla teständringar. I det fallet kommer du kanske kunna se dina ändringar i den visuella editorn, men inte live på sidan.
Om ditt experimentverktyg inte har funktionalitet för att upptäcka uppdateringar på sidan kan du behöva någon med kunskaper i JavaScript för att kunna skriva tester.
För att ta reda på om du behöver tänka på stöd för SPA:er när du väljer verktyg, svara på dessa frågor:
- Är din webbplats en Single Page Application?
- Vilka delar av webbplatsen är byggda som en Single Page Application?
- Har du virtuella sidvisningar, och finns det i så fall platser på sajten där URL:en inte uppdateras även om en ny vy/sida visas?
Vad du kan göra åt det:
- Se till att ditt verktyg har stöd för SPA:er, antingen genom att ha funktionalitet för att observera DOM-ändringar eller möjlighet att trigga verktyget genom att implementera specifika aktiveringsevent.
- Se till att vertyget har en kod-editor så att ni kan skriva tester med JavaScript ifall ni inte kan använda den visuella editorn.
CSS-ramverk med dynamisk namngivning
Webbexperimentvertyg gör ändringar genom att skriva om sidans innehåll med JavaScript. För att det ska vara möjligt så behöver vi berätta vilka specifika element vi vill göra ändringar på. Detta görs med hjälp av selektorer.
Säg att du har en call-to-actionknapp på din sida. HTML-koden för knappen skulle kunna se ut som på bilden nedan.
I det här fallet kan vi välja knappen med hjälp av flera olika selektorer.
- Använder vi elementtypen, a, skulle ändringen göras på alla länkar (<a> element) på sidan om vi inte är mer specifika.
- Klassen, primary-button, skulle göra ändringen på alla element som har samma klass, i det här fallet alltså alla knappar som ser ut som en CTA.
- ID är unikt för ett enskilt element, i det här fallet skulle ändringen göras endast på den specifika knappen med ID ”contact-button”.
Om selektorn för ett element som vi vill ändra byts ut på sidan under testet kommer testet att gå sönder, och ändringarna inte visas.
Vissa CSS-ramverk använder dynamiskt genererade klassnamn som kan ändras varje gång applikationen uppdateras. Detta kommer att göra dem mycket instabila att använda i en visuell editor eller kodeditor. Om ni använder ett sådant ramverk på din sajt kommer du att behöva arbeta tillsammans med dina utvecklare för att lägga till specifika och tillförlitliga attribut eller klasser på de element du vill ändra, så att de förblir desamma under testet.
För att ta reda på om du kommer att påverkas av detta när du väljer verktyg, svara på dessa frågor:
- Använder din sajt den här typen av CSS-ramverk? (Till exempel Styled Components)
- Ändrar sig klassnamnen vid varje rebuild?
- Finns det några andra aspekter som kommer att göra det svårt att rikta in sig på specifika element baserat på klassnamn?
Vad du kan göra åt det:
- Arbeta tillsammans med dina utvecklare för att lägga till specifika och tillförlitliga attribut eller klasser som inte kommer att ändras under testet.
Static site generators / CDN Cachning
När man använder en generator för statiska webbplatser (Static Site Generator, exempelvis Gatsby), kan sajten byggas på en server eller lokalt på utvecklarens dator, och sedan cachas på ett Content Delivery Network, ett CDN. Ett CDN är ett nätverk av proxy-servrar som är geografiskt distribuerade för att öka prestanda och tillgänglighet. Så istället för att webbläsaren skickar en förfrågan till ursprungsservern, skickas istället en request till den proxyserver som är geografiskt närmast användaren. Eftersom sidan redan är färdigbyggd och inte behöver ”sättas ihop” varken i webbläsaren eller på servern, laddas den mycket snabbt.
Om delar av din webbplats är byggda med SSG kan sidan laddas så snabbt att det blir svårt att använda ett webb-experimentverktyg utan att få märkbart flicker, så du kan behöva göra speciallösningar för att kunna testa specifika komponenter på sidan.
Tre anledningar att undvika flicker:
|
En lösning på detta är utvecklarna får hjälpa till att dölja innehållet i den komponent som du vill testa – i både original och variant – och sedan använda JavaScript för att injicera rätt innehåll i båda varianterna med hjälp av A/B-testverktyget. Om utvecklarna sätter komponenten till en fast höjd kommer det att bli mindre innehåll som hoppar runt, och även om innehållet i den specifika komponenten laddar lite långsammare så kommer det att vara lika lång fördröjning i båda varianterna, och därmed ha mindre inverkan på testresultaten.
Alternativet är att leta efter ett verktyg som gör bucketing och ändringar på CDN-nivå (”On the Edge”).
Notera att denna typ av miljö också påverkar valet av Feature experimentverktyg. Många feature experimentlösningar kräver ett anrop till en server för att göra bucketing, men i vissa fall kanske denna arkitektur inte har en server.
För att ta reda på om du behöver tänka på detta när du väljer verktyg, svara på dessa frågor:
- Är några delar av webbplatsen byggda med en generator för statiska webbplatser?
- Vilka delar av webbplatsen är statiska/cachade på ett CDN?
- Vilken typ av innehåll är cachat? Hela sidor eller bara delar?
- Feature Experimentation: Använder ni en origin server?
Vad du kan göra åt det:
- Se över vilka alternativ din A/B-testleverantör erbjuder, men prata också med dina utvecklare för att se vad som är genomförbart från deras perspektiv.
- Samarbeta med dina utvecklare för att dölja innehållet i de komponenter du vill testa, både i original och variant. Ställ in en fast höjd för att begränsa att innehåll hoppar runt (content layout shift). Ladda sedan rätt innehåll beroende på vilken variant användaren tilldelas.
- Överväg att använda dynamiskt innehåll där du behöver kunna A/B-testa.
- Leta efter ett verktyg som gör bucketing på Edge.
Shadow DOM
Shadow DOM är en webbstandard utformad för att inkapsla och avgränsa CSS och JavaScript i webbkomponenter. Det innebär att utvecklare kan skapa isolerade DOM-träd som inte kan påverkas av CSS eller JavaScript från andra delar av webbsidan, vilket förhindrar att stil eller beteende från olika delar av en webbapplikation oavsiktligt påverkar varandra. Tänk att du har en del av sajten i en låda, och du kommer bara åt att måla lådans utsidan, inte innehållet i lådan.
Eftersom webb-experimentverktyg använder Javascript och CSS för att ändra sidan, kan det vara svårt eller omöjligt att använda en visuell editor eller kodeditor för att ändra något inom en Shadow DOM-komponent, eftersom den blockerar innehållet från att påverkas av extern CSS och JavaScript.
ShadowDOM kan vara ”öppen” eller ”stängd”. Öppen Shadow DOM innebär att elementen inuti den fortfarande är åtkomliga med JavaScript, men inte ren CSS. Det blir därför svårare att lägga till stilregler med CSS. En stängd ShadowDOM innebär att elementen inuti den inte ens är åtkomliga med JavaScript.
Vissa verktyg som har inbyggt stöd för Shadow DOM så länge den är öppen, och har du en resurs med JavaScriptkunskap så kan du använda en kodeditor även om den visuella editorn inte skulle funka. Men om många av de element som du kommer att vilja testa på finns inom en stängd Shadow DOM så kommer du inte att kunna använda varken en visuell editor eller kodeditor, utan kommer att behöva göra ändringarna inuti kodbasen istället.
För att ta reda på om du behöver tänka på detta när du väljer verktyg, svara på dessa frågor:
- Använder ni Shadow DOM på sajten?
- Vilka delar av sajten? Är det begränsat till vissa komponenter eller större delar av webbplatsen?
- Stängd eller öppen Shadow DOM? Om den är öppen har vissa verktyg stöd för att få den visuella redigeraren att fungera. Om den är stängd kommer du inte att kunna använda ett webbaserat A/B-testverktyg för att ändra dessa komponenter/områden av webbplatsen utan behöver backend-utveckling.
Vad du kan göra åt det:
- Kontrollera om A/B-testverktyget har stöd för Shadow DOM
- Använd kodeditorn istället för den visuella editorn om du har resurser med JavaScript-kunskap.
- Om du har closed Shadow DOM på stora delar av sajten, överväg att göra feature-testning istället
- Låt utvecklare koda två versioner av komponenten. Använd sedan A/B-testverktyget för att lägga till ett attribut med olika värden för original och variant till ett element som är överordnat Shadow DOM-komponenten, och använd det för att ladda de olika varianterna.
Det finns en lösning
I de flesta fall finns det lösningar; det handlar bara om att hitta rätt verktyg och ha rätt resurser. Genom att titta på frågorna i denna guide kan du säkerställa att du lägger dina pengar och din tid på en lösning som faktiskt fungerar för din webbplats. Då blir du också förberedd på eventuella specifika insatser som behövs vid implementering, eller vilket internt samarbete som behövs för att genomföra testningen.
Och om du någonsin behöver hjälp, tveka inte att kontakta oss
