Yapay Zeka Tabanlı Öneriler İçin Mobil Uygulama Nasıl Oluşturulur

Yapay Zeka Tabanlı Önerilerin Mobil Uygulama İçin Anlamı

Yapay zeka tabanlı öneriler, her kullanıcı için sonraki ne gösterilecek kararını veren uygulama özellikleridir—ürünler, videolar, makaleler, dersler, destinasyonlar veya hatta UI kısayolları gibi—kullanıcı davranışı ve bağlama göre.

Gerçek uygulamalarda göreceğiniz üç desen

Çoğu mobil uygulamadaki öneri deneyimi birkaç yapı taşına indirgenir:

• Sıralama (Ranking): zaten bir öğe setiniz var (ör. “trend” veya arama sonucu) ve sistem bunları belirli bir kullanıcı için sıralar.
• Eşleştirme (Matching): sistem, geniş bir katalogtan kullanıcının niyetine uyan öğeleri seçer (ör. “X’i beğendiğiniz için” veya “seviyenize uygun”).
• Benzer öğeler: sistem, mevcut öğeyle ilişkili alternatifleri bulur (ör. “benzer ayakkabılar”, “buna benzer videolar”, “ilgili kurslar”).

Yaygın kullanım senaryoları (ve neden önemli oldukları)

• Alışveriş: “size önerilenler”, “genellikle birlikte alınanlar”, kişiselleştirilmiş teklifler.
• Medya ve eğlence: ana ekran akışı, “sonraki”, çalma listeleri.
• Haber ve topluluklar: konu akışları, “sonraki oku”, önerilen takipler.
• Öğrenme: kurs yolları, alıştırma setleri, beceri seviyesi önerileri.
• Seyahat ve yerel: destinasyon fikirleri, otel sıralaması, güzergâh önerileri.

Başarıyı nasıl tanımlarsınız

Öneriler ölçülebilir çıktılara bağlanmalıdır. Tipik metrikler CTR (tıklama oranı), dönüşüm (satın alma/abonelik), izlenme/okuma süresi ve uzun vadeli tutma (7. gün/30. gün geri dönüş oranları) içerir.

Bir “kuzey yıldızı” metriği seçin ve birkaç güvenlik ölçütü ekleyin (ör. hemen çıkma oranı, iadeler, churn veya besleme yükleme süresi) ki yalnızca tıklamalar için yanlış optimizasyon yapmayın.

Doğru beklentiyi kurun

Bir öneri motoru tek seferlik bir özellik değildir. Genellikle basit başlar ve uygulama daha iyi sinyaller (görünümler, tıklamalar, kayıtlar, satın almalar, atlamalar) topladıkça ve geri bildirimle öğrendikçe daha akıllı olur.

Doğru Kullanım Senaryosunu ve Kullanıcı Yolculuğunu Seçin

Öneriler, kullanıcıların “tıkandığı” belirli bir anda—kullanıcıların ne yapacağını bilmediği veya çok fazla seçenek olduğu yerlerde—en iyi şekilde işe yarar.

Modelleri düşünmeden önce, önerilerin sürtünmeyi kaldırıp hem kullanıcı hem iş için net bir kazanım yaratabileceği tam yol adımını seçin.

Önemli yolculuğu belirleyin

En çok değeri üreten (ve en çok karar noktası olan) yolla başlayın. Örneğin:

• Bir alışveriş uygulaması: göz atma → karşılaştırma → seçme
• Bir içerik uygulaması: açma → izlenecek/okunacak şey bulma → bağlı kalma
• Bir pazar yeri: arama → değerlendirme → iletişim veya rezervasyon

Yüksek çıkış yapılan ekranlar, ilk eyleme kadar geçen uzun süre veya kullanıcıların tekrar tekrar geri çekildiği yerlere bakın.

Birincil öneri yüzeyini seçin

MVP’nizi odaklı tutmak için bir yüzey seçin ve onu iyi yapın:

• Ana akış: keşif için harika, ancak farklı niyetleri karıştırdığı için değerlendirmesi daha zor.
• Arama: kullanıcı niyetini ifade ettiğinde çok iyi; sonuçları geliştirebilir veya “ilgili aramalar” önerebilir.
• Ürün/ayrıntı sayfası: güçlü bağlam (“benzer öğeler”, “başkalarının baktığı”), genellikle hızlıca işe yarar hale getirmesi en kolay olan.

Birçok uygulama için pratik bir varsayılan, ürün/ayrıntı sayfasıdır; çünkü mevcut öğe güçlü bir sinyal sağlar, kullanıcı hakkında hiçbir şey bilmeseniz bile.

Kullanıcı hedefi vs. iş hedefini tanımlayın

Seçtiğiniz yüzey için her birini bir cümleyle yazın:

• Kullanıcı hedefi: kişinin şu an ne yapmaya çalıştığı (ör. “Uzun süre kaydırmadan hızlıca hoşuma gidecek bir şey bulmama yardımcı ol”).
• İş hedefi: uygulama için başarının ne anlama geldiği (ör. “sepete ekleme oranını artırmak”, “tutmayı iyileştirmek”, “izlenme süresini artırmak”).

Bu, teoride “doğru” olan ama sonuçları etkilemeyen bir şey inşa etmekten alıkoyar.

Yüzey için 3–5 kullanıcı hikâyesi yazın

Bunları spesifik ve test edilebilir tutun. Örnekler:

• “Yeni kullanıcı olarak, tercihler ayarlamadan başlamak için popüler seçimleri göster.”
• “Geri dönen kullanıcı olarak, kaldığım yerden devam etmeme yardımcı ol.”
• “Bir öğeyi görüntülediğimde, hızla karşılaştırma yapabilmem için benzer seçenekleri göster.”
• “Arama yaptığımda, sorgum az sonuç veriyorsa ilgili alternatifleri göster.”

Bunlar netleşince, veri toplama, model seçimi ve değerlendirme için somut bir hedefiniz olur.

Verinizi Planlayın: Olaylar, Öğeler ve Kullanıcı Sinyalleri

Öneriler, beslediğiniz sinyaller kadar iyidir. Bir algoritma seçmeden önce, zaten hangi verilere sahip olduğunuzu, hangilerini hızlıca enstrümente edebileceğinizi ve hangilerinden kaçınmanız gerektiğini haritalayın.

Muhtemelen zaten sahip olduklarınız vs. ihtiyaç duyacaklarınız

Çoğu uygulama “arka uç doğrusu” ve “uygulama davranışı” karışımı ile başlar. Arka uç doğrusu güvenilirdir ama seyrek; uygulama davranışı zengindir fakat izleme gerektirir.

• Çoğunlukla zaten mevcut: kullanıcı hesapları (varsa), siparişler/abonelikler, envanter/katalog, sunucuda yapılan arama sorguları, müşteri destek etiketleri.
• Genellikle toplanması gerekenler: uygulama içi gezinme olayları (görünümler, tıklamalar, atlamalar), harcanan süre, kaydırma derinliği, “ilgilenmiyorum”, takip/ kaydetmeler, ve maruz kalma kayıtları (ne önerdiğiniz).

“Maruz kalma”yı birinci sınıf veri olarak ele alın: ne gösterildiğini kaydetmezseniz, önyüklemeyi değerlendirmek, sorun teşhis etmek veya etkinlik ölçmek zordur.

Ana olaylarınızı tanımlayın (tutarlı kurallarla)

Küçük, iyi tanımlanmış bir olay setiyle başlayın:

• view (öğe ayrıntısı açıldı, yalnızca render edilmesi değil)
• click (liste/öneri modülünden)
• add_to_cart / save
• purchase / subscribe
• skip (açık kapatma veya hızlı çıkış)
• like / rating (topluyorsanız)

Her olay için (ve belgeleyin): zaman damgası, item_id, kaynak (search/feed/reco), pozisyon ve session_id.

Çürüme yapmayacak öğe meta verilerini planlayın

Temiz öğe alanlarıyla öneriler dramatik şekilde iyileşir. Yaygın başlangıçlar arasında kategori, etiketler, fiyat, süre (ör. okuma süresi/video uzunluğu) ve zorluk (öğrenme/fitness için) bulunur.

Analitik ve katalog servisiniz tarafından paylaşılan tek bir “öğe şeması” tutun, böylece model ve uygulama aynı dili konuşur.

Misafir kullanıcılar vs. giriş yapmış kullanıcılar

Kimliği erken tanımlayın:

• Misafir: anonim cihaz/uygulama örneği ID’si ve oturum tabanlı sinyaller kullanın.
• Giriş yapmış: misafir geçmişini kayıt/giriş sırasında hesaba birleştirin.

Birleştirme kurallarını açıkça yapın (neyi birleştireceksiniz, misafir geçmişini ne kadar süre tutacaksınız) ki metrikleriniz ve eğitim veriniz tutarlı kalsın.

Gizlilik, İzin ve Güvenlik Temelleri

İyi öneriler veri gerektirir, ancak güven kullanıcıları elde tutan şeydir. İnsanlar ne topladığınızı anlamazsa (veya sürpriz hissederse), kişiselleştirme hızla “ürkütücü” yerine faydalı hissettirmez.

Amaç basit: açık olmak, daha az toplamak ve sakladıklarınızı korumak.

İzin istemleri: açık, zamanında ve mümkünse isteğe bağlı

Bir özelliğin ihtiyaç duyduğu anda izin isteyin—hemen ilk açılışta her şeyi istemeyin.

Örneğin:

• Öneriler konum kullanıyorsa, kullanıcı “Yakınımda”ya dokunduğunda konum erişimi isteyin.
• “Arkadaşları bul” için kişileri kullanıyorsanız, sistem istemini göstermeden önce ne olacağını açıklayın.

İzin açıklamalarını sade tutun: ne topluyorsunuz, neden topluyorsunuz ve kullanıcı ne kazanıyor. Özellik yine çalışabiliyorsa her zaman “Şimdi değil” yolu sunun. Gizlilik Politikanıza bağlanmayı belirtin: /privacy.

Veri minimizasyonu: sadece gerekeni toplayın

Bir öneri motoru nadiren ham, hassas ayrıntıya ihtiyaç duyar. Seçtiğiniz kullanım senaryosu için minimum sinyalleri tanımlayarak başlayın:

• Tüm arama sorgularını depolamak yerine, yalnızca kategorileri veya niyetleri saklamanız yeterli olabilir.
• Kesin zaman damgalarını saklamak yerine, “son görüntülenenler” sıralaması yeterli olabilir.

Daha az olay türü toplayın, hassasiyeti azaltın (örn. kaba konum) ve gereksiz tanımlayıcıları saklamaktan kaçının. Bu hem riski düşürür hem de veri kalitesini iyileştirebilir.

Saklama ve silme: bunu sisteme erken dahil edin

Davranış günlükleri için bir saklama penceresi belirleyin (örneğin, ürününüze bağlı olarak 30–180 gün) ve bunu dahili olarak belgeleyin. Kullanıcının talep ettiği silmeyi yerine getirebildiğinizden emin olun: profil verisi, tanımlayıcılar ve kişiselleştirme için kullanılan ilişkili olaylar kaldırılmalı.

Pratikte bu şunları içerir:

• Kullanıcıya yönelik bir kontrol (örn. “Verilerimi sil” veya “Önerileri sıfırla”).
• Silmenin analitik, feature store ve eğitim veri kümelerine yayılmasını sağlayan bir arka uç süreci.

Hassas kategoriler: ekstra özen gösterin (veya tamamen kaçının)

Sağlık verileri, çocuklara ilişkin veriler ve hassas konum gibi kategorilerde özellikle dikkatli olun. Bu kategoriler genellikle daha sıkı yasal gereklilikler ve daha yüksek kullanıcı beklentileri tetikler.

Eğer gerçekten ihtiyaç varsa, güçlü korumalar ekleyin—açık rıza, daha sıkı saklama, sınırlı erişim ve muhafazakar varsayılanlar. Çocuklara yönelik uygulamalarda ek kısıtlamalar olacağını varsayın ve erken dönemde hukuk danışmanlığı alın.

Uygulamada Öneri Deneyimini Tasarlayın

Bir öneri motoru mükemmel olsa bile uygulama içinde kafa karıştırıcı veya itici görünüyorsa “yanlış” hissedilebilir. Hedefiniz: önerileri anlaşılır, hızlı harekete geçirilebilir ve düzeltmesi kolay yapmak—ekranı öneri duvarına çevirmeden.

MVP için işe yarayan UI desenleri

Aşağıdaki tanıdık modüllerle başlayın:

• “Bunu izlediğiniz/okuduğunuz/aldığınız için…”: satırın neden var olduğunu açıklar ve güven oluşturur.
• “Benzer öğeler”: kullanıcı ayrıntı sayfasındayken keşif modu için ideal.
• “Size özel en iyi seçimler”: sinyalleriniz oluştuğunda ana ekranda geniş kişiselleştirme için bir satır.

Modül başlıklarını spesifik tutun (ör. “Caz Klasiklerini dinlediğiniz için”)—genel başlıklar (“Önerilen”) uygulamanın tahmin ettiğini hissettirebilir.

Kullanıcıyı bunaltmayın

Kişiselleştirme sonsuz kaydırma lisansı vermez. Ekranda öneri satır sayısını sınırlayın (MVP için genellikle 2–4) ve her satırı kısa tutun. Daha fazla içerik varsa, tek bir “Tümünü gör” girdisiyle ayrılmış bir liste sayfası açın.

Ayrıca önerilerin nerede en iyi uyduğunu düşünün:

• Keşif için ana ekran
• “Benzer” keşif için öğe/ayrıntı sayfaları
• Bir eylemden sonra (tamamlanma, satın alma, beğeni) nazikçe bir sonraki adım önerme

Kullanıcı kontrolleri ekleyin (ve görünür yapın)

Kullanıcılar önerileri düzelttiğinde sistem daha hızlı öğrenir. Basit kontroller ekleyin:

• Bu öğeyi gizle
• Beğenmiyorum / İlgilenmiyorum
• Neden bunu görüyorum? (bir cümle yeterli)
• Tercihleri sıfırla (ayarlar içinde, gömülü değil)

Bu kontroller sadece UX için değil—aynı zamanda öneri motoruna yüksek kaliteli geri bildirim sinyalleri üretir.

Soğuk başlangıç ve boş durumlar için tasarım

Yeni kullanıcıların geçmişi olmayacak; bu yüzden yine de kişisel hissettiren bir boş durum planlayın. Seçenekler: kısa bir onboarding seçici (konular, türler, hedefler), “bölgenizde trend” veya editörün seçtikleri.

Boş durumu açıkça ifade edin (“Ne sevdiğini söyle, seçimlerini kişiselleştirelim”) ve atlanabilir tutun. İlk oturum sıfır veriyle bile kullanışlı hissettirmeli.

Yaklaşım Seçimi: Kurallar, ML veya Hibrit

Faydalı öneriler sunmak için karmaşık bir modele ihtiyacınız yok. Doğru yaklaşım veri hacminize, kataloğun ne kadar hızlı değiştiğine ve deneyimin ne kadar “kişisel” olması gerektiğine bağlıdır.

Kurallar: hızlı, öngörülebilir ve MVP için ideal

Kurallara dayalı öneriler, sınırlı veri olduğunda veya sıkı editöryal kontrol istediğinizde iyi çalışır.

Yaygın basit seçenekler:

• Popülerlik: “En çok oynanan”, “En çok satın alınan”, “Bu hafta trend olanlar.” Açıklaması kolay ve genellikle güvenli.
• En yeni: “Yeni eklenen” öğeler. Katalog sık güncelleniyorsa keşfi destekler.
• Küratör listeleri: editör seçimi, mevsimlik koleksiyonlar veya kategori vurguları. Yeni kullanıcıları yönlendirmek için iyidir.

Kurallar ayrıca soğuk başlangıç için güvenli bir geri dönüş sağlar.

ML Seçeneği 1: içerik tabanlı filtreleme (öğe meta verisi kullanır)

İçerik tabanlı öneriler, kullanıcı daha önce beğendiği öğelere benzer öğeleri eşleştirir; öğe özellikleri (kategori, etiketler, fiyat aralığı, içerikten/ görsellerden elde edilen gömme/embeddings, zorluk seviyesi) kullanılır.

İyi meta veriye sahip olduğunuzda ve daha az kullanıcıyla anlamlı öneri istiyorsanız güçlü bir eşleşmedir. Tekrara düşmemesi için çeşitlilik kontrollerine ihtiyaç duyabilir.

ML Seçeneği 2: iş birliğine dayalı filtreleme (davranış örüntüleri kullanır)

İş birliğine dayalı filtreleme, kullanıcı davranışına (görünümler, beğeniler, kayıtlar, satın almalar, atlamalar) bakar ve “X ile etkileşime girenler Y ile de etkileşti” gibi örüntüler bulur.

Sürpriz ve yüksek performanslı öneriler sunabilir fakat yeterli etkileşim gerektirir ve yeni öğelerle zorlanabilir.

Hibrit: gerçek uygulamalar için pratik kişiselleştirme

Hibrit sistemler kural + içerik + iş birliği sinyallerini birleştirir. Özellikle şu durumlarda faydalıdır:

• Yeni kullanıcılar ve yeni öğeler için güçlü sonuçlar
• Çeşitlilik (tanıdık ve taze karışımı)
• Veri eksik veya gürültülü olduğunda güvenli bir ağ

Yaygın bir hibrit düzen: adayları küratör/popüler listelerden üret, sonra mevcutsa kişiselleştirilmiş sinyallerle yeniden sırala.

Mobil Öneriler İçin Mimari Seçenekleri

Öneri motorunuzun “nerede” çalıştığı maliyeti, hız, gizlilik duruşunu ve yineleme hızını etkiler.

Satın al vs. kur: barındırılan API veya özel servis

Barındırılan öneri API’leri MVP için genellikle en hızlısıdır: daha hızlı kurulum, daha az hareketli parça ve yerleşik izleme. Dezavantajı model detayları üzerinde daha az kontrol ve uzun vadede daha yüksek maliyet olabilir.

Özel öneri servisi (kendi arka ucunuz) sıralama mantığı, deney ve veri kullanımı üzerinde tam kontrol sağlar. Genellikle daha fazla mühendislik gerektirir: veri altyapısı, model eğitimi, dağıtım ve bakım.

Erken aşamadaysanız hibrit yaklaşım işe yarar: basit bir özel servis + kurallar ile başlayın, sinyaller büyüdükçe ML bileşenleri ekleyin.

Eğer darboğazınız uygulama yüzeylerini ve arka uç boru hattını hızlıca kurmaksa, sohbet tabanlı iş akışıyla prototip oluşturmanıza yardımcı olacak bir platform olan Koder.ai işinizi hızlandırabilir. Ekipler genellikle React tabanlı bir web admin, Go + PostgreSQL arka uç ve Flutter mobil uygulama ile başlayıp deneyler ilerledikçe snapshots/rollback ile iterasyon yapar.

Tipik bileşenler ("basit" sistemler için bile)

Çoğu üretim kurulumunda bulunur:

• Uygulama analitiği/olay toplama (tıklamalar, görünümler, satın almalar)
• Veri boru hattı olayları katalog verisiyle temizleyip birleştirmek için
• Feature store (veya daha basit bir feature tablosu) yeniden kullanılabilir kullanıcı/öğe sinyalleri için
• Model eğitimi + değerlendirme döngüsü
• Model servisleme servisi (sıralanmış öğeler döndüren API)
• Önbellek (Redis/CDN-benzeri) gecikmeyi düşük tutmak ve hesaplamayı azaltmak için

Cihazda vs. sunucu tarafı öneriler

Sunucu tarafı varsayılandır: modelleri güncellemek, A/B testleri yürütmek ve daha büyük hesaplama kullanmak daha kolaydır. Dezavantajı ağ bağımlılığı ve gizlilik sorunlarıdır.

Cihazda bazı sinyalleri yerel tutarak gecikmeyi azaltabilir, ancak model güncellemeleri zor, hesaplama sınırlı ve deneme/ hata ayıklama daha yavaştır.

Pratik orta yol: sunucu tarafı sıralama + küçük cihaz içi UI davranışları (örn. yerel yeniden sıralama veya “izlemeye devam et” kutucukları).

SLA’ları ve yedek davranışı tanımlayın

Beklentileri erken belirleyin:

• Gecikme hedefi (örn. uygulamada p95 < 200–400 ms)
• Çalışma süresi (örn. öneri uç noktası için %99.9)
• Veri eksikse veya servis kapalıysa yedekler: trend olan öğeler, editöryal seçimler veya kategori tabanlı varsayılanlar

Bu, kalite üzerinde iterasyon yaparken deneyimi istikrarlı tutar.

Veri Boru Hattını ve Eğitim Döngüsünü Kurun

Bir öneri motoru, onu besleyen boru hattı kadar iyidir. Hedef: uygulama davranışının eğitim verisine dönüştüğü, modelin buna göre iyileştiği tekrarlanabilir bir döngü kurmaktır.

Uçtan uca veri akışı (neresi nereye gider)

Basit güvenilir bir akış şöyle görünür:

Uygulama olayları (görünümler, tıklamalar, kayıtlar, satın almalar) → olay toplayıcı/analitik SDK → arka uç alım (API veya stream) → ham olay deposu → işlenmiş eğitim tabloları → model eğitim işi → model kayıt/değişim yönetimi → servisleme API → uygulama UI.

Uygulamanın rolünü hafif tutun: tutarlı olaylar gönderin (zaman damgası, kullanıcı ID veya anonim ID, item ID ve bağlam: ekran, pozisyon, yönlendirici).

Eğitimi kullanılabilir yapan ön işlemler

Eğitimden önce genellikle şunları yaparsınız:

• Temizleme: bozuk olayları atma, eksik item ID’leri düzeltme, zaman dilimlerini standartlaştırma.
• Tekilleştirme: tekrar göndermeleri, çifte tıklamaları veya çevrimdışı yeniden senkronizasyonu temizleme.
• Oturumlaştırma: olayları oturumlara gruplama (örn. 30 dakikalık etkinliksizlik yeni oturum başlatır) ki “kullanıcıların sonraki ne yaptığı” öğrenilsin.

Ayrıca hangi olayın “pozitif” sinyal sayılacağını (tıklama, sepete ekleme) ve hangisinin sadece maruz kalma olduğunu belirleyin.

Sızma olmadan train/validation ayırma

Modelin geleceğe bakmasını (peek) engelleyin. Zamana dayalı ayırma kullanın: daha önceki olaylarla eğitip daha sonraki olaylarla doğrulayın (çoğunlukla kullanıcı bazlı), böylece offline metrikler gerçek dünyaya daha yakın olur.

Yeniden eğitim sıklığı ve model versiyonları

Sürdürebileceğiniz bir sıklıkla başlayın—MVP için haftalık yaygın; stok veya trendler hızlıysa günlük olabilir.

Her şeyi versiyonlayın: veri seti anlık görüntüsü, feature kodu, model parametreleri ve değerlendirme metrikleri. Her sürümü bir uygulama sürümü gibi ele alın ki kalite düşerse geri alabilelim.

Modelleme İpuçları: Sıralama, Soğuk Başlangıç ve Çeşitlilik

Başarılı uygulamaların çoğu birkaç basit fikri birleştirir ki sonuçlar kişisel, çeşitli ve zamanında hissedilsin.

İki aşamada düşünün: adaylar → sıralama

Yaygın desen iki aşamalı öneri:

• Aday üretimi: “Bu kullanıcı için şu anda hangi 200–1000 öğe işe yarayabilir?” Hızlı ve geniş olmalı.
• Sıralama: “Bu öğeleri hangi sırayla göstermeliyiz?” Daha hassas ve zengin sinyaller kullanabilir.

Bu ayrım uygulamanızın yanıt vermesini sağlarken daha akıllı sıralamaya izin verir.

Embedding’leri basitçe açıklamak

Embedding’ler kullanıcıları ve öğeleri çok boyutlu bir uzayda noktalara çevirir; “daha yakın” olmak “daha benzer” demektir.

• Benzer konu veya kullanım desenine sahip öğeler birbirine yakın yerleşir.
• Bir kullanıcı embedding’i son ilgi alanlarını temsil eder (tıklamalar, kayıtlar, izleme süresi, satın almalar vb. bazında).

Pratikte embedding’ler genellikle aday üretimi için kullanılır; bir sıralama modeli listeyi bağlam (gün saati, oturum niyeti, fiyat aralığı, tazelik, iş kuralları) kullanarak inceltir.

Soğuk başlangıç sorununu erken ele alın

Soğuk başlangıç, kullanıcı veya yeni öğe için yeterli davranış verisi olmadığında ortaya çıkar. Güvenilir çözümler:

• Onboarding anketi: 3–5 hafif soru (ilgi alanları, hedefler, tercih edilen kategoriler). Cevapları ilk adayları başlatmak için kullanın.
• Kategoriye göre popüler: trend olanı gösterin, ancak kullanıcı seçtiği kategori, bölge, dil veya fiyat segmentine göre daraltın.
• Metadata benzerliği: etiketler, metin, yaratıcı veya marka gibi özniteliklerle “buna benzer” önerin—etkileşim verisi olmadan bile.

Akışı tekrarlayıcı olmaktan kurtarın: çeşitlilik ve tazelik ekleyin

Güçlü bir sıralayıcı bile tek bir temaya odaklanabilir. Sıralamadan sonra basit korumalar ekleyin:

• Çeşitlilik sınırları: aynı kategoriden/yaratıcıdan tekrarlamayı sınırlayın (örn. ilk 10’da aynı yaratıcıdan en fazla 2).
• Tazelik artırımı: yeni veya yakın zamanda güncellenmiş öğelere hafifçe öncelik verin.
• Yorgunluk kontrolleri: kullanıcı birkaç kez atladıysa öğeyi düşürün.

Bu kurallar önerileri daha insani yapar—tekrar eden değil, faydalı.

Kaliteyi Değerlendirme: Metrikler ve A/B Testi

Öneri kalitesi duygu değildir—kullanıcılara gerçekten daha iyi öneri verilip verilmediğini gösteren sayılara ihtiyacınız var. İki yerde ölçün: offline (geçmiş veride) ve online (canlı uygulamada).

Göndermeden önce offline metrikler

Offline değerlendirme, geçmiş etkileşimleri kullanarak modelleri hızlıca karşılaştırmanıza yardımcı olur. Yaygın metrikler:

• Precision@K: üst K önerinin kaçı alakalı?
• Recall@K: alakalı öğelerin kaçı üst K içinde başarıyla sunuldu?
• MAP (Ortalama Hassasiyet): birçok kullanıcı boyunca alakalı öğeleri daha üstlerde sıralayan modelleri ödüllendirir.
• NDCG: MAP’a benzer; özellikle alakalı öğeleri üst sıralarda daha çok değerler.

Offline skorlar hızlı iterasyon için iyidir, ancak yenilik, zamanlama, UI ve kullanıcı niyeti gibi gerçek dünya etkilerini kaçırabilir.

Yayına aldıktan sonra online metrikler

Öneriler canlıyken bağlam içinde davranışı ölçün:

• CTR (önerilen öğelerde tıklama oranı)
• Dönüşüm oranı (satın alma, abonelik, sepete ekleme vb.)
• Dwell time (önerilen içerikte geçirilen süre)
• Tutma (örn. D7/D30 geri dönüş oranı)

Bir birincil metrik seçin (ör. dönüşüm veya tutma) ve destekleyici metrikleri güvenlik ölçütleri olarak tutun.

Neden bir temel hattınız olmalı

Temel olmadan “daha iyi” tahmin olur. Temeliniz en popüler, en son görüntülenen, editör seçimleri veya basit kurallar olabilir.

Güçlü bir temel, anlamlı iyileştirmeler sağlar ve karmaşık bir modelin basit yaklaşımdan daha kötü performans göstermesini engeller.

A/B testleri ve güvenlik ölçütleri

Kontrollü A/B testleri yürütün: kullanıcılar rastgele kontrol (temel) vs. treatment (yeni öneri) görür.

Zararları erken yakalamak için güvenlik ölçütleri ekleyin: hemen çıkma oranı, şikayetler/destek talepleri ve gelir etkisi (iadeler veya churn dahil). Ayrıca besleme yükleme süresi gibi performans metriklerini izleyin—yavaş öneriler sonuçları sessizce öldürebilir.

Üretime Hazırlık: Performans, İzleme ve Geri Bildirim

Önerileri yayınlamak sadece model kalitesiyle ilgili değildir—deneyimi gerçek trafik altında hızlı, güvenilir ve güvenli kılmak önemlidir. Harika bir model yavaş yüklenirse (veya sessizce başarısız olursa) kullanıcılar için “bozuk” görünür.

Hızlı hissettiren performans

Kaydırmanın ve geçişlerin anlık hissetmesi için:

• Önbellekleme: kullanıcı/segment başına kısa TTL ile en iyi sonuçları önbelleğe alın. Öğelerin meta verilerini ayrı önbellekte tutun ki her yenilemede başlık/görsel tekrar indirilmesin.
• Sayfalandırma: sonuçları sayfalar halinde döndürün (örn. 10–20 öğe). İlk sayfayı hafif tutun, kullanıcı kaydırdıkça geri kalanı yükleyin.
• Ön yükleme: kullanıcı mevcut sayfanın yarısına geldiğinde sonraki sayfayı ön yükleyin; olası tıklamalar için öğe ayrıntılarını önceden alabilirsiniz.
• Nazik yedekler: öneri yavaşsa veya kullanılamıyorsa trend olan/yeni/kurallı listeleri gösterin. Bu bir hata durumu değil, ürün kararı olsun.

Sorunları erken yakalayan izleme

Olay toplama’dan cihaza render edilmeye kadar tüm zinciri izleyin. En azından şunları takip edin:

• Gecikme (P50/P95) öneri API çağrıları ve uçtan uca render süresi için
• Hata oranı ve zaman aşımı oranı, uygulama sürümü ve ağ türüne göre bölünmüş
• Veri tazeliği: olay alımında, feature güncellemelerinde ve eğitim işlerinde gecikmeler
• Model sapması: puan dağılımlarında, CTR veya dönüşümde kohort bazlı değişimler modelin eskidiğini veya davranışın kaydığını gösterebilir

Uyarı ekleyin, net sahipler belirleyin ve oyun planları hazırlayın (geri alma, devre dışı bırakma, düşük kalite moduna geçme).

Geri bildirim döngüleri ve istismara karşı direnç

Kullanıcılara açık kontroller verin: başparmak yukarı/aşağı, “buna benzer daha az göster” ve “ilgilenmiyorum”. Bunları eğitim sinyallerine dönüştürün ve mümkünse anında filtreleyin.

Manipülasyona karşı plan yapın: spam öğeler, sahte tıklamalar ve bot trafiği. Oran sınırlamaları, anomali tespiti (şüpheli tıklama patlamaları), tekilleştirme ve güven kazanılana kadar yeni öğeleri düşürme gibi önlemler uygulayın.

Yayınlama ve Net Bir Yol Haritasıyla İterasyon

Önerileri göndermek tek seferlik bir “yayına al” anı değildir—kontrollü bir açılım ve tekrarlanabilir iyileştirme döngüsüdür. Net bir yol haritası erken dönemde sizi erken geribildirime göre aşırı uyum sağlamaktan veya çekirdek deneyimi bozmakten korur.

Aşamalı açılım: öğrenirken riski azaltın

Küçük başlayın, stabiliteyi kanıtlayın, sonra kapsamı genişletin:

• İç test: çalışanlar ve test hesaplarıyla dogfood. İzlemeyi, gecikmeyi ve yedekleri doğrulayın.
• Beta: sınırlı bir kullanıcı seti (veya belirli bölge/cihaz kohortu). Nitel geri bildirim ve uç durumları izleyin.
• Yüzde ile açılım: 1% → 5% → 20% → 50% → 100%, duraklatma veya geri alma yeteneğiyle.

Eski deneyimi kontrol olarak tutun ki sonuçları karşılaştırıp önerilerin etkisini izole edebilin.

Yayın kontrol listesi (basit tutun)

Açılım yüzdesini artırmadan önce doğrulayın:

• Olaylar doğrulandı: ana analitik olayları doğru şekilde ateşleniyor (maruz kalma, tıklamalar, sepete ekleme/oynatma, dönüşümler, gizle/atla).
• Panolar hazır: temel metrikler, segment görünüşleri (yeni vs geri dönen, iOS vs Android) ve uyarılar.
• Yedekler çalışıyor: kişiselleştirme başarısızsa popüler/trend veya küratör listeleri gösterilsin—asla boş ekran olmasın.
• Güvenlik kontrolleri: engellenmiş öğeler görünmüyor; izin kuralları uygulanıyor; oran sınırlamaları ve önbellekleme aşırı yükü engelliyor.
• Deney kurulumu: A/B grupları stabil ve çıktıları atfedebiliyorsunuz (sadece tıklamalar değil).

Veriye ve geri bildirime dayalı yineleme döngüleri

İyileştirmeleri kısa döngülerle (haftalık veya iki haftada bir) yapın:

1. Teşhis analitikle (CTR, dönüşüm, tutma) ve hata loglarıyla (zaman aşımı, eksik veri).
2. Dinle geri bildirimleri (uygulama yorumları, uygulama içi anketler, destek biletleri) metrikin arkasındaki “neden”i öğrenin.
3. Bir şeyi değiştirin: UI yerleşimi, aday filtreleri, yeniden sıralama, çeşitlilik kuralları veya soğuk başlangıç stratejisi.
4. Yeniden test edin A/B veya kademeli açılım ile, sonra karar verin: koru, geri al veya yinele.

Uygulama ve dağıtım desteği bilgileri için /pricing sayfasına bakın. Analitik, A/B testi ve soğuk başlangıç gibi pratik rehber ve örüntüler için /blog'u inceleyin.

Hızla fikirden çalışan bir öneri yüzeyine (akış/ayrıntı modülleri, olay izleme uç noktaları ve basit bir sıralama servisi) geçmek istiyorsanız, Koder.ai planlama modu, dağıtım/barındırma ve kaynak kodu dışa aktarımı ile daha hızlı kurup yinelemenize yardımcı olabilir—yönetilen hızın avantajını elde ederken kod tabanınızın sahibi kalmanızı sağlar.