Förklaring av klientsidesbaserad testning och personalisering

Det här inlägget är en del av en serie i flera delar om olika tekniska metoder för A/B-testning och personalisering. I den här artikeln ger jag en djupgående analys av de viktigaste sakerna att tänka på när man implementerar experiment och kampanjer på klientsidan.

Tillvägagångssättet på klientsidan är den överlägset vanligaste lösningen som används på marknaden i dag. Med det här tillvägagångssättet genereras alla tester och upplevelser från klientsidans webbläsare med hjälp av Javascript. 

När en leverantör ber dig att placera deras Javascript-tagg(ar) i HTML-koden på alla sidor på din webbplats kan Javascript-baserade test- och personaliserings-SDK:er sedan injiceras på webbplatsen. Tillsammans med sina kärn-SDK:er bäddar leverantörer in kodrepresentationer av de kampanjer som du definierar i deras användargränssnitt. När taggarna väl finns på din webbplats kan leverantören köra all nödvändig logik för att testa och personalisera innehållet på dina sidor med hjälp av klientsides-Javascript.

Sidans modifieringsteknik är densamma hos alla leverantörer – en kodstump i SDK:n utför en åtgärd baserat på det önskade användningsfallet. 

Några exempel på rendering på klientsidan:

• Identifierar ett eller flera element på sidan via DOM-selektorer och kör sedan JavaScript-kod för att ändra dessa element. Exempel: dölj, ta bort, flytta, duplicera, ändra attribut, ändra CSS-format med mera
• Identifierar ett eller flera element på sidan via DOM-selektorer och kör sedan JavaScript-kod för att ersätta elementet eller elementen med nytt innehåll
• Identifierar ett eller flera element på sidan via DOM-väljare och exekverar sedan Javascript-kod för att infoga nytt innehåll före eller efter elementet/elementen
• Injekterar globala CSS-stilar på sidan och ändrar stilen på elementen på sidan
• Injicerar annan Javascript-kod på sidan, som kan användas för en mängd olika öppna användningsfall (t.ex. infoga ett tredjepartsbibliotek, göra en AJAX-begäran, anropa ett API osv.)

För att ge mer exakt kontroll över webbplatsens laddnings- och renderingsflöde erbjuder de flesta leverantörer dessutom en rad konfigurationer för att mer granulärt optimera laddnings- och körningsbeteendet för sina Javascript-SDK:er. 

Några av dessa inkluderar:

CDNs: Nästan alla leverantörer av testning och personalisering på klientsidan tillhandahåller sina Javascript-filer via innehållsleveransnätverk (CDN). CDN-nätverk optimerar nätverksleveransen av Javascript-filerna genom att spegla filerna på olika serverplatser och sedan optimera leveransvägarna när en användare gör en begäran. Vissa leverantörer gör det också möjligt att lagra deras filer på ett eget utvalt CDN, vilket ger era IT-team bättre kontroll över leverans och inläsning.

DNS-förhämtning: Eftersom de flesta leverantörer distribuerar sina Javascript-filer från ett annat värdnamn än din webbplats kan det ta lite extra tid för webbläsaren att matcha begäran om Javascript SDK-filer mot domännamnsservern (DNS). För att påskynda DNS-matchningsprocessen rekommenderar vissa leverantörer att förhämtningstaggar placeras före deras Javascript-taggar.

Taggplacering: För att erbjuda bästa möjliga upplevelse för era användare rekommenderas det nästan alltid att du placerar en leverantörs Javascript-taggar så högt upp i HTML-koden som möjligt, helst i head-sektionen. Detta gör att webbläsaren snabbt kan läsa in taggarna, vilket minimerar fördröjningen mellan att en sidas HTML-innehåll läses in och att leverantörens SDK gör sina ändringar på sidan. Om denna fördröjning inte minimeras resulterar det i en så kallad flimmer-effekt (flicker) – när en användare ser det serverrenderade innehållet, vanligtvis under millisekunder (eller, i värsta fall, sekunder), innan leverantörens SDK ändrar innehållet. Denna flimmereffekt anses allmänt vara skadlig för användarupplevelsen, eftersom den ofta förvirrar och frustrerar besökare.

Synkron inläsning: Som standard rekommenderar de flesta leverantörer att du ställer in att deras Javascript-taggar ska läsas in synkront för att undvika flimmer. Synkront inlästa Javascript-block hindrar webbläsaren från att rendera HTML-innehåll på taggens plats i HTML-koden. Vid en första anblick kan detta verka oönskat ur ett sidinläsningsperspektiv, men problem med sidinläsning är inte ett stort bekymmer för större leverantörer. Vanligtvis används en rad tekniklösningar, som CDN-användning, små filstorlekar, kodminimering, säkert utformad kod för att förhindra att sidan kraschar med mera, för att säkerställa mycket snabb och pålitlig filinläsning. Dessutom, som nämnts ovan, anser de flesta UX-designers att de försumbara skillnaderna i laddningstid för optimerad synkront inladdad Javascript är en värdig avvägning för att minimera flimmereffekter.

Asynkron inläsning: Du kan också ställa in en leverantörs skripttaggar så att de läses in asynkront. Asynkron inläsning förhindrar att webbläsaren blockeras vid rendering när den läser in leverantörens skript. Med andra ord kommer webbläsaren att rendera HTML-innehåll parallellt med inläsningen av leverantörens Javascript-filer. Fördelen med asynkron inläsning är att det inte påverkar sidans laddtider alls, men detta kommer till priset av en ökad risk för flimmer. För att minska detta kan leverantörer använda vissa stil- och renderingstrick för att förhindra att ett element visas förrän efter att leverantörens SDK har modifierat det. Till exempel kan du använda CSS för att dölja elementet initialt och sedan visa det igen när leverantörens SDK har laddats färdigt. Som ett annat exempel kan du vanligtvis undvika flimmer helt om dina test- och personaliseringsscenarier inte finns ovanför vecket, eftersom leverantörens JavaScript-SDK på de flesta anslutningar har lästs in när en användare hamnar nedanför vecket.

Vilken: synkron vs. asynkron? I slutändan finns det inget universellt rätt eller fel svar när det gäller synkron versus asynkron inläsning – det lämpliga valet beror på dina affärsprioriteringar. Om det är högsta prioritet att undvika flimmer bör synkron inläsning användas. Om det är högsta prioritet att minimera sidans inläsningstid bör asynkron inläsning användas. Med det sagt är effekterna på inläsningstiden och andra risker förknippade med synkron inläsning tillräckligt obetydliga vid användning av en stor leverantör för att synkron inläsning ska vara ett lämpligt tillvägagångssätt för de flesta webbplatser. 

Som en fusklapp för denna diskussion kan du titta på följande tabell:

Caching: De flesta leverantörer använder smarta cachelagringstekniker på sina Javascript SDK-filer, både på servernivå och webbläsarnivå. Cachelagring gör att leverantörens SDK i praktiken endast laddas ner vid den första sidvisningen eftersom SDK-filerna därefter cachelagras lokalt i webbläsaren. Det är dock värt att ha i åtanke att cacheminnets utgångsdatum vanligtvis är inställda på ett lågt antal minuter, vilket gör att du kan göra ändringar i dina test- och personaliseringskampanjer och skicka ut dessa ändringar till användarna i nära realtid. När cacheminnets utgångsdatum har passerat måste användarens webbläsare ladda ner leverantörens SDK på nytt vid nästa sidbegäran. Med det sagt är sessionstiderna för de allra flesta webbplatser inte tillräckligt långa för att detta ska vara ett märkbart problem för de flesta användare.

Leverantörer använder också en rad olika tekniker för att minska filstorleken på sina skript, till exempel minimering, borttagning av inbäddade bibliotek som inte är nödvändiga samt dynamisk borttagning av gamla eller oanvända experiment och personaliseringskampanjer med mera.

Utöver att enbart minska filstorlekarna implementerar vissa leverantörer tekniker för lazy loading (fördröjd inläsning) på dina test- och personalkampanjer så att endast de absolut nödvändiga kampanjerna läses in med SDK:t. I praktiken är de nödvändiga kampanjerna vanligtvis de som visas "above-the-fold" (synliga utan scrolling) på de mest populära sidorna på din webbplats. Andra kampanjer, som de som körs "below-the-fold" (nedanför den synliga ytan) eller utlöses av specifika händelser, markeras för lazy load. Denna användning av lazy loading minskar filstorlekarna och fördröjer nedladdningar till senare nätverksförfrågningar med mindre datamängder.

Klientbaserad rendering har Become alltmer populärt under de senaste åren, lett av bibliotek och ramverk som React och Angular. Eftersom de flesta A/B-tester och omnichannel-personaliseringsplattformar utvecklades före framväxten av klientbaserad rendering saknar de flesta leverantörer fortfarande bra stöd för klientbaserat renderade webbplatser (per början av 2020). 

För de få leverantörer som faktiskt erbjuder ”support” beskrivs deras tillvägagångssätt mer korrekt som tillfälliga lösningar snarare än robusta lösningar, och de har vanligtvis många funktionella begränsningar. 

Vanliga tillvägagångssätt omfattar:

• Utökade implementeringar som främjar aktivering av särskilda spårningsfunktioner på leverantörens SDK i takt med att sidans kontext ändras, vilket gör att leverantören kan hålla koll på webbplatsens livscykel. Detna tillvägagångssätt ger utvecklare full flexibilitet gällande när leverantörens SDK utför åtgärder, till priset av ökat implementeringsarbete och löpande underhållskod.
• Användning av klientsidans DOM-övervakningsfunktioner som Mutation Observer, vilket gör att leverantören automatiskt kan hålla reda på sidändringar utan att det krävs så mycket extra implementeringsarbete från teamets sida. Användningen av sådana funktioner är dock oftast inte robust; DOM-övervakningen kan vara opålitlig, särskilt om din webbplats har ett mer komplicerat renderingsflöde. 

Eftersom sökmotortrafik är en av de viktigaste besökstiderna för de flesta webbplatser vore det olämpligt att inte diskutera de potentiella riskerna med att använda dynamiskt JavaScript-genererat innehåll vid A/B-testning och optimering. Det är ett så viktigt ämne att vi har skrivit ett helt blogginlägg om SEO-påverkan av klientbaserad rendering. Där beskriver vi en serie experiment som vi genomförde, vilket till slut visade att Google faktiskt känner igen och indexerar dynamiskt, JavaScript-baserat innehåll.

När det gäller att jämföra den tekniska prestandan hos plattformar för klientsidestestning och personalisering är skillnaden mycket liten mellan dem. Alla klientsidesmetoder använder Javascript för att utföra sina funktioner, med taggar insatta i sidan enligt beskrivningen i de föregående avsnitten. 

Dessutom har branschen mognat till den grad att alla större leverantörer på området erbjuder liknande optimerings- och konfigurationsalternativ när det gäller Javascript-taggarna. De enda större skillnaderna i teknisk implementering mellan olika leverantörer brukar ligga antingen i data spårnings- och insamlingsmetoder eller i hur integrationen hanteras med ramverk för rendering på klientsidan. När man jämför leverantörer är det därför mycket viktigare att jämföra plattformarnas kärnfunktioner samt deras servicemodeller än prestanda.

Baserat på vår erfarenhet av att arbeta med kunder under de senaste 8 åren är detta de viktigaste tekniska aspekterna att tänka på när det gäller testning och personalisering på klientsidan. I nästa del av denna bloggserie kommer vi att utföra en liknande analys av testning och personalisering på serversidan.