Manfaatkan pengujian A/B untuk mengevaluasi dampak kecepatan situs pada metrik bisnis Anda.
Selama beberapa tahun terakhir, telah diketahui dengan baik bahwa performa kecepatan situs adalah bagian penting dari pengalaman pengguna, dan meningkatkannya akan menguntungkan berbagai metrik bisnis seperti rasio konversi dan rasio pantulan. Beberapa artikel dan studi kasus telah dipublikasikan untuk mendukung hal ini, termasuk Bagaimana Performa Situs Web Mempengaruhi Rasio Konversi dari Cloudflare, Milidetik Perolehan Jutaan, dan Belanja untuk Kecepatan di eBay.com, sebagai sejumlah contoh.
Meskipun alasan kecepatan sudah jelas, banyak perusahaan masih kesulitan memprioritaskan pekerjaan yang akan meningkatkan kecepatan situs karena mereka tidak tahu persis bagaimana pengaruhnya terhadap pengguna mereka dan sebagai hasilnya terhadap bisnis mereka.
Jika tidak ada data, mudah untuk menunda pekerjaan kecepatan situs dan berfokus pada tugas lain. Skenario umum adalah ketika beberapa orang di perusahaan menyadari pentingnya kecepatan situs, tetapi belum dapat membuat kasus untuk hal tersebut dan meyakinkan beberapa pemangku kepentingan untuk berinvestasi dengan sesuai.
Artikel ini memberikan panduan umum tentang cara memanfaatkan pengujian A/B untuk mengevaluasi dampak kecepatan situs terhadap metrik bisnis sehingga memungkinkan pengambilan keputusan yang lebih efektif terkait masalah ini.
Langkah 1: Pilih halaman untuk pengujian A/B
Tujuan Anda adalah menguji hipotesis bahwa kecepatan halaman berkaitan dengan metrik bisnis Anda. Demi kemudahan, pada awalnya Anda dapat membatasi diri pada mengidentifikasi satu halaman untuk analisis. Pekerjaan mendatang dapat diperluas ke beberapa halaman dengan jenis yang sama untuk memverifikasi temuan, lalu ke area lain dari situs. Beberapa saran untuk memulai tersedia di bagian bawah langkah ini. Beberapa persyaratan mendorong proses pemilihan halaman:
- Pengujian A/B hanya boleh dijalankan di perangkat pengguna seluler. Secara global, situs partner yang kami bantu mendapatkan rata-rata lebih dari 50% (dan terus berkembang) traffic mereka yang berasal dari perangkat seluler. Namun, hal ini dapat meningkat secara signifikan berdasarkan wilayah dan vertikal. Perangkat seluler lebih sensitif terhadap situs yang lebih lambat karena pemrosesan dan keterbatasan memori serta jaringan yang kurang stabil. Selain itu, pola penggunaan kapan saja di mana saja berarti ekspektasi kecepatan lebih tinggi.
Halaman yang dipilih untuk pengujian harus menjadi bagian penting dari funnel konversi Anda. Setiap situs memiliki tujuan yang berbeda, jadi setiap situs melacak metrik keberhasilan yang berbeda. Metrik ini biasanya terkait dengan perjalanan pengguna yang dianalisis menggunakan funnel. Misalnya, pengguna di situs e-commerce harus membuka halaman beranda, halaman kategori, halaman produk, dan halaman checkout untuk menyelesaikan pembelian. Jika Anda mengoptimalkan konversi, salah satu halaman tersebut akan menjadi kandidat yang bagus.
Halaman harus memiliki satu tujuan. Kecuali jika situs Anda memiliki misi yang sangat spesifik, sebaiknya hindari penggunaan halaman beranda untuk pengujian Anda. Banyak halaman beranda situs komersial merupakan portal ke berbagai fungsi yang akan membuat analisis Anda bermasalah. Misalnya, jika Anda mengoptimalkan kunjungan halaman per sesi di situs berita, sebaiknya kecualikan bagian situs non-komersial dan fokus pada bagian dan artikel yang dimonetisasi.
Halaman yang dipilih harus mendapatkan traffic yang cukup, sehingga Anda tidak perlu menunggu lama sebelum mendapatkan hasil yang signifikan secara statistik.
Halaman yang dipilih seharusnya relatif lambat. Faktanya, lebih lambat lebih baik. Hal ini tidak hanya berarti bahwa Anda akan lebih mudah memperbaiki halaman, tetapi juga berarti data akan menjadi jauh lebih jelas. Anda dapat melakukan pemindaian cepat melalui Laporan Kecepatan Google Analytics atau laporan Data Web Inti Konsol Penelusuran untuk melihat halaman mana yang paling lambat.
Halaman seharusnya relatif stabil. Jangan perbarui halaman (hal apa pun yang akan memengaruhi metrik bisnis) hingga pengujian selesai. Makin sedikit faktor eksternal yang perlu dipertimbangkan, makin bersih analisisnya.
Dengan menggunakan hal di atas sebagai panduan, akan terlihat sedikit lebih jelas halaman mana yang merupakan kandidat bagus untuk pengujian Anda. Halaman landing iklan juga merupakan pilihan yang baik karena Anda cenderung memiliki metrik bisnis bawaan, pengujian A/B, dan analisis. Jika Anda masih tidak yakin, berikut ini beberapa ide untuk setiap vertical:
- Situs Web Konten: rubrik, artikel
- Etalase: halaman kategori, halaman produk
- Media Player: halaman penemuan/penelusuran video, halaman pemutaran video
- Layanan & Penemuan (perjalanan, mobil sewaan, pendaftaran servis, dll.): halaman awal formulir entri
Langkah 2: Ukur performa
Ada dua cara umum untuk mengukur metrik: di lab dan di lapangan. Secara pribadi, kami mendapati bahwa pengukuran metrik di lapangan (juga dikenal sebagai Pemantauan Pengguna Real-Time (RUM)) lebih berguna karena mencerminkan pengalaman pengguna sebenarnya. Contoh library dan layanan yang dapat membantu Anda melaporkan data RUM meliputi Perfume, Firebase Performance Monitoring, dan Google Analytics Events.
Ada banyak metrik yang dapat dipilih karena metrik tersebut bertujuan untuk menangkap berbagai aspek pengalaman pengguna. Ingatlah bahwa tujuan Anda pada akhirnya adalah menentukan apakah ada korelasi langsung antara metrik kecepatan dan bisnis, jadi sebaiknya lacak beberapa metrik kecepatan untuk menentukan metrik mana yang memiliki korelasi terkuat dengan kesuksesan bisnis Anda. Secara umum, sebaiknya mulai dengan Tanda Vital Web Inti. Library web-vitals.js dapat membantu Anda mengukur beberapa Data Web Inti di lapangan, meskipun perlu diperhatikan bahwa dukungan browser tidak 100%. Selain Data Web Inti, Data Web Lainnya juga patut dilihat. Anda juga dapat menentukan metrik kustom, seperti "Waktu Ke Klik Iklan Pertama".
Langkah 3: Buat varian performa kecepatan
Pada tahap ini, Anda akan mengimplementasikan perubahan untuk membuat versi halaman yang lebih cepat untuk diuji terhadap versi saat ini.
Beberapa hal yang harus diingat:
- Hindari membuat perubahan apa pun pada UI atau UX. Selain satu halaman lebih cepat dari yang lain, perubahan tidak boleh terlihat oleh pengguna.
- Pengukuran juga merupakan aspek kunci pada tahap ini. Saat mengembangkan, alat pengujian lab seperti Lighthouse harus digunakan untuk menunjukkan efek perubahan terhadap performa. Ingatlah bahwa perubahan pada satu metrik sering kali dapat memengaruhi metrik lainnya. Setelah halaman ditayangkan, tetap gunakan RUM untuk evaluasi yang lebih akurat.
Pembuatan varian performa dapat dilakukan dengan berbagai cara. Untuk tujuan pengujian, Anda perlu melakukannya sesederhana mungkin. Di bawah ini adalah beberapa opsinya.
Membuat halaman yang lebih cepat
- Gunakan alat seperti Squoosh untuk mengoptimalkan gambar di halaman pengujian secara manual
- Gunakan cakupan kode DevTools untuk secara manual menghilangkan JavaScript atau CSS yang tidak digunakan hanya untuk satu halaman tersebut
- Memuat skrip pihak ketiga secara efisien
- Gunakan alat seperti Penting untuk membagi dan menyejajarkan CSS penting
- Hapus kode JavaScript yang tidak penting yang tidak memengaruhi pengalaman pengguna dan yang dapat Anda lakukan tanpanya untuk tujuan pengujian (misalnya, library pihak ketiga tertentu)
- Menerapkan pemuatan lambat tingkat browser yang tidak didukung oleh semua browser, tetapi masih dapat meningkatkan performa secara signifikan jika didukung
- Hapus tag analisis yang tidak penting atau muat tag tersebut secara asinkron
Pengoptimalan tambahan yang perlu dipertimbangkan dapat ditemukan di Waktu pemuatan cepat dan Checklist Performa Frontend. Anda juga dapat menggunakan PageSpeed Insights untuk menjalankan Lighthouse, yang mengidentifikasi peluang untuk meningkatkan performa.
Memperlambat halaman
Langkah ini mungkin adalah cara termudah untuk membuat varian dan dapat dilakukan dengan menambahkan skrip sederhana, memperlambat waktu respons server, memuat gambar yang lebih besar, dll. Financial Times memilih opsi ini saat menguji pengaruh performa terhadap metrik bisnisnya: lihat FT.com yang lebih cepat.
Mempercepat pemuatan halaman
Untuk kasus ketika halaman pengujian (misalnya, halaman detail produk) sebagian besar ditautkan dari halaman yang berbeda (misalnya halaman beranda), pengambilan data atau pra-rendering, halaman produk secara langsung dari halaman beranda untuk grup pengujian akan mempercepat pemuatan halaman berikutnya. Perhatikan bahwa dalam hal ini, pemisahan pengujian A/B (langkah 4) dilakukan di halaman beranda. Selain itu, semua hal ini dapat memperlambat halaman pertama, jadi pastikan untuk mengukurnya dan mempertimbangkannya saat menganalisis hasil pengujian (langkah 5).
Langkah 4: Buat pengujian A/B
Setelah Anda memiliki dua versi untuk halaman yang sama yang salah satunya lebih cepat dari halaman lainnya, langkah berikutnya adalah memisahkan traffic untuk mengukur dampak. Secara umum ada banyak teknik dan alat untuk melakukan pengujian A/B, tetapi perlu diketahui bahwa tidak semua metode cocok untuk mengukur dampak performa kecepatan.
Jika Anda menggunakan alat pengujian A/B seperti Optimizely atau Optimize, sebaiknya siapkan pengujian sisi server, bukan pengujian sisi klien, karena pengujian A/B sisi klien sering kali berfungsi dengan menyembunyikan konten halaman hingga eksperimen dimuat, yang berarti pengujian A/B itu sendiri akan mendistorsi metrik yang ingin Anda ukur. Jika Anda hanya dapat melakukan pengujian sisi klien, pertimbangkan untuk menyiapkan eksperimen pada halaman lain dan mengubah link ke halaman pengujian untuk membagi traffic. Dengan cara ini, halaman pengujian itu sendiri tidak ditarik ke bawah oleh pengujian sisi klien.
Contoh perubahan performa pengujian A/B di halaman detail produk (PDP) tertentu melalui pengujian sisi server:
Permintaan ditujukan ke backend, yang mendistribusikan pengguna ke dua versi halaman yang berbeda. Meskipun secara umum ini adalah penyiapan yang baik, sistem ini sering kali memerlukan resource IT untuk menyiapkan pemisahan sisi server.
Berikut adalah contoh penyiapan pengujian sisi klien, yang menggunakan halaman sebelumnya (halaman beranda pada diagram di bawah) untuk menjalankan JavaScript pengujian:
JavaScript pengujian memanipulasi link keluar untuk memberikan link ke dua grup pengujian pengguna ke dua versi PDP yang dimaksud. Pengujian ini mudah disiapkan dan dikelola melalui alat pengujian A/B umum seperti Optimizely atau Optimize, dan tidak memengaruhi pengujian performa karena JavaScript pengujian berjalan di halaman yang berbeda.
Atau, Anda dapat memilih dua halaman yang berfungsi dan berperforma sangat mirip (misalnya, untuk dua produk yang sangat mirip). Terapkan perubahan pada salah satu metrik, lalu bandingkan perbedaan metrik dari waktu ke waktu. Artinya, Anda tidak melakukan pengujian A/B yang tepat, tetapi pengujiannya bisa sangat bermanfaat.
Jika halaman pengujian digunakan sebagai halaman landing untuk kampanye iklan, sebaiknya gunakan alat pengujian A/B bawaan jaringan iklan Anda, seperti Pengujian Terpisah Iklan Facebook atau Draf & Eksperimen Google Ads. Jika tidak memungkinkan, Anda dapat menggunakan dua kampanye dengan penyiapan yang sama, dan menetapkan halaman landing yang berbeda sebagai target.
Langkah 5: Analisis pengujian A/B
Setelah Anda menjalankan pengujian cukup lama dan memiliki cukup data agar Anda merasa yakin dengan hasilnya, sekarang saatnya menyatukan semuanya dan menjalankan analisis. Cara Anda melakukannya sangat bergantung pada bagaimana pengujian telah berjalan, jadi mari kita bahas opsinya.
Jika pengujian Anda dijalankan di halaman landing iklan menggunakan alat yang disebutkan di atas, analisis harus semudah membaca hasilnya. Jika Anda menggunakan Draf & Eksperimen Google, lihat perbandingannya menggunakan ScoreCard.
Platform seperti Optimizely atau Optimize juga menawarkan cara mudah untuk menafsirkan hasil dan menentukan seberapa besar dampak kecepatan pada halaman Anda.
Jika menggunakan Google Analytics atau alat serupa, Anda harus mengumpulkan laporan sendiri. Untungnya, Google Analytics memudahkan pembuatan laporan kustom, jadi dari situlah Anda harus memulai. Jika Anda mengirim data kecepatan ke Google Analytics menggunakan dimensi kustom, lihat Panduan pelaporan untuk mempelajari cara menyiapkan dimensi kustom tersebut dan menyertakannya dalam laporan kustom. Pastikan laporan Anda mencakup tanggal eksperimen dan dikonfigurasi untuk menampilkan kedua varian. Apa yang harus dicantumkan dalam laporan ini?
- Terutama, Anda harus menyertakan metrik bisnis yang paling penting bagi Anda: konversi, penayangan halaman, iklan yang dilihat, rasio konversi, metrik e-commerce, rasio klik-tayang, dll.
- Selain itu, metrik halaman standar lainnya yang juga menjadi alasan bagus untuk meningkatkan kecepatan situs adalah rasio pantulan, durasi sesi rata-rata, dan persentase keluar.
Anda mungkin juga perlu memfilter untuk seluler dan pastikan untuk mengecualikan bot dan traffic non-pengguna lainnya. Analisis yang lebih canggih juga akan memfilter menurut wilayah, jaringan, perangkat, sumber traffic, serta profil dan jenis pengguna, seperti pengguna baru versus pengunjung berulang. Setiap grup pengguna mungkin lebih atau kurang sensitif terhadap kecepatan yang lebih lambat dan mengidentifikasinya juga cukup membantu.
Looker Studio (sebelumnya Data Studio) atau alat visualisasi data lainnya memudahkan untuk mengintegrasikan berbagai sumber data termasuk Google Analytics. Hal ini memudahkan untuk melakukan analisis, dan juga membuat dasbor yang dapat dibagikan dengan banyak pemangku kepentingan yang terlibat dalam menjalankan situs modern untuk dukungan lebih lanjut. Misalnya, Guardian membuat sistem pemberitahuan otomatis yang memperingatkan tim editorial saat konten yang baru-baru ini dipublikasikan melampaui batas ukuran atau kecepatan halaman dan kemungkinan dapat mengakibatkan pengguna yang tidak puas.
Langkah 6: Mengambil kesimpulan dan memutuskan langkah selanjutnya
Setelah memiliki data yang menghubungkan metrik performa dan bisnis, Anda dapat memeriksa hasilnya dan mulai menarik kesimpulan.
Jika Anda dapat melihat dengan jelas korelasi antara peningkatan performa dan peningkatan metrik bisnis, rangkum hasilnya dan laporkan di seluruh perusahaan. Sekarang, setelah Anda berbicara tentang performa kecepatan dalam "bahasa bisnis", Anda lebih mungkin untuk menarik perhatian berbagai pemangku kepentingan dan menempatkan performa kecepatan situs di depan umum semua orang. Langkah berikutnya adalah menetapkan anggaran performa berdasarkan hasil, dan merencanakan pekerjaan untuk memenuhi anggaran tersebut. Karena Anda tahu nilai yang akan diberikan oleh pekerjaan tersebut, Anda akan dapat membuat prioritas yang sesuai.
Jika Anda tidak dapat mengidentifikasi korelasi, lihat peringatan di bawah dan nilai apakah pengujian serupa sebaiknya dijalankan di tempat lain di situs (misalnya, melalui seluruh funnel pembelian atau di jenis halaman yang berbeda).
Peringatan
Mungkin ada beberapa alasan tidak menemukan korelasi yang signifikan antara metrik kecepatan situs dan metrik bisnis:
- Halaman yang dipilih tidak memiliki pengaruh yang cukup terhadap metrik bisnis yang Anda periksa. Misalnya, halaman produk yang lebih cepat mungkin tidak berpengaruh besar pada rasio konversi jika halaman checkout sangat tidak mudah atau lambat. Pertimbangkan untuk melihat metrik yang lebih relevan seperti rasio pantulan, rasio penambahan ke keranjang, atau metrik lain yang lebih terhubung langsung ke halaman yang Anda uji.
- Perbedaan kecepatan tidak cukup signifikan antara kedua versi tersebut. Hal ini harus dievaluasi berdasarkan metrik RUM yang Anda ukur.
- Terjadi error dengan mekanisme pengujian A/B. Traffic mungkin tidak didistribusikan dengan benar atau analisis tidak dilaporkan dengan benar. Untuk mengatasi hal ini, pertimbangkan untuk menjalankan pengujian A/A dengan menguji versi halaman yang sama menggunakan mekanisme pengujian yang sama dan memastikan tidak ada perbedaan hasil saat melakukannya.
- Kecepatan situs benar-benar tidak memengaruhi metrik bisnis Anda. Hal ini jarang terjadi, tetapi dapat terjadi jika target pasar Anda kurang sensitif terhadap kecepatan (misalnya situs sebagian besar diakses dari perangkat canggih pada jaringan yang kuat) atau permintaan pengguna sangat tinggi dan pilihannya terbatas (misalnya layanan tiket yang hanya menjual tiket untuk pertunjukan dengan permintaan tinggi). Perlu diperhatikan bahwa hal ini tidak berarti bahwa situs yang lebih cepat tidak akan meningkatkan kualitas pengalaman pengguna, dan akibatnya akan memengaruhi reputasi brand.
Kesimpulan
Meskipun Anda tergoda untuk meluncurkan pengoptimalan kecepatan di seluruh situs, akan lebih bermanfaat dalam jangka panjang. Perbedaan antara mengatakan "kami meningkatkan FCP sebesar 1,5 detik" dan "kami meningkatkan FCP sebesar 1,5 detik dan meningkatkan rasio konversi sebesar 5%". Dengan demikian, Anda dapat memprioritaskan pekerjaan lebih lanjut, mendapatkan dukungan dari berbagai pemangku kepentingan, dan menjadikan performa kecepatan situs sebagai upaya di seluruh perusahaan.