Periksa retensi GA4 sebelum menjanjikan perbandingan perilaku pembaca dengan tahun lalu. Laporan agregat dapat masih menampilkan histori, sementara rincian yang dibutuhkan pada Explorations sudah tidak tersedia. Memperpanjang retensi sekarang tidak menghidupkan data yang sudah terhapus.

Keputusan retensi sebaiknya berangkat dari pertanyaan yang ingin dijawab. Website yang hanya memeriksa kunjungan bulanan mempunyai kebutuhan berbeda dari tim yang ingin membandingkan jalur pembaca sebelum dan sesudah perubahan navigasi selama beberapa musim.

Sebelum memilih data yang disimpan, periksa scope akuisisi GA4 agar dimensi dan metrik yang diekspor sesuai dengan pertanyaan laporan.

Bedakan laporan agregat dan analisis terperinci

Pengaturan retensi GA4 mengatur data tingkat pengguna dan event yang terkait. Untuk properti standar, pilihan umumnya 2 atau 14 bulan, dengan pengecualian menurut ukuran dan jenis data. Pengaturan ini tidak memengaruhi laporan standar yang sudah diagregasikan; Explorations dan laporan funnel mempunyai ketergantungan pada retensi tersebut. Dokumentasi retensi Google Analytics.

Karena itu, pertanyaan “data tahun lalu masih ada?” perlu diikuti pertanyaan lain: data apa, pada laporan mana, dan dengan rincian apa? Jawaban dari satu grafik kunjungan belum membuktikan semua dimensi atau jalur pengguna lama masih dapat dianalisis.

Jangan menaikkan retensi hanya untuk berjaga-jaga tanpa tujuan. Tentukan kebutuhan analisis, batas penyimpanan organisasi, serta siapa yang bertanggung jawab terhadap akses dan penghapusan.

Buat matriks kebutuhan histori

Berikut contoh ilustratif untuk blog edukasi yang memiliki lonjakan pembaca saat tahun ajaran baru:

Pertanyaan Kebutuhan waktu Pemeriksaan awal
Apakah sesi organik bulan ini berubah? Dua bulan yang sebanding Laporan akuisisi dengan filter konsisten
Apakah jalur baca berbeda dari musim lalu? Periode musim yang sama tahun sebelumnya Apakah rincian yang dibutuhkan masih tersedia di Explore?
Apakah kategori baru lebih banyak dibaca? Sebelum dan sesudah kategori diterapkan Tanggal mulai pengiriman kategori dan definisinya
Apa yang terjadi sebelum tag diperbaiki? Periode historis yang bermasalah Apakah data pernah terkumpul secara benar?

Baris terakhir tidak dapat diselesaikan hanya dengan retensi panjang. Data yang tidak pernah dikumpulkan berbeda dari data yang dikumpulkan lalu terhapus. Simpan kedua keadaan itu sebagai keterbatasan yang berbeda.

Tentukan juga tanggal terakhir yang dibutuhkan. Membandingkan bulan Oktober dengan Oktober tahun lalu bukan sekadar memilih “12 bulan terakhir”; kamu memerlukan rentang yang mencakup kedua bulan tersebut.

Periksa konfigurasi dan bukti ketersediaan

Dengan akses yang sesuai, buka bagian Admin lalu pengaturan Data retention pada properti yang benar. Catat pilihan yang aktif dan waktu pemeriksaannya. Nama menu dapat mengikuti bahasa antarmuka, sehingga cocokkan label pengaturan dengan dokumentasi resmi, bukan screenshot lama.

Kemudian buka analisis yang benar-benar dibutuhkan. Pilih periode lama dan dimensi yang telah disepakati. Periksa apakah data tersedia, apakah ada pembatasan kualitas data, dan kapan instrumentasinya mulai mengirim informasi tersebut.

Simpan empat hal: property, pengaturan retensi, rentang yang diuji, dan hasil uji. “Retensi sudah 14 bulan” tidak cukup sebagai bukti bahwa dataset yang kamu butuhkan lengkap selama 14 bulan.

Jika tim memakai beberapa properti, ulangi pada masing-masing properti. Pengaturan akun lain atau situs lain tidak membuktikan konfigurasi website yang sedang dianalisis.

Contoh: perubahan setting setelah sebagian histori hilang

Misalnya pada 20 Oktober sebuah tim menemukan retensi pendek, lalu memilih periode lebih panjang sesuai kebutuhannya. Ini contoh ilustratif; kita tidak sedang memeriksa akun tertentu.

Data lama yang masih tersimpan dapat mengikuti periode retensi yang diperpanjang. Data yang sudah terhapus tidak kembali. Dokumentasi Google juga menjelaskan adanya jeda 24 jam untuk menerapkan perubahan serta proses penghapusan bulanan. Jangan mengasumsikan perubahan hanya berlaku untuk event yang akan datang, dan jangan mengasumsikan semua histori lama pulih.

Rencana yang masuk akal adalah memeriksa batas tanggal yang benar-benar tersedia, menandai gap, lalu mulai membangun seri yang dapat dibandingkan. Jika pembanding tahunan tidak tersedia, gunakan laporan agregat yang sah untuk pertanyaan yang lebih sederhana, dengan batasnya dinyatakan.

Mengganti pertanyaan lebih jujur daripada membuat angka perkiraan terlihat seperti data akun.

Tentukan apa yang perlu disimpan terpisah

Untuk laporan rutin, ekspor tabel agregat yang memang diperlukan beserta definisi metrik, filter, zona waktu, dan tanggal pengambilan. Nama file yang rapi tidak menggantikan kontrak data. Tanpa filter yang tercatat, tabel bulan depan dapat memakai definisi berbeda.

Jika kebutuhan membutuhkan data event mentah, evaluasi integrasi penyimpanan seperti BigQuery sebagai proyek tersendiri. Periksa biaya, akses, cakupan ekspor, dan kebijakan retensinya. Menghubungkan layanan itu sekarang juga bukan cara otomatis mengisi semua periode sebelum integrasi. Penjelasan BigQuery Export GA4.

Jangan membuat ekspor data pengguna ke spreadsheet publik hanya untuk menghindari batas suatu laporan. Simpan informasi minimum yang diperlukan dengan kontrol akses yang sesuai.

Jadwalkan pemeriksaan pada perubahan yang relevan

Tinjau kembali kebutuhan histori ketika ada migrasi properti, perubahan tag, penambahan dimensi, atau kebutuhan analisis baru. Catat tanggal perubahan definisi sehingga perbandingan tahunan tidak mencampurkan dua cara pengukuran tanpa penjelasan.

Langkah awal yang bisa kamu kerjakan hari ini adalah memilih satu pertanyaan musiman, menghitung rentang tanggal yang dibutuhkan, lalu mencoba laporan itu dengan rincian yang sebenarnya. Dari sana, keputusan retensi mempunyai alasan yang jelas dan batas data yang dapat dibuktikan.