Wawasan Oura • Diperbarui 2 Oktober 2026
Mengukur prospek dengan GA4: event, inquiry, dan kualitas sales
Oura Works

Pengukuran prospek dengan GA4 dimulai dari definisi tindakan yang dianggap berhasil oleh bisnis. Klik kontak, formulir yang dikirim, inquiry yang diterima, dan prospek berkualitas adalah tahap yang berbeda. Catat event pada kondisi yang tepat, lalu baca laporan analitik bersama tindak lanjut sales.
Misalnya, pengunjung menekan tombol WhatsApp tetapi belum mengirim pesan. Website dapat mencatat klik tersebut, namun belum mengetahui apakah percakapan terjadi. Sebaliknya, formulir mungkin menampilkan error setelah tombol ditekan. Menghitung keduanya sebagai lead membuat laporan terlihat lebih baik daripada proses yang sebenarnya berjalan.
Panduan ini membahas definisi, rancangan event, pemeriksaan, serta evaluasi yang dapat disiapkan bersama tim website. Contoh merupakan simulasi, bukan hasil implementasi atau data klien Oura. Pengaturan aktual mengikuti sistem formulir, akses, serta kebijakan pengukuran bisnis Anda.
Ringkasan untuk tim bisnis
- Tentukan arti inquiry berhasil sebelum memasang tag.
- Pisahkan klik, pengiriman formulir, penerimaan permintaan, dan kualifikasi.
- Pilih key event yang benar-benar membantu keputusan pemasaran.
- Periksa skenario sukses, gagal, pengiriman ulang, dan consent.
- Jaga nama, email, nomor telepon, serta isi pesan agar tidak terkirim ke Analytics.
- Gabungkan laporan website dengan catatan sales menggunakan proses yang disepakati.
1. Apa perbedaan klik kontak dan prospek?
Klik kontak menunjukkan niat awal, sedangkan inquiry diterima menunjukkan proses permintaan telah mencapai sistem tujuan. Prospek berkualitas memerlukan penilaian bisnis berikutnya. Gunakan definisi tertulis agar marketing, pengembang, dan sales tidak memakai istilah lead untuk tindakan yang berbeda.
Oura menyarankan peta tindakan seperti berikut sebelum pekerjaan tracking:
| Tahap | Contoh tindakan | Bukti yang tersedia |
|---|---|---|
| Minat awal | Klik tombol konsultasi | Klik dari halaman tertentu |
| Interaksi | Mulai mengisi formulir | Interaksi dengan form |
| Permintaan | Sistem menerima inquiry | Respons sukses sesuai kontrak sistem |
| Kualifikasi | Sales menilai kebutuhan cocok | Status dan alasan dalam catatan sales |
| Pelanggan | Kerja sama dimulai | Catatan transaksi atau proses bisnis yang berlaku |
Jangan memaksa semua tahap masuk ke satu metrik. Website biasanya mengetahui tindakan awal lebih dahulu daripada status kerja sama. Sediakan catatan tentang tempat tiap tahap dicatat dan siapa pemiliknya. Ini membantu menjelaskan laporan tanpa menyimpulkan bahwa semua pengunjung yang menekan kontak menjadi pelanggan.
2. Bagaimana menetapkan definisi lead sebelum tracking?
Sepakati tindakan, kondisi sukses, dan pengecualian bersama pemilik proses. Untuk formulir konsultasi, kondisi sukses bisa berupa penerimaan permintaan oleh layanan backend. Untuk jalur lain, gunakan definisi yang dapat diperiksa pada sistem tersebut. Definisi harus mengikuti proses nyata yang sedang digunakan.
Contoh simulasi: tim menyepakati satu inquiry ketika backend menerima permintaan konsultasi yang lolos validasi. Permintaan dengan field wajib kosong, error jaringan, atau respons gagal tidak termasuk. Inquiry dari pengujian diberi penanda pada lingkungan pemeriksaan dan dipisahkan dari laporan operasional.
Buat dokumen singkat berisi nama tindakan, trigger, pemilik sistem, dan bukti sukses. Jika backend hanya menerima email untuk antrean, jangan menyebutnya sebagai bukti email telah dibaca sales. Bila inquiry diterima tetapi gagal diarahkan ke CRM, catat masalah routing secara terpisah agar angka tidak menutupi kegagalan tindak lanjut.
Definisi ini dapat dimasukkan dalam brief proyek website. Dengan begitu, pengukuran menjadi bagian kriteria pekerjaan yang dipahami kedua pihak sebelum pengembangan dimulai.

3. Event dan key event apa yang perlu dipilih?
Event mencatat tindakan; key event menandai tindakan yang penting bagi bisnis. Google menjelaskan bahwa event yang dikumpulkan dapat dijadikan key event sesuai kebutuhan. Pilih setelah definisi serta trigger diperiksa, bukan hanya karena sebuah event sudah muncul di laporan. Rujuk panduan key events.
Google menyediakan generate_lead sebagai recommended event untuk penciptaan lead, misalnya melalui form. Parameter mengikuti definisi pada dokumentasi recommended events. Jika memakai nilai uang, pastikan arti nilai dan currency mengikuti kebutuhan pelaporan; jangan menetapkan nominal acak agar dashboard tampak lengkap.
Untuk rancangan Oura, klik WhatsApp dan permintaan konsultasi yang diterima tetap dibedakan. Klik dapat membantu mengevaluasi penempatan CTA. Inquiry diterima dapat membantu menilai jalur perolehan permintaan. Pilihan mana yang menjadi key event mengikuti tujuan bisnis serta kualitas pencatatan yang sudah diperiksa.
Jangan menambahkan event dengan nama berbeda untuk tindakan yang sama tanpa tujuan jelas. Catat arti event dan parameter dalam kamus pengukuran. Kamus itu membantu saat tim atau vendor berubah, sehingga laporan lama masih dapat dijelaskan.
4. Kapan event dicatat pada formulir?
Catat event sesuai tahap yang ingin diukur. Jika targetnya inquiry diterima, trigger harus mengikuti respons sukses yang disepakati dengan pengembang. Menekan tombol, lolos validasi browser, dan menerima respons backend adalah kejadian yang berbeda dalam proses formulir.
GA4 enhanced measurement dapat menyediakan form_start dan form_submit untuk interaksi formulir. Pelajari dokumentasi enhanced measurement lalu periksa implementasi aktual. Nama event saja tidak membuktikan penyimpanan data, penerimaan email, atau pembentukan lead di CRM.
Formulir berbasis AJAX sering menampilkan hasil tanpa berpindah halaman. Pengembang perlu menjelaskan respons mana yang menunjukkan penerimaan sukses. Jika memakai halaman terima kasih, periksa apakah halaman dapat dibuka langsung atau dimuat ulang. Jangan menjadikan setiap kunjungan ke URL tersebut sebagai permintaan baru tanpa kontrol yang sesuai.
| Skenario simulasi | Inquiry diterima? | Pemeriksaan yang diperlukan |
|---|---|---|
| Klik kirim dengan field wajib kosong | Tidak | Validasi dan tidak adanya trigger sukses |
| Backend memberi respons gagal | Tidak | Penanganan error dan tidak adanya event sukses |
| Backend menerima permintaan | Ya, menurut definisi sistem | Trigger sukses sesuai respons |
| Halaman sukses dimuat ulang | Bukan bukti permintaan baru | Pencegahan pencatatan ulang |
| Klik WhatsApp | Belum diketahui | Event klik terpisah dari lead |

5. Bagaimana memeriksa duplikasi dan pengiriman gagal?
Periksa satu rangkaian tindakan dari awal sampai akhir, termasuk skenario yang tidak berhasil. Gunakan lingkungan atau jalur pengujian yang disepakati. Jangan mengirim data pelanggan sungguhan atau menghasilkan permintaan operasional tanpa koordinasi dengan pemilik proses.
Google menyediakan DebugView untuk melihat event dan properti saat debug mode aktif. Tag Assistant atau preview dapat digunakan untuk membantu pemeriksaan pada perangkat penguji. Kondisi consent dan kontrol privasi dapat memengaruhi apa yang terlihat. Rujuk panduan DebugView, kemudian simpan bukti pemeriksaan yang relevan.
Dalam rekomendasi QA Oura, periksa apakah tindakan yang sama dicatat oleh dua jalur. Contohnya, Google Tag Manager dan kode halaman dapat sama-sama mengirim event ketika callback sukses berjalan. Jangan menghapus salah satu jalur sebelum memahami dependensinya; tentukan pemilik implementasi lalu lakukan perubahan yang dapat ditinjau.
Catat skenario, waktu, hasil sistem, event yang terlihat, dan event yang seharusnya tidak muncul. Jika tombol ditekan ulang ketika permintaan pertama masih diproses, periksa perilaku form serta backend. Pencegahan duplikasi bukan hanya urusan laporan; antarmuka juga perlu menjelaskan bahwa permintaan sedang dikirim.

6. Data apa yang tidak boleh dikirim ke Analytics?
Jangan mengirim informasi yang dapat mengidentifikasi seseorang melalui data Analytics. Google memberikan panduan untuk menghindari PII, termasuk risiko data dalam URL dan field yang diteruskan. Ikuti panduan PII Google Analytics saat merancang event maupun meninjau implementasi.
Untuk pekerjaan Oura, parameter seperti jenis layanan dari pilihan terkontrol dapat dibahas sebagai kebutuhan pelaporan. Nama, email, telepon, pesan bebas, atau URL yang memuat data tersebut harus diperiksa agar tidak terkirim. Jangan menganggap setiap field aman hanya karena labelnya terlihat umum.
Audit juga parameter otomatis dan tujuan form. Query string atau nama dokumen dapat memuat informasi yang tidak dimaksudkan untuk analitik. Mintalah pengembang menjelaskan asal data, tujuan pengiriman, dan kondisi pengumpulan. Perbaikan teknis mengikuti kebijakan privasi serta izin yang berlaku pada bisnis.
Keperluan kontak tetap berada di sistem yang memang menangani inquiry. Kebutuhan mengukur jumlah tindakan tidak berarti seluruh isi permintaan perlu dikirim ke platform analitik. Panduan ini membahas rancangan operasional; kebijakan serta tanggung jawab organisasi harus ditetapkan oleh pemilik bisnis.
7. Bagaimana memakai UTM secara konsisten?
Gunakan UTM pada tautan kampanye eksternal agar penamaan sumber, medium, dan kampanye dapat dibaca secara konsisten. Google menyediakan parameter kampanye serta URL builder pada panduan custom URLs. Tetapkan aturan penamaan bersama tim yang membuat tautan.
Contoh simulasi: kampanye LinkedIn memakai sumber linkedin, medium paid_social, dan nama kampanye yang disepakati. Contoh ini menjelaskan konsistensi pencatatan, bukan memastikan klasifikasi laporan tertentu. Pengelompokan channel mengikuti aturan dan konfigurasi Analytics yang perlu diperiksa.
Simpan daftar tautan, penanggung jawab, tujuan, tanggal, serta nama kampanye. Gunakan label yang menjelaskan kegiatan tanpa memuat identitas penerima atau informasi sensitif. Periksa apakah redirect atau sistem tujuan mempertahankan parameter yang diperlukan dalam alur yang sedang digunakan.
Dalam rancangan Oura, tautan internal tidak diberi UTM hanya untuk membandingkan tombol halaman. Pakai event atau parameter tindakan yang dirancang untuk kebutuhan tersebut. Ini menjaga pemisahan antara asal kunjungan dengan interaksi di dalam website dan membuat laporan lebih mudah dijelaskan.
8. Bagaimana membaca kualitas prospek bersama sales?
Kualitas prospek perlu definisi dari bisnis, bukan ditebak dari event website. Sales dapat menilai kecocokan kebutuhan, layanan, wilayah, atau kesiapan proyek berdasarkan proses yang disepakati. Gunakan kategori yang jelas dan tidak terlalu banyak agar pencatatan dapat dijalankan secara konsisten.
Oura merekomendasikan catatan evaluasi seperti berikut:
| Catatan | Kegunaan | Pemilik utama |
|---|---|---|
| Permintaan diterima | Memeriksa fungsi inquiry | Tim website atau operasional |
| Layanan yang dibutuhkan | Menilai kecocokan penawaran | Sales |
| Status tindak lanjut | Melihat proses respons | Sales |
| Alasan tidak sesuai | Menentukan perbaikan pesan atau targeting | Sales dan marketing |
| Asal yang diketahui | Membahas kontribusi kanal dengan konteks | Marketing |
Jika sebagian besar inquiry mengira layanan Anda berbeda, tinjau konten halaman layanan. Jika permintaan sesuai tetapi sulit ditindaklanjuti, periksa pembagian pemilik dan informasi yang dibutuhkan sales. Jangan langsung mengubah kampanye sebelum hambatan prosesnya dipahami.
Penggabungan data CRM dan analitik memerlukan rancangan identitas, izin, serta akses yang sesuai. Tabel di atas bukan instruksi untuk mengekspor data pelanggan ke GA4. Mulai dari ringkasan bisnis yang diperlukan dan periksa integrasi bersama pengelola sistem.

9. Mengapa angka GA4 dan CRM dapat berbeda?
Perbedaan angka perlu ditelusuri dari definisi dan cakupan data. GA4 dapat mencatat interaksi website, sementara CRM mencatat permintaan atau pelanggan menurut proses lain. Penyamaan periode saja belum membuat kedua sumber mengukur kejadian yang sama.
Periksa definisi lead, zona waktu, filter, status consent, serta jalur inquiry yang tidak melewati website. Tinjau juga permintaan ulang, spam, penggabungan kontak, dan perubahan status oleh sales. Jangan mengubah event hanya untuk memaksa jumlahnya sama dengan laporan lain.
Pengelompokan channel mengikuti definisi yang tersedia pada Analytics. Rujuk panduan default channel group untuk memahami klasifikasi yang sedang dipakai. Channel “Direct” tidak dapat diperlakukan sebagai bukti bahwa semua pengunjung mengetik URL secara manual.
Tuliskan batas interpretasi dalam laporan. Atribusi membantu membahas kontribusi kanal, tetapi pembacaan laporan saja tidak membuktikan hubungan sebab akibat terhadap penjualan. Bila ingin mengevaluasi perubahan, catat apa yang berubah, periode, kondisi kampanye, serta faktor lain yang diketahui.
10. Checklist sebelum laporan dipakai mengambil keputusan
- [ ] Definisi inquiry berhasil disepakati oleh bisnis dan pengembang.
- [ ] Nama event, trigger, dan parameter tersedia dalam kamus pengukuran.
- [ ] Klik kontak dipisahkan dari permintaan yang diterima.
- [ ] Skenario field kosong, error, sukses, dan pengiriman ulang diperiksa.
- [ ] Tidak ada dua implementasi yang mencatat tindakan sama tanpa alasan.
- [ ] Reload halaman sukses tidak dianggap lead baru secara otomatis.
- [ ] Parameter, URL, dan form tidak meneruskan PII ke Analytics.
- [ ] Kondisi consent serta lalu lintas pengujian dipahami.
- [ ] Penamaan tautan kampanye dijaga konsisten.
- [ ] Sales memakai definisi kualifikasi serta pemilik tindak lanjut yang jelas.
- [ ] Selisih data dijelaskan melalui cakupan, bukan disembunyikan.
- [ ] Perubahan pengukuran dicatat agar perbandingan periode dapat dibaca.

Contoh keputusan: mengapa dua laporan berbeda tidak langsung berarti tracking rusak
Seseorang dapat mengklik kontak, kembali melalui kanal lain, lalu mengirim kebutuhan yang sama dua kali. Analytics dan CRM melihat bagian proses yang berbeda. Perbandingan perlu dimulai dari definisi, rentang tanggal, zona waktu, dan aturan duplikasi sebelum tim mengubah tag.
| Perbedaan contoh | Pemeriksaan awal | Risiko kesimpulan terburu-buru |
|---|---|---|
| Event lebih banyak dari inquiry | Validasi, pengiriman ulang, dan tujuan event | Menyamakan semua event dengan lead |
| CRM menerima inquiry tanpa sumber | Jalur kontak lain dan referrer yang hilang | Menganggap semuanya error Analytics |
| Peluang sales lebih sedikit | Kesesuaian, spam, dan status tindak lanjut | Menilai kualitas hanya dari jumlah form |
Tabel ini simulasi tanpa angka hasil. Pilih beberapa contoh yang dapat diperiksa dengan izin yang tepat. Jangan memasukkan identitas pribadi ke Analytics untuk mencocokkan laporan. Gunakan prosedur rekonsiliasi yang disepakati dan tulis batas atribusi pada laporan yang dibagikan ke pengambil keputusan.
Kesimpulan: ukur proses yang benar-benar terjadi
Mulailah dari satu inquiry yang jelas definisinya. Periksa fungsi form, trigger event, dan data yang dikirim. Setelah pencatatan dapat dijelaskan, gunakan laporan bersama sales untuk memilih perbaikan halaman, kampanye, atau tindak lanjut.
Jika laporan saat ini belum membedakan klik dan permintaan diterima, bahas pengukuran website dengan Oura. Siapkan URL, jalur kontak yang dipakai, sistem tujuan, dan laporan yang sudah tersedia. Informasi tersebut membantu merumuskan pemeriksaan serta ruang lingkup integrasi yang diperlukan.
FAQ
Apakah form_submit otomatis cukup untuk menghitung inquiry?
Periksa tujuan pengukurannya. Interaksi submit belum menjelaskan seluruh proses penerimaan inquiry. Jika bisnis ingin menghitung permintaan yang diterima backend, validasi event terhadap respons sukses yang disepakati. Simpan hasil pemeriksaan sebelum memilihnya sebagai metrik operasional.
Apa yang dilakukan bila event tercatat dua kali?
Telusuri trigger dan semua jalur pengiriman event terlebih dahulu. Periksa kode halaman, Tag Manager, callback, dan kunjungan ulang halaman sukses. Tentukan sumber pencatatan utama bersama pengembang, lalu tinjau perubahan dengan skenario yang sama. Jangan memperbaikinya hanya dengan menyembunyikan angka di laporan.
Apakah semua event perlu menjadi key event?
Tidak. Pilih tindakan yang penting bagi keputusan bisnis dan sudah memiliki pencatatan yang dapat diperiksa. Scroll atau klik dapat menjadi informasi pendukung. Inquiry yang diterima atau tindakan lain yang disepakati dapat memiliki peran berbeda dalam evaluasi pemasaran.
Bolehkah nama dan email dari form masuk ke GA4?
Jangan memasukkan PII ke Analytics. Simpan kebutuhan kontak pada sistem inquiry atau CRM yang sesuai. Audit juga URL serta parameter otomatis agar data tidak terkirim tanpa sengaja. Ikuti dokumentasi platform dan kebijakan organisasi saat merancang pengumpulan data.
Apakah klik WhatsApp berarti lead baru?
Klik menunjukkan interaksi dengan jalur kontak, bukan bukti percakapan telah terjadi. Catat sebagai tindakan terpisah. Bila tim perlu menilai inquiry dari WhatsApp, tentukan proses pencatatan di kanal atau sistem operasional yang digunakan, beserta izin dan batas pengukurannya.
Kapan laporan mulai layak dibandingkan antarperiode?
Setelah definisi, trigger, dan cakupan data cukup konsisten untuk dibandingkan. Catat perubahan implementasi, kampanye, serta proses sales yang terjadi. Bila ada perubahan besar, beri penjelasan dalam laporan dan gunakan baseline baru sesuai kebutuhan evaluasi.


















