Filter produk pada custom conversion perlu diuji dengan kasus yang seharusnya masuk dan kasus yang seharusnya tidak masuk. Periksa format data, identitas produk, operator yang tersedia, dan overlap antar-kategori sebelum memakai hasilnya untuk keputusan campaign.
Satu transaksi contoh yang berhasil terhitung belum membuktikan filter benar. Aturan dapat menerima transaksi yang salah atau melewatkan sebagian pembelian yang seharusnya cocok.
Lihat data yang benar-benar dikirim
Mulai dari contoh event yang sah melalui alat pemeriksaan integrasi kamu. Catat apakah produk dikirim sebagai satu string, daftar ID, objek item, kategori, atau kombinasi parameter.
Periksa juga jenis ID: product ID, variant ID, SKU internal, dan ID katalog belum tentu sama. Produk dengan dua ukuran bisa mempunyai satu parent product ID tetapi beberapa variant ID. Jika filter memakai identitas yang salah, sebagian pembelian dapat hilang dari subset.
Jangan menulis aturan hanya berdasarkan URL halaman produk yang ditampilkan pada iklan. Pembeli dapat memilih produk berbeda atau menambah beberapa item sebelum checkout. Gunakan kontrak event dan conversion untuk menentukan data yang mewakili transaksi sebenarnya.
Buat tabel nilai harapan sebelum menguji
Contoh hipotetis ini ingin mendeteksi order yang benar-benar mengandung SKU1. Operator dan representasi aktual tetap perlu disesuaikan dengan integrasi serta pilihan akun.
| Kasus | Data produk ilustratif | Seharusnya cocok? |
|---|---|---|
| Produk target saja | SKU1 | Ya |
| Produk berbeda yang namanya mirip | SKU10 | Tidak |
| Basket campuran | SKU1 dan SKU2 | Ya |
| Produk lain | SKU2 | Tidak |
| Identitas produk tidak terkirim | Kosong | Belum dapat dinilai sebagai cocok |
Jika aturan membaca data sebagai string substring, pencarian SKU1 dapat menerima SKU10. Jika datanya daftar dengan pencocokan elemen penuh, perilakunya dapat berbeda. Karena itu, saran selalu memakai contains atau selalu memakai equals tidak cukup.
Uji operator yang benar-benar tersedia pada representasi data yang kamu gunakan. Jika fitur tidak dapat menyatakan kondisi dengan aman, pertimbangkan perbaikan parameter atau pengukuran pada sistem lain, lalu jangan menyajikan subset yang keliru sebagai benar.
Tambahkan kasus yang mudah terlewat
Periksa huruf besar/kecil, spasi, prefix, pemisah daftar, produk varian dan perubahan katalog. Jangan menganggap sistem menormalisasi semuanya dengan cara yang kamu inginkan.
Untuk filter berbasis URL, uji query parameter, trailing slash, halaman terjemahan, redirect dan halaman konfirmasi yang dapat dibuka tanpa transaksi baru. URL yang cocok tidak selalu membuktikan pembelian sah.
Gunakan transaksi uji dan lingkungan yang sesuai. Simpan input, hasil harapan, hasil teramati serta bukti. Hindari mengirim data pelanggan atau purchase palsu ke produksi sekadar untuk membuat indikator hijau.
Pahami overlap kategori
Misalkan contoh toko mempunyai tiga order: O1 berisi rak, O2 berisi meja, dan O3 berisi rak serta meja. Custom conversion kategori rak dapat menghitung O1 dan O3: dua order. Kategori meja dapat menghitung O2 dan O3: dua order.
Jumlah kedua kolom adalah empat, sementara unique orders hanya tiga. Tidak ada transaksi keempat; O3 memenuhi dua definisi.
Tulis apakah kategori dimaksudkan saling eksklusif atau boleh overlap. Jika kamu membutuhkan total unik, gunakan identitas order dan logika gabungan yang tepat pada data yang tersedia. Jangan menjumlahkan kolom subset begitu saja. Lihat rekonsiliasi event, order dan buyer untuk dasar keunikannya.
Jangan menganggap nilai subset sebagai revenue item
Order O3 pada contoh bernilai Rp500.000: rak Rp200.000 dan meja Rp300.000. Jika event membawa nilai seluruh order, label kategori rak belum tentu mengubah nilai itu menjadi Rp200.000.
Periksa bagaimana nilai conversion yang tampil dibentuk. Jangan mengklaim Rp500.000 sebagai revenue rak dan Rp500.000 lagi sebagai revenue meja tanpa menjelaskan overlap dan basis nilai. Revenue kategori berbasis item memerlukan data serta alokasi yang sesuai.
Perbedaan ini penting saat menilai product mix dan kontribusi melalui hubungan ROAS dengan biaya produk.
Tentukan bukti kelulusan filter
Filter layak dipakai setelah kasus positif diterima, kasus negatif ditolak, data kosong terlihat, dan overlap serta nilai sudah dipahami. Catat batas yang belum dapat diuji.
Tambahkan tanggal, versi aturan, owner serta contoh event yang sudah disanitasi. Saat integrasi checkout atau katalog berubah, jalankan kembali paket kasus yang sama. Perubahan schema dapat merusak filter meskipun nama conversion tidak berubah.
Setelah definisinya dapat dipercaya, tentukan apakah subset hanya diperlukan untuk laporan atau layak dipertimbangkan sebagai tujuan delivery melalui reporting versus optimization. Simpan tabel uji sebagai bukti kerja. Pilih artikel lain sesuai kebutuhanmu di topik Meta Ads.
