Meta Pixel + CAPI Deduplication: Cara Memverifikasi event_id Berfungsi

Untuk mengukur konversi Meta secara akurat, Anda mengirim event yang sama dari Pixel (browser) dan Conversions API (CAPI / server) — ini adalah setup yang direkomendasikan langsung oleh Meta. Jika salah satu sisi gagal karena consent atau pembatasan browser, sisi lainnya masih bisa menangkap event tersebut, sehingga memberi Anda redundansi. Tapi ketika "kirim keduanya" ini berjalan tanpa deduplication, satu konversi malah dihitung dua kali. Desain yang dimaksudkan untuk redundansi justru langsung berubah menjadi angka yang menggelembung.

Apakah ini terdengar familiar?

• Sejak menambahkan Pixel dan CAPI, konversi menjadi lebih tinggi dari kondisi sebenarnya
• Di Events Manager, pembelian yang sama muncul sebagai dua event — satu dari browser, satu dari server
• Total revenue (value) menggelembung melebihi penjualan aktual
• Anda sudah mengatur deduplication, tapi duplikat tetap tidak hilang

Panduan ini merangkum mengapa deduplication Meta diperlukan, kondisinya (event_id plus nama event), dan cara memverifikasi apakah ini benar-benar berfungsi di sisi browser dan server — dari perspektif praktis dan hands-on.

Prinsip dasar: "kirim keduanya" dan "double counting" hanya berjarak setipis rambut

Mulai dari premisnya. Meta merekomendasikan menjalankan Pixel dan Conversions API bersamaan untuk mengurangi event yang terlewat. Sisi browser mudah hilang karena tracking protection dan ad blocker; sisi server sebagian besar kebal terhadap hal itu. Jadi Anda mengirim event yang sama dari keduanya, dengan asumsi bahwa Meta akan menggabungkan duplikat tersebut menjadi satu event (deduplication).

Kondisi	Yang terjadi
Kirim hanya satu sisi	Event yang terlewat kemungkinan besar terjadi (tanpa redundansi)
Kirim keduanya + deduplication aktif	Terhitung dengan benar sebagai satu event (direkomendasikan)
Kirim keduanya + deduplication tidak aktif	Satu event yang sama menggelembung menjadi dua

Jadi masalahnya bukan "mengirim keduanya" — melainkan apakah deduplication berfungsi setelah Anda mengirim keduanya. Yang perlu Anda verifikasi bukan "apakah sudah terkirim" tapi "apakah Meta sudah menggabungkannya menjadi satu."

Kondisi deduplication: event_id yang sama + nama event yang sama

Kondisi agar Meta memperlakukan event sisi browser dan sisi server sebagai "kejadian yang sama" itu sederhana.

• event_id yang cocok … untuk satu konversi, kirimkan nilai yang persis sama dari browser dan server
• event_name yang cocok … gunakan nama event yang sama di kedua sisi, seperti Purchase atau Lead

Hanya ketika kedua hal ini sejalan, Meta akan memutuskan "ini adalah kejadian yang sama yang datang dari browser dan server" lalu menggabungkannya menjadi satu. fbp (browser ID, nilai dari cookie _fbp) juga digunakan sebagai sinyal pendukung, tapi sumbu utamanya selalu kecocokan pada event_id plus nama event.

Jebakan umum: nama event cocok tapi event_id hanya dipasang di satu sisi. Ini akan diperlakukan sebagai "nama sama tapi kejadian berbeda," dan dua event bertahan tanpa terdeduplikasi. Sebaliknya, meski Anda menyamakan event_id, ketidakcocokan nama event seperti Purchase vs. purchase juga membuat keduanya dihitung sebagai hal yang terpisah (panduan pelacakan konversi Meta).

Jendela deduplication 48 jam

Meta tidak menyimpan event tanpa batas waktu untuk dicocokkan. Ketika event sisi browser dan sisi server memiliki event_id dan nama event yang sama, Meta hanya akan menggabungkannya jika keduanya tiba dalam rentang 48 jam satu sama lain. Setelah jendela ini tertutup, bahkan kecocokan event_id yang sempurna sekalipun akan diabaikan — kedua event dihitung secara terpisah.

Dalam praktiknya hal ini jarang menimbulkan masalah, karena Pixel langsung menembak instan dan CAPI biasanya menyusul dalam hitungan detik atau menit. Tapi jika pipeline sisi server Anda memiliki delay yang panjang — batch job yang berjalan semalaman, antrean yang menumpuk di akhir pekan, atau logic retry yang menahan event yang gagal — event CAPI bisa mendarat di luar jendela 48 jam dan deduplication berhenti bekerja secara diam-diam.

Tips: jika Anda memproses konversi secara batch, jaga agar delay-nya jauh di bawah 48 jam. Pengiriman real-time atau near-real-time dari server adalah pendekatan paling aman.

Cara memverifikasi: apakah event_id sisi browser dan sisi server cocok?

Memverifikasi apakah deduplication berfungsi pada dasarnya adalah membandingkan event_id di kedua sisi dan memastikan nilainya sama. Berikut langkah-langkahnya.

1. Baca event_id sisi browser

Buka tab "Network" di DevTools browser Anda dan filter untuk facebook.com/tr. Lakukan aksi konversi target sekali, lalu periksa parameter eid (= event_id) pada request yang tertembak. eventID dari fbq('track', 'Purchase', {...}, {eventID: '...'}) akan muncul di sini.

2. Baca event_id sisi server

Di sisi CAPI, konfirmasi bahwa payload yang dikirim server Anda ke Meta (data[].event_id) berisi nilai yang sama. Menggunakan log implementasi Anda atau kode test-event, bandingkan dengan nilai persis yang Anda konfirmasi di browser.

3. Rekonsiliasi di "Test Events" Events Manager

Buka Events Manager → dataset Anda → Test Events, dan hasilkan satu konversi di situs. Dua event seharusnya masuk — satu dari browser, satu dari server. Jika Meta menggabungkannya menjadi satu sebagai "deduplicated," akan ada indikasi tersebut. Jika kedua event tetap terdaftar terpisah, deduplication tidak berfungsi.

Jebakan umum: Test Events hanya menampilkan "momen ini, di lingkungan Anda." Meski cocok di mesin Anda, jika titik tempat Anda menghasilkan event_id secara dinamis di production menjadi tidak sinkron, duplikat hanya akan muncul di jalur pengunjung sebenarnya. Jangan merasa aman hanya dengan satu pola di mesin Anda sendiri.

Membaca tingkat deduplication di Events Manager

Test Events menunjukkan satu snapshot, tapi Events Manager juga menyediakan metrik deduplication agregat untuk pemantauan berkelanjutan. Cara menemukannya:

1. Buka Events Manager dan pilih dataset (pixel) Anda.
2. Klik nama event tertentu — misalnya, Purchase.
3. Di tampilan detail, bandingkan jumlah Received (total event mentah dari semua sumber) dengan jumlah Deduplicated (event yang dikenali sebagai duplikat dan digabungkan).

Selisih antara kedua angka ini adalah deduplication yang benar-benar terjadi. Setup dual-source yang sehat (Pixel + CAPI sama-sama menembak dengan andal) biasanya menunjukkan tingkat deduplication sekitar 40–70% untuk suatu event tertentu. Berikut arti dari angka-angka tersebut:

Tingkat dedup	Kemungkinan artinya
40–70%	Sehat — kedua sumber menembak dan Meta menggabungkannya
Mendekati 0%	event_id tidak dikirim atau tidak cocok
Mendekati 100%	Tidak biasa — kemungkinan satu sumber sama sekali tidak sampai ke Meta

Catatan: tingkat deduplication di tab Overview bukan real-time. Beri waktu minimal 48–72 jam traffic live sebelum menarik kesimpulan, terutama tepat setelah deployment.

Alasan umum deduplication tidak berfungsi

Anda sudah menambahkan event_id tapi duplikat tidak hilang — berikut pola-pola yang umum terjadi.

1. event_id berbeda antara kedua sisi

Penyebab paling umum. Jika browser dan server menghasilkan event_id secara independen, nilainya tidak akan cocok dan diperlakukan sebagai hal yang berbeda. event_id membutuhkan mekanisme yang selalu menghasilkan nilai yang sama di kedua sisi — kirimkan nilai yang dihasilkan di sisi browser ke server, atau turunkan nilai yang sama dari logic bersama.

2. event_id hanya ada di satu sisi

Anda mengirim eventID ke Pixel tapi tidak menyertakan event_id di CAPI (atau sebaliknya). Tanpa apa pun di satu sisi, tidak ada yang bisa direkonsiliasi, dan deduplication tidak pernah terjadi.

3. Nama event tidak cocok

Purchase vs. purchase, atau mencampur standard event dengan custom event — ketidakcocokan nama event juga menonaktifkan deduplication. Gunakan nama yang persis sama di kedua sisi.

4. fbp / fbc tidak dikirim

Jika fbp (browser ID) atau fbc (click ID), yang digunakan untuk rekonsiliasi pendukung, tidak dikirim ke sisi server, ini mempengaruhi akurasi rekonsiliasi dan kualitas pencocokan. Kecocokan event_id adalah sumbu utamanya, tapi mengirim ini juga merupakan setup yang lebih disarankan.

Mengirim event_id melalui GTM Server-Side

Jika Anda menggunakan Google Tag Manager (GTM) Server-Side untuk implementasi CAPI, alur untuk menjaga event_id tetap konsisten di kedua sisi biasanya terlihat seperti ini:

1. Hasilkan event_id di client. Di JavaScript website Anda (atau tag GTM sisi client), buat ID unik (UUID atau order ID) untuk setiap konversi.
2. Kirim ke Pixel. Sertakan ID tersebut sebagai eventID dalam pemanggilan fbq('track', ...) Anda.
3. Teruskan ke server container. Kirim ID yang sama sebagai parameter dalam event GA4 Anda (atau melalui custom data-layer variable) agar sampai ke server-side GTM container.
4. Petakan di tag Meta CAPI. Dalam konfigurasi tag Meta sisi server Anda, petakan parameter yang masuk ke field event_id.

Poin krusialnya: client dan server harus menggunakan satu sumber kebenaran (single source of truth) untuk ID tersebut. Jika server container menghasilkan ID-nya sendiri alih-alih membaca ID yang dikirim client, nilainya akan berbeda dan deduplication rusak. Untuk pembahasan lebih luas tentang memverifikasi setup GTM sisi server Anda, lihat verifikasi GTM server-side.

Apa yang tidak bisa diketahui hanya dengan memeriksa dari mesin Anda sendiri

Memeriksa sekali, secara manual, dari mesin Anda sendiri memiliki dua batasan struktural.

1. Lingkungan Anda bukan lingkungan pengunjung Anda. Tergantung status login, ekstensi, dan status consent, event_id bisa terlihat sejajar di mesin Anda tapi deduplication rusak di kondisi pengunjung nyata (hanya sisi browser yang gagal saat consent ditolak, timing pembuatan event_id bergeser pada sumber traffic tertentu, dan sebagainya).
2. Konversi yang melibatkan klik iklan sulit diverifikasi. Untuk benar-benar merekonstruksi "apakah ini benar-benar tergabung menjadi satu melalui iklan," Anda perlu mengklik iklan live dan mengikuti jalurnya — yang membawa risiko pelanggaran kebijakan iklan sebagai klik mandiri (self-click).

Dengan kata lain, mengonfirmasi "event_id sudah sejajar" pada aksi Anda sendiri bukanlah bukti bahwa deduplication berfungsi di jalur nyata yang dilalui pengunjung Anda.

Checklist verifikasi

• Apakah Pixel dan CAPI mengirim event_id yang sama untuk konversi yang sama?
• Apakah nama event (event_name) cocok persis di kedua sisi (termasuk huruf besar/kecil)?
• Apakah Anda benar-benar merekonsiliasi eid sisi browser terhadap event_id sisi server?
• Apakah Anda mengonfirmasi status "deduplicated" di Test Events?
• Apakah event_id unik per konversi dan identik di kedua sisi?
• Apakah fbp / fbc juga dikirim ke sisi server?
• Selain satu pola di mesin Anda, apakah bebas duplikat di bawah kondisi pengunjung production nyata?

Pertanyaan yang sering diajukan

T. Apakah saya sebaiknya memasang Pixel dan CAPI sejak awal? J. Ya — ini rekomendasi Meta. Jika satu sisi gagal karena consent atau pembatasan browser, sisi lainnya masih bisa menangkap event tersebut, memberi Anda redundansi. Tapi ini hanya berlaku dengan premis bahwa deduplication (event_id + nama event) berfungsi. Jika tidak, mengirim keduanya langsung berubah menjadi double counting (dasar-dasar double counting).

T. Nilai apa yang sebaiknya digunakan untuk event_id? J. Nilai apa pun yang secara unik mengidentifikasi satu konversi (misalnya, order ID) bisa dipakai, selama Anda menggunakan nilai yang sama di browser dan server. Dua hal yang penting: "unik per konversi" dan "identik di kedua sisi." Ini tidak akan berfungsi jika nilai berbeda ditetapkan setiap kali, atau salah satu sisi kosong.

T. Saya sudah mencocokkan nama event tapi duplikat tidak hilang. J. Kemungkinan besar event_id tidak cocok di kedua sisi. Periksa apakah nilai yang dihasilkan di sisi browser benar-benar dikirim ke server, dan apakah pembuatan yang independen menyebabkan nilainya berbeda (memverifikasi CAPI).

T. Jika Test Events menunjukkan deduplicated, apakah production juga aman? J. Test Events adalah pemeriksaan terhadap lingkungan Anda, pada saat itu. Di production, penetapan dan pencocokan event_id bisa rusak tergantung status consent dan sumber traffic, dan satu pola di mesin Anda mungkin tidak mereproduksinya. Verifikasi di bawah kondisi pengunjung nyata diperlukan.

T. Saya juga ingin tahu cara memverifikasi Pixel itu sendiri. J. Memverifikasi instalasi, penembakan, dan penerimaan Pixel itu sendiri dibahas di artikel terpisah (memverifikasi Meta Pixel). Deduplication di artikel ini adalah tahap berikutnya — membuat Pixel dan CAPI berdampingan.

Kesimpulan: "kirim keduanya" belum selesai sampai "tergabung menjadi satu"

Memasang Pixel dan CAPI sekaligus adalah rekomendasi Meta dan desain yang solid untuk mengurangi event yang terlewat. Tapi ini bertumpu pada premis bahwa Meta menggabungkannya menjadi satu (deduplication) melalui event_id yang sama plus nama event yang sama. Jika deduplication tidak berfungsi, desain yang dimaksudkan untuk redundansi menjadi penyebab double counting. Mulailah dengan merekonsiliasi event_id di kedua sisi, dan konfirmasi "deduplicated" di Test Events.

Meski begitu, satu kali pemeriksaan di mesin Anda sendiri tidak bisa menangkap deduplication yang rusak hanya di jalur pengunjung nyata. ConversionOK menjalankan halaman live Anda di browser independen dan terisolasi, lalu mencegat event Pixel dan CAPI yang benar-benar terkirim (dan apakah event_id mereka cocok), kemudian memverifikasinya — tanpa perlu mengklik iklan Anda sendiri dan tanpa gangguan dari lingkungan kantor Anda. Mulai dengan pemeriksaan statis gratis untuk mengonfirmasi titik masuk pengukuran Anda.