Bagaimana beralih dari nol menjadi satu dalam perjalanan eksperimen sisi server Anda

Pikirkan perjalanan Anda sebagai pengguna Netflix. Jika Anda seperti saya, Anda dapat menonton film dokumenter satwa liar di ponsel Anda sambil menyeruput kopi pagi Anda. Makan malam mungkin ditemani oleh favorit lama seperti Forrest Gump di laptop. Malam akhir pekan akan dihabiskan untuk beralih antara profil Anda dan profil anak-anak Anda, sambil mencoba acara Netflix baru, sebaiknya di layar yang lebih besar.

Sekarang katakanlah Netflix menjalankan kampanye diskon khusus negara. Jika Anda adalah bagian dari kampanye eksperimen yang dijalankan oleh Netflix, bagaimana mereka memastikan bahwa Anda adalah bagian dari kampanye yang sama setiap kali Anda masuk, terlepas dari perangkat dan profil yang Anda gunakan, dan melihat promosi yang sama di mana-mana? Bagaimana mereka memastikan bahwa pengalaman Anda dengan variasi yang disajikan selalu lancar setiap saat dan bagaimana Anda terlibat dengan variasi dilacak secara konsisten?

Jawabannya terletak pada eksperimen omnichannel, yang merupakan kasus penggunaan umum dari pengujian sisi server.

Haruskah Anda lebih memilih pengujian sisi server daripada sisi klien?

Contoh Netflix yang disebutkan di atas akan sangat rumit untuk dilakukan di sisi klien dan dapat menghambat pengalaman pengguna. Di sisi server, ini relatif mudah dijalankan dan memastikan pengalaman yang konsisten bagi pengguna. Ini juga memastikan dampak minimal pada kinerja halaman. Selain itu, ini menghilangkan masalah terkait privasi karena tidak ada aktivitas di browser seperti itu.

Ada kasus penggunaan lain di mana pengujian sisi server direkomendasikan untuk ketahanan dan fleksibilitasnya. Kami akan membicarakannya di artikel ini. Tapi pertama-tama, apa sebenarnya pengujian sisi server, dan yang lebih penting, untuk siapa?

Dalam pengujian sisi server, variasi pengujian diproses di server web. Saat pengunjung membuka halaman yang sedang diuji, variasi diambil langsung dari server dan dikirimkan ke browser pengunjung. Tidak ada modifikasi selanjutnya yang terjadi di front end atau browser. Berlawanan dengan ini, dalam pengujian sisi klien, laman asli dimuat terlebih dahulu di browser pengunjung dan platform eksperimen Anda membuat variasi di front-end itu sendiri menggunakan JavaScript. Mari kita pahami ruang lingkup kedua bentuk pengujian ini dengan sebuah contoh.

Bayangkan Mike dan Bob adalah dua sahabat yang sedang mencoba bereksperimen dengan cara kerja sebuah mobil baru. Mike berada di belakang kemudi dan memiliki akses ke rem, akselerator, dasbor, dan sejenisnya. Bob memiliki pandangan tentang komponen internal seperti mesin, radiator, baterai, dll. Keduanya dapat mempengaruhi mobil dengan cara yang berbeda. Apa yang dilakukan Bob dengan aksesnya ke komponen mobil dapat tercermin di luar bagi Mike. Perubahan yang diuji Mike didasarkan pada visibilitas mobilnya. Dari sudut pandang pembeli mobil, hasil eksperimen yang dijalankan oleh Bob dan Mike dapat memiliki tujuan yang sama pentingnya, tetapi berbeda.

Oleh karena itu, Anda tidak harus memilih satu bentuk pengujian di atas yang lain. Kasus penggunaan berbeda dan tim yang menggunakan alat juga berbeda. Pengujian sisi server adalah jalan eksperimen bagi pengembang dan manajer produk, sama seperti pengujian sisi klien yang lebih sering digunakan oleh pemasar.

Masalah mana yang dapat diatasi dengan pengujian sisi server?

Pengujian sisi server yang dijalankan oleh tim produk memecahkan masalah terkait berbagai industri mulai dari eCommerce dan SaaS hingga perbankan dan media. Beberapa kasus penggunaan penting di mana pengujian sisi server direkomendasikan daripada pengujian sisi klien di industri yang berbeda dijelaskan di bawah ini:

Rekomendasi produk

Rangkaian produk yang direkomendasikan mana yang menarik pengunjung Anda untuk membeli lebih banyak? Pengujian sisi server memungkinkan Anda menguji beberapa algoritme rekomendasi produk untuk menentukan pilihan yang mengarah pada peningkatan penjualan dan pendapatan. Misalnya, Anda dapat menguji apakah tata letak yang mempromosikan produk serupa berfungsi lebih baik daripada tata letak yang mempromosikan produk paling populer. Anda juga dapat memutuskan apakah akan melakukan upsell atau cross-sell berdasarkan temuan eksperimen sisi server Anda.

Biaya pengiriman

Berapa nilai keranjang ideal yang harus memenuhi syarat pesanan untuk pengiriman gratis? Anda dapat menguji berbagai ambang batas untuk menentukan ambang batas yang secara positif memengaruhi keputusan pembelian pelanggan.

Cari algoritma

Bereksperimen dengan algoritme penelusuran Anda memerlukan modifikasi pada kode yang ada dan fleksibilitas untuk menguji secara mendalam. Anda ingin pengunjung Anda dapat dengan cepat menemukan apa yang mereka cari dan Anda dapat menguji algoritme pencarian Anda di sisi server untuk mencapainya.

Panjang bentuk

Uji coba gratis dan formulir permintaan demo sangat penting untuk bisnis SaaS. Tapi berapa panjang formulir ideal yang memastikan penurunan yang lebih rendah sekaligus menangkap semua informasi yang diperlukan? Anda dapat menguji bidang yang tidak wajib melalui pengujian sisi klien. Jika bidang Anda wajib, menyembunyikan bidang menggunakan JavaScript tidak akan berfungsi karena validasi formulir menggunakan logika sisi server akan gagal. Oleh karena itu, pengujian sisi server disarankan untuk bereksperimen dengan bidang wajib untuk mengoptimalkan panjang dan kompleksitas formulir Anda.

Penawaran dan diskon

Meskipun gaya, tampilan dan nuansa, serta penempatan penawaran di beranda Anda dapat diuji dengan mudah di sisi klien, ada faktor penting lainnya seperti nilai diskon, durasinya, atau kriteria kelayakan untuk dipertimbangkan. Anda dapat menguji di sisi server untuk menentukan nilai optimal dan memastikan bahwa nilai tersebut konsisten di seluruh saluran untuk pengunjung tertentu.

Insentif penjualan

Menguji insentif dinamis seperti penawaran periode terbatas atau izin stok memerlukan fleksibilitas pengujian sisi server karena perincian yang terlibat.

Aliran berlangganan

Berapa banyak langkah yang idealnya terlibat dalam proses berlangganan? Haruskah login sosial disediakan? Bereksperimen dengan alur berlangganan dapat membantu menjawab pertanyaan-pertanyaan ini.

Paywall

Pengujian sisi server memungkinkan Anda menguji berbagai konfigurasi paywall dengan cara yang sangat mudah. Sebagai penayang, Anda dapat menjalankan pengujian sisi server untuk bereksperimen dengan konten terjaga keamanannya dan memonetisasinya. Menjalankan pengujian yang sama di sisi klien tidak disarankan, karena pengunjung dapat melewati paywall dengan menghapus atau menyisih dari cookie.

Perbankan seluler

Beberapa elemen dapat dioptimalkan dalam proses pendaftaran untuk pinjaman atau kartu kredit. Tetapi ketika datang ke mobile banking, keamanan data menjadi yang terpenting. Dengan pengujian sisi klien, data sensitif yang dikumpulkan oleh bank atau lembaga keuangan dapat berada pada risiko kerentanan. Untuk menghindari risiko ini, eksperimen sisi server biasanya direkomendasikan untuk aplikasi perbankan.

Sekarang mari kita memahami bagaimana Anda dapat menjalankan tes Fitur di sisi server dan keuntungan melakukannya dengan VWO.

Bagaimana VWO membuat pengujian sisi server lebih mudah

Untuk kasus penggunaan sisi server yang dijelaskan di atas, VWO memberi Anda fleksibilitas untuk menyusun kampanye Anda baik sebagai pengujian A/B atau pengujian Fitur. Pengujian fitur digunakan untuk memvalidasi nilai parameter fitur dan memberi Anda kontrol untuk mengonfigurasi fitur dengan cepat, tanpa menulis kode. Dalam beberapa kasus penggunaan seperti menguji algoritme penelusuran mana yang lebih baik, kampanye dapat disusun sebagai uji A/B atau uji Fitur.

Misalnya, Anda ingin mengevaluasi tiga vendor untuk algoritme penelusuran yang mereka buat untuk situs web Anda.

Pengujian fitur memungkinkan manajer produk seperti Anda untuk menguji dan menyimpulkan dengan cepat dengan ketergantungan minimum pada rekayasa dan kontrol konfigurasi maksimum. Dengan kemampuan pengujian Fitur VWO, Anda mendapatkan kerangka kerja yang ditetapkan di mana Anda perlu menulis lebih sedikit kode karena platform melakukan sebagian besar pekerjaan berat untuk Anda. Dalam pengujian Fitur, algoritme dapat didefinisikan sebagai variabel fitur dan dikonfigurasikan dalam kontrol dan variasi eksperimen dari alur penyiapan platform itu sendiri untuk menguji algoritme penelusuran mana yang lebih efisien.

Eksperimen ini juga dapat dilakukan melalui pengujian A/B sisi server. VWO memfasilitasi distribusi lalu lintas dan kemampuan model statistik eksperimen melalui SDK sisi servernya. Tim teknik dapat menggunakan hal yang sama untuk memasukkan kode algoritme pencarian dan menguji yang lebih berdampak.

Berikut adalah beberapa skenario lain di mana pengujian Fitur berguna. Katakanlah bahwa vendor pihak ketiga yang menangani pengisian ulang ponsel ingin membebankan jumlah nominal kepada pengguna per pengisian ulang. Mereka ingin menguji jumlah yang sesuai untuk hal yang sama. Atau perusahaan seperti Airbnb, di mana biaya properti ditangani oleh pemiliknya, ingin menambahkan biaya pembersihan dan melihat apakah itu berdampak pada jumlah pemesanan. Ini adalah kasus penggunaan eksperimen khas untuk berbagai perusahaan untuk menemukan sweet spot di mana biaya layanan dapat dimasukkan tanpa memengaruhi metrik bintang utara. Bisa berupa convenience fee, facility fee, covid fee, packaging fee, atau sejenisnya.

Kasus penggunaan yang rumit seperti yang dijelaskan di atas sangat mudah untuk diuji di VWO. Berikut adalah video penjelasan yang menunjukkan kepada Anda bagaimana Anda dapat dengan cepat membuat fitur biaya kenyamanan dan menetapkan nilai untuk itu (dalam hal ini jumlah biaya). Anda dapat menautkan hipotesis Anda untuk mengidentifikasi biaya yang menambah pendapatan tanpa memengaruhi jumlah pemesanan, memilih lingkungan tempat Anda menjalankan pengujian, dan mengaktifkan variasi Anda. Setelah Anda melakukannya, Anda akan diberikan kode kampanye yang masuk ke server Anda. Yang tersisa adalah Anda menentukan sasaran yang ingin Anda lacak dan mengelompokkan audiens Anda jika Anda mau – itu saja, kampanye Anda sudah siap.

Jika Anda seorang manajer produk dan Anda melihat di dasbor bahwa variasi 3 tidak berfungsi untuk pengguna; itu berdampak negatif pada pendapatan, Anda dapat mematikannya di sana hanya dengan menonaktifkan variasi di VWO. Seperti yang ditunjukkan pada tangkapan layar di bawah, ini tidak memengaruhi kode dan tidak mengharuskan tim teknik Anda membuat perubahan apa pun. Anda harus mematikannya, klik 'simpan', dan variasi berhenti menerima lalu lintas.

Pada dasarnya, kode hanya perlu diterapkan sekali per kampanye.

Haruskah Anda membangun atau membeli platform untuk menjalankan pengujian sisi server?

Mari kita akhiri perdebatan build vs buy. VWO bukan hanya penghasil angka acak yang menunjukkan variasi berbeda kepada audiens yang berbeda dan menangkap peristiwa konversi. VWO adalah platform eksperimen lengkap dengan model statistik yang kuat. Untuk mempertimbangkan apakah akan membangun mekanisme pengujian sisi server secara internal atau berinvestasi dalam platform seperti VWO, Anda perlu mempertimbangkan tiga faktor utama:

1. Biaya kepemilikan

Bahkan ketika perusahaan berhasil membangun infrastruktur yang dibutuhkan secara internal, mereka masih perlu mengelola dan menskalakannya. Membayar tim pengembangan Anda untuk membangun dan memelihara mesin eksperimen seperti VWO alih-alih berfokus pada pekerjaan inti mereka kemungkinan akan lebih memakan waktu dan biaya bagi Anda daripada berinvestasi di VWO.

2. Kemudahan penggunaan

Anda dapat membuat solusi yang menunjukkan variasi tertentu kepada audiens tertentu – tetapi apakah Anda memiliki antarmuka yang mudah digunakan yang dapat dikontrol tidak hanya oleh tim teknik tetapi juga oleh manajer produk? Jika tidak, itu pemblokir lain bagi Anda untuk menjalankan tes sisi server.

3. Pelaporan intuitif

Biasanya solusi internal akan memberi Anda hal-hal dasar seperti jumlah pengunjung dan konversi yang berasal dari variasi tertentu. Tetapi yang Anda butuhkan adalah hasil yang signifikan secara statistik. Anda memerlukan laporan Anda untuk didukung oleh mesin statistik Bayesian seperti VWO SmartStats. Di situlah letak kesenjangannya – Anda dapat membangun solusi dasar yang sulit dipertahankan dan Anda dapat menghabiskan waktu dan sumber daya untuk menguraikan nilai-p. Atau Anda dapat memilih solusi seperti VWO di mana ada tim yang berdedikasi untuk memelihara dan menskalakannya dan telah menghabiskan waktu bertahun-tahun pada algoritme Bayesian untuk memberi Anda hasil yang mudah ditafsirkan. Dasbor dalam aplikasi di VWO memungkinkan bahkan anggota tim non-teknis Anda untuk memahami hasil; mereka tidak perlu bergantung pada tim Analytics untuk melacak eksperimen atau membuat dasbor hasil – sehingga menghemat waktu dan mengurangi biaya eksperimen.

4. Mekanisme bebas kesalahan

Membangun solusi pengujian sisi server secara internal dapat rentan terhadap kesalahan, dan pada skala itu, kesalahan mungkin tidak mudah ditemukan. Bandingkan dengan kualitas platform yang digunakan oleh merek global dan Anda yakin bahwa kemungkinan kesalahan merayap sangat kecil. Setiap kesalahan, jika ada, ditandai dan diperbaiki paling cepat oleh tim dukungan yang cakap yang tersedia untuk Anda.

Selain itu, ketika Anda berinvestasi dalam platform terkelola seperti VWO, praktik terbaik yang penting akan dibangun ke dalam produk. Anda tidak perlu khawatir tentang menghapus outlier dari hasil Anda, memvisualisasikan data Anda, atau tentang masalah yang timbul karena pembaruan versi.

Kemampuan yang harus dimiliki untuk menjalankan pengujian sisi server yang kompleks dengan integritas

Menjalankan eksperimen sisi server bisa sangat bermanfaat bila dijalankan dengan benar. Untuk melakukannya, Anda harus memiliki serangkaian kemampuan fitur yang tepat. Beberapa di antaranya diuraikan di bawah ini:

1. Pengacakan pengunjung di setiap pengujian – Dalam pengujian, saat Anda memasukkan audiens ke dalam kampanye, pengacakan pengunjung harus benar-benar acak dan bukan acak semu.
2. Pengalaman omnichannel yang konsisten – Meskipun pengelompokan pengguna harus dilakukan secara acak, Anda juga perlu memastikan bahwa satu pengguna mengalami variasi yang sama setiap kali mereka masuk, terlepas dari perangkat yang mereka gunakan. Eksperimen harus dilanjutkan tanpa gangguan.
3. Kampanye yang saling eksklusif – Katakanlah Anda memiliki tiga faktor untuk dipertimbangkan saat menentukan apakah pengguna harus menjadi bagian dari pengujian Anda. Ini bisa berupa keteraturan penggunaan, kemungkinan churn yang rendah, dan zona waktu. Selain mempertimbangkan variabel-variabel ini, Anda juga perlu menentukan eksklusivitas – jadi berapa banyak tes yang dapat diikuti oleh pengguna yang memenuhi persyaratan ini? Hal ini perlu ditentukan dengan cara yang tidak mengarah pada data miring dan memungkinkan Anda mengaitkan peningkatan rasio konversi ke kampanye yang tepat tanpa bias.
4. Konvensi penamaan standar – Baik Anda menyiapkan fitur baru untuk diuji atau tanda fitur, Anda harus mengikuti konvensi penamaan standar untuk menghindari campur-baur dan kasus menginisialisasi fitur atau pengujian yang salah.
5. Pengidentifikasi kampanye yang unik dan tidak merepotkan – Anda harus menggunakan kunci alfanumerik untuk mengidentifikasi pengujian secara unik dalam kode Anda dan menghindari kerepotan di tahap selanjutnya.
6. Memilih lingkungan yang tepat – Anda harus menentukan lingkungan tempat Anda menjalankan pengujian – misalnya, Anda dapat menerapkan pengujian di lingkungan staging atau QA untuk tim QA Anda guna memvalidasi eksperimen. Pemeriksaan kewarasan tes Anda sangat penting untuk keberhasilannya dan Anda harus memiliki pilihan untuk memilih lingkungan yang tepat untuk itu.
7. Alokasi lalu lintas logis – Saat Anda menjalankan beberapa kampanye atau saat Anda memiliki pengumuman acara penting seperti Obral Minggu Hitam, misalnya, Anda tidak perlu menyertakan seluruh kumpulan pengunjung yang mendarat di halaman Anda dalam pengujian Anda. Anda harus memilih persentase lalu lintas yang ingin Anda sertakan dalam kampanye percobaan dan juga bagaimana Anda ingin mendistribusikan lalu lintas ini di antara variasi.
8. Penghitungan waktu untuk mencapai signifikansi statistik – Perkiraan waktu pengujian Anda untuk mencapai signifikansi statistik harus ditentukan oleh rasio konversi saat ini dari tujuan utama Anda dan peningkatan minimum yang ingin Anda capai melalui variasi Anda. Ini juga harus mempertimbangkan kemungkinan 95% untuk mengalahkan tingkat konversi dasar.

Ini adalah beberapa praktik terbaik dan fitur pengujian sisi server yang harus dimiliki – daftar sebenarnya jauh lebih panjang. Seperti yang disebutkan sebelumnya, Anda dapat membangun kemampuan ini secara internal, atau Anda dapat menggunakan VWO di mana kami melakukan pekerjaan untuk Anda.

Kesimpulannya

Apakah Anda seorang pengembang atau manajer produk, Anda tidak perlu membatasi ide pengujian Anda. Anda dapat menjalankan pengujian yang rumit tanpa mengkhawatirkan masalah kinerja atau privasi dengan pengujian sisi server dan memecahkan masalah nyata yang dihadapi oleh pelanggan Anda. Anda dapat mengoptimalkan setiap titik kontak digital sehingga pelanggan Anda hanya mengalami yang terbaik.

Jika Anda menggunakan platform seperti VWO, kerumitan pengujian tidak akan membebani Anda – karena setiap masukan Anda dalam kampanye bersifat intuitif dan praktik bagus yang memperkuat pengujian Anda. Untuk memahami lebih lanjut tentang bagaimana Anda dapat menjalankan pengujian sisi server dengan mudah menggunakan VWO, mintalah demo dengan pakar produk kami.