Feedback CRM dapat terkirim dua kali ketika koneksi terputus atau respons penerima tidak sampai. Ia juga bisa tiba tidak berurutan. Cara menanganinya dimulai dari membedakan kejadian bisnis, perubahan state, dan upaya pengiriman.

Saya menyarankan menuliskan hasil yang diharapkan sebelum menguji integrasi. Dengan begitu, kamu bisa membedakan data ganda yang perlu diperbaiki dari dua kejadian nyata yang memang perlu dicatat.

Satu kejadian bisa mempunyai beberapa upaya kirim

Bayangkan lead L-104 dinilai qualified pada Selasa pukul 10.00. Sistem mengirim kejadian itu, tetapi mengalami timeout. Ia mengulang pengiriman pukul 10.02 karena belum mengetahui apakah pengiriman pertama diterima.

Ada dua upaya pengiriman, tetapi hanya satu kejadian qualification. Jika setiap retry membuat identitas kejadian baru, sistem penerima dapat kesulitan mengenali bahwa keduanya mewakili hal yang sama.

Rancang identitas internal yang tetap untuk occurrence tersebut. Catat nomor upaya, waktu pengiriman, hasil respons, dan alasan retry secara terpisah. Cara menerjemahkannya ke field integrasi harus mengikuti kontrak teknis yang digunakan; nama kolom internal tidak otomatis sama dengan field Meta.

Sebelum membahas retry, pastikan makna setiap tahap CRM sudah jelas. Sistem yang rajin mengulang status dengan definisi salah hanya membuat kesalahan lebih konsisten.

Jangan menyamakan status bisnis dengan status pengiriman

Lead dapat sudah won di CRM, sementara pesan qualification masih menunggu retry. Jika kamu hanya mempunyai kolom “done”, sulit mengetahui apakah yang selesai adalah proses sales atau pengiriman data.

Pisahkan setidaknya keadaan bisnis dan keadaan koneksi. Keadaan bisnis bisa qualified atau won. Keadaan pengiriman bisa pending, acknowledged, perlu retry, atau gagal yang membutuhkan pemeriksaan.

Simpan timeline perubahan bisnis. Saat pesan lama tiba setelah pesan baru, histori harus tetap menunjukkan kapan masing-masing kejadian terjadi. Jangan membiarkan kedatangan pesan lama menimpa state bisnis terbaru hanya karena ia diproses terakhir.

Penerapan persisnya bergantung pada sistem. Yang perlu kamu minta kepada pengelola integrasi adalah perilaku yang dapat diuji, bukan janji bahwa jaringan tidak pernah mengirim pesan ganda.

Pakai matriks kasus sintetis

Berikut contoh pengujian dengan identitas buatan, tanpa data pelanggan nyata.

Kasus Kondisi uji Hasil internal yang diharapkan
Pengiriman normal Satu kejadian, satu kirim Satu occurrence dan hasil respons tercatat
Timeout lalu retry Occurrence sama dikirim ulang Histori upaya bertambah, occurrence tetap satu
Pesan terlambat Qualified tiba setelah won Timeline tetap benar, state terkini tidak mundur sembarang
Perubahan penilaian Qualified kemudian dikoreksi Koreksi tercatat dengan alasan dan waktu
Lead masuk ulang Kontak sama, kebutuhan berbeda Ditinjau sebagai peluang baru sesuai aturan bisnis

Tentukan juga kapan retry dihentikan dan siapa yang meninjau kegagalan permanen. Mengulang tanpa batas dapat menambah beban tanpa memperbaiki data yang memang tidak valid.

Rekonsiliasi dari sumber ke penerima

Ambil sejumlah kejadian yang memang seharusnya dikirim pada jendela tertentu. Hitung berapa yang antre, berapa yang mendapat acknowledgement, dan berapa yang membutuhkan investigasi. Jumlah log pengiriman bukan denominator yang tepat jika satu occurrence dicoba berkali-kali.

Sebagai ilustrasi, 50 occurrence dapat menghasilkan 58 send attempts karena delapan retry. Itu tidak berarti bisnis mendapat 58 lead. Bila 47 occurrence sudah acknowledged dan tiga belum jelas, tulis keadaan tersebut apa adanya.

Acknowledgement juga perlu dimaknai sesuai kontrak penerima. Respons teknis berhasil belum selalu membuktikan record dapat dicocokkan, muncul pada laporan yang diharapkan, atau digunakan sebagai tujuan optimasi.

Pisahkan koreksi data dari koreksi laporan

Jika tim menemukan status awal keliru, perbaiki sumber kebenaran terlebih dahulu dan simpan alasan perubahan. Setelah itu, periksa cara integrasi menangani koreksi. Jangan berasumsi mengirim ulang record akan menghapus semua dampak data sebelumnya pada sistem lain.

Untuk laporan, catat batch atau periode yang terpengaruh. Hal ini penting ketika event melonjak setelah newsletter dikirim: lonjakan bisa melibatkan kejadian baru, pengiriman tertunda, atau pengulangan yang perlu dipisahkan.

Output yang kamu butuhkan adalah matriks pengujian, log hasil, daftar exception, dan owner perbaikannya. Itu membuat percakapan dengan tim teknis lebih konkret daripada sekadar meminta “dedup dibenerin”.

Tetapkan bukti untuk menutup masalah

Untuk setiap exception, simpan contoh ID sintetis, perilaku yang diharapkan, perilaku yang terlihat, waktu pemeriksaan, dan pemilik tindak lanjut. Setelah perbaikan, ulangi kasus yang gagal serta satu kasus normal. Jangan hanya melihat bahwa pesan error sudah hilang.

Jika jumlah event berkurang setelah deduplikasi diperbaiki, jelaskan perubahan definisi pada laporan. Penurunan itu belum tentu berarti kualitas campaign memburuk. Tim perlu tahu kapan pengukuran berubah agar tidak membandingkan periode yang menghitung retry sebagai hasil bisnis dengan periode yang sudah memakai occurrence unik.

Pilih artikel lain sesuai kebutuhanmu di topik Meta Ads. Gunakan hasilnya untuk memperbaiki keandalan data sebelum mengandalkan angka tersebut untuk keputusan akuisisi.