niranar.com Veri Normalizasyonu: Çoklu Kaynaktan Tek DB

Bir kullanıcı niranar.com'a girip "Bodrum, 15-22 Temmuz, 4 kişi, havuzlu villa" araması yaptığında, saniyeler içinde anlamlı sonuçlar karşısında bulur kendini. Mülk isimleri tutarlı. Fiyatlar EUR cinsinden ve birbirleriyle karşılaştırılabilir. Konumlar belirli — Yalıkavak, Türkbükü, Gümüşlük. Fotoğraflar yükleniyor, takvim dolu, kapasite bilgisi doğru. Her şey düzenli, her şey aynı dilde konuşuyor, her şey bir arada.

Ama bu düzenin arkasında görünmez bir iş katmanı var. 300.000'i aşkın aktif ilan, birden fazla dış kaynaktan toplanmış verilerden oluşuyor. Bu ilanların her biri farklı bir formatta gelmiş, farklı bir kelime hazinesiyle tanımlanmış, farklı bir coğrafi kodlama mantığıyla yerleştirilmiş, farklı bir para birimiyle fiyatlandırılmış olabilir. Temiz bir arama sonucu, görünmez bir normalizasyon sürecinin çıktısıdır. Kullanıcı yalnızca sonucu görüyor — içinden geçilen veri mühendisliği sürecini değil.

Sorun: Çoklu Kaynak Verisi Neden Zordur?

Tatil kiralama sektöründe ilanlar onlarca farklı platformda, yerel ajans sitesinde ve bağımsız mülk sahibinin web sayfasında yer alır. Bu kaynakların hiçbiri aynı veri modelini kullanmaz. Biri "Villa" derken diğeri "Yazlık", "Müstakil Ev", "Tatil Evi" veya sadece "Kiralık Mülk" der. Biri "5 kişilik kapasite" yazarken diğeri "3+1 oda" yazar ve kapasiteyi kullanıcıya bırakır. Biri koordinat bilgisi sunarken diğeri yalnızca mahalle adı yazar. Biri fiyatı dolar cinsinden gösterirken, bir diğeri TL olarak, bir başkası zaten EUR'da gösterir.

Bu farklılıklar birer veri hatası değildir. Her platform kendi kullanıcı kitlesine göre optimize edilmiştir. Yerel bir ajans sitesi Türk ev sahiplerinin dilini kullanır. Uluslararası bir platform farklı bir taksonomi dayatır. Sorun şu ki bu farklılıkları koruduğunuzda 300.000 ilan birbirine bağlı bir arama deneyimi oluşturmaz — yalnızca birbirinden kopuk listeler yığınıdır. Filtre anlamlı çalışmaz. Harita tutarsız görünür. Fiyat karşılaştırması imkânsız hale gelir.

Çoklu kaynak verisiyle çalışan her platformun temel sorularla yüzleşmesi gerekir: Mülk tipi sınıflandırması nasıl tutarlı hale getirilir? Koordinat bilgisi olmayan ya da hatalı koordinat içeren mülkler haritada nasıl konumlandırılır? Aynı mülkün birden fazla kaynakta listelendiği tespit edilebilir mi, edilirse hangisi esas alınır? Farklı para birimlerindeki fiyatlar nasıl tek bir standarda çekilir ve bu standart nasıl güncel tutulur? Takvim bilgisi kaynak ile kaynak arasında nasıl tutarlı tutulur? Bunların hepsi teknik sorular olduğu kadar ürün kararlarıdır da.

Mülk Sınıflandırması: Villa ve Daire Nasıl Ortaya Çıkar?

niranar.com'da iki ana mülk kategorisi var: Villalar ve Daireler. Bu iki kategori navigasyonda filtre seçeneği olarak çalışıyor — kullanıcı "Villalar" dediğinde platforma sormak istediği şey son derece nettir: özel havuzu olan, geniş, genellikle müstakil bir tatil mülkü.

Ama bu netlik otomatik olarak kaynaklardan gelmiyor. Farklı platformlarda bir mülk "Villa", "Lüks Villa", "Özel Villa", "Müstakil Yazlık", "Kiralık Bağımsız Ev", "Tripleks", "Kottaj" ya da başka onlarca etiketle tanımlanmış olabilir. Benzer çeşitlilik daire kategorisi için de geçerlidir: "Daire", "Rezidans", "Kiralık Daire", "Apart", "Stüdyo", "Flat" — bunların hepsi, içerik ve bağlama göre, niranar.com'daki iki kategoriden birine düşmesi gerekiyor.

Bu sınıflandırmayı doğru yapmak, arama deneyiminin temel kalitesini belirliyor. Bir kullanıcı villa filtresiyle arama yaptığında daire sonuçlarıyla karşılaşırsa platforma güveni anında sarsılır. Tersi de geçerli: villa araması yapan bir kullanıcının stüdyo dairelerle karşılaşması, arama fonksiyonunun temel işlevini bozmaktır. 300.000'i aşkın ilanın bu iki kategoride tutarlı biçimde düzenlenmesi, hangi kaynak hangi format kullansın fark etmeksizin doğru çalışan bir sınıflandırma mekanizması gerektirir.

Dil ve Terminoloji Sorunu

Türkçe tatil kiralama terminolojisi de kendi içinde tutarsız olabilir. "Yazlık" hem villa hem daire anlamında kullanılabilen bir kelimedir. "Apart" bir dairenin belirli bir tipini ifade ediyor olabilir ya da bir binanın adı olabilir. "Tatil evi" neredeyse her türlü mülkü kapsayacak kadar geniş bir terim. Bu dil belirsizliği, mülk tipi sınıflandırmasını yalnızca etiket eşleştirmesinden ibaret olmayan, bağlamı da değerlendiren bir süreç haline getirir.

Üstelik bazı kaynaklar mülk tipini hiç belirtmeyebilir. Yapısal özelliklerden (kaç oda, özel havuz var mı, bağımsız mülk mü) tipin çıkarsanması gerekebilir. Bu, sınıflandırmanın yalnızca sözlük tabanlı değil, mülkün diğer özelliklerini de hesaba katan bir mantık gerektirdiği anlamına gelir.

Coğrafi Tutarlılık: Akdeniz Bölgesi Neden Normalize Edilmesi Zor Bir Hedeftir?

niranar.com Antalya, Bodrum, Fethiye, Sapanca, Kuşadası ve Alanya başta olmak üzere Türkiye'nin Akdeniz ve Ege kıyı bölgelerini kapsamaktadır. Haritada bu destinasyonları görmek kolay. Ama birden fazla kaynaktan gelen veride bu coğrafyayı tutarlı biçimde temsil etmek başka bir meseledir.

Türkiye'nin tatil kiralama bölgelerinde mülk konumlarına atıflar son derece değişken olabilir. "Bodrum'un Yalıkavak mahallesi" bir kaynakta "Bodrum — Yalıkavak" olarak geçerken, diğerinde sadece "Muğla", başka birinde "Yalıkavak, 48770" olarak yazılmış olabilir. Antalya için durum daha da karmaşıktır: Lara, Belek, Kemer, Alanya'nın her biri hem bağımsız destinasyon hem de "Antalya bölgesi" olarak temsil edilebilir. Fethiye çevresindeki köy isimleri — Ölüdeniz, Hisarönü, Ovacık — bazı kaynaklarda ayrı destinasyon olarak, bazılarında Fethiye alt konumu olarak görünebilir.

Bu belirsizlik, kullanıcı deneyimi açısından somut bir sorundur. Bir kullanıcı "Fethiye" araması yaptığında haritada Hisarönü'ndeki bir mülkün göründüğünü, başka bir araştırmada ise aynı mülkün Ölüdeniz altında listelendiğini görürse, platform güvenilirliğini sorgulamaya başlar.

Harita Görünümü Koordinat Hatalarını Anında Görünür Kılar

Leaflet üzerinden çalışan haritada bir mülkün doğru konumda görünmesi için koordinatların hem var hem de doğru olması gerekir. Yanlış koordinat mülkü denizin ortasına ya da dağın tepesine koyar. Eksik koordinat mülkü haritadan düşürür — liste görünümünde var, haritada yok. "Bodrum bölgesi" gibi geniş bir konum tanımı harita görünümünde merkezi bir noktaya pin koyar, ki bu tatilci için gerçek konumu göstermez.

300.000+ ilanın her biri için coğrafi bilginin kullanılabilir ve tutarlı olması, platformun temel değer önerisinin —"nereye gidiyorsun, tam olarak nerede kalacaksın?"— gerçek anlamda karşılanmasını sağlıyor. Harita tabanlı gezinme, bir özellik olarak var olmasının ötesinde, bu coğrafi tutarlılığın doğru çalıştığının canlı kanıtıdır.

Fiyat Normalizasyonu: EUR Neden Birleştirici Para Birimi Oldu?

niranar.com'daki tüm ilanlar EUR cinsinden fiyatlandırılmış. Bu, kullanıcı arayüzünde tek tip, karşılaştırılabilir bir fiyat deneyimi sağlıyor. Bir kullanıcı Antalya'dan bir villa ile Bodrum'dan bir dairenin gecelik ücretini aynı birim üzerinden görebiliyor ve kur hesabı yapmadan bütçe kararı verebiliyor.

Bu birliği sağlamak için dış kaynaklardaki fiyatların çeşitli birimlerde geldiği varsayılabilir. Türk mülk piyasasında TL yaygın para birimidir. Uluslararası platformlarda dolar ya da doğrudan EUR kullanılıyor olabilir. Bazı ilanlar mevsimlik dönemlere göre farklı para birimleri kullanabilir. Farklı kaynaklardan toplanan 300.000+ ilanın tamamını tutarlı bir EUR fiyatıyla sunmak, para birimi dönüşümünün ötesinde bir karar gerektiriyor: hangi kur kullanılıyor, ne sıklıkla güncelleniyor, geçmiş kur farklılıkları nasıl ele alınıyor?

Tatil Kiralama Fiyatlandırmasının Karmaşıklığı

Tatil kiralama fiyatları statik değil. Sezonluk değişim — yüksek sezon ile düşük sezon arasındaki fark önemli olabilir — hafta sonu fiyat farklılığı, minimum konaklama süresi şartları, erken rezervasyon indirimleri ve son dakika fırsatları fiyatı etkileyen parametrelerdir. 300.000+ ilan arasında fiyat karşılaştırmasını anlamlı kılmak için bu parametrelerin kaynak bağımsız biçimde temsil edilmesi gerekiyor. Yoksa "50 EUR" bir mülkün minimum 7 gecelik koşuluyla geçerli fiyatı, diğerinin ise tek gecelik fiyatı olabilir.

Platformun fiyat filtresi bu normalizasyonun somut kanıtıdır: yaklaşık 50 EUR ve altındaki erişilebilir segment ile premium katman, anlamlı bir bant olarak çalışıyor. Bu yalnızca kullanıcı arayüzü tercihi değil — altta yatan fiyat verisinin yeterince tutarlı ve karşılaştırılabilir olduğunu kanıtlayan bir özellik.

Ölçek: 300.000 İlan Ne Anlama Geliyor?

Normalizasyon problemlerinin boyutu doğrusal değildir. 100 ilan için çalışan bir kural seti 1.000 ilanda çatlamaya başlar, 300.000 ilanda tamamen farklı bir mühendislik disiplini haline gelir.

Küçük kataloglarda manuel gözlem hatayı tespit eder. Bir editör listeyi gezer, yanlış kategorize edilmiş mülkü fark eder, düzeltir. Ölçek büyüdükçe bu yaklaşım imkânsız hale gelir. Hatalı bir kategori kuralı tek bir mülkü değil, belirli bir kaynaktan gelen yüzlerce mülkü etkileyebilir. Tutarsız koordinat çözümlemesi bir mülkü değil, belirli bir bölgedeki tüm mülkleri haritadan düşürebilir. Yanlış para birimi dönüşümü bir ilanı değil, tüm ilanların fiyat gösterimini bozabilir.

Bu ölçekte normalizasyonun anlamı değişir: kuralların doğru ve güvenilir olması yeterli değil, aynı zamanda uç durumları ve aykırı verileri tanıyıp uygun biçimde ele alması gerekir. Beklenmedik formatlarda gelen ilanlar, kısmi bilgiye sahip mülkler, çelişkili veri içeren girişler, güncellenmeyi bekleyen eski kayıtlar — bunlar istisna değil, normaldir. 300.000 ilan yeterince büyük bir evren oluşturuyorsa tüm olası sorunları temsil eden örnekler mutlaka içindedir.

Yinelenen İlan Sorunsalı

Çoklu kaynak veri birleştirmesinin karşılaştığı ek bir problem, yineleme tespiti ya da tekilleştirmedir. Aynı fiziksel mülk birden fazla platform üzerinde listelenmiş olabilir. Bu durumu tespit etmek kolay değildir: mülk adları kaynaklara göre farklılaşabilir, koordinatlar hafif sapabilir, fotoğraflar yeniden işlenmiş olabilir. Yinelenen ilanları göstermek kullanıcının arama sonuçlarını gereksiz yere şişirir — "300.000 ilan" rakamının gerçek katalog derinliğini yansıtması için bu sorunun da ele alınmış olması gerekir. niranar.com'un bu konudaki spesifik yaklaşımı kamuya açık değil, ancak 300.000+ birbirinden farklı ilanın var olması, yineleme probleminin kontrol altında tutulduğunu gösteriyor.

Takvim ve Müsaitlik: Zamanı Normalize Etmek

Tatil kiralama platformlarında tarih ve müsaitlik verisi ayrı bir normalizasyon problemi oluşturuyor. niranar.com özel bir takvim uygulaması kullanıyor — bu seçim, üçüncü taraf takvim servisine bağımlılığı ortadan kaldırırken platform genelinde müsaitlik yönetimini tek elde topluyor.

Dış kaynaklardan toplanan ilanların müsaitlik bilgileri farklı formatlarda ve farklı güncelleme frekanslarında gelebilir. Bazı mülkler takvimlerini iCal formatında sunar. Bazıları API çağrısıyla erişilebilir müsaitlik bilgisi sağlar. Bazılarında güncelleme manuel yapılır. Birbirinden farklı zaman dilimi tanımları, eksik ya da gecikmeli güncelleme verileri, örtüşen rezervasyon dönemlerinin çakışmaları — bunların hepsi kullanıcıya yanlış müsaitlik gösterme riskini taşır.

Bir kullanıcının 15-22 Temmuz tarihlerini girip gerçekte müsait olmayan mülkleri arama sonuçlarında görmesi platforma güveni doğrudan zedeler. Tatil planlaması zaten stresli bir süreçtir; yanlış müsaitlik bilgisi kullanıcının zaman ve duygusal enerjisini harcar. Bu yüzden müsaitlik bilgisinin normalize edilmesi, mülk adı ya da fiyat normalizasyonundan daha az görünür ama operasyonel açıdan kritik bir sorun alanı oluşturur.

Çıktı Gerçeği: Kanıt Sonuçta Görünüyor

niranar.com'un veri normalizasyonu sürecinin iç mekanizmaları hakkında kamuya açık teknik açıklama mevcut değil ve bu doğal. Hangi araçların kullanıldığı, hangi algoritmaların çalıştığı, hangi kural setlerinin uygulandığı — bunlar ürünün operasyonel detaylarıdır.

Ama çıktı görünür ve doğrulanabilir.

Platform 300.000'i aşkın ilanı villa/daire olarak tutarlı biçimde sınıflandırmış halde sunuyor. Antalya, Bodrum, Fethiye, Alanya, Kuşadası ve Sapanca bölgelerindeki mülkler coğrafi olarak doğru konumlandırılmış — Leaflet haritasında anlamlı biçimde görüntülenebilir durumda. Tüm fiyatlar EUR cinsinden ve karşılaştırılabilir bant içinde. Takvim bazlı müsaitlik filtrelemesi çalışıyor. Çoklu filtre kombinasyonları — konum artı tarih aralığı artı misafir sayısı artı özellik filtresi artı fiyat dilimi — anlamlı ve tutarlı sonuçlar döndürüyor.

Bu çıktı kümesi, dağınık çok kaynaklı verinin üzerinden geçilmiş mühendislik problemlerinin kanıtıdır. Normalizasyonun iç mimarisini bilmeden, dışarıdan görülen bu tutarlılığın ne kadar iş gerektirdiğini anlamak mümkündür — bir arama kutusuna değer girilip "Enter" tuşuna basıldığında elde edilen düzenli sonuçlar, kendiliğinden gelmiyor.

Bu Mimari Neyi Gösteriyor?

Çoklu kaynak normalizasyonu, arama platformlarının görünmez altyapısıdır — kotireitti.fi'nin çoklu kaynak agregasyonunda da benzer bir mühendislik sorunsalını Finlandiya pazarı bağlamında ele aldık. Bunu doğru yapan platformlar kullanıcıya şeffaf bir deneyim sunar — arama çalışır, sonuçlar anlamlıdır, karşılaştırmalar mümkündür, harita güvenilirdir. Bunu yapmayan platformlarda ise arama teknik olarak çalışsa bile kullanıcı tutarsız sonuçlar, yanlış filtreler, haritada anlamsız pinler ve güvensizlik hisseder.

niranar.com bu ayrımın farkında olarak inşa edilmiş. 300.000+ ilanın tutarlı, filtrelenebilir ve haritada görüntülenebilir olması, veri kalitesinin ürün kararlarının merkezine yerleştirildiğini gösteriyor. Kullanıcı arayüzü ne kadar temiz tasarlanmış olursa olsun, altta yatan veri tutarsızsa kullanıcı bunu hisseder — zira arama sonuçları o tutarsızlığı yansıtır.

Smart Maple'ın bu projedeki yaklaşımı, normalizasyon problemini yalnızca teknik bir temizlik işi olarak değil, arama deneyiminin kalitesini belirleyen bir tasarım meselesi olarak ele almaktır. Tek geliştirici ve yapay zeka destekli geliştirme ortamıyla bu ölçekte veri tutarlılığı sağlamak, doğru araçların yanı sıra doğru mühendislik önceliklerini belirleyebilmeyi de gerektiriyor. Platformun mevcut çıktı kalitesi, bu önceliklendirmenin başarılı biçimde yapıldığını gösteriyor.

Pazar yerlerini, agregasyon platformlarını ya da çoklu kaynak veri akışlarını yönetmesi gereken ürünleri geliştirmek isteyen ekipler için niranar.com, veri normalizasyonunun ne zaman öncelik alması gerektiğini gösteren somut bir referans noktasıdır: her zaman ve en başından.

Sonuç

Bir tatil kiralama arama sonucu, görünmez mühendislik çalışmasının yüzeyidir. niranar.com'da 300.000'i aşkın ilan, birden fazla dış kaynaktan toplanan hammaddeden — tutarsız formatlar, değişken terminoloji, eksik koordinatlar, farklı para birimleri — tek tip ve filtrelenebilir bir veri yapısına dönüştürülmüştür.

Bu dönüşümün spesifik metodolojisi kamuya açık değil. Ama sonucu açık: villalar villa, daireler daire; Bodrum Bodrum, Fethiye Fethiye; EUR EUR. Kullanıcı aramayı girdiğinde platform anlam üretiyor. Bu anlam, normalizasyonun başarısıdır.

Serinin diğer yazıları bu altyapının farklı boyutlarını ele alıyor. Arama mimarisi için bkz. niranar.com'un Arama Mimarisi. Teknik yığın kararları için bkz. niranar.com'un Teknoloji Yığını. Platforma genel bakış için bkz. niranar.com Ürün Tanıtımı.