Seyahat sektöründe fiyat verisi toplamak, diğer endüstrilere kıyasla çok daha karmaşık bir meydan okuma sunar. Bir uçuş biletinin fiyatı, nerede oturduğunuza, hangi cihazı kullandığınıza, geçmiş aramalarınıza ve hatta tarayıcı çerezlerinize göre değişebilir. Bu dinamik fiyatlandırma ortamı, scrape flight prices stratejisi geliştiren ekipler için benzersiz zorluklar yaratır.
Bu rehber, seyahat şirketleri, fare-monitoring startup'ları ve fintech ekipleri için proxy tabanlı fiyat izleme altyapısını stratejik bir bakış açısıyla ele alıyor. Teknik detaylardan ziyade, ürün yöneticileri ve veri ekiplerının karar alma süreçlerini destekleyen bir çerçeve sunuyoruz.
Neden Seyahat Fiyatları Bu Kadar Zor?
Seyahat fiyatlandırması, diğer e-ticaret kategorilerinden farklı olarak çok katmanlı bir dinamik yapıya sahiptir. Bir otel odasının veya uçuş biletinin fiyatı, en az beş farklı faktöre bağlı olarak değişebilir:
- Point of Sale (PoS) kuralları: Aynı uçuş, ABD'den bakıldığında 500$, Almanya'dan bakıldığında 420€ olabilir. Havayolları ve oteller, müşterinin bulunduğu ülkeye göre farklı fiyatlandırma stratejileri uygular.
- Dinamik kişiselleştirme: Platformlar, kullanıcının geçmiş aramalarını, tıklama davranışlarını ve satın alma eğilimlerini analiz ederek fiyatları gerçek zamanlı olarak ayarlar.
- Çerez tabanlı takip: Tekrar eden ziyaretlerde fiyatların arttığı, "urgency pricing" olarak bilinen yaygın bir stratejidir.
- Kapasite bazlı dalgalanma: Koltuk doluluk oranı, sezon, tatil dönemleri ve rakip fiyatları anlık olarak değişir.
- Para birimi ve vergi farklılıkları: Her ülke için farklı vergi oranları ve para birimi kuru uygulanır.
Bu karmaşıklık, travel data scraping projelerinde veri tutarlılığını sağlamak için özel bir yaklaşım gerektirir. Veriyi doğru yorumlamak için, fiyatın hangi bağlamda (ülke, tarih, saat, kullanıcı profili) oluştuğunu da kaydetmeniz gerekir.
Point of Sale (PoS) Fiyatlandırması Nasıl Çalışır?
PoS tabanlı fiyatlandırma, havayollarının gelir yönetimi stratejisinin temel bileşenidir. Örneğin, İstanbul-New York uçuşu için:
- Türkiye'den yapılan aramalarda Türk Lirası ile fiyatlandırma ve yerel vergiler
- ABD'den yapılan aramalarda USD fiyatlandırma ve ABD vergileri
- AB ülkelerinden yapılan aramalarda Euro fiyatlandırma ve AB tüketicilerine özel promosyonlar
Bu durum, fiyat karşılaştırma platformlarının her hedef pazar için ayrı ayrı veri toplamasını zorunlu kılar. Türkiye'den bakılan bir fiyat, Almanya'dan bakılan fiyatla doğrudan karşılaştırılamaz.
Geo-Targeted Residential Proxy'ler Neden Zorunlu?
Seyahat verisi toplarken iki temel teknik engelle karşılaşırsınız: coğrafi kısıtlamalar ve anti-bot sistemleri. Her iki sorunu da çözmek için hotel price monitoring proxies stratejisinde residential proxy'ler kritik rol oynar.
Datacenter IP'ler Neden Engellenir?
Online travel agency'ler (OTA'lar) ve havayolları, datacenter IP aralıklarını otomatik olarak tespit edebilir. Bu IP'ler şu özellikleri nedeniyle şüphe çeker:
- ASN (Autonomous System Number) veritabanlarında "hosting" veya "datacenter" olarak işaretlenir
- Gerçek kullanıcı davranışına uymayan trafik pattern'leri gösterir
- Teknik olarak tek bir konumdan yüksek hacimli istek yapar
- ISP olarak görünmez, bulut sağlayıcı olarak görünür
Expedia, Booking.com ve büyük havayolları, PerimeterX veya Akamai Bot Manager gibi sistemler kullanarak datacenter trafiğini otomatik olarak engeller. Bu engel, bazen CAPTCHA sayfası olarak, bazen de sessizce hatalı veri döndürerek (yanlış fiyat gösterme) kendini gösterir.
Residential Proxy'lerin Stratejik Değeri
Residential proxy'ler, gerçek ISP'lerden sağlanan IP adresleridir. Bir kullanıcı gibi görünür ve şu avantajları sağlar:
- Coğrafi hedefleme: Farklı ülkelerden fiyat sorgulama yapabilme
- Güvenilirlik: Datacenter engellemelerini aşma
- Davranışsal gizlilik: Gerçek kullanıcı pattern'lerine uyum
ProxyHat gibi sağlayıcılar, ülke ve şehir bazlı hedefleme sunar. Örneğin, Almanya'dan Frankfurt şehri için fiyat sorgulamak için:
curl -x "http://user-country-DE-city-frankfurt:PASSWORD@gate.proxyhat.com:8080" "https://www.expedia.de/Flights"Bu yaklaşımla, her hedef pazar için doğru PoS fiyatlarını toplayabilirsiniz.
Hedef Veri Kaynakları: OTA'lar, Metasearch ve Doğrudan Siteler
Başarılı bir scrape flight prices stratejisi, doğru veri kaynaklarını seçmekle başlar. Her kaynak türü farklı avantajlar ve zorluklar sunar.
Online Travel Agency (OTA) Platformları
OTA'lar, en kapsamlı fiyat verisini sunar ancak en güçlü anti-bot korumasına sahiptir:
- Expedia Group: Expedia.com, Hotels.com, Travelocity, Orbitz
- Booking Holdings: Booking.com, Priceline, Agoda, Kayak
- Trip.com Group: Trip.com, Skyscanner (metasearch), Ctrip
Bu platformlar genellikle Akamai Bot Manager kullanır ve yoğun rate limiting uygular. Residential proxy rotation ve insan benzeri davranış pattern'leri gerektirir.
Metasearch Motorları
Metasearch platformları, birden fazla kaynağı karşılaştırarak sunar:
- Google Flights: En geniş havayolu kapsamı, güçlü ITA altyapısı
- Kayak: Fiyat trendi grafikleri ve "Price Alert" verisi
- Skyscanner: AB pazarında güçlü, esnek tarih arama
- Momondo: Küçük havayolları ve charter uçuşları
Google Flights, özellikle değerlidir çünkü doğrudan havayollarından ve OTA'lardan veri toplar. Ancak Google'ın anti-bot sistemi son derece gelişmiştir ve residential proxy zorunludur.
Havayolları ve Otel Zincirleri
Doğrudan kaynaktan veri toplamak, en doğru fiyatı verir:
- Major havayolları: American Airlines, Delta, United, Lufthansa, Emirates, Turkish Airlines
- Low-cost carriers: Ryanair, Southwest, easyJet, Pegasus
- Otel zincirleri: Marriott, Hilton, Accor, IHG
Havayolları genellikle PerimeterX kullanır ve sık sık CAPTCHA gösterir. Doğrudan sitelerden veri toplamak, OTA'ların eklediği komisyonları analiz etmek için de değerlidir.
Build-vs-Buy Çerçevesi: Ne Zaman Kendi Çözümünüzü Yapmalısınız?
Seyahat verisi toplama altyapısı için "build vs buy" kararı, maliyet, kontrol ve zaman arasında bir denge gerektirir. Aşağıdaki çerçeve bu kararı desteklemek için tasarlanmıştır.
| Faktör | API Satın Al (Skyscanner, Amadeus) | In-House Scraping |
|---|---|---|
| Başlangıç maliyeti | Düşük (aylık $500-5,000) | Yüksek ($20,000+ geliştirme) |
| Veri kalitesi | Yüksek, doğrulanmış | Değişken, doğrulama gerekli |
| Veri kaynağı kapsamı | Sınırlı (API sağlayıcısına bağlı) | Sınırsız (tüm kaynaklar) |
| Anti-bot maliyeti | Sıfır (API sağlayıcı üstlenir) | Yüksek (proxy + geliştirme) |
| Özelleştirme | Düşük (API limitleri) | Tam kontrol |
| Bakım yükü | Minimal | Yüksek (sürekli güncelleme) |
| Time to market | Hızlı (haftalar) | Yavaş (aylar) |
| Rekabet avantajı | Düşük (herkes erişebilir) | Yüksek (özel veri seti) |
Ne Zaman API Satın Almalı?
API satın alma, aşağıdaki durumlarda mantıklıdır:
- MVP veya erken aşama ürün geliştirme
- Sınırlı teknik ekip kapasitesi
- Standart rota ve otel verisi yeterli
- Hızlı time-to-market kritik
- Yasal uyumluluk endişeleri (API'ler genellikle ToS uyumlu)
Ne Zaman In-House Scraping Yapmalı?
Kendi scraping altyapınızı kurmak şu durumlarda avantajlıdır:
- Özel veri setleri (niş rotalar, boutique oteller)
- Gerçek zamanlı fiyat takibi (flash fare'ler)
- Rekabet avantajı için benzersiz veri
- Yüksek hacimli sorgulama (API maliyeti prohibitive)
- Fiyat tahmin algoritmaları için historical veri
Maliyet Örneği: Gerçek Sayılar
Bir mid-size fare monitoring startup'ı için yıllık maliyet karşılaştırması:
- Skyscanner API: ~$50,000/yıl (1M sorgu/ay)
- Amadeus API: ~$30,000/yıl + kullanım bazlı
- In-house + ProxyHat: ~$15,000/yıl (proxy) + 1 FTE geliştirici (~$80,000) = $95,000 ilk yıl, $15,000 sonraki yıllar
İkinci yıldan itibaren in-house çözüm daha ekonomik hale gelir. Ancak bu, teknik borç ve bakım maliyetini hesaba katmaz.
Seyahat Sektöründe Yaygın Anti-Bot Teknolojileri
Seyahat siteleri, bot trafiğini engellemek için gelişmiş sistemler kullanır. Bu sistemleri anlamak, travel data scraping stratejinizi şekillendirir.
PerimeterX
PerimeterX, havayolları arasında en yaygın kullanılan anti-bot sistemidir. Şu özelliklere sahiptir:
- JavaScript challenge doğrulaması
- Browser fingerprinting
- Behavioral analysis (mouse movement, scroll pattern)
- Machine learning tabanlı anomali tespiti
PerimeterX'i aşmak için residential proxy, gerçek browser rendering (Puppeteer/Playwright) ve insan benzeri davranış simülasyonu gerekir.
Akamai Bot Manager
OTA'ların tercih ettiği Akamai, şu teknikleri kullanır:
- Advanced JavaScript obfuscation
- TLS fingerprinting
- IP reputation scoring
- Rate limiting ve throttling
Akamai, özellikle datacenter IP'leri agresif şekilde engeller. Residential proxy rotation zorunludur.
Cloudflare ve Diğerleri
Bazı küçük OTA'lar ve havayolları Cloudflare kullanır:
- Cloudflare Bot Management
- Rate limiting rules
- CAPTCHA challenge pages
Cloudflare genellikle PerimeterX ve Akamai'ye kıyasla daha az agresiftir, ancak yine de residential proxy önerilir.
Altyapı: Scraping Fleet Coğrafi Dağılımı ve Yenileme Sıklığı
Başarılı bir seyahat verisi toplama sistemi, doğru altyapı mimarisi gerektirir. İki temel karar: coğrafi dağılım ve yenileme sıklığı.
Coğrafi Proxy Dağılımı
Her hedef pazar için o ülke çıkışlı proxy kullanmak, PoS fiyatlarını doğru toplamanızı sağlar:
- ABD pazarı: ABD residential proxy'ler (tüm büyük şehirler)
- AB pazarı: Almanya, Fransa, İtalya, İspanya, Hollanda proxy'leri
- Asya pazarı: Japonya, Singapur, Hong Kong, Güney Kore
- MENA pazarı: UAE, Suudi Arabistan, Türkiye
ProxyHat, ülke ve şehir bazlı hedefleme sunarak her pazar için doğru PoS fiyatlarına erişim sağlar. Detaylı lokasyon bilgisi için proxy lokasyonları sayfasını inceleyebilirsiniz.
Yenileme Sıklığı Stratejisi
Veri yenileme sıklığı, kullanım senaryosuna göre değişir:
- Flash fare'ler (hata fares, mistake fares): 15 dakika - 1 saat aralıklarla yüksek öncelikli rotalar
- Günlük fiyat takibi: 24 saatte bir, tüm rotalar
- Haftalık trend analizi: Haftalık historical veri toplama
- Rekabet analizi: Günlük veya saatlik, ana rakipler
Flash fare'ler için yüksek frekanslı scraping, maliyet ve altyapı yükü oluşturur. Bu nedenle, sadece stratejik rotalar (yüksek hacimli, yüksek marjlı) için yüksek frekans önerilir.
Örnek Kullanım Senaryosu: Avrupa İçi Uçuş Fiyatları
Bir fare monitoring startup'ı için örnek scraping senaryosu:
- Hedef: Avrupa içi popüler 50 rota (Londra-Paris, Berlin-Roma, vb.)
- Veri kaynakları: Google Flights, Skyscanner, Ryanair, Lufthansa
- Proxy gereksinimi: 5 AB ülkesi için residential proxy (Almanya, Fransa, İtalya, İspanya, Hollanda)
- Yenileme sıklığı: 30 dakikada bir
- Günlük sorgu sayısı: 50 rota × 4 kaynak × 5 ülke × 48 yenileme = 48,000 sorgu/gün
- Aylık proxy maliyeti: ~$200-400 (ProxyHat pricing'a göre)
Bu senaryoda, API kullanımı maliyeti çok daha yüksek olurdu (Skyscanner API ile ~$5,000+/ay). In-house scraping + residential proxy, %90+ maliyet tasarrufu sağlar.
Yasal ve Etik Hususlar
Seyahat verisi toplama, yasal sınırlar içinde kalmayı gerektirir:
- robots.txt uyumu: Her site için robots.txt kontrol edin
- Terms of Service: API kullanımı ToS'a uygun, scraping genellikle ToS dışı
- Rate limiting: Aşırı yük bindirmek DDOS olarak algılanabilir
- GDPR/CCPA: Kişisel veri toplamayın, sadece fiyat verisi
- Veri kullanımı: Toplanan veriyi yeniden satmak ToS ihlali olabilir
Bu konularda yasal danışmanlık almanız önerilir. ProxyHat, yasal uyumluluk konusunda tavsiye vermez; kullanıcılar kendi sorumluluklarında hareket etmelidir.
Sonuç ve Sonraki Adımlar
Seyahat fiyat verisi toplama, teknik karmaşıklığı yüksek ancak rekabet avantajı sağlayan bir alandır. Doğru yaklaşım, hedeflerinize göre değişir:
- Erken aşama startup: API ile başlayın, hızlı POC yapın
- Büyüme aşaması: Hibrit model (API + scraping) değerlendirin
- Olgun ürün: In-house scraping + residential proxy ile ölçekleyin
ProxyHat, seyahat verisi toplama projeleri için ülke ve şehir bazlı residential proxy çözümleri sunar. Fiyatlandırma ve lokasyon detayları için pricing sayfasını inceleyebilirsiniz.
Web scraping kullanım senaryoları hakkında daha fazla bilgi için web scraping rehberimizi okuyabilirsiniz.
Key Takeaways:
- PoS tabanlı fiyatlandırma, her hedef pazar için o ülke çıkışlı proxy gerektirir
- Datacenter IP'ler OTA'lar ve havayolları tarafından engellenir; residential proxy zorunludur
- Build-vs-buy kararı: hız için API, rekabet avantajı için in-house scraping
- Flash fare'ler için 15-30 dakika, trend analizi için günlük yenileme önerilir
- Yasal uyumluluk (robots.txt, ToS, GDPR) kritik öneme sahiptir
