Jak przejść od zera do jednego w eksperymentalnej podróży po stronie serwera

Pomyśl o swojej podróży jako użytkownik Netflix. Jeśli jesteś podobny do mnie, popijając poranną kawę, możesz oglądać na telefonie dokument przyrodniczy. Kolacji może towarzyszyć ulubieniec z dawnych czasów, taki jak Forrest Gump na laptopie. Weekendowe wieczory spędzisz na przełączaniu się między Twoim profilem a profilem Twoich dzieci podczas wypróbowywania nowych programów Netflix, najlepiej na większym ekranie.

Załóżmy teraz, że Netflix prowadzi kampanię rabatową dla danego kraju. Jeśli bierzesz udział w tej kampanii eksperymentalnej prowadzonej przez Netflix, w jaki sposób zapewnią, że będziesz częścią tej samej kampanii za każdym razem, gdy się logujesz, niezależnie od urządzenia i profilu, z którego korzystasz, i wszędzie widzisz tę samą promocję? W jaki sposób zapewniają, że Twoje doświadczenia z wyświetlaną odmianą są za każdym razem bezproblemowe, a sposób, w jaki korzystasz z tej odmiany, jest konsekwentnie śledzony?

Odpowiedź tkwi w eksperymentach wielokanałowych, które są typowym przypadkiem użycia testowania po stronie serwera.

Czy wolisz testowanie po stronie serwera niż po stronie klienta?

Podany powyżej przykład Netflix byłby niezwykle skomplikowany do przeprowadzenia po stronie klienta i mógłby utrudnić użytkownikowi korzystanie z niego. Po stronie serwera jest stosunkowo łatwy w obsłudze i zapewnia użytkownikom spójne wrażenia. Zapewnia również minimalny wpływ na wydajność strony. Poza tym eliminuje wszelkie problemy związane z prywatnością, ponieważ nie ma żadnej aktywności w przeglądarce jako takiej.

Istnieją inne przypadki użycia, w których testowanie po stronie serwera jest zalecane ze względu na jego niezawodność i elastyczność. Porozmawiamy o nich w tym artykule. Ale najpierw, czym dokładnie jest testowanie po stronie serwera i, co ważniejsze, dla kogo?

W testach po stronie serwera odmiany testowe są przetwarzane na serwerze sieciowym. Gdy odwiedzający trafia na testowaną stronę, odmiana jest pobierana bezpośrednio z serwera i dostarczana do przeglądarki odwiedzającego. Żadne późniejsze modyfikacje nie są wtedy wykonywane w interfejsie użytkownika ani w przeglądarce. W przeciwieństwie do tego, w testach po stronie klienta oryginalna strona ładuje się najpierw w przeglądarce użytkownika, a Twoja platforma eksperymentalna tworzy odmianę samego interfejsu za pomocą JavaScript. Przyjrzyjmy się zakresowi tych dwóch form testowania na przykładzie.

Wyobraź sobie, że Mike i Bob to dwaj przyjaciele, którzy próbują poeksperymentować z działaniem nowego samochodu. Mike siedzi za kierownicą i ma dostęp do hamulców, pedału przyspieszenia, deski rozdzielczej i tym podobnych. Bob ma widok na wewnętrzne elementy, takie jak silnik, chłodnica, akumulator itp. Oba mogą w różny sposób wpływać na samochód. To, co Bob robi ze swoim dostępem do komponentów samochodu, może odbić się na Mike'u z zewnątrz. Zmiany, które testuje Mike, opierają się na jego widoczności samochodu. Z perspektywy nabywcy samochodu wyniki eksperymentów prowadzonych zarówno przez Boba, jak i Mike'a mogą służyć równie ważnym, ale innym celom.

Dlatego nie musisz wybierać jednej formy testowania nad drugą. Przypadki użycia są różne, a zespoły korzystające z narzędzi są różne. Testowanie po stronie serwera to ścieżka eksperymentów dla programistów i menedżerów produktów, podobnie jak testowanie po stronie klienta jest częściej wykorzystywane przez marketerów.

Jakie problemy można rozwiązać za pomocą testów po stronie serwera?

Testy po stronie serwera prowadzone przez zespoły produktowe rozwiązują problemy dotyczące wielu branż, od eCommerce i SaaS po bankowość i media. Poniżej opisano kilka ważnych przypadków użycia, w których testowanie po stronie serwera jest zalecane zamiast testowania po stronie klienta w różnych branżach:

Rekomendacja produktu

Który zestaw polecanych produktów zachęca odwiedzających do większych zakupów? Testowanie po stronie serwera umożliwia testowanie wielu algorytmów rekomendacji produktów w celu określenia wyboru, który prowadzi do wzrostu sprzedaży i przychodów. Możesz na przykład sprawdzić, czy układ promujący podobne produkty działa lepiej niż układ promujący te najpopularniejsze. Na podstawie wyników eksperymentu po stronie serwera możesz również zdecydować, czy chcesz sprzedawać więcej, czy sprzedawać krzyżowo.

Opłata przewozowa

Jaka jest idealna wartość koszyka, która powinna kwalifikować zamówienia do bezpłatnej wysyłki? Możesz przetestować różne progi, aby określić ten, który pozytywnie wpływa na decyzje zakupowe klientów.

Algorytmy wyszukiwania

Eksperymentowanie z algorytmem wyszukiwania wymaga modyfikacji istniejącego kodu i elastyczności w głębokim testowaniu. Chcesz, aby odwiedzający mogli szybko znaleźć to, czego szukają, i możesz przetestować swój algorytm wyszukiwania po stronie serwera, aby to osiągnąć.

Długość formularza

Bezpłatne formularze wniosków o wersję próbną i demo mają kluczowe znaczenie dla firm SaaS. Ale jaka jest idealna długość formularza, która zapewnia mniejsze porzucanie, a jednocześnie rejestruje wszystkie wymagane informacje? Pola nieobowiązkowe można przetestować za pomocą testów po stronie klienta. Jeśli twoje pole jest obowiązkowe, samo ukrycie go za pomocą JavaScript nie zadziała, ponieważ walidacja formularza za pomocą logiki po stronie serwera nie powiedzie się. Dlatego zaleca się testowanie po stronie serwera, aby poeksperymentować z obowiązkowymi polami, aby zoptymalizować długość i złożoność formularza.

Oferty i rabaty

Chociaż styl, wygląd i styl oraz umieszczanie ofert na stronie głównej można łatwo przetestować po stronie klienta, należy wziąć pod uwagę inne ważne czynniki, takie jak wartość rabatu, czas jego trwania lub kryteria kwalifikacyjne. Możesz przetestować po stronie serwera, aby określić optymalną wartość i upewnić się, że są one spójne we wszystkich kanałach dla konkretnego użytkownika.

Zachęty sprzedażowe

Testowanie dynamicznych zachęt, takich jak oferty na ograniczony okres lub wyprzedaże zapasów, wymaga elastyczności testowania po stronie serwera ze względu na stopień szczegółowości.

Przepływy subskrypcji

Ile etapów powinno być najlepiej zaangażowanych w proces subskrypcji? Czy należy podać loginy społecznościowe? Eksperymentowanie z przepływem subskrypcji może pomóc w znalezieniu odpowiedzi na te pytania.

Paywalle

Testowanie po stronie serwera pozwala testować różne konfiguracje paywall w niezawodny sposób. Jako wydawca możesz przeprowadzać testy po stronie serwera, aby poeksperymentować z treściami bramkowanymi i zarabiać na nich. Uruchamianie tego samego testu po stronie klienta nie jest zalecane, ponieważ odwiedzający mogą obejść paywall, usuwając lub rezygnując z plików cookie.

Bankowość mobilna

Wiele elementów można zoptymalizować w procesie rejestracji o pożyczkę lub kartę kredytową. Ale jeśli chodzi o bankowość mobilną, bezpieczeństwo danych staje się najważniejsze. W przypadku testów po stronie klienta wrażliwe dane gromadzone przez banki lub instytucje finansowe mogą być narażone na ryzyko podatności. Aby uniknąć tego ryzyka, w aplikacjach bankowych zwykle zaleca się eksperymenty po stronie serwera.

Pozwól nam teraz zrozumieć, w jaki sposób możesz uruchomić testy funkcji po stronie serwera i jakie są zalety takiego działania z VWO.

Jak VWO ułatwia testy po stronie serwera

W przypadku opisanych powyżej przypadków użycia po stronie serwera VWO zapewnia elastyczność w organizacji kampanii jako testów A/B lub testów funkcji. Testy funkcji służą do sprawdzania wartości parametrów funkcji i zapewniają kontrolę nad szybką konfiguracją funkcji bez pisania kodu. W niektórych przypadkach użycia, takich jak testowanie, który algorytm wyszukiwania jest lepszy, można zorganizować kampanię zarówno jako test A/B, jak i test funkcji.

Załóżmy na przykład, że chcesz ocenić trzech dostawców pod kątem algorytmu wyszukiwania, który zbudowali dla Twojej witryny.

Testowanie funkcji umożliwia menedżerowi produktu takiemu jak Ty szybkie testowanie i zakończenie przy minimalnej zależności od inżynierii i maksymalnej kontroli nad konfiguracją. Dzięki możliwościom testowania funkcji VWO otrzymujesz zestaw, w którym musisz pisać mniej kodu, ponieważ platforma wykonuje większość zadań za Ciebie. W przypadku testowania funkcji algorytm można zdefiniować jako zmienną funkcji i skonfigurować w celu kontrolowania i zmienności eksperymentu z samego przepływu konfiguracji platformy, aby sprawdzić, który algorytm wyszukiwania jest bardziej wydajny.

Ten eksperyment można również przeprowadzić za pomocą testów A/B po stronie serwera. VWO ułatwia dystrybucję ruchu i możliwości modelu statystyk eksperymentów za pośrednictwem swoich zestawów SDK po stronie serwera. Zespoły inżynierskie mogą używać tego samego do wstawiania kodu algorytmów wyszukiwania i testowania, które mają większy wpływ.

Oto kilka innych scenariuszy, w których przydatne jest testowanie funkcji. Załóżmy, że zewnętrzny dostawca obsługujący doładowania telefonów komórkowych chce obciążać użytkowników kwotą nominalną za każde doładowanie. Chcą przetestować odpowiednią kwotę za to samo. Lub firma taka jak Airbnb, w której opłatami za nieruchomości zajmuje się właściciel, chce doliczyć opłatę za sprzątanie i sprawdzić, czy wpłynie to na liczbę rezerwacji. Jest to typowy eksperymentalny przypadek użycia dla różnych firm, aby znaleźć najlepsze miejsce, w którym można wprowadzić opłatę za usługę bez wpływu na wskaźnik gwiazdy północnej. Może to być opłata za wygodę, opłata za obiekt, opłata za nosicielstwo, opłata za opakowanie lub coś podobnego.

Złożone przypadki użycia, takie jak ten opisany powyżej, są bardzo łatwe do przetestowania w VWO. Oto film instruktażowy, który pokazuje, jak szybko utworzyć funkcję opłaty za wygodę i przypisać jej wartość (w tym przypadku kwotę opłaty). Możesz powiązać swoją hipotezę dotyczącą określenia opłaty, która zwiększa przychody bez wpływu na liczbę rezerwacji, wybrać środowisko, w którym przeprowadzasz test, i włączyć swoje odmiany. Gdy to zrobisz, otrzymasz kod kampanii, który trafi na Twój serwer. Pozostaje tylko zdefiniować cele, które chcesz śledzić i segmentować odbiorców, jeśli chcesz – to wszystko, Twoja kampania jest gotowa.

Jeśli jesteś menedżerem produktu i widzisz na pulpicie nawigacyjnym, że odmiana 3 nie działa dla użytkowników; ma to negatywny wpływ na przychody, możesz go zabić, po prostu wyłączając odmianę w VWO. Jak pokazano na poniższym zrzucie ekranu, nie ma to wpływu na kod i nie wymaga wprowadzania jakichkolwiek zmian przez zespół inżynierów. Musisz ją wyłączyć, kliknąć „zapisz”, a odmiana przestanie otrzymywać ruch.

Zasadniczo kod należy zaimplementować tylko raz na kampanię.

Czy powinieneś zbudować lub kupić platformę do przeprowadzania testów po stronie serwera?

Zakończmy debatę na temat budowania kontra kupowania. VWO to nie tylko generator liczb losowych, który pokazuje różne odmiany różnym odbiorcom i rejestruje zdarzenia konwersji. VWO to kompletna platforma eksperymentalna z solidnym modelem statystycznym. Aby rozważyć, czy zbudować własny mechanizm testowania po stronie serwera, czy zainwestować w platformę taką jak VWO, należy wziąć pod uwagę trzy podstawowe czynniki:

1. Koszt posiadania

Nawet jeśli firmom uda się zbudować wymaganą infrastrukturę we własnym zakresie, nadal muszą nią zarządzać i skalować. Płacenie zespołom programistycznym za zbudowanie i utrzymanie silnika eksperymentalnego, takiego jak VWO, zamiast koncentrowania się na ich podstawowych zadaniach, prawdopodobnie będzie bardziej czasochłonne i kosztowne niż inwestowanie w VWO.

2. Łatwość użycia

Mógłbyś zbudować rozwiązanie, które pokaże pewną odmianę określonej grupie odbiorców – ale czy miałbyś łatwy w użyciu interfejs, którym mogą sterować nie tylko zespoły inżynierskie, ale także menedżerowie produktu? Jeśli nie, to kolejny bloker do uruchamiania testów po stronie serwera.

3. Intuicyjne raportowanie

Zazwyczaj rozwiązanie wewnętrzne daje podstawowe informacje, takie jak liczba odwiedzających i konwersje pochodzące z określonej odmiany. Potrzebujesz jednak wyniku istotnego statystycznie. Potrzebujesz, aby Twoje raporty były zasilane przez silnik statystyk Bayesa, taki jak VWO SmartStats. W tym właśnie tkwi luka – możesz zbudować podstawowe rozwiązanie, które jest trudne do utrzymania i możesz poświęcić czas i zasoby na rozszyfrowanie wartości p. Możesz też wybrać rozwiązanie takie jak VWO, w którym istnieje zespół zajmujący się jego utrzymaniem i skalowaniem, który spędził lata na algorytmie Bayesa, aby uzyskać łatwe do interpretacji wyniki. Pulpit nawigacyjny w aplikacji w VWO umożliwia nawet nietechnicznym członkom zespołu zrozumienie wyników; nie muszą polegać na zespole Analytics, aby śledzić eksperymenty lub tworzyć panele wyników — oszczędzając w ten sposób czas i obniżając koszty eksperymentów.

4. Bezbłędny mechanizm

Tworzenie własnego rozwiązania do testowania po stronie serwera może być podatne na błędy, a przy takiej skali błędy mogą nie być łatwe do wykrycia. Porównaj to z jakością platformy, z której korzystają globalne marki, a masz pewność, że szanse na wkradnięcie się błędów są znikome. Wszelkie błędy, jeśli w ogóle, są zgłaszane i naprawiane najwcześniej przez kompetentny zespół wsparcia dostępny dla Ciebie.

Poza tym, gdy inwestujesz w zarządzaną platformę, taką jak VWO, ważne najlepsze praktyki są wbudowane w produkt. Nie musisz się martwić usuwaniem wartości odstających z wyników, wizualizacją danych ani problemami wynikającymi z aktualizacji wersji.

Niezbędne funkcje do przeprowadzania złożonych testów po stronie serwera z zachowaniem integralności

Eksperymenty po stronie serwera mogą być bardzo owocne, jeśli są wykonywane poprawnie. Aby to zrobić, musisz mieć odpowiedni zestaw funkcji. Niektóre z nich przedstawiono poniżej:

1. Randomizacja odwiedzających w każdym teście — podczas testowania, gdy grupujesz odbiorców w kampanie, randomizacja odwiedzających musi być naprawdę losowa, a nie pseudolosowa.
2. Spójne środowisko wielokanałowe — chociaż grupowanie użytkowników musi być losowe, musisz również upewnić się, że jeden użytkownik doświadcza tych samych zmian za każdym razem, gdy się loguje, niezależnie od urządzenia, z którego korzysta. Eksperyment powinien być kontynuowany bez żadnych zakłóceń.
3. Wzajemnie wykluczające się kampanie — załóżmy, że przy ustalaniu, czy użytkownik powinien wziąć udział w teście, należy wziąć pod uwagę trzy czynniki. Mogą to być regularność użytkowania, niskie prawdopodobieństwo rezygnacji i strefa czasowa. Oprócz uwzględnienia tych zmiennych należy również określić wyłączność – w ilu testach może więc uczestniczyć użytkownik spełniający te warunki? Należy to określić w sposób, który nie prowadzi do wypaczenia danych i umożliwia przypisanie poprawy współczynnika konwersji do właściwej kampanii bez uprzedzeń.
4. Standardowa konwencja nazewnictwa — niezależnie od tego, czy konfigurujesz nową funkcję do przetestowania, czy flagę funkcji, musisz przestrzegać standardowej konwencji nazewnictwa, aby uniknąć pomyłek i przypadków inicjowania niewłaściwych funkcji lub testów.
5. Unikalne i bezproblemowe identyfikatory kampanii — należy użyć klucza alfanumerycznego, aby jednoznacznie zidentyfikować test w kodzie i uniknąć problemów na późniejszym etapie.
6. Wybór odpowiedniego środowiska — należy określić środowisko, w którym przeprowadzasz test — na przykład możesz wdrożyć test w środowisku pomostowym lub QA, aby zespół QA mógł zweryfikować eksperyment. Sprawdzenie poprawności testu ma kluczowe znaczenie dla jego powodzenia i powinieneś mieć możliwość wyboru odpowiedniego dla niego środowiska.
7. Logiczna alokacja ruchu – gdy prowadzisz wiele kampanii lub gdy masz ważne ogłoszenie o wydarzeniu, takie jak na przykład wyprzedaż z okazji Czarnego Tygodnia, nie musisz uwzględniać w teście całego zestawu odwiedzających lądujących na Twojej stronie. Należy wybrać procent ruchu, który ma zostać uwzględniony w kampanii testowej, a także sposób podziału tego ruchu na odmiany.
8. Obliczanie czasu do osiągnięcia istotności statystycznej — szacowany czas osiągnięcia przez test istotności statystycznej powinien być określony przez obecny współczynnik konwersji głównego celu i minimalną poprawę, jaką chcesz osiągnąć dzięki swoim odmianom. Powinna również uwzględniać 95% prawdopodobieństwa pokonania podstawowego współczynnika konwersji.

Oto niektóre z najlepszych praktyk i niezbędnych funkcji testowania po stronie serwera – rzeczywista lista jest znacznie dłuższa. Jak wspomniano wcześniej, możesz albo zbudować te możliwości we własnym zakresie, albo skorzystać z VWO, gdzie wykonujemy dla Ciebie pracę.

Podsumowując

Niezależnie od tego, czy jesteś programistą, czy menedżerem produktu, nie musisz ograniczać swoich pomysłów na testy. Możesz przeprowadzać złożone testy bez obawy o problemy z wydajnością lub prywatnością dzięki testom po stronie serwera i rozwiązywać rzeczywiste problemy, z którymi borykają się Twoi klienci. Możesz zoptymalizować każdy cyfrowy punkt styku, aby Twoi klienci korzystali tylko z tego, co najlepsze.

Jeśli korzystasz z platformy takiej jak VWO, złożoność testu nie przytłoczy Cię – ponieważ każde Twoje wejście w kampanię jest intuicyjne i stanowi dobrą praktykę, która napędza Twój test. Aby dowiedzieć się więcej o tym, jak z łatwością przeprowadzać testy po stronie serwera za pomocą VWO, poproś o demo z naszymi ekspertami ds. produktów.