Rekomendasi Bacaan Focus Deck
detikcom

Simulasi rollout push notif untuk fitur Rekomendasi Bacaan

Fokus deck ini saya sempitkan ke Rekomendasi Bacaan saja, berdasarkan poin yang ada di PDF: notif artikel satuan yang personal, dikirim otomatis oleh sistem, di luar push manual dari redaksi, dengan frequency cap 1-2 notifikasi per hari, serta logic untuk exclude artikel yang sudah dibaca. Di versi deck ini, fokus eksperimennya adalah 50:50 split antara manual dan recommendation tanpa mengikat pengiriman ke jam tertentu. Baseline operasional yang dipakai sekarang adalah total push notif harian sekitar 70-an kiriman.

Yang tertulis di PDF

  • Rekomendasi Bacaan dikirim otomatis tanpa perlu diatur tim redaksi.
  • Target utamanya active dan power users dengan minat topik yang jelas.
  • Trigger recommendation berasal dari preference/topik + sinyal minat + artikel baru yang relevan.
  • Success metric yang disebut: CTR?CTR adalah Click-Through Rate, yaitu persentase user yang menekan notifikasi setelah menerimanya. lebih tinggi dari broadcast biasa dan engagement time?Engagement time adalah lama waktu user benar-benar mengonsumsi konten setelah notifikasi dibuka. > 60 detik.
  • Acceptance penting: jangan rekomendasikan artikel yang sudah dibaca.

Masalah rollout yang paling nyata

  • Jalur manual redaksi tetap hidup, jadi conflict utamanya adalah manual vs recommendation.
  • Masalah inti bukan sekadar model rekomendasi, tetapi slot allocation?Slot allocation adalah pembagian jatah kirim notifikasi antara jalur manual dan jalur recommendation., collision?Collision adalah kondisi ketika dua jalur notif mendorong topik atau cerita yang sama ke user yang sama., fallback?Fallback adalah rute cadangan ketika recommendation tidak punya artikel yang cukup layak untuk dikirim., dan frequency cap.
  • Kalau 50:50 dipaksakan terlalu kaku, rekomendasi bisa kosong saat inventory?Inventory di sini berarti stok artikel baru yang tersedia untuk dipertimbangkan oleh engine recommendation. lemah, atau editorial bisa kehilangan ruang saat breaking news.
Current volume
~70/hari
Artinya skenario 50:50 secara kasar berarti sekitar 35 slot manual vs 35 slot recommendation dalam satu hari.
Recommendation share
50%
Dalam versi simulasi ini, recommendation dibaca sebagai porsi slot harian, bukan fixed send window.
Frequency cap
1-2 / hari
Cap ini kelihatan aman sendiri, tetapi tetap bisa jebol jika editorial punya jalur terpisah.
Core input
Interest + read history
Kalau salah satu lemah, sistem akan kesulitan mengisi slot recommendation secara konsisten.
Constraint
Manual push tetap hidup
Artinya Anda butuh arbitration layer?Arbitration layer adalah lapisan keputusan yang memilih notifikasi mana yang benar-benar boleh terkirim saat beberapa kandidat bersaing., bukan sekadar scheduler recommendation.

Breakdown fitur Rekomendasi Bacaan

Bagian ini menurunkan requirement PDF menjadi komponen operasional yang benar-benar akan menentukan sehat atau tidaknya rollout.

Feature anatomy

Eligibility layer

  • User harus punya preferensi topik yang cukup jelas.
  • History baca harus cukup untuk membentuk confidence score?Confidence score adalah skor keyakinan sistem bahwa minat user terhadap topik tertentu memang cukup kuat dan stabil..
  • User yang belum cukup sinyal tidak boleh dipaksa menerima rec yang setengah random.

Inventory layer

  • Harus ada artikel baru yang benar-benar cocok dengan topik user.
  • Artikel juga harus punya quality signal, misalnya velocity?Velocity adalah sinyal kecepatan konsumsi artikel, misalnya seberapa cepat artikel itu dibaca atau naik performanya dalam waktu singkat. tinggi seperti yang disebut di PDF.
  • Kalau inventory lemah, slot recommendation tidak selalu bisa diisi penuh.

Delivery layer

  • Notif dikirim otomatis oleh sistem sesuai alokasi slot recommendation yang sedang diuji.
  • Harus ada exclude terhadap artikel yang sudah dibaca.
  • Harus ada guardrail lintas editorial supaya user tidak merasa dihajar dua sistem sekaligus.

Failure modes khusus Rekomendasi Bacaan

Karena fokusnya hanya recommendation, tabel ini hanya memetakan kegagalan yang lahir dari interaksi recommendation dengan jalur manual redaksi.

Recommendation-only risk map
Failure mode Mengapa terjadi Dampak Guardrail minimum
Slot kosong
High		 Eligible users?Eligible users adalah pengguna yang dianggap layak menerima recommendation karena sinyal minatnya cukup kuat. ada, tetapi tidak cukup artikel baru yang benar-benar cocok. 50% slot recommendation tidak terisi atau terpaksa diisi recommendation yang terlalu generik. Fallback hierarchy?Fallback hierarchy adalah urutan keputusan cadangan saat recommendation utama tidak bisa mengisi slot, misalnya personalized lalu broad-interest lalu dikembalikan ke editorial. yang jelas: personalized -> broad-interest -> return to editorial.
Topic collision
High		 Editorial dan recommendation mendorong cluster cerita yang sama pada hari yang sama. User merasa spammy walau tiap tim merasa hanya mengirim “satu notif yang wajar”. Story-level dedupe?Story-level dedupe berarti dua artikel yang sebenarnya membahas cerita yang sama tetap dianggap duplikat walau ID artikelnya berbeda. lintas channel dan cooldown?Cooldown adalah jeda minimum sebelum user boleh menerima notifikasi lain untuk topik atau story yang sama. per topik.
Weak personalization
Medium		 Preference signal terlalu dangkal, topik terlalu lebar, atau model tidak cukup presisi. CTR recommendation mendekati broadcast biasa, jadi value feature hilang. Minimum confidence threshold?Confidence threshold adalah batas minimum keyakinan model sebelum sistem berani mengirim recommendation ke user. sebelum user dianggap eligible menerima rec.
Editorial starvation
Medium		 Ratio 50:50 diterapkan kaku saat redaksi sedang punya banyak push penting. Breaking / urgent update kalah oleh quota recommendation. Breaking-news override?Breaking-news override adalah aturan yang mengizinkan berita sangat penting menembus quota biasa dan langsung diprioritaskan. dan editorial reserve lane.
Cap breach
High		 Recommendation merasa punya cap sendiri, editorial juga punya jalur sendiri. Per-user daily push cap jebol tanpa ada pihak yang merasa bersalah. Global cap service?Global cap service adalah sistem pusat yang menghitung semua notifikasi lintas channel agar batas harian user tidak dilanggar. per user-day, bukan cap per channel.

Plan simulasi 50:50 dalam satu hari

Bagian ini menjawab pertanyaan inti dari skenario mentor Anda: jika proporsi notifikasi rekomendasi dan manual dibuat 50:50 dalam satu hari, seperti apa requirement ideal-nya dan apa implikasi ke backend.

Mentor focus

1. Plan simulasi

  • Tentukan dulu total slot push per hari yang menjadi basis pembagian.
  • Karena baseline aktual ada di kisaran 70-an notif per hari, maka skenario 50:50 berarti membagi sekitar 35 slot manual dan 35 slot recommendation.
  • Bagi slot menjadi 50% manual dan 50% recommendation pada level sistem, bukan di level tim.
  • Jalankan simulasi pada beberapa kondisi: hari normal, hari breaking, dan hari saat inventory recommendation lemah.
  • Bandingkan 3 policy: hard 50:50, elastic reallocation, dan manual priority override.
  • Output yang dievaluasi: fill-rate recommendation, manual backlog, collision rate, dan cap pressure per user.

2. Requirement ideal

  • Sistem harus punya satu sumber kebenaran untuk slot harian, bukan pembagian manual per tim.
  • Sistem harus bisa menandai user yang eligible, artikel yang layak direkomendasikan, dan artikel yang sudah dibaca.
  • Harus ada dedupe lintas channel, global frequency cap, dan breaking-news override.
  • Harus ada fallback resmi saat slot recommendation tidak bisa diisi: broad-interest backfill, return ke editorial, atau dibiarkan kosong.
  • Semua keputusan harus bisa dilog: kenapa user dapat notif, kenapa notif dibatalkan, dan kenapa slot dialihkan.

3. Implikasi ke backend

  • Backend tidak cukup hanya punya scheduler kirim. Harus ada arbitration service untuk memilih notifikasi final.
  • Perlu candidate pipeline terpisah untuk manual push dan recommendation push sebelum keduanya dipertemukan.
  • Perlu service untuk dedupe story/topic, frequency cap, dan slot ledger harian.
  • Perlu event logging dan observability: candidate created, candidate dropped, delivered, clicked, read, dan suppressed reason.
  • Perlu experiment config yang bisa diubah tanpa redeploy: ratio, fallback mode, override rule, dan cap.

Interactive simulator: editorial vs recommendation

Model ini hanya memotret perang slot antara redaksi dan recommendation. Tidak ada Daily Digest atau Recall di dalam versi ini.

Focused what-if model
Final manual pushes
0
Personalized pushes
0
Lost to collision
0
Unused / diluted slots
0

Channel orchestration

    Cap pressure

      Top risks in this setup

        Likely measurement distortions

          What the platform should do next

            Sample one-day timeline

            Model ini sengaja hanya memetakan rollout Rekomendasi Bacaan. Daily Digest dan Recall sengaja dikeluarkan agar diskusinya fokus ke satu fitur.

            Rollout path yang saya sarankan untuk Rekomendasi Bacaan

            Kalau targetnya adalah relevance naik tanpa mengganggu disiplin push redaksi, jangan mulai dari rasio kaku. Mulai dari kontrol, logging, dan arbitration.

            Recommended path

            Stage 1: Shadow mode

            1. Generate candidate recommendation tanpa mengirim.
            2. Log overlap terhadap push editorial yang benar-benar terkirim.
            3. Ukur fill-rate, match quality, dan collision rate per topik.

            Stage 2: Controlled live

            1. Live-kan recommendation pada porsi kecil lebih dulu, bukan langsung 50% penuh.
            2. Aktifkan story dedupe, global cap, dan breaking-news override.
            3. Jangan dulu memaksa 50:50 jika rec inventory belum sehat.

            Stage 3: Elastic scaling

            1. Naikkan share recommendation hanya jika coverage dan CTR benar-benar bagus.
            2. Formal-kan fallback hierarchy untuk slot kosong.
            3. Pastikan reporting recommendation dan editorial tetap terpisah dengan attribution yang jelas.