Notifikasi cuaca yang baik harus tepat waktu, relevan, dan jarang salah bunyi. Di Satu Cuaca, kami memperlakukan notifikasi sebagai sinyal keputusan, bukan sekadar pesan. Artinya, setiap alert harus melalui ambang yang jelas, kontrol kualitas data, dan evaluasi pasca-kirim agar tingkat false alarm rendah tanpa mengorbankan lead time.

Sumber data dan konsensus. Untuk hujan, gabungkan probabilitas presipitasi per menit (nowcasting 0–120 menit), intensitas (mm/jam), dan jarak sel inti hujan dari lokasi pengguna. Untuk kualitas udara, gunakan AQI berbasis nowcast PM2.5 dan gas, disertai QC (ketersediaan data ≥75% per jam, de-spike, koreksi kelembapan). Notifikasi hanya terbit jika konsensus terpenuhi: misalnya 2 dari 3 sumber independen (sensor lokal, model, radar/satelit) setuju arah perubahan.

Ambang hujan yang praktis. Hindari sekadar “PoP ≥ 50%”. Terapkan ambang komposit:

• Peringatan Ringan: kirim bila PoP_60min ≥ 70% dan intensitas kini atau >15 menit ke depan ≥ 0.3 mm/jam, atau inti hujan terdeteksi bergerak mendekat <5 km.
• Peringatan Sedang–Lebat: kirim bila salah satu: PoP_60min ≥ 80% dan intensitas ≥ 1.5 mm/jam, atau proyeksi akumulasi 1–3 jam >5–10 mm.

Tambahkan histeresis: setelah memberi peringatan, jangan langsung men-downgrade sampai PoP_30min < 30% selama ≥20 menit dan intensitas <0.2 mm/jam, supaya notifikasi tidak “kedip-kedip”.

Ambang AQI yang bertanggung jawab. Untuk publik umum, kirim notifikasi saat naik kelas (misal Baik → Sedang atau Sedang → Tidak Sehat) dan bertahan ≥10–15 menit pada dua pembacaan berturut-turut (mengurangi spike sesaat). Untuk kelompok sensitif (anak, lansia, asma), gunakan ambang lebih rendah, misalnya AQI ≥ 80 (mendekati batas Sedang→Tidak Sehat untuk sensitif). Tambahkan histeresis serupa (turun stabil ke <70 selama 20 menit sebelum menutup peringatan).

Mengelola false alarm: keseimbangan biaya. Tidak ada ambang yang sempurna. Tetapkan rasio biaya λ = C_false_alarm / C_miss per jenis peringatan. Jika λ kecil (lebih takut “tidak memperingatkan”), ambang boleh lebih agresif; jika λ besar (pengguna cepat jenuh), ambang harus konservatif. Secara operasional, targetkan precision (PPV) ≥70% untuk peringatan hujan ringan dan ≥80% untuk hujan lebat/AQI Tidak Sehat, sambil menjaga lead time median 10–20 menit (hujan) dan waktu deteksi <15 menit (AQI).

Kontrol frekuensi dan penggabungan. Terapkan cooldown per kategori: misalnya maksimal 2 alert/jam untuk hujan dan 1 alert/2 jam untuk AQI, kecuali ketika naik kelas ke kategori lebih berat (boleh menembus cooldown). Gabungkan peringatan beruntun dalam update thread (“Hujan diperkirakan mulai 15 menit lagi → kini hujan ringan → hujan mereda”), agar kotak masuk pengguna rapi dan fatigue menurun.

Konteks, personalisasi, dan lokasi. Notifikasi harus menyebut lokasi/area, tingkat keyakinan, dan saran praktis (bawa payung, tunda aktivitas luar). Pengguna bisa memilih profil ambang (Umum vs Sensitif) dan radius lokasi (rumah, kantor, rute harian). Di kota berlembah seperti Bandung atau koridor pesisir Johor, pertimbangkan orografi/angin lokal: gunakan zona mikro (1–3 km) ketimbang kota utuh agar relevansi meningkat.

Isi pesan dan transparansi. Hindari clickbait. Tampilkan kategori + intensitas (“Hujan Ringan, 0.5–1.2 mm/jam”), window waktu (“±25 menit”), dan alasan singkat (“awan konvektif bergerak dari barat”). Sertakan confidence (“keyakinan tinggi/sedang”), waktu pembaruan berikutnya, dan tautan detail ke dashboard. Untuk AQI, sebut polutan dominan dan anjuran (“kurangi aktivitas berat di luar”).

Evaluasi berkelanjutan. Lakukan backtesting dan shadow evaluation: hitung precision/recall, false alarm rate, average lead time, dan calibration (apakah PoP 70% benar-benar terjadi ~70%?). Terapkan A/B test ambang berbeda pada sebagian pengguna, dan gunakan analisis pasca-event (misalnya hujan benar/bohong di 30 menit setelah alert). Tinjau hasil per wilayah (Bandung, Johor) karena pola hujan/angin berbeda.

Sketsa implementasi di Satu Cuaca. Pipeline mengubah data sensor & model menjadi event kandidat, kemudian policy engine menerapkan aturan: konsensus sumber → QC → ambang → histeresis → rate limit → personalisasi → rendering pesan. Event yang lolos dikirim via push/email/WA gateway dengan id thread untuk penggabungan. Semua keputusan dan metrik disimpan untuk evaluasi dan tuning ambang otomatis (mis. penyesuaian musiman).

Checklist cepat sebelum Go-Live.

1. mbang komposit hujan & AQI diset + histeresis aktif.
2. Konsensus minimal dua sumber + QC lulus.
3. Cooldown & penggabungan alert diuji.
4. Pesan berisi kategori, intensitas/perkiraan waktu, confidence, dan saran.
5. Panel evaluasi precision/lead-time berjalan harian.

Dengan disiplin di lima poin ini, notifikasi terasa jarang namun berarti—tepat saat pengguna benar-benar perlu tahu.