Testowanie po stronie klienta vs. Testowanie po stronie serwera: oba wygrywają.
Opublikowany: 2020-05-28
Jeśli chodzi o przeprowadzanie eksperymentów, optymalizatorzy mogą wybierać między testowaniem po stronie klienta i po stronie serwera.
Chociaż możesz przeprowadzić prawie każdy test po stronie klienta po stronie serwera i kilka lekkich eksperymentów zaplecza za pomocą testów po stronie klienta (przy użyciu eksperymentów z podziałem adresu URL lub przekierowaniem), nie będzie to tak wykonalne ani niezawodne, jak Ty. Podoba mi się… ponieważ dla każdej hipotezy tylko jedna z dwóch działa najlepiej .
A wybór właściwego wymaga starannego rozważenia. Przy dokonywaniu tego wyboru należy wziąć pod uwagę wiele aspektów. Przyjrzyj się wpływowi konfiguracji na szybkość i SEO, nakład pracy i wymagania czasowe związane z cyklem życia eksperymentu, cel eksperymentu i nie tylko.
Przyjrzyjmy się tym czynnikom i zobaczmy , jak testowanie po stronie klienta różni się od testowania po stronie serwera oraz jakie są zalety i wady każdego z nich.
Testowanie po stronie klienta vs. Testowanie po stronie serwera
Jaka jest różnica między testowaniem po stronie klienta a testowaniem po stronie serwera?
W testach po stronie klienta, gdy użytkownik zażąda strony, serwer ją dostarczy. ALE w tym przypadku narzędzie do eksperymentów implementuje część kodu JavaScript w przeglądarce użytkownika, aby zmienić treść dostarczaną przez serwer, tak aby użytkownik końcowy otrzymał odpowiednią odmianę na podstawie reguł kierowania. (Przeglądarka jest „klientem”).
Z drugiej strony w testach po stronie serwera, gdy użytkownik zażąda strony, serwer określa wersję do dostarczenia i dostarcza właśnie to. Twoje narzędzie do eksperymentów działa na serwerze, a nie w przeglądarce użytkownika.
Ponieważ testowanie po stronie klienta odbywa się tylko przy wykonywaniu kodu JS na poziomie przeglądarki, można za jego pomocą testować tylko elementy na poziomie powierzchni, takie jak układy, kolory i wiadomości. Niektórzy optymalizatorzy nazywają takie testy testami „kosmetycznymi”.
Byłoby to jednak dyskontowaniem testów po stronie klienta.
Testowanie po stronie klienta może wydawać się proste, ale ma dużą moc.
Łatwo jest odrzucić testy A/B po stronie klienta jako „łatwe testowanie”, które każdy może wykonać. Zgadzam się: to łatwe do wdrożenia. Czasami może to być tak małe, jak testowanie innego koloru lub kopii przycisku CTA.
Jednak niezależnie od tego, czy chodzi o to, czy o testowanie przeprojektowania lub odnowionej strony, testowanie po stronie klienta wpływa na wyniki firmy .
Co to jest testowanie po stronie klienta?
W skrócie: testowanie po stronie klienta oznacza, że optymalizacja odbywa się na poziomie przeglądarki. Na podstawie skonfigurowanych reguł kierowania przeglądarka odwiedzającego zmodyfikuje treść, aby dostarczyć zamierzoną wersję.
W tym studium przypadku firma SaaS wykorzystała Convert Experiences jako narzędzie do testowania A/B po stronie klienta, aby zwiększyć wzrost liczby potencjalnych klientów o 61% na swojej stronie głównej:
Oto kolejny eksperyment z testami A/B z wykorzystaniem Convert Experiences jako narzędzia do testowania po stronie klienta dla tej samej firmy SaaS na jej stronie cenowej, który doprowadził do 57% wzrostu liczby potencjalnych klientów:
Większość historii sukcesu optymalizacji konwersji, które widzisz w Internecie, to testy po stronie klienta, które z powodzeniem zoptymalizowały doświadczenie na poziomie powierzchni i odniosły duże sukcesy.
Testowanie po stronie serwera pozwala jednak przetestować więcej.
Kiedy musisz przetestować głębiej niż frontend, musisz przejść do testowania po stronie serwera.
Co to jest testowanie po stronie serwera?
Testowanie po stronie serwera to rodzaj eksperymentu, w którym serwer sieciowy określa wersję treści do dostarczenia. W testach po stronie serwera cała optymalizacja jest implementowana bezpośrednio na serwerach, a nie w przeglądarkach odwiedzających.
Spójrzmy na to z perspektywy z kilkoma scenariuszami.
Jeśli prowadzisz działalność eCommerce, możesz przeprowadzić eksperyment testów A/B po stronie klienta, aby dowiedzieć się, czy przeprojektowany pasek wyszukiwania może zwiększyć liczbę wyszukiwań w sklepie (i zwiększyć sprzedaż).
Jeśli jednak chciałbyś przetestować nowy algorytm wyszukiwania, który może przynosić trafniejsze wyniki wyszukiwania (i który w dłuższej perspektywie przyniesie większą sprzedaż), musisz przeprowadzić eksperyment testowania A/B po stronie serwera .
Jeśli zamiast tego prowadzisz firmę B2B SaaS, możesz przeprowadzić eksperyment po stronie klienta, aby określić, czy określony UVP działa lepiej na Twojej stronie głównej. Albo czy długa kopia mogłaby przewyższyć krótszą.
Jeśli jednak chcesz przetestować szybszy backend i sprawdzić, czy może poprawić retencję lub zaangażowanie, musisz przeprowadzić eksperyment po stronie serwera. Jeśli chcesz ponownie przetestować nową sekwencję wprowadzającą, musisz przeprowadzić eksperyment po stronie serwera. Ponieważ oprócz obsługi nowego przepływu pracy podczas wdrażania, testowanie po stronie serwera umożliwiłoby również zorganizowanie wielokanałowego eksperymentu obejmującego wiadomości e-mail, SMS-y i inne, które odbywają się na różnych urządzeniach.
Podobnie, jeśli prowadzisz firmę B2C SaaS, możesz przeprowadzić eksperyment po stronie klienta, aby dowiedzieć się, czy określony plan cenowy może działać lepiej niż inne.
Jeśli jednak chciałbyś przetestować lepszy silnik rekomendacji, musiałbyś przejść do testów po stronie serwera.
Jak możesz zrozumieć z różnych przypadków użycia testowania po stronie serwera, jest on bardziej nastawiony na tworzenie lepszych produktów niż na natychmiastowe konwersje. W przeciwieństwie do eksperymentów po stronie klienta, które koncentrują się na natychmiastowej sprzedaży lub konwersjach, eksperymenty po stronie serwera koncentrują się na optymalizacji produktu lub rozwiązania, tak aby wzrastała długoterminowa wartość klienta.
Można powiedzieć, że jeśli testowanie po stronie klienta jest przeznaczone dla marketerów, to testowanie po stronie serwera jest przeznaczone głównie dla zespołów produktowych i inżynierskich. Narzędzia do testowania A/B, takie jak Convert Experiences, oferują zarówno testy po stronie klienta, jak i po stronie serwera, aby uwzględnić zarówno zespoły marketingowe, jak i inżynierskie.
Wypróbuj bezpłatnie przez 15 dni!
Ponieważ testowanie tak głębokich zmian na poziomie produktu wymaga znacznie więcej niż prostej manipulacji JS w przeglądarce, nie może się to zdarzyć wewnątrz przeglądarki i należy się tym zająć na poziomie serwera.
Chociaż testowanie po stronie serwera ma swoje unikalne przypadki użycia, niektóre firmy używają go do przeprowadzania nawet testów kosmetycznych — testów, które działałyby idealnie bezbłędnie nawet po stronie klienta.
Często robią to, aby uniknąć „migotania” lub zjawiska „Flash of Original Content”. Migotanie ma miejsce, gdy narzędzie do eksperymentowania zmienia oryginalną zawartość obsługiwaną przez serwer po tym, jak użytkownicy końcowi już ją widzieli. Wyobraź sobie, że Twoi użytkownicy widzą określony nagłówek, a następnie widzą, jak błyskawicznie zmienia się na inny. (Tak, migotanie może poważnie wpłynąć na wrażenia użytkownika!)
Innym razem robią to dla lepszej szybkości. Chociaż testowanie nie spowalnia witryny ani nie powoduje poważnych problemów z wydajnością, dodaje sekundę lub dwie do postrzeganego wczytywania witryny. Po stronie serwera może to przyspieszyć.
Czasami firma może przeprowadzić eksperyment po stronie serwera zamiast po stronie klienta ze względu na kwestie prywatności lub bezpieczeństwa. Ponieważ kierowanie na odbiorców odbywa się na serwerze, a kod eksperymentalny znajduje się na serwerze podczas testów po stronie serwera, firmy uzyskują lepszą kontrolę nad aspektami prywatności i bezpieczeństwa.
Jednak wdrożenie eksperymentu po stronie serwera nie zawsze jest możliwe, zwłaszcza gdy po stronie klienta poradzi sobie równie dobrze.
Wdrażanie eksperymentów po stronie serwera
W testowaniu po stronie klienta potrzebujesz tylko ograniczonych zasobów projektowych i programistycznych, aby zbudować swoje eksperymenty i je wykonać. Nie będziesz ich nawet potrzebował, jeśli zmieniasz tylko tekst lub zmieniasz kolor przycisku. Wszystko, co musisz zrobić, to:
1. Zaloguj się do narzędzia takiego jak Convert.
2. Użyj edytora WYSIWYG i zbuduj wariacje.
3. Skonfiguruj eksperyment (ustaw warunki kierowania na odbiorców, czas trwania eksperymentu, wielkość i podział próbki, poziom ufności itp.)
Chwyć kod JS i dodaj go do swojej witryny.
I zrobione.
W przypadku utraty kontroli należałoby szukać pomocy programistycznej, aby wdrożyć zwycięską wersję.
Testowanie po stronie serwera nie jest jednak takie proste.
Tutaj będziesz musiał:
1. Stwórz swój eksperyment w Konwertuj doświadczenia
2. Opracuj i wdróż wszystkie odmiany swojego eksperymentu na swoim serwerze.
3. Zmapuj swoje doświadczenia wdrożone na serwerze w Konwertuj doświadczenia, używając kodu niestandardowego (używając identyfikatora eksperymentu, identyfikatorów odmian ustawionych w narzędziu do eksperymentowania i nie tylko).
W takich eksperymentach po stronie serwera kod musi informować serwer, którą odmianę ma pokazać bieżącemu użytkownikowi. Możesz użyć plików cookie, aby to ułatwić. Na przykład, aby zaimplementować test A/B po stronie serwera za pomocą Convert, musisz skonfigurować plik cookie z następującymi danymi:
Serwer odczyta Twój plik cookie i
podawaj odpowiednią wersję (i wszystkie kolejne sesje).
Ponieważ serwer określa, którą wersję wysłać do użytkownika, kierowanie odbywa się na serwerze (a nie wewnątrz przeglądarki, jak w przypadku testowania po stronie klienta). Twoja precyzja testowania będzie zależeć od tego, jak dobrze potrafisz zakodować warunki kierowania na serwerze. Dzięki testom po stronie klienta możesz laserowo kierować swoich odbiorców do wszystkich swoich doświadczeń.
Ponadto testowanie po stronie serwera może stać się bardziej złożone w konfiguracji wieloserwerowej, a także w przypadku konieczności zintegrowania sieci CDN.
4. Uruchom eksperyment.
5. Rozwiń zwycięską wersję i wycofaj przegranych.
Może być również konieczne oczyszczenie serwerów, opublikowanie ostatecznego wdrożenia/wycofania.
Jak widać, cykl życia eksperymentu po stronie serwera jest długi i złożony, w przeciwieństwie do eksperymentu po stronie klienta. Dlatego testowanie po stronie serwera wymaga pewnej namysłu.
Ogólnie rzecz biorąc, nie przeprowadziłbyś eksperymentu po stronie serwera, gdyby zrobił to po stronie klienta…
Przeprowadzenie nawet pojedynczego eksperymentu po stronie serwera jest trudne, ponieważ jego opracowywanie i wdrażanie jest procesem bardziej wymagającym zasobów i czasochłonnym.
Poza tym, jeśli używasz testowania po stronie serwera do testowania zmian, które można łatwo zweryfikować po stronie klienta, osiągnięcie dobrej prędkości testowania i solidnego programu eksperymentalnego będzie trudne.
Ponadto w przypadku takich eksperymentów wybór eksperymentów po stronie serwera, gdy masz kilka świetnych narzędzi do testowania A/B po stronie klienta, które pozwalają na ich uruchamianie bez migotania bez wpływu na SEO lub szybkość, nie obiecuje najlepszego wykorzystania testów pasmo.
Eksperymenty po stronie serwera powinny być preferowane tylko wtedy, gdy dają mocne uzasadnienie dla danej hipotezy. Robią to kilka razy, ponieważ wiele eksperymentów, które mają wpływ na wyniki firmy, może odbywać się tylko po stronie serwera.
Więc powiedz nam… czy przeprowadziłeś jakieś testy po stronie serwera? Jeśli tak, jaka była najtrudniejsza część procesu? Aha, a jeśli chcesz przeprowadzić test A/B po stronie serwera, wypróbuj Convert (za darmo przez 15 dni!)
