Tracking29 Julai 20267 min baca

Kenapa Purchase event Meta anda tak tepat, dan cara betulkannya

Ads Manager tunjuk 40 jualan, sistem anda tunjuk 58. Punca jurang itu, dan kenapa event_id yang dikongsi antara pixel dan server menyelesaikannya.

Kalau Ads Manager melaporkan 40 Purchase tetapi sistem order anda menunjukkan 58, anda tidak keseorangan. Jurang ini adalah normal untuk pixel yang hanya berjalan dalam browser, dan ia bukan pepijat pada Meta. Ia akibat langsung daripada cara pixel berfungsi pada tahun 2026.

Ke mana perginya event yang hilang

Punca	Kesan biasa
Ad blocker dan browser privacy	10–30% event tidak pernah dihantar
ATT iOS (pengguna tekan Ask App Not to Track)	Padanan merosot dengan ketara
Pembeli tutup tab sebelum page terima kasih dimuatkan	Purchase tidak pernah menyala
COD ditutup melalui WhatsApp, bukan di web	Tiada event langsung

Perhatikan baris terakhir. Untuk seller Malaysia yang banyak menutup jualan melalui WhatsApp, itu bukan kes tepi — kadangkala ia 20% daripada jualan.

Penyelesaiannya: hantar event dari server, bukan browser

Conversions API (CAPI) membenarkan server anda menghantar event terus kepada Meta. Server anda tidak boleh disekat oleh ad blocker, tidak peduli tetapan privacy browser, dan ia tahu tentang jualan yang berlaku di luar web sepenuhnya.

Tetapi memasang CAPI tanpa berhati-hati mencipta masalah baharu: setiap jualan dikira dua kali — sekali oleh pixel browser, sekali oleh server.

Kuncinya ialah event_id yang dikongsi

Meta menyahduplikasi event apabila kedua-dua penghantaran membawa event_id yang sama. Jana satu ID untuk setiap jualan, hantar ia bersama pixel browser sebagai eventID, dan hantar ID yang sama dari server. Meta akan menyimpan satu dan membuang pendua.

Pixel sampai dahulu untuk kebanyakan pembeli desktop → Meta simpan yang itu.
Pixel disekat → hanya event server sampai, dan jualan tetap dikira.
Kedua-duanya sampai → dinyahduplikasi, dikira sekali.

Kalau anda hanya mengambil satu perkara daripada artikel ini: jangan hantar Purchase dari browser sahaja, dan jangan hantar dari kedua-dua tempat tanpa event_id yang dikongsi. Yang pertama kehilangan data, yang kedua mencipta data palsu.

Purchase sepatutnya direkod di server, sentiasa

Ada sebab kedua untuk merekod Purchase dari server yang lebih penting daripada ketepatan: browser tidak boleh dipercayai.

Kalau page terima kasih anda menyalakan Purchase, sesiapa sahaja boleh memuat semula page itu sepuluh kali dan menyuntik sepuluh jualan palsu ke dalam data anda. Nilainya pun datang dari URL, jadi ia boleh diubah. Untuk COD, Purchase sepatutnya direkod pada masa order dicipta di server. Untuk FPX, ia sepatutnya direkod pada callback pembayaran — selepas gateway mengesahkan duit sudah masuk, bukan sebelum.

Apa yang berubah selepas anda betulkan ini

Kiraan Purchase menghampiri kiraan order sebenar anda. Jurang 30% biasanya mengecil menjadi bawah 10%.
Meta mendapat isyarat yang lebih lengkap untuk mengoptimum, jadi kos per pembelian biasanya turun selepas 1–2 minggu pembelajaran semula.
Anda boleh mula mempercayai ROAS dalam Ads Manager cukup untuk membuat keputusan bajet.

Cara menyemak sama ada anda sudah betul

Buka Events Manager → Test Events. Buat satu order ujian. Anda sepatutnya nampak satu Purchase, bukan dua.
Semak lajur "Event Deduplication" dalam Events Manager. Kalau ia menunjukkan 0% dinyahduplikasi sedangkan anda menghantar dari kedua-dua tempat, event_id anda tidak sepadan.
Bandingkan kiraan Purchase 7 hari dengan kiraan order sah 7 hari dalam sistem anda. Jurang di bawah 10% adalah sihat.

ROAS.my merekod Purchase di server secara lalai — COD pada penciptaan order, FPX pada callback pembayaran — dan berkongsi event_id dengan pixel browser supaya nyahduplikasi berlaku sendiri. Butirannya ada dalam senarai ciri.