Meta Pixel vs Conversions API: Kapan Perlu Keduanya

Apa beda Meta Pixel dan Conversions API?

Meta Pixel mengirim event dari browser pengunjung lewat kode JavaScript di halaman, sedangkan Conversions API (CAPI) mengirim event dari server atau sistem Anda. Meta menyarankan memakai keduanya secara redundan: kirim event yang sama lewat dua jalur dengan identitas event yang sama, sehingga Meta dapat membuang duplikat dan tetap menerima event yang hilang di salah satu jalur. Jadi pertanyaannya jarang "Pixel atau CAPI", melainkan "event mana yang perlu dua jalur dan bagaimana menjaganya tidak dihitung ganda".

Penjelasan dasar CAPI ada di Apa itu Meta Conversions API. Artikel ini fokus pada pemilihan setup dan deduplikasi.

Kapan Pixel saja sudah cukup?

Pixel saja dapat menjadi titik awal yang wajar ketika situs sederhana, event yang diukur hanya beberapa, belum ada sistem server yang memegang catatan konversi andal, dan tim belum siap memelihara integrasi tambahan. Syaratnya event dipasang benar, diuji, dan definisinya jelas. Meta tetap menyarankan setup redundan, jadi pilihan Pixel-saja sebaiknya menjadi keputusan sadar, bukan kelalaian. Artikel ini tidak mengklaim seberapa besar selisih hasil antara kedua setup.

Kapan menambahkan CAPI (setup hybrid)?

• Event bernilai tinggi, seperti pembelian atau lead yang terverifikasi, dikonfirmasi di server atau CRM dan bukan di browser.
• Tindakan terjadi di luar browser, misalnya percakapan pesan bisnis, penjualan offline, atau perubahan status di CRM.
• Anda menemukan jumlah di Pixel tidak konsisten dengan catatan backend.
• Anda ingin ada jalur cadangan ketika halaman gagal dimuat atau koneksi pengunjung terputus.
• Ada pemilik teknis yang bisa memeliharanya: token, log kegagalan, dan pemeriksaan berkala.

Bagaimana deduplikasi Pixel dan CAPI bekerja?

Dokumentasi Meta menjelaskan dua metode. Metode yang direkomendasikan mencocokkan eventID pada Pixel dengan event_id pada CAPI, dan nama event pada Pixel dengan event_name pada CAPI. Metode alternatif memakai fbp dan atau external_id dengan event_name yang konsisten, tetapi hanya bekerja jika event dari browser tiba lebih dulu daripada event dari server.

Beberapa batas dari dokumentasi yang perlu diingat:

• Deduplikasi hanya terjadi jika kedua event diterima dalam jendela 48 jam.
• Meta umumnya mempertahankan event yang diterima lebih dulu.
• Deduplikasi hanya berlaku antara dua jalur. Event ganda dari Pixel saja atau dari server saja tetap terhitung ganda.
• Pada metode alternatif (fbp dan atau external_id), dokumentasi Meta mencatat batasan bahwa deduplikasi tidak terjadi jika hanya satu sumber yang membawa pengenal tersebut.

Praktik yang aman: buat satu event_id ketika tindakan terjadi, kirim ID itu ke Pixel dan pakai ID yang sama pada payload CAPI. Jika pengiriman server gagal dan diulang, pakai ID yang sama. Jangan membuat ID baru untuk setiap percobaan, karena Meta akan melihatnya sebagai event baru.

Contoh hipotetis: pengunjung mengirim formulir, server menyimpan lead dan membuat sebuah ID unik, halaman konfirmasi mengirim event Lead ke Pixel dengan ID itu, dan server mengirim event Lead yang sama ke CAPI dengan ID yang sama. Ini contoh hipotetis, bukan bukti bahwa alur tersebut telah dibangun atau dijalankan oleh Fikran Dev.

Checklist QA setup hybrid

• Nama event di Pixel dan CAPI identik untuk event yang sama.
• event_id sama untuk kedua jalur dan unik per tindakan.
• Percobaan ulang memakai event_id yang sama.
• Kedua event tiba dalam 48 jam.
• Tab Event Deduplication di Events Manager menunjukkan kunci deduplikasi terpakai.
• test_event_code hanya dipakai saat uji dan dihapus dari produksi.
• Status consent yang sama menjadi syarat pengiriman di kedua jalur.

Bagaimana dengan consent?

Untuk Pixel, dokumentasi Meta menjelaskan perintah fbq consent revoke untuk menjeda pengiriman dan grant untuk melanjutkannya setelah pengunjung menyetujui; revoke dipanggil di setiap halaman sebelum inisialisasi. Halaman dokumentasi yang ditinjau tidak menjelaskan consent untuk CAPI. Artinya, keputusan mengirim atau tidak mengirim event dari server berada di logika Anda sendiri: simpan status consent, dan jangan mengirim data pengunjung yang belum atau tidak menyetujui sesuai kebijakan serta aturan yang berlaku.

Consent mode server-side dari Google hanya mengatur tag Google, seperti Analytics dan Google Ads. Halaman dokumentasinya tidak membahas tag Meta, jadi mengatur consent mode Google tidak otomatis mengatur pengiriman ke Meta. Ini bukan nasihat hukum; putuskan bersama pemilik bisnis atau penasihat yang berwenang.

Batas dan langkah berikutnya

Setup hybrid tidak menjamin ROAS atau jumlah lead. Ia menambah titik kegagalan yang harus diuji: duplikasi, event tidak cocok, dan token kedaluwarsa. Untuk melihat rantai pengukuran secara utuh dari event sampai CRM, baca cara tracking konversi Meta Ads, dan jika hasil kampanye mengecewakan, periksa diagnosis Meta Ads tidak menghasilkan lead. Untuk membahas implementasi dengan akses nyata, lihat layanan Meta CAPI atau hubungi Fikran Dev.

Pertanyaan yang sering diajukan

Apakah saya harus memilih salah satu antara Pixel dan CAPI?

Tidak harus. Meta menyarankan setup redundan, yaitu memakai keduanya dan mengirim event yang sama lewat dua jalur. Apakah biaya implementasinya sepadan bergantung pada nilai event, sistem yang Anda miliki, dan kemampuan tim memeliharanya.

Apa yang terjadi jika event_id di Pixel dan CAPI berbeda?

Metode deduplikasi utama tidak dapat mencocokkan kedua event, sehingga event yang sama berpotensi terhitung dua kali. Buat satu event_id per tindakan, pakai untuk kedua jalur, dan pakai kembali ID yang sama saat mengulang pengiriman.

Apakah setup hybrid membuat semua konversi terlacak?

Tidak. Hybrid mengurangi risiko event hilang di salah satu jalur, tetapi jumlah yang tercatat tetap dipengaruhi consent, kualitas data pencocokan, dan kebenaran definisi event. Setup ini juga menambah titik yang harus diuji, seperti duplikasi dan token kedaluwarsa.

Sumber resmi dan tanggal tinjauan

Perbandingan dan saran setup redundan dirujuk dari best practices Conversions API dan panduan deduplikasi Pixel dan server event. Perilaku Pixel dan consent dirujuk dari ikhtisar Meta Pixel dan penanganan consent Meta Pixel. Batas cakupan consent mode Google dirujuk dari consent mode di server-side tagging. Sumber ditinjau 30 September 2026; dokumentasi platform dapat berubah, jadi periksa ulang sebelum implementasi.