Deduplikasi Event Pixel dan CAPI: Cara Kerja event_id dan Cara Mengujinya

01Kenapa satu kejadian bisa terhitung dua kali

Meta menyarankan setup redundan: Pixel di browser dan Conversions API (CAPI) di server sama-sama mengirim event yang sama. Tujuannya supaya kejadian yang gagal terkirim dari satu jalur tetap tercatat lewat jalur lain. Efek sampingnya jelas: ketika kedua jalur berhasil, Meta menerima dua kiriman untuk satu kejadian. Meta hanya menyatukannya bila bisa memastikan keduanya sama. Kalau tidak bisa, keduanya bisa terhitung dan angka conversion Anda membengkak.

Perbedaan dasar jalur browser dan jalur server dibahas di Meta Pixel vs Conversions API. Artikel ini fokus pada satu masalah: cara membuat dua kiriman itu tampak identik di mata Meta, dan cara membuktikannya sebelum campaign berjalan.

Ilustrasi dengan angka rekaan, bukan data pelanggan: sebuah toko memiliki 40 pesanan senilai Rp250.000 dalam sehari dengan biaya iklan Rp5.000.000. Pixel hanya menangkap 34 pesanan karena sebagian pembeli memakai pemblokir atau menutup halaman lebih cepat, sedangkan server mencatat 40. Tanpa deduplikasi, Meta membaca 74 Purchase senilai Rp18.500.000, sehingga ROAS terbaca 3,7 padahal angka sebenarnya 2,0. Dengan event_id yang cocok, 34 pasangan disatukan dan 6 event server melengkapi sisanya, total 40 Purchase senilai Rp10.000.000.

Kalau masalah Anda kebalikannya, yaitu angka Pixel yang terlalu rendah atau hilang, penyebabnya berbeda dan dibahas di data Pixel Facebook hilang.

02Cara Meta mendeduplikasi: event_name, event_id, dan jendela 48 jam

Dokumentasi resmi Meta untuk developer menyebut dua metode. Metode pertama direkomendasikan Meta. Metode kedua berfungsi sebagai alternatif dengan syarat yang lebih ketat.

• Jendela waktu. Event hanya dideduplikasi jika diterima dalam 48 jam sejak Meta menerima event pertama dengan event_id tersebut.
• Event yang dipertahankan. Jika isi event browser dan server tidak berbeda berarti, Meta umumnya memilih event yang diterima lebih dulu.
• Sifat event_id. Bersifat opsional tetapi disarankan. Meta menyebut nomor pesanan atau ID transaksi sebagai contoh yang cocok.

Gambaran lengkap payload CAPI untuk bisnis yang closing di chat ada di pilar Meta CAPI untuk WhatsApp. Untuk definisi dasarnya, baca apa itu Meta CAPI.

03event_id Meta CAPI: cara membuat yang konsisten

Meta tidak mewajibkan format tertentu. Yang dicari hanya dua sifat: nilainya identik di browser dan server untuk kejadian yang sama, dan berbeda untuk setiap kejadian. Bagaimana Anda mencapainya bergantung pada apakah kejadian itu sudah punya ID bisnis yang tetap.

Contoh alur untuk kejadian tanpa ID bisnis. ID dibuat satu kali saat kejadian terjadi, lalu dipakai oleh kedua jalur:

// 1. Buat ID sekali, saat kejadian terjadi
const eventId = crypto.randomUUID();

// 2. Kirim ke Pixel memakai ID itu
fbq('track', 'Lead', { content_name: 'Form konsultasi' }, { eventID: eventId });

// 3. Kirim ID yang sama ke server Anda, yang meneruskannya ke CAPI
fetch('/konsultasi', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ eventId, /* data form lain */ }),
});

• Buat ID saat kejadian terjadi, bukan saat mengirim. ID yang dibuat di titik kirim berganti setiap kali ada retry.
• Simpan ID bersama record di database sebelum kiriman pertama, lalu pakai ulang untuk setiap retry.
• Samakan event_name persis, termasuk huruf besar dan kecil.
• Kirim event server segera. Jangan biarkan antrean melewati jendela 48 jam.
• Sertakan fbp dan external_id juga. Keduanya membantu Meta mencocokkan pengguna dan dibahas di Event Match Quality Meta.

04Contoh pasangan event Pixel dan CAPI dengan event_id sama

Berikut pasangan event untuk satu kejadian yang sama di sebuah toko online, yaitu pembayaran sebuah pesanan. Ini contoh umum untuk implementasi sendiri, bukan payload Dalekta. Semua nilai, termasuk ID pesanan dan URL, adalah placeholder ilustrasi. Pertama, event dari browser lewat Meta Pixel:

fbq('track', 'Purchase',
  { value: 250000, currency: 'IDR' },
  { eventID: 'ORD-2026-0142:Purchase' });

Lalu event dari server untuk kejadian yang sama. Perhatikan event_name dan event_id yang identik dengan event Pixel:

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": "<unix timestamp saat pesanan dibayar>",
      "event_id": "ORD-2026-0142:Purchase",
      "action_source": "website",
      "event_source_url": "https://contoh.id/checkout/selesai",
      "user_data": {
        "em": ["<sha256 email>"],
        "fbp": "fb.1.<waktu>.<angka acak>",
        "fbc": "fb.1.<waktu klik>.<[fbclid](/glosarium/fbclid)>",
        "client_ip_address": "<IP pengunjung>",
        "client_user_agent": "<user agent browser>"
      },
      "custom_data": { "value": 250000, "currency": "IDR" }
    }
  ]
}

05Bagaimana Dalekta membentuk event_id dan mencegah kirim ganda

Dalekta membentuk event_id di server. Untuk setiap event yang dikirim ke Meta, formatnya adalah ID lead diikuti tanda titik dua dan tahap bisnis, yaitu <id-lead>:<tahap>. Karena ID lead dan tahapnya tetap, event_id untuk lead dan tahap yang sama selalu identik, kapan pun dan berapa kali pun pengirimannya dicoba. Nama event di sisi Meta ditentukan oleh mapping workspace, sedangkan event_id tidak ikut berubah. Hanya tahap yang sudah punya mapping, dan hanya lead yang terdeteksi berasal dari Meta, yang dikirim ke Meta.

Sebelum mengirim, Dalekta mencatat satu baris log berstatus PENDING untuk event_id itu. Selama log PENDING atau SUCCESS untuk event_id yang sama masih ada, pengiriman baru diblokir. Perilaku pada tiap situasi:

Dalekta tidak menjalankan Meta Pixel di landing page Anda, jadi tidak ada Pixel Dalekta yang perlu dideduplikasi. Yang perlu Anda waspadai adalah Pixel milik Anda sendiri. ID lead dibuat di server Dalekta dan tracker tidak mengeluarkannya ke halaman, sehingga eventID Pixel Anda tidak mungkin sama dengan event_id Dalekta. Kalau Pixel Anda menembak event bernama sama dengan hasil mapping Dalekta, metode utama Meta (event_name dan event_id) tidak bisa memasangkannya.

Ada satu kemungkinan lain. Tracker Dalekta membaca atau menyusun cookie _fbp dan _fbc, lalu payload CAPI Dalekta membawa keduanya sebagai fbp dan fbc bila lead punya data klik situs. Lead Click-to-WhatsApp (CTWA) tidak punya data itu, jadi event-nya terkirim tanpa fbp, fbc, IP, dan user agent. Kualitas pencocokannya lebih rendah dan Meta bisa menganggap event itu kurang lengkap. Dalekta juga belum memakai jalur CAPI Business Messaging. Untuk lead dari landing page, metode kedua Meta, yaitu event_name yang sama dengan fbp yang sama, mungkin menyatukan sebagian pasangan. Meta merekomendasikan metode event_id, dan metode kedua ini mensyaratkan event browser tiba lebih dulu, jadi jangan dijadikan andalan.

Ilustrasi dengan angka rekaan, untuk skenario terburuk saat metode kedua Meta tidak menyatukan apa pun: landing page menembak Contact dari Pixel setiap tombol WhatsApp ditekan, dan mapping Click CTA di Dalekta juga bernama Contact. Dari 500 klik, Pixel menangkap 460 karena sebagian diblokir, sedangkan Dalekta mengirim 500. Events Manager bisa menampilkan sampai 960 Contact untuk 500 klik nyata. Solusinya bukan mengakali event_id, melainkan membagi tugas berdasarkan nama event: biarkan Pixel mengurus PageView dan ViewContent di halaman, dan pakai Dalekta untuk kejadian setelah klik WhatsApp.

06Cara menguji deduplikasi di Events Manager

Ada dua jalur pengujian, tergantung apakah Anda membangun sendiri Pixel dan CAPI atau memakai Dalekta. Mulai dari jalur untuk implementasi sendiri, yang memakai tab Test Events.

1. Buka Events Manager, pilih Pixel atau dataset Anda, lalu buka tab Test Events. Salin kode uji yang ditampilkan.
2. Tambahkan kode itu ke request CAPI sebagai test_event_code di level atas payload, sejajar dengan data.
3. Picu satu kejadian nyata di situs sehingga Pixel dan server sama-sama mengirim event dengan event_id yang sama.
4. Lihat panel Test Events. Menurut dokumentasi Meta, tool ini menunjukkan event mana yang diproses dan mana yang dideduplikasi. Satu kejadian harus menghasilkan satu event terhitung, bukan dua.
5. Buka detail tiap event dan bandingkan event_name serta event_id yang diterima Meta. Selisih satu karakter cukup membuat keduanya tidak cocok.
6. Hapus test_event_code sebelum produksi. Event dengan kode uji tidak dibuang. Event itu tetap masuk ke Events Manager dan dipakai untuk targeting dan pengukuran iklan.
7. Setelah live, bandingkan jumlah event di tab Overview dengan jumlah kejadian sebenarnya di sistem Anda, misalnya jumlah pesanan hari itu. Tab Diagnostics juga bisa memperlihatkan masalah pada event yang masuk.

Jalur untuk workspace Dalekta berbeda. Payload Dalekta tidak menyertakan test_event_code, jadi event Dalekta tidak muncul di tab Test Events dan event percobaan masuk ke data asli Pixel. Bukti pengirimannya ada di halaman Event Logs, yang punya kolom Event ID.

1. Buat lead uji dari URL campaign Meta: buka URL itu, tekan tombol WhatsApp di landing page, lalu kirim pesan dengan kode lead [D-...] yang sudah terisi. Chat baru tanpa kode itu dan tanpa metadata iklan tidak membuat lead. Setelah itu ubah statusnya ke tahap yang ingin diuji. Untuk Closing, pakai nominal kecil yang mudah dikenali.
2. Buka Event Logs dan cari lead itu dengan kode lead atau nama campaign. Kolom Event ID menampilkan event_id dalam bentuk <id-lead>:<tahap>, dan kotak pencarian juga mengenali Event ID, jadi Anda bisa menempelkan nilai itu untuk menyaring log.
3. Pastikan hanya ada satu baris SUCCESS untuk event_id tersebut. Simpan tahap yang sama sekali lagi, lalu muat ulang log: jumlah baris SUCCESS untuk event_id itu tetap satu.
4. Di Events Manager, tab Overview, bandingkan jumlah event bernama sesuai mapping dengan jumlah lead unik pada tahap itu di tanggal yang sama. Jumlah yang lebih besar dari lead unik berarti ada sumber lain, biasanya Pixel Anda sendiri atau dua tahap yang dipetakan ke nama yang sama.

Arti status PENDING, SUCCESS, dan FAILED, serta urutan debug lengkapnya, ada di dokumentasi Event Logs dan Sync Logs.

07Gejala umum dan penyebabnya

08Referensi resmi dan bacaan lanjutan

09Pertanyaan umum