Laporan properti GA4 Anda mencatat 4,180 pembelian bulan lalu. Tabel pesanan Anda menunjukkan 4,690. Jika ditanya mana yang benar, jawaban jujurnya adalah tidak ada yang benar, sampai Anda dapat menjelaskan ke mana perginya 510 pesanan yang hilang tersebut. Ini bukan masalah kerapian. Setiap hasil eksperimen dan setiap skor prioritas yang Anda hasilkan dihitung berdasarkan angka yang salah dengan jumlah yang tidak diketahui dan ke arah yang tidak diketahui pula.
Google memperlakukan sebagian besar data yang tidak terukur sebagai hal yang normal: pemodelan perilaku untuk mode persetujuan tidak diaktifkan sampai properti tersebut mencatatnya. setidaknya 1,000 acara per hari dengan analytics_storage='denied' selama minimal 7 hariDi bawah itu, data yang hilang akan tetap hilang.
Ini ditujukan bagi siapa pun yang bertanggung jawab atas analitik atau CRO di tim e-commerce. Pada akhirnya, Anda akan memiliki tabel rekonsiliasi, dekomposisi kesenjangan Anda ke dalam penyebab yang teridentifikasi dengan pengujian untuk masing-masing penyebab, dan angka toleransi yang dapat Anda pertahankan.
Apa sebenarnya yang diukur oleh rekonsiliasi pembelian?
Rekonsiliasi bukanlah "menyamakan angka". Angka-angka tersebut tidak akan pernah cocok, dan tim yang memaksanya untuk cocok biasanya telah melakukan sesuatu yang lebih buruk daripada membiarkan selisihnya begitu saja. Rekonsiliasi menjawab tiga pertanyaan: seberapa besar selisihnya, mekanisme spesifik apa yang menyebabkannya, dan berapa banyak yang dapat dipulihkan dengan biaya berapa. Kami menjalankannya sebelum melakukan eksperimen apa pun, karena pengujian yang diukur pada peristiwa konversi yang secara diam-diam menghilangkan sebagian pesanan yang tidak diketahui bukanlah sebuah eksperimen.
Langkah 1: ambil dua tabel yang dapat digabungkan berdasarkan ID pesanan
Anda memerlukan satu baris per pesanan, dari kedua sistem, untuk rentang kalender yang sama, dengan kunci yang ada di kedua sisi.
- backend: ID pesanan, stempel waktu pembuatan dalam zona waktu pelaporan properti, nilai pesanan berdasarkan pajak dan pengiriman yang sama seperti yang Anda konfigurasikan di GA4, metode pembayaran, perangkat, negara, status.
- GA4: Ekspor BigQuery, bukan UI-nya. Kueri
purchaseacara denganecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, kategori perangkat, dan sumber lalu lintas.
Gunakan BigQuery dengan bijak. Data yang dimodelkan dari mode persetujuan muncul dalam laporan standar GA4 dan beberapa eksplorasi, tetapi Google menyatakan bahwa itu adalah tidak Dalam ekspor BigQuery, audiens, penjelajah pengguna, eksplorasi kohort atau retensi, atau metrik prediktif. Bandingkan UI dengan tabel pesanan Anda dan Anda membandingkan perkiraan dengan fakta.
Kemudian lakukan full outer join pada ID pesanan. Sekarang Anda memiliki tiga bucket: di keduanya, hanya backend, dan hanya GA4. Bucket ketiga lebih kecil tetapi paling diagnostik.
Langkah 2: ungkapkan kesenjangan tersebut dengan tiga cara, bukan hanya satu cara.
Persentase bulanan tunggal menyembunyikan semuanya. Hitung ketiganya:
- Selisih jumlah pesanan: (pesanan backend dikurangi pembelian GA4 yang cocok) / pesanan backend. Ini mengisolasi kehilangan pelacakan.
- Kesenjangan pendapatan: Perhitungan yang sama berlaku untuk nilai. Jika selisih jumlah adalah 3% dan selisih pendapatan adalah 11%, Anda tidak memiliki masalah pelacakan, tetapi masalah definisi nilai (pajak, pengiriman, diskon, mata uang, kartu hadiah).
- Varians gap harian: Plotlah selisih jumlah pesanan harian. Garis datar berarti penyebab struktural seperti persetujuan atau penghambat. Lonjakan berarti peluncuran, lonjakan kampanye, atau insiden penyedia pembayaran.
Langkah 3: Uraikan kesenjangan tersebut menjadi penyebab-penyebab yang teridentifikasi
Kerjakan tabel ini. Setiap penyebab memiliki tes yang dapat mengkonfirmasi atau menyingkirkannya dalam waktu kurang dari satu jam.
| Menyebabkan | Bagaimana cara mengujinya? | Tanda tangan dalam data |
|---|---|---|
| Persetujuan ditolak, tag tidak pernah aktif. | Bandingkan log status persetujuan CMP Anda dengan sesi GA4 untuk periode yang sama. | Persentase harian stabil; terkonsentrasi pada lalu lintas Uni Eropa dan Turki. |
| Pemblokir iklan dan pelacak | Hitung jumlah permintaan log server untuk URL konfirmasi, bandingkan dengan peristiwa pembelian GA4 pada URL tersebut. | Mempengaruhi desktop, Firefox, dan browser privasi; stabil seiring waktu. |
| Halaman konfirmasi tidak pernah dimuat. | Hitung pesanan khusus backend yang URL konfirmasinya tidak pernah diminta dalam log server. | Berfokus pada metode pembayaran pengalihan bank dan 3DS. |
| Peristiwa pembelian ganda | Hitung peristiwa pembelian GA4 per transaction_id | GA4 melebihi kapasitas backend pada beberapa hari; halaman yang sering di-refresh dan sering diklik kembali akan mengalami beban yang berat. |
| Tautan lintas domain rusak | Periksa apakah _gl selamat sampai perjalanan pulang dari penyedia pembayaran | Pembelian lahan dalam sesi baru yang dikaitkan dengan domain pembayaran sebagai rujukan. |
| Pengaturan ulang masa berlaku cookie | Segmentasikan tingkat pengguna baru berdasarkan peramban. | Peningkatan jumlah pengguna baru dan lalu lintas langsung di Safari dan iOS |
| Dimodelkan versus mentah | Bandingkan total UI GA4 dengan BigQuery untuk rentang tanggal yang sama. | Kedua angka Google tersebut berbeda bahkan sebelum Anda membuka tabel pesanan. |
| Definisi nilai | Hitung ulang pendapatan backend dengan dan tanpa pajak, biaya pengiriman, dan diskon. | Jumlahnya cocok, tapi pendapatannya tidak cocok. |
| Batas zona waktu | Gabungkan kembali ke minggu penuh | Selisihnya menyusut mendekati nol pada granularitas mingguan. |
Dua di antaranya membutuhkan perhatian ekstra. transaction_id Deduplikasi hanya berfungsi pada aliran web, bukan aliran aplikasi, dan Google memperingatkan bahwa mengirimkan string kosong akan menyebabkan Analytics melakukan deduplikasi. setiap acara pembelian yang diselenggarakan transaction_id=''Satu bug itu bisa menghapus sebagian besar data dalam sehari. Selain itu, daftar rujukan yang tidak diinginkan dibatasi hingga 50 domain per aliran data, yang menjadi masalah jika Anda menggunakan beberapa penyedia layanan pembayaran, dompet digital, dan halaman bank.
[DATA INTERNAL YANG DIBUTUHKAN: distribusi yang diamati dari sembilan penyebab ini di seluruh kegiatan rekonsiliasi Switas, sehingga pembaca dapat melihat mana yang biasanya mendominasi.]
Langkah 4: tetapkan toleransi yang dapat Anda pertahankan
Google tidak menerbitkan angka selisih yang dapat diterima, dan pernyataan yang banyak dikutip "5% tidak masalah" tidak muncul dalam dokumentasi Google mana pun yang dapat kami temukan. Tetapkan sendiri angka selisih Anda, berdasarkan dekomposisi dan bukan hanya berdasarkan angkanya saja.
| Selisih jumlah pesanan bulanan | Bacaan | Tindakan |
|---|---|---|
| Hingga 2% | Batas zona waktu dan deduplikasi normal | Catat penyebabnya, periksa kembali setiap triwulan. |
| 2% untuk 5% | Hanya dapat diterima jika setiap poin dikaitkan dengan penyebab yang disebutkan namanya. | Dokumentasikan, lalu lanjutkan ke eksperimen. |
| 5% untuk 10% | Setidaknya satu penyebab struktural belum teratasi. | Perbaiki dulu sebelum mempercayai angka konversi absolut. |
| Di atas 10% | Tidak cocok untuk eksperimen | Hentikan penggunaan pembelian GA4 sebagai metrik eksperimen utama sampai masalah ini diperbaiki. |
Ini adalah ambang batas operasional kami, bukan standar industri. Kualifikasinya adalah intinya: 3% yang tidak dapat dijelaskan lebih buruk daripada 8% yang dapat dijelaskan.
Langkah 5: perbaiki dalam urutan yang menghasilkan pemulihan pesanan terbanyak per jam kerja.
- Definisi nilai dan zona waktu. Konfigurasi, bukan rekayasa, dan biasanya memakan waktu satu sore.
- ID transaksi duplikat dan kosong. Satu perbaikan dataLayer.
- Rujukan lintas domain dan yang tidak diinginkan. Konfigurasikan keduanya, lalu uji ulang jalur pengembalian pembayaran langsung, bukan jalur pengujian.
- Peristiwa pembelian sisi server. Kirim pembelian dari sistem pemesanan Anda dengan Protokol Pengukuran, menggunakan
client_idTag web Anda telah dibuat. Google memerlukan peristiwa ini dalam waktu 48 jam sejak stempel waktu peristiwa sisi klien asli, atau atribusi mungkin tidak diproses seperti yang diharapkan. Inilah yang memulihkan pesanan yang hilang karena pemblokir dan halaman konfirmasi yang tidak pernah ditampilkan. - Arsitektur persetujuan. Yang paling lambat dan paling politis. Perlakukan sisanya sebagai kesenjangan yang diketahui, terukur, dan terdokumentasi.
Apa yang berubah jika Anda berjualan di Turki atau Uni Eropa?
Dua fakta regional mengubah angka-angka tersebut.
Di Turki, persetujuan juga bersifat sukarela, tetapi tanpa jaring pengaman dari Google. Otoritas perlindungan data Turki mendenda operator situs web sebesar 300,000 TL dalam keputusan 2022/1358 (23 Desember 2022) karena menjalankan cookie iklan dan pemasaran tanpa dasar hukum, dan mewajibkan persetujuan aktif untuk cookie yang tidak penting. Banyak situs web Turki menanggapi dengan banner yang langsung memblokir tag Google, alih-alih banner yang mengirimkan sinyal persetujuan. Perbedaan itu mahal: pemodelan membutuhkan analytics_storage='denied' Peristiwa harus ada. Sebuah banner yang tidak menampilkan apa pun tidak memberi Google bahan untuk membuat model, sehingga data tersebut hilang dan tidak dapat diestimasi.
Proses pengembalian dana 3DS Turki dilakukan melalui pos. Dengan iyzico, pedagang menampilkan halaman 3DS yang telah didekode dan, setelah konfirmasi OTP, iyzico mengarahkan ke halaman pedagang tersebut. callbackUrl dengan status, paymentId ke mdStatusPengembalian berbasis POST persis seperti yang disebut Google sebagai pelanggaran pengukuran lintas domain, karena pengalihan dapat menghilangkan _gl sebelum tujuan pengiriman dimuat. Jika selisihnya terletak pada pembayaran kartu dan hampir nol untuk pembayaran tunai saat pengiriman, inilah alasannya.
Dua klaim yang banyak diulang-ulang namun tidak dapat kami verifikasi.
"Safari membatasi masa berlaku cookie pihak pertama hingga 7 hari." Tidak tepat. Dokumentasi WebKit menyatakan bahwa ITP menghapus cookie JavaScript dan penyimpanan lain yang dapat ditulis oleh skrip setelah 7 hari. tidak ada interaksi penggunaSelain itu, sistem membatasi cookie JavaScript hingga 24 jam ketika halaman arahan diakses melalui tautan dari domain iklan baris. Pengujian Simo Ahava menemukan bahwa penghitung waktu dihitung berdasarkan hari penggunaan browser, bukan hari kalender, sehingga pelanggan tetap dapat menyimpan pengenal tersebut lebih dari seminggu.
"Selisih sebesar 5% dapat diterima." Kami tidak menemukan sumber Google untuk angka ini. Angka ini beredar melalui blog vendor dan jawaban forum. Gunakanlah sebagai cerita rakyat, bukan sebagai patokan.
Di mana metode ini gagal
Ini tidak mencakup aliran aplikasi, di mana transaction_id Deduplikasi tidak berlaku, begitu pula model berlangganan dan pengiriman sebagian, di mana "pesanan" bukanlah satu peristiwa. Ia tidak dapat memulihkan identitas pengguna yang menolak persetujuan, hanya memperkirakan volumenya. Ia tidak memperbaiki atribusi saluran, masalah terpisah dan lebih sulit. Dan ia mengasumsikan tabel pesanan Anda bersih: jika pesanan yang dibatalkan dan diblokir karena penipuan dihitung secara tidak konsisten di kedua sisi, Anda akan mencari celah yang hanya ada dalam kueri Anda.
Pertanyaan yang sering diajukan
Seberapa sering kita harus menjalankan ini? Lakukan dekomposisi penuh sekali, lalu grafik gap harian. Jalankan kembali dekomposisi penuh setelah setiap perubahan checkout, CMP, penyedia pembayaran, atau pengelola tag.
Mengapa tidak menggunakan antarmuka GA4 sebagai pengganti BigQuery? Antarmuka dapat mencakup pengguna dan sesi yang dimodelkan yang tidak disertakan dalam ekspor, sehingga kedua angka Google tersebut saling bertentangan. Penyesuaian terhadap perkiraan membuat kesenjangan tersebut tidak mungkin diuraikan.
Apakah penandaan sisi server akan menutup kesenjangan sepenuhnya? Tidak. Sistem ini memulihkan pesanan yang hilang karena pemblokiran dan halaman konfirmasi yang tidak pernah ditampilkan. Sistem ini tidak memulihkan pengguna yang menolak persetujuan.
GA4 lebih tinggi daripada backend kita. Apakah itu mungkin? Ya. Biasanya berupa duplikasi pembelian akibat penyegaran halaman, halaman kosong, atau halaman yang digunakan kembali. transaction_idatau perintah pementasan yang diarahkan ke properti produksi.
Apakah mode persetujuan dapat mengatasi kesenjangan persetujuan di Turki? Sebagian. Sinyal yang ditolak memungkinkan pemodelan, dengan tunduk pada ambang batas volume Google. Ini bukan pengganti banner resmi menurut peraturan Turki.
Apa yang dianggap sebagai jeda yang baik? Suatu kondisi di mana setiap poin persentase memiliki nama. Angka 8% yang terdokumentasi lebih baik daripada angka 3% yang tidak dapat dijelaskan.
Apakah kita perlu menyusun ulang laporan-laporan historis setelah memperbaiki hal ini? Tidak. Beri catatan pada tanggal perbaikan dan perlakukan periode tersebut sebagai rangkaian terpisah. Menyatakan ulang konversi yang dilacak akan merusak jejak audit.
Bisakah kita menjalankan pengujian A/B saat selisihnya di atas 10%? Jalankan pengujian berdasarkan metrik relatif yang diukur di dalam alat pengujian, tetapi jangan melaporkan dampak pendapatan absolut dari GA4 sampai kesenjangan tersebut diuraikan.
Lakukan rekonsiliasi ini di toko Anda sendiri bulan ini, atau minta tim analitik kami untuk menjalankannya bersama Anda. dan memberikan Anda rinciannya, toleransinya, dan urutan perbaikannya.
sumber
- [GA4] Pemodelan perilaku untuk mode persetujuan, Bantuan Google Analytics
- [GA4] Minimalkan kejadian kunci duplikat dengan ID transaksi, Bantuan Google Analytics
- [GA4] Rujukan yang tidak diinginkan, Bantuan Google Analytics
- [GA4] Pengukuran lintas domain, Bantuan Google Analytics
- Kirim peristiwa Measurement Protocol ke Google Analytics, Google for Developers
- Parameter mode persetujuan, dokumentasi Google Tag Platform
- Pencegahan Pelacakan di WebKit
- Batas Masa Berlaku Cookie JavaScript Dihapus di Browser WebKit, Simo Ahava
- KVKK Kurul karari 2022/1358, 23 Desember 2022
- Implementasi 3DS, dokumentasi pengembang iyzico
