Purchase events, pesanan dan pembeli unik mengukur unit berbeda. Satu pembeli dapat memiliki beberapa transaksi sah, sementara satu transaksi dapat dikirim melalui beberapa jalur tracking. Rekonsiliasi perlu membedakan kedua keadaan itu sebelum kamu menghitung AOV, CPA atau biaya pelanggan baru.

Saya akan memakai contoh toko kecil dengan order ID dan buyer ID sintetis. Tujuannya membangun logika yang bisa diperiksa; kamu tidak perlu membagikan data pribadi pelanggan untuk membuat latihan ini.

Mulai dari tabel transaksi bisnis

Contoh ini hanya memakai transaksi yang memenuhi definisi selesai pada toko ilustratif. Status pembayaran dan pembatalan sudah diperiksa.

Buyer Order Kejadian Nilai neto
A O-101 Pembelian awal Rp100.000
A O-102 Upsell sebagai transaksi terpisah Rp20.000
B O-103 Pembelian awal Rp80.000

Ada tiga order, dua pembeli, dan pendapatan neto Rp200.000. AOV per order adalah Rp200.000 dibagi tiga, sekitar Rp66.667. Revenue per buyer adalah Rp200.000 dibagi dua, Rp100.000.

Kedua angka benar untuk pertanyaan masing-masing. Menggunakan Rp100.000 sebagai AOV per order akan mencampur unit pembeli dan transaksi.

Definisi order selesai juga perlu mengikuti model bisnis. Pesanan dibuat, pembayaran lunas, pesanan COD diterima, dan refund adalah status berbeda. Tuliskan status mana yang masuk laporan dan kapan status tersebut dinilai.

Pisahkan transaksi dari pengiriman event

Order O-101 bisa menghasilkan event browser dan event server yang mewakili tindakan sama. Dua pengiriman itu tidak berarti dua penjualan.

Pada identifikasi event browser/server, event name dan event ID digunakan bersama untuk mengenali event yang sama. Karena itu, periksa keselarasan identitas pada integrasi yang dipakai, bukan hanya kesamaan nilai atau waktu. Kecocokan tersebut perlu dibuktikan melalui pengujian serta hasil diagnosis integrasi.

Jangan memakai buyer ID sebagai satu event ID untuk seluruh pembelian orang tersebut. A pada contoh mempunyai dua transaksi sah. Identitas yang terlalu luas berisiko menyamarkan peristiwa yang sebenarnya berbeda. Sebaliknya, ID baru setiap kali halaman konfirmasi dimuat ulang dapat membuat satu tindakan terlihat seperti banyak peristiwa jika implementasinya tidak benar.

Simpan hubungan order ID, event name, event ID, sumber pengiriman, waktu kejadian, nilai dan currency dalam bukti pengujian yang aksesnya dibatasi. Log pengiriman dan hasil atribusi tetap merupakan lapisan berbeda.

Periksa apakah upsell transaksi baru atau pembaruan order

Pada tabel awal, upsell Rp20.000 adalah transaksi terpisah O-102. Maka total Rp100.000 dan Rp20.000 masuk sebagai dua transaksi yang berbeda.

Situasinya berbeda jika sistem hanya memperbarui order O-101 dari Rp100.000 menjadi Rp120.000. Mengirim Rp100.000 lalu Rp120.000 sebagai dua pembelian baru dapat menghasilkan nilai Rp220.000, padahal pembeli hanya membayar Rp120.000.

Jangan mengatasi masalah itu dengan menebak bahwa platform akan memahami nilai kedua sebagai pengganti. Tinjau perilaku integrasi, definisi order, serta mekanisme pembaruan yang didukung. Jika tambahan pembayaran memang diperlakukan sebagai transaksi baru, nilai tambahannya dan identitas transaksinya harus jelas.

Tugas pemeriksaan adalah memastikan total nilai transaksi sah kembali ke penerimaan dan pencatatan bisnis, tanpa menjumlahkan nilai kumulatif dua kali.

Hitung biaya dengan denominator yang sesuai

Misalkan spend yang relevan pada contoh Rp60.000 dan ketiga transaksi berada pada scope pengukuran yang sama. Cost per order adalah Rp60.000 dibagi tiga, yaitu Rp20.000.

Jika kedua buyer benar-benar pelanggan baru dan cakupan akuisisinya sesuai, media CAC terhadap dua pelanggan baru adalah Rp30.000. Jika B ternyata pelanggan lama, denominator pelanggan baru menjadi satu dan media CAC pada scope yang sah perlu dihitung ulang.

Namun kamu tidak boleh membagi spend satu campaign dengan seluruh pelanggan baru toko lalu menyebutnya CAC campaign tanpa dasar hubungan yang sesuai. Definisikan channel, cohort, periode dan cakupan biaya melalui kamus metrik. CAC seluruh biaya akuisisi juga dapat mencakup biaya lain di luar spend media.

Gunakan paket kasus uji yang kecil

Siapkan kasus pembelian tunggal, browser/server untuk transaksi sama, reload halaman konfirmasi, upsell transaksi terpisah, pembaruan order, pembatalan dan refund. Untuk setiap kasus, tulis jumlah order serta nilai bisnis yang seharusnya tercatat sebelum melakukan pengujian.

Gunakan transaksi uji dan cara pengujian yang sesuai lingkungan kamu. Jangan mengirim purchase fiktif ke sistem produksi hanya agar indikator terlihat aktif. Sesudah pengujian, cocokkan log dan hasil yang tersedia dengan nilai harapan.

Jika laporan memiliki custom conversion per kategori, satu order multi-item dapat memenuhi beberapa kategori. Itu bukan alasan menjumlahkan seluruh kolom sebagai unique orders. Lanjutkan dengan pengujian filter produk dan overlap.

Simpan tiga total yang berbeda

Pertahankan total transaksi sah, total nilai neto, dan jumlah pembeli unik menurut identitas yang tersedia. Tambahkan status keterbatasan, misalnya buyer yang tidak dapat dihubungkan secara konsisten. Jangan memaksakan keunikan jika datanya tidak mendukung.

Bandingkan hasil bisnis tersebut dengan lapisan event dan atribusi menggunakan rekonsiliasi Meta Ads dan toko. Untuk funnel, lanjutkan ke denominator peristiwa versus pengguna.

Lembar rekonsiliasi selesai ketika setiap selisih dapat ditelusuri atau ditandai terbuka, dan orang lain dapat menghitung ulang totalnya. Pilih artikel lain sesuai kebutuhanmu di topik Meta Ads.