Event Facebook tidak muncul di Events Manager (Flutter)

Sebelum Anda mengubah kode apa pun, kesampingkan dulu alur pelaporannya. Pelaporan agregat Meta di Events Manager tidak berjalan real time. Event yang sudah dikirim aplikasi Anda dengan benar bisa saja belum terlihat di tampilan yang Anda buka, semata karena belum selesai diproses ke tampilan itu.

Jadi jangan menelusuri masalah lewat dasbor agregat. Pakai Test Events di Events Manager: buka aplikasi Anda di Events Manager, masuk ke tab Test Events, lalu picu event itu secara manual di perangkat. Test Events menampilkan event dalam hitungan detik, sehingga pertanyaan apakah event sampai atau tidak berubah menjadi ya atau tidak.

Ada dua kemungkinan, dan keduanya membawa Anda ke bagian halaman yang berbeda. Jika event muncul di Test Events, pengirimannya berjalan dan masalah Anda ada di atribusi: lompat ke bagian terakhir. Jika tidak ada yang muncul setelah event dipicu manual, event itu tidak sampai ke Meta, dan bagian konfigurasi di bawah adalah titik awalnya.

Satu hal saat Anda menguji. SDK menyimpan event dan mengirimkannya dalam batch, jadi panggil flush() setelah event yang Anda uji: panggilan itu langsung mengirim semua yang tersimpan ke server, sehingga satu lagi alasan event terlambat hilang.

Tiga lapis, dengan urutan ini. Setiap lapis bisa menimbulkan gejalanya sendiri, dan setiap lapis lebih murah dikesampingkan daripada lapis sesudahnya.

1. Konfigurasi. App id, client token, dan entri di manifest atau plist yang mengarahkan SDK ke keduanya. Kalau ini salah, tidak ada apa pun yang terkirim.
2. Pengiriman. Versi Graph API, tipe nilai parameter event, dan setelan yang menahan pengiriman. Event dibuat di kode Anda dan tidak pernah diterima Meta.
3. Atribusi. Event sampai dan tercatat, tetapi angka yang menempel pada kampanye Anda tidak cocok dengan data Anda sendiri.

Urutannya penting karena dari luar masalah atribusi terlihat persis seperti masalah pengiriman. Keduanya muncul sebagai jumlah yang terlalu kecil, atau nol. Sebagian besar orang mulai menelusuri di lapis yang mereka tulis sendiri, yang biasanya justru lapis yang tidak bermasalah, dan kehilangan satu hari di sana. Pastikan dulu event sampai, baru perdebatkan arti angkanya.

Dua hal harus ada. Punya salah satu tanpa yang lain adalah penyebab paling umum di Android ketika tidak ada event yang sampai.

Resource string

Di android/app/src/main/res/values/strings.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="facebook_app_id">[APP_ID]</string>
  <string name="facebook_client_token">[CLIENT_TOKEN]</string>
  <string name="fb_login_protocol_scheme">fb[APP_ID]</string>
  <string name="app_name">[APP_NAME]</string>
</resources>

Rujukan di manifest

Resource string saja tidak cukup. Entri meta-data di AndroidManifest.xml itulah yang benar-benar dibaca SDK saat aplikasi mulai berjalan. Tanpa entri itu, nilainya hanya tersimpan di resource dan tidak ada yang pernah membacanya.

<application android:label="@string/app_name" ...>
  <meta-data android:name="com.facebook.sdk.ApplicationId" android:value="@string/facebook_app_id"/>
  <meta-data android:name="com.facebook.sdk.ClientToken" android:value="@string/facebook_client_token"/>
</application>

Build flavor

Kalau aplikasi Anda memakai build flavor, periksa strings.xml mana yang Anda ubah. Direktori resource sebuah flavor menimpa direktori utama, jadi nilai yang diletakkan di strings.xml flavor yang salah memang tidak ada di build yang Anda jalankan. Ini penyebab yang sering terjadi dan sulit terlihat: file yang terbuka di layar Anda tampak benar.

Bangun flavor yang Anda uji, lalu periksa manifest gabungan dan resource gabungan hasil build, bukan file sumber yang Anda ubah.

Ketiga kunci ini harus ada di Info.plist:

<key>FacebookAppID</key>
<string>[APP_ID]</string>
<key>FacebookClientToken</key>
<string>[CLIENT_TOKEN]</string>
<key>FacebookDisplayName</key>
<string>[APP_NAME]</string>

FacebookClientToken yang hilang atau salah adalah salah satu penyebab paling umum event diam-diam tidak sampai. Aplikasi tetap terbangun. SDK tetap terinisialisasi. Panggilan logEvent Anda kembali tanpa error. Tidak ada yang sampai ke Events Manager, dan tidak ada apa pun di aplikasi Anda yang menjelaskan sebabnya.

Ambil nilainya di App Dashboard pada Settings > Advanced > Security > Client token, lalu bandingkan karakter demi karakter dengan yang ada di Info.plist. Client token yang disalin dari aplikasi lain dalam akun bisnis yang sama akan terlihat wajar dan tidak akan bekerja.

Facebook SDK v18.x dirilis dengan versi Graph API default yang sudah dihapus Meta dari produksi. Nilai default-nya berbeda di setiap platform.

Kenapa mengunci versi itu penting

Versi yang dihapus bukan jurang. Panduan versi Meta menyebutkan bahwa setelah sebuah versi tidak lagi bisa dipakai, panggilan ke versi itu diarahkan ke versi berikutnya paling tua yang masih bisa dipakai. Jadi permintaan Anda tetap dilayani, hanya saja oleh versi yang dipilihkan Meta, bukan versi yang diminta aplikasi Anda. Kalau Anda mengunci versi dengan sengaja, keadaan itulah yang ingin Anda hindari.

Yang benar-benar Anda rasakan adalah pemberitahuannya. Aplikasi yang masih memakai default lama akan menerima email deprecation dari Meta beserta tenggat penghapusan, dan tenggat itu berasal dari batas bawah pemberitahuan pengembang yang sedang berlaku di Meta, bukan dari tanggal kedaluwarsa asli versi yang Anda pakai. Satu contohnya dilaporkan di plugin ini sebagai issue #474:

Your app is currently accessing a version of the Marketing API prior to v23.0. On February 19, 2026, all versions prior to v23.0 will be removed.

Batas bawah itu bergerak sesuai jadwal Meta, jadi versi dan tanggal pada pemberitahuan yang Anda terima tidak akan sama dengan itu. Bentuknya itulah intinya: tenggat yang bukan Anda tentukan, pada versi yang bukan Anda pilih secara sadar.

Apa yang dilakukan plugin ini

facebook_app_events menimpa versi Graph API saat plugin diinisialisasi, jadi hampir semua aplikasi tidak perlu mengonfigurasi apa pun untuk itu. Pada plugin 0.30.3, versi yang dipakai adalah v24.0. Jadikan README dan CHANGELOG plugin sebagai acuan nilai yang berlaku sekarang, karena nilai itu ikut bergerak seiring rentang versi yang didukung Meta.

Kalau Anda perlu versi tertentu, misalnya agar sama dengan backend Anda, panggil setGraphApiVersion sedini mungkin saat aplikasi mulai berjalan, sebelum apa pun yang bisa memicu permintaan Graph API. Panggilan Anda yang menang: plugin menyetel default-nya saat plugin terpasang, dan panggilan Dart Anda berjalan setelah itu.

final facebookAppEvents = FacebookAppEvents();

// Optional. The plugin already sets a default at initialization.
await facebookAppEvents.setGraphApiVersion('v24.0');

await facebookAppEvents.activateApp();

Dua kasus masih memakai default SDK. Aplikasi yang memakai SDK native secara langsung, tanpa plugin ini di jalur inisialisasi, mendapat versi yang dibawa SDK, bukan versi yang masih berlaku. Begitu juga fork yang menghapus penggantian nilai itu.

Meta belum memperbaikinya. Ketika SDK v19 rilis dengan default yang benar, penggantian ini tidak lagi berpengaruh dan panggilan di atas boleh dihapus dari kode Anda.

Facebook SDK native hanya menerima nilai parameter event bertipe String dan angka. Event yang membawa nilai bertipe lain dibuang oleh SDK: tanpa suara, tanpa error, dan tidak muncul di mana pun di Events Manager. Bukan hanya parameter yang salah itu. Seluruh event-nya.

facebook_app_events membuat kesunyian itu terlihat. logEvent menerima String, num, dan bool. Boolean diubah menjadi "1" dan "0", mengikuti konvensi ya dan tidak dari Meta, sehingga event tercatat sama di kedua platform. Tipe lain apa pun yang bukan null memunculkan ArgumentError di tempat pemanggilan, alih-alih menghilang.

Nilai terstruktur harus dikodekan sebagai string JSON lebih dulu, dan itulah yang ditetapkan Meta untuk parameter seperti fb_content:

// Throws ArgumentError: a List is not an accepted parameter value type.
await facebookAppEvents.logEvent(
  name: 'checkout_started',
  parameters: {'fb_content': items},
);

// Correct: encode the structure as a JSON string first.
await facebookAppEvents.logEvent(
  name: 'checkout_started',
  parameters: {'fb_content': jsonEncode(items)},
);

Bagian ini ada di halaman ini karena event yang dibuang tanpa suara justru gejala yang membawa orang ke sini. Kalau Anda memanggil SDK native secara langsung di bagian mana pun aplikasi Anda, atau mencatat event melalui pembungkus lain, periksa tipe nilainya di sana. ArgumentError dari plugin ini justru kabar baik: dia menyebutkan parameter mana yang salah.

Plugin ini tidak menampilkan dialog ATT, tidak mengelola persetujuan pengguna, dan tidak membuat aplikasi Anda memenuhi aturan privasi. Itu tanggung jawab aplikasi Anda, dan tidak ada plugin yang bisa mengambil alih.

Yang dilakukan plugin ini adalah menyediakan tombol privasi milik SDK native. Menyetelnya dengan benar juga tugas aplikasi Anda, dan salah menyetel salah satunya membuat data hilang tanpa pesan error apa pun.

setAdvertiserIdCollectionEnabled(bool)

Dipetakan 1:1 ke setelan native di kedua platform: Settings.shared.isAdvertiserIDCollectionEnabled di iOS dan FacebookSdk.setAdvertiserIDCollectionEnabled di Android. Setelan ini menentukan apakah advertiser id, yaitu IDFA di iOS atau Google Advertising ID di Android, dikirim bersama event Anda. Di iOS advertiser id baru tersedia setelah izin ATT diberikan, jadi menyetelnya ke true saja tidak menghasilkan identifier.

setAdvertiserTracking sudah tidak dipakai dan tidak berpengaruh di iOS 17+

Kalau aplikasi Anda masih memanggilnya dan mengharapkan ada efeknya, Anda punya bug yang tidak bersuara. Settings.isAdvertiserTrackingEnabled dinyatakan usang di Facebook SDK v17. SDK sekarang menyimpulkan persetujuan pelacakan dari ATTrackingManager.trackingAuthorizationStatus dan mengabaikan setter itu di iOS 17+. Di Android tidak ada flag pelacakan sama sekali, jadi panggilan itu menyusut menjadi setAdvertiserIdCollectionEnabled(enabled && collectId). Pakai setAdvertiserIdCollectionEnabled sebagai gantinya, dan minta izin ATT di aplikasi Anda.

Dua jalur lain yang menahan data

setDataProcessingOptions dan setLimitEventAndDataUsage keduanya membatasi apa yang boleh Meta lakukan dengan data yang Anda kirim: Limited Data Use pada yang pertama, dan pada yang kedua, semua penggunaan di luar analitik dan konversi. Salah satu saja, yang disetel di suatu tempat saat aplikasi mulai berjalan, bisa menjelaskan laporan yang Anda anggap hilang. Cari keduanya, termasuk di dalam SDK persetujuan yang bukan Anda tulis sendiri.

Dampaknya pada angka Anda

Kalau dialog ATT belum dijawab, atau gerbang persetujuan Anda menahan inisialisasi, event tidak akan mengalir. Celah di Events Manager akan sama persis dengan celah yang muncul dari integrasi yang rusak. Karena itu bagian ini berada di antara konfigurasi dan atribusi: ini lapis di mana aplikasinya benar, pluginnya benar, dan datanya tetap tidak ada.

Kalau Test Events menampilkan event Anda, konfigurasi di atas sudah benar, dan angka kampanye tetap tidak cocok dengan basis data Anda sendiri, masalah Anda bukan pengiriman. Masalah Anda atribusi, dan itu penelusuran yang berbeda dengan alat yang berbeda.

Penyebab yang biasa muncul:

• Jendela konversi dan pemetaan nilai SKAdNetwork. Untuk atribusi SKAdNetwork di iOS, yang diterima Meta adalah postback sesuai jadwal Apple yang membawa nilai konversi yang Anda konfigurasikan, bukan event seperti yang Anda catat. Kalau pemetaan itu tidak mewakili hal yang Anda ingin dipelajari kampanye, kampanye belajar dari sinyal yang salah, dan totalnya tidak akan pernah sama baris per baris dengan basis data Anda.
• Event server Conversions API yang bertumpuk dengan event klien. Ketika pembelian yang sama dikirim dari aplikasi dan dari server Anda tanpa kunci deduplikasi bersama, Meta tidak punya acuan yang andal untuk mencocokkannya dan bisa menghitungnya dua kali.
• Jendela atribusi. Meta mengaitkan sebuah konversi dengan klik atau tayangan yang mendahuluinya di dalam jendelanya. Basis data Anda mengaitkannya sesuai model Anda sendiri. Dua model atas event yang sama menghasilkan dua angka berbeda, dan tidak satu pun dari keduanya adalah bug.

Ketiganya bisa diperiksa. Tidak satu pun bisa diperiksa dari sebuah halaman web. Semuanya butuh build yang benar-benar Anda rilis, akun Events Manager, akun iklan, dan angka Anda sendiri diletakkan berdampingan, karena jawabannya biasanya ada pada selisih di antara semua itu, bukan pada salah satunya saja.

Itulah batas jujur sebuah panduan tertulis. Kalau Anda sudah menelusuri semua yang di atas, event Anda sampai, dan uangnya tetap tidak masuk hitungan, yang tersisa adalah seseorang membaca setelan Anda dengan datanya ada di depan mata. Pilihan di bawah menjelaskan mana dari kasus itu yang kami tangani gratis dan mana yang kami kenakan biaya.