Pada aplikasi yang berpindah layar tanpa memuat dokumen baru, jumlah page view bergantung pada implementasi navigasi dan analytics. Satu perpindahan dapat terlewat, atau justru dihitung dua kali oleh pemicu otomatis dan manual. Mulai pemeriksaan dari siapa yang mengirim page_view untuk setiap keadaan.
Single-page application atau SPA mempertahankan dokumen awal dan memperbarui tampilan melalui JavaScript. Perubahan address bar belum membuktikan event analytics benar. Kamu perlu memeriksa jumlah event sekaligus informasi halaman yang menyertainya.
Jika perpindahan route juga mengubah isi yang tersedia untuk pencarian, lakukan diagnosis rendering JavaScript sebagai pemeriksaan terpisah dari pengiriman analytics.
Sepakati apa yang dianggap satu halaman
Buat daftar perpindahan yang bermakna bagi pengguna. Membuka artikel lain biasanya merupakan halaman baru. Mengganti tab kecil dalam satu artikel mungkin hanya interaksi. Mengubah parameter sortir bisa mempunyai makna berbeda sesuai aplikasi.
Jangan membiarkan setiap perubahan URL otomatis menjadi definisi bisnis tanpa diperiksa. Sebaliknya, jangan mengabaikan perpindahan penting hanya karena URL tidak berubah.
Contoh ilustratif: aplikasi tutorial mempunyai halaman daftar, halaman panduan, dan panel pilihan ukuran teks. Daftar menuju panduan dihitung sebagai page view baru. Membuka panel ukuran teks dicatat sebagai interaksi bila dibutuhkan, tanpa menambah halaman fiktif.
Tuliskan keputusan tersebut sebelum debugging agar developer dan analis menguji perilaku yang sama.
Temukan seluruh pemicu page view
Inventaris Google tag pada kode, Google Tag Manager, pengaturan Enhanced Measurement, serta callback router. Satu implementasi bisa mempunyai beberapa jalur yang semuanya terlihat masuk akal saat diperiksa sendiri-sendiri.
GA4 dapat mengirim page view dari pemuatan halaman dan perubahan browser history. Jika kamu mengendalikan page view secara manual, periksa keduanya. send_page_view: false pada konfigurasi tag tidak otomatis mematikan page view dari perubahan history pada Enhanced Measurement. Panduan pengukuran pageviews.
Pilih jalur yang sesuai dengan arsitektur. Pengaturan otomatis berbasis history dapat dipakai pada implementasi yang cocok; jalur router atau event khusus memerlukan pengelolaan manual yang jelas. Ikuti panduan sesuai penggunaan Google tag atau GTM, dan jangan mencampurkan keduanya tanpa desain deduplikasi. Panduan pengukuran SPA.
Periksa konteks sesudah navigasi selesai
Event yang jumlahnya benar masih bisa membawa judul atau lokasi lama. Router mungkin memperbarui URL terlebih dahulu, kemudian mengambil konten dan mengganti judul. Jika event dikirim di tengah proses, laporan dapat memasangkan URL baru dengan judul lama.
Untuk jalur manual, tentukan titik ketika navigasi berhasil dan metadata tujuan siap. Pembatalan navigasi, error, serta redirect internal perlu mempunyai perilaku yang disepakati. Jangan hanya memakai jeda tetap beberapa milidetik untuk menutupi urutan yang belum dipahami.
Periksa page_location, page_title, dan page_referrer pada event. Pada navigasi internal yang diukur sebagai halaman baru, referrer perlu mencerminkan konteks sebelumnya sesuai implementasi. Pastikan parameter URL yang membawa data pribadi tidak ikut terkirim.
Gunakan matriks uji, bukan satu klik homepage
Berikut contoh ekspektasi untuk aplikasi tutorial tadi. Sesuaikan keputusan halaman dengan produkmu:
| Tindakan | Page view yang diharapkan | Konteks yang diperiksa |
|---|---|---|
| Membuka URL panduan secara langsung | 1 | Judul dan lokasi panduan |
| Daftar menuju panduan | 1 tambahan | Lokasi tujuan dan halaman sebelumnya |
| Tombol Back menuju daftar | 1 tambahan | Konteks daftar kembali benar |
| Reload panduan | 1 untuk pemuatan baru | Tidak ditambah lagi oleh inisialisasi router |
| Membuka panel ukuran teks | 0 tambahan | Bukan halaman baru menurut kontrak |
Normalisasi URL dengan replaceState |
Sesuai keputusan, biasanya tanpa halaman tambahan | Tidak menggandakan pemuatan yang sama |
Angka ini adalah ekspektasi ilustratif, bukan standar universal untuk setiap aplikasi. Yang perlu konsisten adalah hubungan antara definisi layar dan kejadian yang dikirim.
Aktifkan mode debug pada lingkungan yang sesuai. Jalankan tindakan satu per satu, catat waktu, lalu lihat urutan page_view pada DebugView dan request browser. Hindari membuka banyak tab uji bersamaan ketika sedang menelusuri satu urutan.
Contoh: satu navigasi menghasilkan dua event
Misalnya perpindahan ke panduan mengirim event dari history otomatis dan callback router. Kedua event mempunyai lokasi sama dengan selisih waktu singkat. Ini hipotesis ilustratif yang harus dibuktikan melalui konfigurasi dan trigger.
Matikan jalur yang memang tidak dipilih pada lingkungan uji, lalu ulangi seluruh matriks. Jangan sekadar mengurangi angka laporan menjadi separuh. Navigasi langsung mungkin hanya terhitung sekali, sedangkan navigasi internal dua kali; pembagian seragam akan merusak bagian data yang semula benar.
Jika duplikasi hilang tetapi direct load tidak lagi tercatat, kamu menghapus lebih dari pemicu ganda. Pulihkan pengiriman awal yang diperlukan, lalu pisahkan kepemilikannya dari navigasi lanjutan.
Simpan bukti setelah perbaikan
Catat versi tag dan aplikasi, daftar pemicu yang aktif, hasil matriks, serta tanggal penerapan. Jelaskan kepada pembaca laporan bahwa jumlah views sebelum dan sesudah perbaikan mungkin tidak langsung sebanding.
Page view yang sehat membantu membaca perjalanan pembaca, tetapi tidak membuktikan indexing, kualitas konten, atau keberhasilan SEO. Untuk pertanyaan pencarian, tetap pasangkan dengan sumber pengukuran yang sesuai.
Langkah berikutnya: pilih satu perjalanan tiga layar, tulis jumlah event yang diharapkan, kemudian cocokkan urutan aktualnya. Perjalanan kecil yang dapat diulang lebih berguna daripada mencoba memahami seluruh aplikasi dari satu grafik total.
