İstemci Tarafı Testi Vs. Sunucu Tarafı Testi: İkisi de Kazanır.

Deneme çalıştırma söz konusu olduğunda, optimize ediciler, istemci tarafı ve sunucu tarafı testi arasında seçim yapabilir.

Sunucu tarafında hemen hemen her istemci tarafı testi ve istemci tarafı testi (bölünmüş URL veya yönlendirme deneyleri kullanarak) yoluyla birkaç hafif arka uç denemesini çalıştırabilseniz de, bunu yapmak sizin kadar uygun veya sağlam olmayacaktır' d gibi… çünkü herhangi bir hipotez için , ikisinden sadece biri en iyi sonucu verir .

Ve doğru olanı seçmek dikkatli bir değerlendirme gerektirir. Bu seçimi yaparken tartılması gereken birçok yön vardır. Kurulumun hız ve SEO üzerindeki etkisine, deneme yaşam döngüsü için çaba ve zaman gereksinimlerine, denemenin hedefine ve daha fazlasına bakın.

Şimdi bu faktörleri gözden geçirelim ve istemci tarafı testinin sunucu tarafı testinden nasıl farklı olduğunu ve her birinin artıları ve eksilerini görelim.

İstemci Tarafı Testi Vs. Sunucu Tarafı Testi

Ancak, bu, müşteri tarafı testlerinde indirim yapmak olacaktır.

İstemci Tarafı Testi Basit Görünebilir, Ancak Güçlüdür.

İstemci tarafı A/B testini herkesin yapabileceği “kolay test” olarak reddetmek kolaydır. Kabul: uygulanması kolaydır. Ve bazen, farklı bir CTA düğmesi rengini veya kopyasını test etmek kadar küçük olabilir.

Ancak ister bu ister yeniden tasarımı veya yenilenmiş bir sayfayı test etmek kadar büyük bir şey olsun, müşteri tarafı testleri işletmenin kârlılığını etkiler .

Bu örnek olay incelemesinde, bir SaaS şirketi, ana sayfalarında olası satışlardaki büyümeyi %61 oranında artırmak için, müşteri tarafı A/B test aracı olarak Deneyimleri Dönüştür'ü kullandı:

Aynı SaaS şirketinin fiyatlandırma sayfasında, olası satışlarda %57'lik bir artışa yol açan, Deneyimleri Dönüştürme'yi istemci tarafı test aracı olarak kullanan başka bir A/B testi denemesi:

Çevrimiçi olarak gördüğünüz dönüşüm optimizasyonu başarı öykülerinin çoğu, yüzey düzeyinde bir deneyimi başarıyla optimize eden ve büyük kazançlar elde eden müşteri tarafı testleridir.

Ancak Sunucu Tarafı Testi Gerçekten Daha Fazlasını Test Etmenizi Sağlar.

Ön uçtan daha derin bir test yapmanız gerektiğinde, sunucu tarafı testi yapmanız gerekir.

Bunu birkaç senaryo ile perspektife koyalım.

Bir e-ticaret işletmesi olsaydınız, yeniden tasarlanmış bir arama çubuğunun mağaza içi aramalarınızı artırıp artıramayacağını (ve daha fazla satışla sonuçlanıp sonuçlanamayacağını) öğrenmek için müşteri tarafında bir A/B testi denemesi kullanabilirsiniz.

Ancak, daha alakalı arama sonuçları getirebilecek (ve uzun vadede daha fazla satışla sonuçlanacak) yeni bir arama algoritmasını test etmek istiyorsanız, sunucu tarafı A/B testi denemesi yapmanız gerekir. .

Bunun yerine bir B2B SaaS işletmesi olsaydınız, belirli bir UVP'nin ana sayfanızda daha iyi çalışıp çalışmadığını belirlemek için müşteri tarafında bir deneme çalıştırabilirsiniz. Veya uzun biçimli bir kopya, kısa biçimli bir kopyayı yenebilirse.

Ancak, daha hızlı bir arka ucu test etmek ve tutmayı veya etkileşimi iyileştirip iyileştiremeyeceğini görmek istiyorsanız, sunucu tarafında bir deneme çalıştırmanız gerekir. Yeni bir katılım dizisini test etmek isterseniz, yine sunucu tarafı denemesine gitmeniz gerekir. Çünkü, yeni işe alım iş akışınızı desteklemenin yanı sıra, sunucu tarafı testi, e-postalar, SMS'ler ve farklı cihazlar üzerinde gerçekleşen diğerlerini kapsayan çok kanallı bir deney düzenlemenize de olanak tanır.

Benzer şekilde, bir B2C SaaS işletmesi olsaydınız, belirli bir fiyatlandırma planının diğerlerinden daha iyi çalışıp çalışmayacağını öğrenmek için müşteri tarafında bir deneme çalıştırabilirsiniz.

Ancak, daha iyi bir öneri motorunu test etmek istiyorsanız, sunucu tarafı testine gitmeniz gerekir.

Sunucu tarafı testinin farklı kullanım durumlarından anlayabileceğiniz gibi, anında dönüşümler kazanmaktan ziyade daha iyi ürünler oluşturmaya yöneliktir. Anında satışlara veya dönüşümlere odaklanan müşteri tarafı deneylerinin aksine, sunucu tarafı deneyleri, ömür boyu müşteri değerini artıracak şekilde ürünü veya çözümü optimize etmeye odaklanır.

Müşteri tarafı testi pazarlamacılar içinse, sunucu tarafı testinin de öncelikle ürün ve mühendislik ekipleri için olduğunu söyleyebilirsiniz. Ve Deneyimleri Dönüştür gibi A/B test araçları, hem pazarlama hem de mühendislik ekiplerine uyum sağlamak için hem istemci hem de sunucu tarafı testleri sunar.

Bu tür derin ürün düzeyindeki değişiklikleri test etmek, tarayıcı tabanlı basit JS manipülasyonundan çok daha fazlasını gerektirdiğinden, tarayıcının içinde gerçekleşemez ve sunucu düzeyinde ele alınması gerekir.

Sunucu tarafı testinin kendine özgü kullanım durumları olsa da, bazı şirketler bunu, istemci tarafında bile kusursuz bir şekilde sorunsuz çalışacak olan kozmetik testleri bile çalıştırmak için kullanır.

Bunu genellikle "titreme" veya "Orijinal İçeriğin Flaşı" fenomeninden kaçınmak için yaparlar. Titreme, deneme aracı, son kullanıcılar zaten gördükten sonra sunucu tarafından sunulan orijinal içeriği değiştirdiğinde meydana gelir. Kullanıcılarınızın belirli bir başlık gördüğünü ve ardından bunun bir anda diğerine dönüştüğünü hayal edin. (Evet, titreme bir kullanıcının deneyimini ciddi şekilde tehlikeye atabilir!)

Diğer zamanlarda, bunu daha yüksek hız için yaparlar. Test bir web sitesini yavaşlatmaz veya ciddi performans sorunlarına neden olmaz, ancak web sitesinin algılanan yükleme deneyimine bir veya iki saniye ekler. Sunucu tarafı bunu daha hızlı hale getirebilir.

Bazen bir şirket, gizlilik veya güvenlik endişeleri nedeniyle istemci tarafı yerine sunucu tarafı deneyi çalıştırabilir. Hedef kitle hedefleme sunucuda gerçekleştiğinden ve sunucu tarafı testinde deneme kodu sunucuda bulunduğundan, şirketler gizlilik ve güvenlik yönleri üzerinde daha iyi kontrol sahibi olurlar.

Ancak sunucu tarafı denemesi uygulamak her zaman mümkün değildir, özellikle de istemci tarafı da aynı şekilde başarılı olduğunda.

Sunucu Tarafı Deneylerini Uygulama

İstemci tarafı testinde, deneylerinizi oluşturmak ve yürütmek için yalnızca sınırlı tasarım ve geliştirme kaynaklarına ihtiyacınız vardır. Yalnızca metin değişiklikleri yapıyorsanız veya bir düğmenin rengini değiştiriyorsanız bunlara ihtiyacınız bile olmaz. Tek yapmanız gereken:

1. Dönüştür gibi bir araca giriş yapın.

2. WYSIWYG düzenleyicisini kullanın ve varyasyonları oluşturun.

3. Denemeyi ayarlayın (kitle hedefleme koşullarını, deneme süresini, örnek boyutunu ve bölünmesini, güven düzeyini vb. ayarlayın)

JS kodunu alın ve web sitenize ekleyin.

Ve bitti.

Ardından, kontrolün kaybedilmesi durumunda kazanan sürümü kullanıma sunmak için geliştirme yardımı arayabilirsiniz.

Ancak sunucu tarafı testi o kadar basit değildir.

Burada yapmanız gerekenler:

1. Deneyimleri Dönüştür'de denemenizi oluşturun

2. Denemenizin tüm varyasyonlarını sunucunuzda geliştirin ve dağıtın.

3. Özel kod kullanarak (denemenizin kimliğini, deneme aracınızda ayarlanan varyasyonların kimliklerini ve daha fazlasını kullanarak) Deneyimleri Dönüştür'de sunucu tarafından dağıtılan deneyimlerinizi eşleyin.

Bu tür sunucu tarafı deneylerinde, kodunuzun sunucuya hangi varyasyonun geçerli bir kullanıcıya gösterileceğini söylemesi gerekir. Bunu kolaylaştırmak için çerezleri kullanabilirsiniz. Örneğin, Convert ile bir A/B sunucu tarafı testi uygulamak için aşağıdaki verilerle bir tanımlama bilgisi oluşturmanız gerekir:

Sunucu daha sonra çerezinizi okuyacak ve
buna göre bir sürüm (ve sonraki tüm oturumlar) sunar.

Bir kullanıcıya hangi sürümün gönderileceğini sunucunuz belirlediğinden, hedefleme sunucuda gerçekleşir (istemci tarafı testinde olduğu gibi tarayıcının içinde değil). Test hassasiyetiniz, sunucunuzdaki hedefleme koşullarınızı ne kadar iyi kodlayabileceğinize bağlı olacaktır. İstemci tarafı testiyle, tüm deneyimleriniz için hedef kitlenizi lazerle hedefleyebilirsiniz.

Ayrıca, sunucu tarafı testi, çok sunuculu bir kurulumda ve ayrıca bir CDN'nin entegre edilmesi gerektiğinde daha karmaşık hale gelebilir.

4. Deneyi çalıştırın.

5. Kazanan versiyonu yayınlayın ve kaybedenleri geri alın.

Ayrıca sunucularınızı temizlemeniz, son kullanıma sunma/geri alma işlemini göndermeniz gerekebilir.

Gördüğünüz gibi, sunucu tarafı deneyinin yaşam döngüsü, istemci tarafı deneyinin aksine uzun ve karmaşıktır. Bu nedenle, sunucu tarafı testine devam etmek biraz müzakere gerektiriyor.

Genel olarak, İstemci Taraflı Bir Deney Yaparsa, Sunucu Taraflı Bir Deneme Çalıştırmazsınız…

Tek bir sunucu tarafı denemesi bile yürütmek zordur çünkü onu geliştirmek ve kullanıma sunmak daha kaynak yoğun ve zaman alıcı bir süreçtir.

Ayrıca, istemci tarafında kolayca doğrulanabilen değişiklikleri test etmek için sunucu tarafı testi kullanırsanız, iyi bir test hızına ve sağlam bir deneme programına ulaşmak zor olacaktır.

Ayrıca, bu tür deneyler için, SEO'nuzu veya hızınızı etkilemeden titreşimsiz çalıştırmanıza izin veren birkaç harika istemci tarafı A/B test aracınız varken sunucu tarafı denemelerini tercih etmek, testinizin en iyi şekilde kullanılacağını vaat etmez. Bant genişliği.

Sunucu taraflı deneyler, yalnızca verilen hipotez için güçlü bir durum oluşturduklarında tercih edilmelidir. Ve bunu birkaç kez yaparlar çünkü bir işletmenin kârlılık metriklerini etkileyen birçok deney yalnızca sunucu tarafında gerçekleşebilir.

Öyleyse bize söyleyin… herhangi bir sunucu tarafı testi yaptınız mı? Eğer öyleyse, sürecin en zor kısmı neydi? Oh, ve eğer bir sunucu tarafı A/B testi yapmak istiyorsanız, Convert'e göz atın (15 gün boyunca ücretsizdir!)