Veri ve UX’ten model seçimi, test ve gizlilik uygulamalarına kadar yapay zeka tabanlı öneriler sunan bir mobil uygulamayı planlamayı, oluşturmayı ve yayınlamayı öğrenin.
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.
Çoğu mobil uygulamadaki öneri deneyimi birkaç yapı taşına indirgenir:
Ö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.
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.
Ö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.
En çok değeri üreten (ve en çok karar noktası olan) yolla başlayın. Örneğin:
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.
MVP’nizi odaklı tutmak için bir yüzey seçin ve onu iyi yapın:
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.
Seçtiğiniz yüzey için her birini bir cümleyle yazın:
Bu, teoride “doğru” olan ama sonuçları etkilemeyen bir şey inşa etmekten alıkoyar.
Bunları spesifik ve test edilebilir tutun. Örnekler:
Bunlar netleşince, veri toplama, model seçimi ve değerlendirme için somut bir hedefiniz olur.
Ö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.
Ç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.
“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.
Küçük, iyi tanımlanmış bir olay setiyle başlayın:
Her olay için (ve belgeleyin): zaman damgası, item_id, kaynak (search/feed/reco), pozisyon ve session_id.
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.
Kimliği erken tanımlayın:
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.
İ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.
Bir özelliğin ihtiyaç duyduğu anda izin isteyin—hemen ilk açılışta her şeyi istemeyin.
Örneğin:
İ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.
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:
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.
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:
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.
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.
Aşağıdaki tanıdık modüllerle başlayın:
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.
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:
Kullanıcılar önerileri düzelttiğinde sistem daha hızlı öğrenir. Basit kontroller ekleyin:
Bu kontroller sadece UX için değil—aynı zamanda öneri motoruna yüksek kaliteli geri bildirim sinyalleri üretir.
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.
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.
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:
Kurallar ayrıca soğuk başlangıç için güvenli bir geri dönüş sağlar.
İç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.
İş 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 sistemler kural + içerik + iş birliği sinyallerini birleştirir. Özellikle şu durumlarda faydalıdır:
Yaygın bir hibrit düzen: adayları küratör/popüler listelerden üret, sonra mevcutsa kişiselleştirilmiş sinyallerle yeniden sırala.
Öneri motorunuzun “nerede” çalıştığı maliyeti, hız, gizlilik duruşunu ve yineleme hızını etkiler.
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.
Çoğu üretim kurulumunda bulunur:
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ı).
Beklentileri erken belirleyin:
Bu, kalite üzerinde iterasyon yaparken deneyimi istikrarlı tutar.
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.
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ğitimden önce genellikle şunları yaparsınız:
Ayrıca hangi olayın “pozitif” sinyal sayılacağını (tıklama, sepete ekleme) ve hangisinin sadece maruz kalma olduğunu belirleyin.
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.
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.
Başarılı uygulamaların çoğu birkaç basit fikri birleştirir ki sonuçlar kişisel, çeşitli ve zamanında hissedilsin.
Yaygın desen iki aşamalı öneri:
Bu ayrım uygulamanızın yanıt vermesini sağlarken daha akıllı sıralamaya izin verir.
Embedding’ler kullanıcıları ve öğeleri çok boyutlu bir uzayda noktalara çevirir; “daha yakın” olmak “daha benzer” demektir.
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ıç, kullanıcı veya yeni öğe için yeterli davranış verisi olmadığında ortaya çıkar. Güvenilir çözümler:
Güçlü bir sıralayıcı bile tek bir temaya odaklanabilir. Sıralamadan sonra basit korumalar ekleyin:
Bu kurallar önerileri daha insani yapar—tekrar eden değil, faydalı.
Ö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).
Offline değerlendirme, geçmiş etkileşimleri kullanarak modelleri hızlıca karşılaştırmanıza yardımcı olur. Yaygın metrikler:
Offline skorlar hızlı iterasyon için iyidir, ancak yenilik, zamanlama, UI ve kullanıcı niyeti gibi gerçek dünya etkilerini kaçırabilir.
Öneriler canlıyken bağlam içinde davranışı ölçün:
Bir birincil metrik seçin (ör. dönüşüm veya tutma) ve destekleyici metrikleri güvenlik ölçütleri olarak tutun.
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.
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.
Ö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.
Kaydırmanın ve geçişlerin anlık hissetmesi için:
Olay toplama’dan cihaza render edilmeye kadar tüm zinciri izleyin. En azından şunları takip edin:
Uyarı ekleyin, net sahipler belirleyin ve oyun planları hazırlayın (geri alma, devre dışı bırakma, düşük kalite moduna geçme).
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.
Ö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.
Küçük başlayın, stabiliteyi kanıtlayın, sonra kapsamı genişletin:
Eski deneyimi kontrol olarak tutun ki sonuçları karşılaştırıp önerilerin etkisini izole edebilin.
Açılım yüzdesini artırmadan önce doğrulayın:
İyileştirmeleri kısa döngülerle (haftalık veya iki haftada bir) yapın:
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.
Start with one surface where users commonly get “stuck,” such as a product/detail page or search results. Write one user goal and one business goal (e.g., “help me compare quickly” vs. “increase add-to-cart rate”), then define 3–5 user stories you can test.
A focused MVP is easier to instrument, evaluate, and iterate than a broad “personalized home feed” on day one.
Most apps use a small set of interaction events:
view (detail opened, not just shown)impression/exposure (what recommendations were displayed)click (tap from a recommendation module)save / add_to_cartpurchase / subscribeskip / dismiss / quick bounceInclude consistent fields like user_id (or anonymous ID), item_id, timestamp, source (feed/search/reco), position, and session_id.
Log an exposure (impression) event whenever a recommendation module renders with a specific ordered list of item IDs.
Without exposure logging you can’t reliably compute CTR, detect position bias, audit what users were shown, or understand whether “no click” was because items were bad or because they were never displayed.
Pick one primary “north star” metric aligned to the surface (e.g., conversion on a shopping detail page, watch time on a media feed). Add 1–3 guardrails such as bounce rate, refunds/cancellations, complaint rate, or latency.
This prevents optimizing for easy wins (like CTR) that don’t improve real outcomes.
Use a layered fallback strategy:
Design the UI so empty states never show a blank screen—always show a safe default list.
Rules are best when you need speed, predictability, and a strong baseline (popularity, newest, curated lists). Content-based filtering works well when item metadata is strong and you want relevance with limited user interactions.
Collaborative filtering typically needs more behavior volume and struggles with brand-new items, so many teams adopt a hybrid: rules for coverage, ML for re-ranking when signals exist.
Build a hybrid system that combines:
This approach improves coverage, reduces repetitiveness, and gives reliable fallbacks when data is sparse.
Set clear product and engineering targets:
Use caching (per user/segment), return results in pages (10–20 items), and prefetch the first page so screens feel instant even on poor networks.
Use a time-based split: train on earlier interactions and validate on later ones. Avoid random splits that can leak future behavior into training.
Also define what counts as a positive (click, add-to-cart) vs. just an impression, and deduplicate/sessionize events so your labels reflect real user intent.
Collect only what you need, explain it clearly, and give users control:
Link policy details with a relative URL like /privacy and ensure deletions propagate to analytics, feature stores, and training datasets.