Anda memasang Conversions API (CAPI) dengan pikiran, "Sekarang akhirnya saya bisa memulihkan data yang hilang gara-gara iOS dan ad blocker" — tapi apakah Anda benar-benar sudah memastikan event benar-benar sampai ke Meta dari server Anda? Anda mungkin yakin CAPI sudah terkonfigurasi, padahal access token yang sudah kedaluwarsa atau server yang tidak pernah benar-benar terpicu bisa berarti tidak ada satu pun event yang sampai ke Meta. Yang lebih parah, karena pixel di browser masih berjalan, semuanya bisa terlihat "baik-baik saja secara keseluruhan" — dan inilah kasus yang paling sulit untuk terdeteksi.
Apakah salah satu dari ini terdengar familier?
- Di Events Manager, event server masih tertulis "belum diterima," atau jumlahnya mencurigakan rendah
- Pixel di browser muncul, tapi Anda tidak bisa menemukan event sisi server di mana pun
- Anda mendapat peringatan bahwa Event Match Quality rendah, tapi tidak tahu penyebabnya
- Sejak menambahkan CAPI, jumlah konversi Anda tampak berlipat ganda
Panduan ini merangkum cara memastikan CAPI benar-benar berjalan, alasan mengapa event bisa terkirim dari server tapi tetap tidak terpakai, dan cara berpikir yang sistematis tanpa menebak-nebak.
Sebelum memeriksa: CAPI bukan pengganti pixel — melainkan pelengkap
Mari kita luruskan premisnya dulu. CAPI bukan mekanisme yang menggantikan pixel browser (yang dikirim fbevents.js ke facebook.com/tr); CAPI mengirim event langsung ke Meta dari server Anda untuk melengkapinya. Tujuannya adalah mengisi bagian yang hilang dari pixel browser akibat ITP, ad blocker, hilangnya sinyal iOS, dan sejenisnya, melalui pengiriman sisi server.
Itulah sebabnya apa yang perlu Anda periksa berbeda dari setup pixel-saja. Memisahkan ketiga level ini membuat diagnosis jauh lebih mudah.
| Level | Arti | Jebakan umum |
|---|---|---|
| ① Server mengirim | Server Anda mengirim event ke API Meta | Token kedaluwarsa / server tidak pernah terpicu |
| ② Meta menerima | Meta menerima event server tersebut | Parameter kurang / tujuan salah (pixel ID) |
| ③ Pencocokan & dedup | Dicocokkan dengan sisi browser, dikaitkan ke satu orang, duplikat dihapus | event_id tidak cocok menyebabkan penghitungan ganda, EMQ rendah |
Poin kuncinya: ① pengiriman dan ③ pencocokan adalah dua hal yang berbeda. Meski request sudah keluar dari server Anda, masalah pada deduplikasi dengan sisi browser atau kualitas pencocokan bisa membuat event tersebut tidak dalam bentuk yang bisa dipakai untuk optimasi. Kebanyakan pemeriksaan berhenti di ①.
Ketika Anda menjalankan CAPI berdampingan dengan pixel browser, Meta melakukan deduplikasi terhadap dua event yang memiliki nama event dan
event_idyang sama.event_idyang hilang atau tidak cocok menyebabkan penghitungan ganda atau kehilangan data. Lihat Memverifikasi deduplikasi (event_id) untuk detailnya.
Langkah 1: Lihat "metode koneksi" di Events Manager
Pertama, di Events Manager → dataset (pixel) Anda → detail masing-masing event, periksa dari mana event tersebut datang.
- Setiap event menampilkan metode koneksi seperti "Server," "Browser," atau "Server dan browser"
- Apakah event target Anda (
Purchase,Lead, dll.) menunjukkan Server? - Apakah waktu penerimaan event server itu terbaru (tidak berhenti)?
Yang bisa diketahui dari sini: apakah ada catatan event yang benar-benar sampai dari server (pemeriksaan paling dekat dengan ① dan ②). Yang tidak bisa diketahui: apakah kode yang sedang Anda konfigurasi saat ini terkirim dengan benar (Langkah 2 membahas ini).
Jebakan umum: menganggap "sudah konfigurasi CAPI, berarti sudah jalan." Bukan hal aneh jika seseorang hanya menyimpan halaman pengaturan sementara kode sisi server atau konektornya belum pernah terpicu sama sekali. Selalu lihat catatan penerimaan event yang sebenarnya.
Langkah 2: Test Events + test_event_code
Test Events resmi dari Meta (Events Manager → dataset Anda → Test Events) menampilkan event yang masuk secara real-time saat ini. Untuk CAPI, triknya adalah menyertakan test_event_code pada pengiriman server Anda.
- Ambil
test_event_codeyang ditampilkan di layar Test Events (string sepertiTEST12345) - Sertakan
test_event_codeitu dalam payload pengiriman server Anda dan kirim satu event uji - Dalam hitungan detik, event itu seharusnya muncul di stream Test Events sebagai event Server
Yang bisa diketahui dari sini: bahwa kode server Anda, secara spesifik, bisa mengirim event dalam bentuk yang diterima Meta (bukti paling dekat dengan ③).
Jebakan umum: merasa puas hanya dengan aksi dari browser. Event browser yang muncul di Test Events adalah bukti pixel berjalan — bukan bukti bahwa CAPI (server) berjalan. Selalu pastikan baris yang berasal dari server benar-benar muncul.
Periksa respons API di sisi server
Ada detail yang sering diangkat oleh kompetitor tapi mudah terlewat: server Anda menerima respons HTTP setiap kali memanggil Conversions API milik Meta. Mencatat dan memeriksa respons tersebut adalah salah satu cara tercepat menangkap masalah.
| Status HTTP | Arti | Tindakan |
|---|---|---|
| 200 | Meta menerima event tersebut | Pastikan jumlah events_received di response body cocok dengan yang Anda kirim |
| 400 | Request salah — payload rusak atau field wajib hilang | Baca pesan error-nya; penyebab umum adalah event_time, action_source yang hilang, atau user_data yang salah di-hash |
| 401 / 403 | Kegagalan autentikasi atau izin | Access token Anda kedaluwarsa, dicabut, atau kurang scope — buat ulang di Events Manager |
Jika Anda belum mencatat respons API sampai sekarang, Anda sebenarnya sedang berjalan tanpa arah. Tingkat error di atas beberapa persen berarti event sedang hilang diam-diam.
Tips: Sebelum men-deploy perubahan, tempelkan payload JSON Anda ke Payload Helper milik Meta (di dalam Events Manager → Conversions API → Payload Helper). Alat ini memvalidasi field wajib, hashing yang benar, dan kesalahan umum — tanpa benar-benar mengirim event ke pixel Anda.
Langkah 3: Apakah browser dan server sama-sama muncul — dan terdeduplikasi?
Ketika Anda menjalankan CAPI berdampingan dengan pixel, kondisi sehatnya adalah keduanya muncul lalu di-deduplikasi. Di Test Events, pastikan hal berikut.
- Untuk konversi yang sama, bisakah Anda melihat event browser dan server sekaligus?
- Apakah keduanya berbagi nama event dan
event_idyang sama? - Apakah Meta mengenalinya sebagai "terdeduplikasi" dan tidak menghitungnya dua kali?
Yang bisa diketahui dari sini: bukan sekadar event sampai, tapi apakah event tersebut dicocokkan dengan benar dan penghitungan ganda dicegah.
Jebakan umum: browser dan server membentuk
event_idsecara berbeda (hanya satu sisi yang mengaturnya, atau nilainya berbeda). Akibatnya Meta memperlakukannya sebagai event terpisah dan konversi Anda menggelembung dua kali lipat. Selaraskan logika pembuatanevent_iddi kedua pengirim.
Langkah 4: Event Match Quality (EMQ) dan parameter informasi pelanggan
Nilai CAPI bukan sekadar "sampai" — tapi event tersebut terkait dengan satu orang. Yang menunjukkan hal ini adalah Event Match Quality (EMQ).
- Di detail masing-masing event dalam Events Manager, periksa skor kualitas pencocokan dan parameter informasi pelanggan mana yang dikirim
- Apakah email (
em), telepon (ph), nama (fn/ln), external ID (external_id), dan sejenisnya dikirim setelah di-hash? - Semakin banyak — dan semakin akurat — parameter yang Anda kirim, umumnya semakin tinggi kualitas pencocokannya
Yang bisa diketahui dari sini: apakah event yang sampai terkait dengan satu orang di Meta dalam bentuk yang bisa dipakai untuk optimasi dan atribusi.
Jebakan umum: mencoba mengirim informasi pribadi apa adanya (dalam bentuk teks polos). Field seperti
emdanphwajib di-hash (SHA-256). Kirim nilai mentah dan Meta tidak bisa memprosesnya dengan benar, sehingga tidak akan cocok. Selalu pastikan proses hashing terjadi di sisi server.
Jangan lupakan fbp, fbc, dan sinyal perangkat
Selain field PII seperti email dan telepon, ada beberapa parameter non-PII yang secara signifikan meningkatkan kualitas pencocokan — dan panduan-panduan kompetitor secara konsisten menyorotinya:
fbp(Facebook browser ID): nilai cookie_fbpyang diatur oleh pixel Meta. Meneruskannya dari browser ke pengiriman server Anda memungkinkan Meta mengaitkan event server dengan sesi browser yang sama.fbc(Facebook click ID): nilai cookie_fbc, yang terisi ketika pengguna datang melalui klik iklan. Mengirimkannya sangat penting untuk mengatribusikan event server ke iklan yang mendatangkan kunjungan tersebut.client_ip_addressdanclient_user_agent: Meta menggunakan keduanya untuk mencocokkan event server dengan event browser. Tanpa keduanya, kualitas pencocokan turun secara nyata bahkan ketika PII yang di-hash sudah ada.
Keempat field ini tidak memerlukan persetujuan pengguna di luar yang sudah dibutuhkan pixel, namun mengabaikannya adalah salah satu penyebab paling umum skor EMQ rendah. Untuk lebih lanjut soal kehilangan sinyal dari browser, lihat Safari ITP dan Kehilangan Konversi.
Mengapa event bisa terkirim dari server tapi tidak terhitung
Anda sudah memastikan pengiriman (①), tapi konversinya tidak terpakai sesuai harapan. Alasan umumnya:
- Access token kedaluwarsa: access token CAPI sudah kedaluwarsa atau dicabut, sehingga pengiriman ditolak
- Deduplikasi bermasalah: browser dan server tidak berbagi
event_id, menyebabkan penghitungan ganda atau kehilangan data - Parameter yang di-hash tidak cukup: informasi pelanggan terlalu sedikit sehingga kualitas pencocokan rendah, jadi kurang terpakai dalam optimasi
- Server tidak terpicu: pengiriman sisi server sekadar tidak berjalan pada saat konversi terjadi
- Tujuan salah (pixel ID): Anda mengirim ke dataset yang berbeda atau tujuan yang tidak valid
Singkatnya, memastikan server "bisa mengirim" bukanlah bukti bahwa Meta menerima, mencocokkan, dan mendeduplikasi di production.
Apa yang tidak bisa diketahui hanya dari pemeriksaan di komputer sendiri
Memeriksa sekali, secara manual, di komputer Anda sendiri memiliki dua batasan struktural.
- Lingkungan Anda bukan lingkungan pengunjung Anda. Pengiriman uji dengan
test_event_codemungkin berhasil, tapi itu tidak berarti pengiriman yang sama juga terpicu di jalur server production yang sebenarnya pada saat pengunjung asli benar-benar melakukan pembelian atau pertanyaan. Pengiriman uji yang berhasil bukan berarti alur production juga berhasil. - Konversi yang melibatkan klik iklan sulit diverifikasi. Untuk benar-benar melihat "apakah ini benar-benar terlacak dan teroptimasi lewat iklan," Anda perlu mengklik iklan yang aktif untuk mereplikasi jalurnya — yang membawa risiko pelanggaran kebijakan iklan karena dianggap self-click.
Menyimpulkan "pengiriman uji berhasil, jadi semuanya beres" cenderung melewatkan masalah event server yang hilang di jalur nyata yang dilalui pengunjung Anda.
Checklist untuk memverifikasi dengan percaya diri
- Di Events Manager, apakah event target menunjukkan metode koneksi Server?
- Apakah waktu penerimaan event server terbaru, tidak berhenti?
- Apakah pengiriman server dengan
test_event_codemuncul di Test Events sebagai Server? - Untuk konversi yang sama, apakah browser dan server sama-sama terlihat dan terdeduplikasi dengan
event_idyang sama? - Apakah access token CAPI masih berlaku (tidak kedaluwarsa)?
- Apakah informasi pelanggan (
em,ph, dll.) dikirim dalam keadaan di-hash, dengan kualitas pencocokan pada rentang yang dapat diterima? - Selain pengiriman uji Anda sendiri, apakah event server tidak hilang di jalur pengunjung nyata di production?
Pertanyaan yang sering diajukan
Q. Kalau pixel browser sudah jalan, bukankah CAPI jadi berlebihan? A. Tidak. CAPI melengkapi, di sisi server, bagian yang hilang dari pixel browser akibat ITP, ad blocker, hilangnya sinyal iOS, dan sejenisnya. Dengan pixel saja, bagian yang hilang itu sekadar hilang begitu saja. Untuk pemeriksaan pemicuannya, lihat juga Memverifikasi pixel Meta terpicu.
Q. Event muncul di Test Events, tapi tidak tertulis "Server."
A. Kemungkinan besar itu hanya pixel browser yang bekerja. Kirim satu event dari server Anda dengan test_event_code terpasang dan pastikan baris yang berasal dari Server muncul di stream. Jika tidak muncul, curigai kode servernya tidak terpicu atau token-nya tidak valid.
Q. Sejak menambahkan CAPI, konversi saya tampak berlipat ganda.
A. Kemungkinan besar event browser dan server tidak berbagi event_id dan tidak terdeduplikasi. Selaraskan nama event dan event_id di keduanya. Lihat Memverifikasi deduplikasi (event_id) untuk detailnya.
Q. Bagaimana cara meningkatkan Event Match Quality (EMQ)? A. Kirim lebih banyak — dan lebih akurat — parameter informasi pelanggan yang di-hash. Mengirim email, telepon, nama, external ID, dan sejenisnya, yang di-hash dengan benar (SHA-256) di server, umumnya meningkatkan skor.
Q. Saya menggunakan setup CAPI satu klik dari Meta (CAPI Gateway). Apakah tetap perlu verifikasi? A. Ya, tetap perlu. CAPI satu klik (dirilis April 2026) menghilangkan kerumitan konfigurasi, tapi Anda tetap perlu memastikan event sampai dengan metode koneksi Server, deduplikasi berfungsi, dan EMQ berada pada rentang yang dapat diterima. Karena Meta yang meng-hosting infrastrukturnya, Anda tidak punya akses langsung ke log server — sehingga pemeriksaan pada Langkah 1 hingga 4 di atas justru menjadi semakin penting. Perlu dicatat bahwa CAPI satu klik hanya mencakup event web standar; event kustom atau konversi offline tetap memerlukan implementasi manual yang perlu Anda verifikasi secara terpisah.
Q. Berapa lama sampai access token kedaluwarsa? A. Masa berlakunya tergantung pada jenis token dan cara penerbitannya. Karena kedaluwarsa terjadi diam-diam tanpa menghentikan pengiriman server Anda secara terlihat, cara paling aman adalah memeriksa catatan penerimaan event secara berkala, dan untuk operasi jangka panjang, menentukan kebijakan pembaruan token sejak awal.
Kesimpulan: jangan berhenti di "sudah terkirim" — pastikan "Meta menerima dan mencocokkannya"
Menjalankan Langkah 1 (metode koneksi) → 2 (test_event_code) → 3 (deduplikasi) → 4 (kualitas pencocokan) memungkinkan Anda mengisolasi semuanya, dari pengiriman hingga pencocokan. Yang penting adalah gambaran menyeluruh: apakah event server diterima, dicocokkan dan dideduplikasi dengan sisi browser, serta tercatat di jalur pengunjung nyata di production. Untuk gambaran lengkap pelacakan konversi Meta, lihat Panduan Lengkap Pelacakan Konversi Meta.
ConversionOK menjalankan halaman live Anda di browser independen dan terisolasi, lalu mencegat event yang benar-benar terkirim untuk diverifikasi — tanpa perlu mengklik iklan Anda sendiri dan tanpa gangguan dari lingkungan kantor Anda. Mulai dengan pemeriksaan statis gratis untuk memastikan titik awal pengukuran Anda.