Paris'te bir otel odası, Booking.com'da Fransız IP'sinden 200 € olarak listelenirken, aynı tarayıcı aynı URL'ye ABD IP'sinden eriştiğinde 260 €'ya çıkıyor. Bu bir döviz dönüşüm hatası değil — coğrafi konuma dayalı kasıtlı bir dinamik fiyatlandırmadır. SaaS tarafında ise Slack veya Jira'daki aynı koltuk, Amerika Birleşik Devletleri ile Hindistan arasında %40 fark edebilir. Bu fiyat farklılıklarını ölçekte izlemek, havayolları ve bulut satıcılarının kazıyıcılara karşı kullandığı aynı dolandırıcılık önleme sistemlerine karşı dayanıklı bir proxy altyapısı gerektirir.
Aynı SKU'nun Sınırlar Arasında Neden Farklı Fiyatlandığı
Coğrafi arbitraj fiyatlandırmasını üç mekanizma yönlendirir. Birincisi, gizli kâr marjlarıyla döviz dönüşümü — otelin rezervasyon motoru, ülkeye göre değişen %3-5'lik bir döviz kuru farkı uygular. İkincisi, yerel vergi rejimleri: AB'de KDV, Hindistan'da GST, ABD'de satış vergisi. Üçüncüsü ve en agresifi, talebe dayalı dinamik fiyatlandırmadır. British Airways'in Londra-New York uçuşu, talep Birleşik Krallık IP'sinden geldiğinde Almanya IP'sinden geldiğinden daha yüksek bir fiyat gösterir; çünkü algoritma, Birleşik Krallık yolcularının daha yüksek ödeme isteği olduğunu varsayar. Atlassian ve Salesforce gibi SaaS satıcıları, bölge başına ayrı fiyat listeleri tutar ve genellikle gelişmekte olan pazarlar için %30-50 indirim sunar. Bu fiyatları programatik olarak yakalamanın tek yolu, isteğin her hedef pazardan geliyormuş gibi görünmesini sağlamaktır.
Çok Bölgeli Fiyat Yakalama için Proxy Mimarisi
Tek bir konut proxy havuzu yeterli değildir. Ülke, şehir ve hatta bazen operatörle (örneğin, bir Fransız mobil ISS'si ile bir Fransız konut DSL'si) eşleşen çıkış düğümlerinden oluşan bir havuza ihtiyacınız var. Standart yaklaşım, dönen bir kimliği doğrulanmış proxy listesi tutan bir proxy aracısı kullanır. Aşağıda, bir Fransız proxy üzerinden otel fiyatı getiren, Accept-Language başlığını fr-FR olarak ayarlayan ve yakın tarihli bir Chrome yapısından gerçekçi bir User-Agent gönderen minimal bir curl komutu bulunmaktadır:
curl -s -x "http://user:pass@fr-proxy.example.com:3128" \
-H "Accept-Language: fr-FR,fr;q=0.9" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" \
"https://www.booking.com/hotel/fr/paris-ritz.html" | grep -oP '"price":"[^"]+"'Bu tek komut, proxy DataDome veya Akamai gibi bir bot algılama hizmeti tarafından biliniyorsa %60-80 oranında başarısız olur. Başarısızlık oranı, ancak proxy rotasyonunu oturum kalıcılığı ve proxy'nin gerçek ISS'siyle eşleşen başlık parmak izi ile birleştirdiğinizde düşer.
Dolandırıcılık Önleme Bot Algılama: Gerçek Darboğaz
Seyahat ve SaaS platformları bot algılamaya büyük yatırım yapar. Yalnızca IP'nin itibarını değil, aynı zamanda TLS el sıkışma parmak izini (JA3), HTTP/2 ayarlarını, zamanlama titreşimini ve HTTP başlıklarının sırasını da kontrol ederler. Bir kontrolden geçen proxy, diğerinde başarısız olabilir. Örneğin, temiz bir IP'ye sahip ancak bilinen bir kazıma aracıyla eşleşen JA3 imzasına sahip bir veri merkezi proxy'si anında engellenir. Konut proxy'leri bağışık değildir — çoğu enfekte cihazlardan gelir ve kara listelerde görünür. En etkili strateji, hedef sitenin algılama yığınına karşı test ettiğiniz özel bir proxy havuzu kullanmaktır. İdeal koşullarda bile proxy başına %10-20 başarı oranı bekleyin. Bu, her 5-10 saniyede bir istek olacak şekilde istikrarlı bir kazıma hızını sürdürmek için hedef bölge başına en az 5-10 proxy'ye ihtiyacınız olduğu anlamına gelir.
İşte ödünleşimin can yakıcı noktası: daha yüksek proxy kalitesi (konut, statik IP'ler, yüksek itibar) veri merkezi proxy'lerinden 10 kat daha pahalıdır, ancak başarı oranı yalnızca iki katına çıkabilir. Saatte 100 SKU'yu 10 bölgede izleyen bir fiyat izleme operasyonu için aylık proxy faturası 2.000 $'ı aşabilir. Alternatif — ücretsiz genel proxy'ler kullanmak — bir seçenek değildir çünkü IP'leri zaten büyük anti-bot hizmetlerinin her biri tarafından işaretlenmiştir. Ücretsiz bir proxy'den gelen tek bir istek, bir CAPTCHA veya 403 yanıtını tetikleyecektir.
Pratik İş Akışı: Hız Sınırlama, IP Soğuma Süreleri ve Hata Yönetimi
Kazıyıcınız, proxy IP'si başına bir durum makinesi uygulamalıdır. Başarılı bir istekten sonra proxy bir soğuma süresine girer — otel siteleri için 30 saniye, SaaS yönetim panelleri için 60 saniye. Bir başarısızlıktan (HTTP 403, 429 veya CAPTCHA sayfası) sonra soğuma süresi 5 dakikaya uzar ve proxy yeniden değerlendirilmek üzere işaretlenir. Tüm proxy'ler arasında saniyede 2 istek gibi bir genel sınır uygulayan bir token bucket hız sınırlayıcı kullanın. Aşağıdaki Python parçacığı (asyncio ve aiohttp kullanarak) temel döngüyü gösterir:
import asyncio, aiohttp, random
PROXY_POOL = [{"url": "http://user:pass@fr1:3128", "cooldown_until": 0}]
async def fetch_price(session, proxy, url):
now = asyncio.get_event_loop().time()
if now < proxy["cooldown_until"]:
await asyncio.sleep(proxy["cooldown_until"] - now)
try:
async with session.get(url, proxy=proxy["url"],
headers={"Accept-Language": "fr-FR"}) as resp:
if resp.status == 200:
proxy["cooldown_until"] = now + 30
return await resp.text()
else:
proxy["cooldown_until"] = now + 300
return None
except Exception:
proxy["cooldown_until"] = now + 300
return NoneAynı proxy'den ardışık başarısızlıklar için üstel geri çekilme ekleyin — üç hatadan sonra bu IP'yi 24 saatliğine emekli edin. Başarılı yanıtların toplam denemelere oranını izleyin; bir bölge için %20'nin altına düşerse, o ülke için tüm proxy havuzunu döndürün. Son olarak, her yanıt başlığını, özellikle Set-Cookie ve X-Frame-Options'i kaydedin, çünkü bunlar sitenin JavaScript yürütmesi gerektiren bir bot algılama betiği çalıştırıp çalıştırmadığını ortaya çıkarır. İstemci tarafı işlemeye dayanan siteler için Playwright veya Puppeteer gibi bir başsız tarayıcıya geçmelisiniz, bu da gecikme ve proxy maliyetine bir kat daha ekler. Çapraz bölge fiyat izleme bir hafta sonu projesi değildir — sürekli ayar gerektiren, hareketli bir hedefe karşı sürekli bir mühendislik yatırımıdır.