Jumlah lead naik setelah formulir diperbarui, tetapi tim penjualan tidak menerima lebih banyak permintaan. Salah satu kemungkinan adalah event dikirim ketika tombol ditekan, termasuk saat validasi gagal. Grafik terlihat membaik karena definisi keberhasilan berubah tanpa disadari.
Sebelum memakai key event untuk menilai hasil SEO, uji apakah event tersebut mewakili kejadian yang kamu maksud. Kita membutuhkan definisi, trigger, parameter, dan pembanding dari sistem yang menjalankan proses bisnisnya.
Definisikan keberhasilan secara operasional
Untuk formulir, bedakan klik tombol, percobaan submit, pengiriman yang diterima server, dan lead yang memenuhi kriteria. Untuk toko, bedakan mulai checkout, pembayaran diproses, transaksi selesai, serta pembatalan atau refund.
GA4 menyediakan recommended events seperti generate_lead, purchase, dan refund. Event tersebut membutuhkan konteks tambahan dan tidak otomatis terkirim hanya karena nama event tersedia dalam dokumentasi. Panduan recommended events GA4.
Pilih event dan parameter sesuai proses. Jangan memakai satu nama untuk beberapa kejadian berbeda hanya agar laporan lebih sederhana.
Buat kontrak event
| Bagian | Isi contoh untuk lead |
|---|---|
| Kejadian | Permintaan informasi diterima sistem |
| Trigger | Respons sukses yang sesuai dari proses pengiriman |
| Bukan trigger | Klik tombol, validasi gagal, atau request error |
| Parameter | Konteks formulir yang dibutuhkan dan aman dikirim |
| Pemilik | Tim yang mengelola implementasi serta definisinya |
| Pembanding | Record penerimaan pada backend atau CRM |
Contoh ini merupakan rancangan pengukuran, bukan klaim bahwa setiap bisnis harus memakai trigger identik. Jelaskan keputusanmu agar developer dan analis tidak memiliki definisi keberhasilan berbeda.
Jangan mengirim isi formulir, alamat email, atau informasi pribadi sebagai parameter analytics biasa. Gunakan konteks nonpribadi yang memang dibutuhkan untuk analisis.
Uji keadaan sukses dan gagal
Siapkan data uji yang aman serta lingkungan yang sesuai. Jalankan skenario berikut:
- Submit kosong yang gagal validasi.
- Submit valid yang berhasil diterima.
- Gangguan jaringan atau respons error.
- Klik dua kali ketika proses belum selesai.
- Reload halaman konfirmasi.
- Kembali ke halaman konfirmasi dari riwayat browser.
Tentukan hasil yang diharapkan sebelum tes. Keadaan gagal seharusnya tidak menambah event keberhasilan. Reload tidak boleh menciptakan transaksi bisnis baru dalam laporan hanya karena komponen dipasang ulang.
Gunakan DebugView dan pemeriksaan request untuk melihat nama event serta parameter yang benar-benar dikirim. Bukti request terkirim tetap perlu dipasangkan dengan bukti bahwa kejadian bisnisnya benar. Panduan verifikasi setup Google Analytics.
Contoh: lead terhitung dua kali
Bayangkan formulir memiliki listener di kode aplikasi dan trigger serupa di tag manager. Satu pengiriman sukses menghasilkan dua event generate_lead. Ini contoh ilustratif, bukan temuan pada website tertentu.
Catat urutan event dan sumber pemicunya. Perbaiki kepemilikan trigger sehingga satu kejadian memiliki jalur pengiriman yang jelas. Jangan sekadar membagi angka laporan dengan dua, karena tidak semua keadaan mungkin mengalami duplikasi yang sama.
Untuk transaksi, gunakan identitas transaksi yang konsisten dengan sistem pesanan. Dokumentasi validasi ecommerce juga membahas penggunaan transaction ID dan masalah pengiriman ganda. Jangan memakai ID kosong atau ID yang sama untuk seluruh pembelian. Validasi ecommerce GA4.
Rekonsiliasi pada unit yang tepat
Bandingkan jumlah kejadian dalam periode dan cakupan yang sama. Analytics dapat memiliki batas consent atau pengiriman, sementara backend mencatat proses bisnis dengan definisi lain. Targetnya memahami selisih, bukan memaksa persamaan angka.
| Kelompok selisih | Pemeriksaan |
|---|---|
| Analytics lebih tinggi | Duplikasi trigger, event sebelum sukses, data uji |
| Analytics lebih rendah | Tag gagal, consent, pemuatan, parameter salah |
| Jumlah cocok tetapi nilai berbeda | Mata uang, pajak, ongkir, definisi nilai |
| Lead banyak tetapi kualitas buruk | Spam, permintaan tidak relevan, definisi qualified lead |
Pisahkan lead masuk dan lead berkualitas. Perubahan kualitas bukan selalu masalah tracking, tetapi tidak terlihat jika semua event diperlakukan sebagai hasil bisnis yang sama.
Jaga definisi saat rilis berikutnya
Simpan kontrak event, daftar tes, dan tanggal implementasi. Setiap perubahan formulir, checkout, atau tag perlu memeriksa kembali event terkait.
Jika definisi event berubah, tandai laporan historis. Kenaikan setelah rilis bisa mencerminkan pengukuran yang lebih lengkap atau trigger yang berbeda, bukan pertumbuhan bisnis. Dengan pemeriksaan ini, angka hasil SEO memiliki dasar yang lebih kuat untuk dipakai mengambil keputusan.
