A/B-testning och personalisering på klientsidan vs serversidan

Det här blogginlägget är del tre i en analys i flera delar om de olika tekniska metoderna för A/B-testning och personalisering. I del ett och två erbjöd vi en djupare analys av de viktigaste tekniska övervägandena vid implementering av rendering på klientsidan och serversidan. I det här inlägget kommer vi att jämföra de två på en övergripande nivå.

Eftersom webben har mognat med åren har det Become en viktig praxis inom marknadsföring att både experimentera med och personalisera de upplevelser som webbplatser erbjuder sina användare. Med tiden har leverantörer på området landat i två primära tillvägagångssätt för A/B-testning och personalisering:

• Klientsidan
• Serversida

Vi har sammanfattat definitionerna och skillnaderna mellan tillvägagångssätten nedan:

Tillvägagångssättet på klientsidan är den i särklass vanligaste lösningen 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å webbplatsen kan Javascript-baserade test- och personaliserings-SDK:er sedan injiceras på webbplatsen. Vid sidan av 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 finns på webbplatsen kan leverantören köra all nödvändig logik för att testa och personalisera innehållet på sidorna med hjälp av Javascript på klientsidan.

The page modification technique is the same across all vendors – a piece of code in the SDK performs an action based on the desired use case.

A few client-side rendering examples:

• 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 och så vidare

• Identifierar ett eller flera element på sidan via DOM-selektorer och kör sedan JavaScript-kod för att ersätta elementet/elementen med nytt innehåll

• Identifierar ett eller flera element på sidan via DOM-selektorer och kör sedan Javascript-kod för att infoga nytt innehåll före eller efter elementen

• Injekterar globala CSS-stilar på sidan och ändrar formateringen för element på sidan

• Injekterar 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.)

Medan traditionella klientsidesimplementationer anropar personaliseringstjänster från webbläsaren via Javascript, gör serverintegration det möjligt för organisationer att anropa personaliseringstjänsten innan sidan renderas, inifrån sin egen teknikstack.

Testning och personalisering på serversidan tillhandahålls vanligtvis av leverantören i form av ett REST API, som anropas från den renderande webbapplikationen (servern) innan sidan levereras. Förfrågningar och svar till REST API:er använder JSON-formatet för data, vilket är ett allmänt anpassat och effektivt sätt att representera data.

Vid ren serverbaserad integration interagerar din server säkert med en API Gateway, skickar detaljerna för sidbegäran och begär relevanta personaliseringsupplevelser.

Svaret är vanligtvis en JSON-nyttolast. Det är sedan anroparens ansvar att tolka svaret och agera utifrån det. Du måste också rapportera tillbaka eventuell interaktion med de valda upplevelserna eller viktiga händelser för användarna. Engagemang och händelser rapporteras på liknande sätt (POST till en API-slutpunkt) som personalisering.

Eftersom personalisering på serversidan sker i din webbapplikationsstack på back-end kräver en lyckad implementering noggrann design och utveckling av ert teknikteam.

Exempel på användningsfall för rendering på serversidan:

• Större strukturella ändringar på sidan
• Omdirigeringar av helsidor
• Säker åtkomst till backendsystem (prismodeller, lager i realtid)
• Förhandsrendera personalisering för Single Page Apps

Den långvariga debatten om testning på klientsidan kontra serversidan kretsar ofta kring bekvämlighet: vad är enklast att integrera och testa med?

Enligt det här mätvärdet är tävlingen inte ens i närheten av jämn. Testning på klientsidan, där klientsidig JavaScript-kod återger tester direkt i användarens webbläsare, överträffar med råge testning på serversidan när det gäller enkelhet. Rendering på klientsidan kan dock ofta krocka med befintlig teknik och nya ramverk, misslyckas med att nå önskad prestanda eller förhindra att varumärken expanderar samma kundupplevelse till andra kanaler.

Så även om servermetoden är betydligt mer komplex kompenserar det bredare utbudet av funktioner, djupare insikterna och den övergripande sofistikeringen för det som metoden saknar i form av enkelhet och smidighet. Det krävs ju en centraliserad lösning för att leverera genuint relevanta upplevelser under hela kundresan – en lösning som kan samla in alla datakällor och aktivera dem oavsett vilken kanal, enhet eller webbteknik som applikationen levereras från.

Valet av rätt tillvägagångssätt beror i slutändan på dina specifika behov, dina tekniska resurser och din långsiktiga vision. Om dina primära användare är marknadsförare och snabbhet är högsta prioritet är klientsidan sannolikt det bästa valet. Å andra sidan, om dina teknik- och FoU-avdelningar kommer att vara djupt involverade, eller om du planerar mer avancerade integrationer eller sådana som sträcker sig bortom det traditionella webben, kan serversidan mycket väl vara det rätta valet.

Enkelheten i API-konceptet innebär att du inte nödvändigtvis måste göra ett antingen/eller-val mellan server- och klientrendering för personalisering. Vissa moderna personaliseringsplattformar har funktioner för att implementera en hybridlösning där förrenderade tester och personaliseringsändringar på serversidan kan samexistera med traditionella tester på klientsidan, och där användarengagemang kan rapporteras direkt till leverantören från webbläsaren.

Amid the proliferation of A/B testing and personalization, marketers have more tools than ever at their fingertips. But when looking at the competitive landscape, adopting advanced solutions that offer holistic, cross-channel experiences is not a luxury anymore. Doing so is quickly becoming a must if you wish to continue to effectively engage your audience and meet your KPIs. Given that, it may be time to consider jettisoning client-side testing and migrating to the server.