← Bloga geri dön

Şehirdeki bölgeler için taksi ve teslimat fiyatlarını proxy ile nasıl toplayabilirsiniz: Analistler için rehber

Taksilerin ve teslimatların fiyat izleme sisteminin nasıl kurulacağını ele alıyoruz - veri kaynaklarının seçilmesinden coğrafi hedefleme için proxy ayarlarına kadar.

📅31 Ekim 2026

Aynı şehirdeki taksi ve teslimat fiyatları, bölgeye, günün saatine ve yol yoğunluğuna bağlı olarak iki-üç kat farklılık gösterebilir. Lojistik şirketleri, agregatörler ve perakendeciler için bu kritik veriler, fiyatlandırma modellerinin, talep tahminlerinin ve yeni lokasyonlarda hizmet başlatma kararlarının temelini oluşturur. Ancak bu verileri toplamak o kadar da kolay değildir: taksi ve teslimat hizmetleri, fiyatları kullanıcının coğrafi konumuna sıkı bir şekilde bağlar ve otomatik veri toplama işlemlerini aktif olarak engeller.

İşletmeler için bölgelere göre fiyat izleme neden önemlidir

Taksi ve teslimat fiyatları uygulamalarda dinamik olarak belirlenir: algoritma belirli bir bölgedeki talebi, günün saatini, hava durumunu, sürücülerin ve kuryelerin yoğunluğunu dikkate alır. Aynı güzergah şehir merkezinde ve kenar mahallede farklı fiyatlandırılabilir, hatta aynı hizmette bile. Bu, işletmeler için birkaç pratik sorun ortaya çıkarır.

Lojistik şirketleri, rakiplerinin fiyat verilerini kullanarak kendi tarifelerini gerçek zamanlı olarak ayarlamaktadır. Eğer bir rakip belirli bir bölgede teslimat fiyatını düşürürse, müşterilerin ona geçmeden önce buna akıllıca tepki vermek gerekir. Taksi ve araç paylaşım agregatörleri, bölgeler arasındaki fiyat dinamiklerini analiz ederek yüksek talep alanlarını belirler ve sürücüleri yeniden dağıtır. Perakendeciler ve yemek teslimat hizmetleri (Yandex.Eda ve SberMarket benzeri) rakiplerinin teslimat fiyatlarını takip ederek kendi ücretsiz teslimat alanlarını ve minimum sipariş tutarlarını doğru bir şekilde ayarlamaktadır.

Ayrı bir kullanıcı kategorisi, şehir mobilitesi analistleri ve araştırma şirketleridir; bu şirketler, bölgeler arasındaki "fiyat eşitsizliği" haritalarını oluşturur. Bu tür veriler, geliştiricilerin yeni inşaat projelerinin ulaşım erişimini değerlendirmesine ve şehir yetkililerinin ulaşım hizmeti eksikliği olan alanları belirlemesine yardımcı olur. Bölgelere göre sistematik veri toplama olmadan bu görevlerden hiçbiri çözülemez; çünkü tek seferlik manuel fiyat kontrolleri çarpıtılmış bir tablo verir, çünkü fiyatlar her birkaç dakikada bir değişir.

Hizmetler neden coğrafi konumdan veri toplamayı engelliyor

Taksi ve teslimat hizmetleri, fiyat verilerini birkaç nedenle korumaktadır. Öncelikle, dinamik fiyatlandırma ticari bir sırdır ve tüm bölgelerdeki güncel tarifeleri bilmek, kolayca kopyalanabilen bir rekabet avantajıdır. İkincisi, bir IP adresinden gelen toplu talepler sunucular üzerinde yük oluşturur ve gerçek talep istatistiklerini çarpıtır, bu nedenle dolandırıcılık karşıtı sistemler bu tür talepleri agresif bir şekilde yasaklar.

Teknik olarak, koruma birkaç seviyede inşa edilmektedir. Uygulamalar, coğrafi konumu yalnızca GPS ile değil, IP adresi ile de belirler; eğer Moskova IP'sinden gelen bir istek Novosibirsk koordinatlarıyla gelirse, sistem bunu şüpheli olarak işaretler. Ayrıca, bir IP'den belirli bir zaman diliminde yapılan istekler için bir sınır vardır: bu eşiğin aşılması geçici bir yasaklamaya veya yanlış fiyatların verilmesine yol açar. Üçüncü seviye, cihaz ve tarayıcı parmak izi olup, gerçek kullanıcıyı bir dizi parametreyle (ekran çözünürlüğü, yazı tipi listesi, fare davranışı) ayırt eder.

Bu nedenle, tek bir IP adresiyle basit bir script hızla yasaklanır veya çarpıtılmış veriler alır. Bir şehirdeki onlarca bölgeden fiyatları istikrarlı bir şekilde toplamak için, gerçek kullanıcıların farklı noktalardan gelen taleplerini taklit eden bir altyapıya ihtiyaç vardır ve burada gerekli coğrafi konuma bağlı proxy olmadan geçiş yapılamaz.

Hangi veriler toplanmalı ve hangi platformlardan

Veri toplama ayarlarını yapmadan önce, analitik için hangi göstergelerin gerektiğini belirlemek önemlidir. Taksi için genellikle: standart güzergah üzerindeki temel yolculuk maliyeti, artan talep katsayısı, aracın gelme süresi ve belirli bir bölgede ekonomik/konfor/biznes sınıfının erişilebilirliği. Teslimat için ise: belirli bir tutar için teslimat maliyeti, ücretsiz teslimat için minimum tutar, kurye bekleme süresi ve kapsama alanının varlığı.

Rusya ve BDT'deki ana veri kaynakları, büyük taksi agregatörlerinin, yemek ve ürün teslimat hizmetlerinin uygulamaları ve web siteleri ile kendi lojistiği olan pazar yerleridir. Eğer görev karşılaştırmalı analiz ise, aynı bölgelerde ve zaman dilimlerinde birden fazla rakip hizmetten veri toplamak önemlidir; aksi takdirde karşılaştırma hatalı olur: farklı hizmetlerdeki fiyatlar asenkron olarak dalgalanır.

Kontrol noktalarının listesini önceden belirlemek önemlidir; her bölgede güzergahın inşa edileceği belirli adresler veya koordinatlar. Sabit noktalar olmadan veriler birbirleriyle karşılaştırılamaz: şehir merkezinden bir uyku bölgesine giden yolculuk fiyatını, aynı bölgedeki bir yolculuk fiyatıyla karşılaştırmak, zaman içindeki dinamikleri analiz etmek için anlamsızdır.

Veri toplama yöntemleri: manuel, otomasyon, API

Fiyat verilerini toplamak için üç ana yaklaşım vardır. Manuel izleme — bir çalışan uygulamayı açar, kalkış noktasını değiştirir ve fiyatı kaydeder. Bu, tek seferlik bir araştırma için çalışır, ancak düzenli analitik için tamamen uygunsuzdur: fiyatlar her dakika değişir ve üç hizmette 20 bölgeyi manuel olarak kontrol etmek saatler alır.

İkinci yaklaşım — tarayıcı scriptleri veya headless tarayıcılar aracılığıyla otomasyon, bu araçlar kullanıcı eylemlerini taklit eder: web sitesini açar, adresi girer ve ekrandan fiyatı okur. Bu yöntem daha iyi ölçeklenebilir, ancak bot koruma sistemlerini aşmayı ve web sitesinin arayüzündeki değişikliklere sürekli olarak uyum sağlamayı gerektirir.

Üçüncü yöntem — mobil uygulamaların iç API'leri aracılığıyla çalışma, genellikle web arayüzünden daha kolaydır, ancak istek başlıklarını daha doğru bir şekilde taklit etmeyi gerektirir ve çoğu zaman oturum açmaya bağlıdır. Seçilen yöntem ne olursa olsun, belirli bir bölgedeki gerçekçi fiyatları elde etmek için taleplerin bu şehirde fiziksel olarak bulunan bir IP adresinden gelmesi gerekir; ideal olarak, ilgili bölgeden veya en azından ilgili birimden.

Coğrafi hedefleme veri toplamada proxy'nin rolü

Proxy, bölgelere göre fiyat izleme görevinde anonimlik sorununu değil, veri güvenilirliği sorununu çözer. Taksi ve teslimat hizmetleri, talebin fiziksel olarak nereden geldiğine bağlı olarak farklı fiyatlar gösterir. Eğer Saint Petersburg'daki fiyatları Moskova IP'sinden toplarsanız, sistem ya coğrafi konum hatası verir ya da ilgili şehirdeki gerçek pazara uymayan yanlış tarifeler gösterir.

Bu görev için en iyi seçenek rezidans proxy'leri'dir — bunlar gerçek ev sağlayıcılarının IP adreslerini kullanır ve belirli bir şehir veya bölge seçmenize olanak tanır; bu, onlarca bölgeyi karşılaştırırken kritik öneme sahiptir. Sunucu adreslerinin aksine, rezidans IP'leri taksi hizmetlerinin dolandırıcılık karşıtı sistemlerinde kara listeye alınmaz, çünkü bunlar mobil veya ev ağlarından gelen sıradan kullanıcılar gibi görünür.

Özellikle mobil uygulamaların izlenmesi (web versiyonları değil) için iyi bir seçenek mobil proxy'ler'dir — bunlar, dolandırıcılık karşıtı sistemler tarafından genellikle daha güvenilir kabul edilen mobil ağ operatörlerinin IP'lerini kullanır, çünkü bunların arkasında genellikle binlerce gerçek abone (NAT) bulunur ve böyle bir adresin yasaklanması birçok sıradan kullanıcıyı etkiler, bu nedenle hizmetler bunu önlemeye çalışır.

Veri merkezleri proxy'leri de uygulanabilir — örneğin, coğrafi konuma sıkı bir bağlılık olmadan kamuya açık web sayfalarından veri toplamak için, burada hız önemlidir, kesin şehir ağına uyum değil. Ancak taksi ve teslimat fiyatları için, coğrafi bağlılık talebin sonucunu doğrudan belirlediği için, rezidans ve mobil çözümler önemli ölçüde daha kararlı ve gerçekçi veriler sağlar.

Hangi proxy türü seçilmeli: karşılaştırma

Seçim yapmak için, fiyat izleme için özellikle önemli olan anahtar parametreler açısından proxy türlerini karşılaştırmak faydalıdır.

Proxy Türü Coğrafi Hedefleme Hassasiyeti Yasaklama Riski Uygun Olduğu Alanlar
Rezidans Proxy'leri Yüksek, şehir/bölgeye kadar Düşük Taksi, teslimat siteleri ve uygulamaları, bölgelere göre detaylı analiz
Mobil Proxy'ler Yüksek, operatör ve bölgeye bağlı Çok düşük Taksi ve teslimat mobil uygulamaları üzerinden izleme
Veri Merkezi Proxy'leri Düşük, kesin coğrafi bağlılık olmadan Ortalama üstü Coğrafi bağlılığın kritik olmadığı genel veri toplama

Pratikte birçok analitik ekip, yaklaşımları birleştirir: web sitesinde fiyatları ilk toplamak için rezidans proxy'leri kullanır ve uygulama verilerini kontrol etmek için mobil proxy'leri kullanır, çünkü fiyatlar bazen web versiyonundan farklıdır.

Veri toplama ayarları için adım adım kılavuz

Şirketin kendi geliştiricisi yoksa, düzenli izlemeyi bir anti-detect tarayıcı ve proxy kombinasyonu ile kod yazmadan ayarlamak mümkündür. Yaklaşım şu şekildedir: bir anti-detect tarayıcı (Dolphin Anty, AdsPower, Multilogin veya Octo Browser) açarsınız, izlemek istediğiniz her şehir veya bölge için ayrı bir profil oluşturursunuz.

Profil ayarlarında, gerekli bölgeye bağlı bir proxy belirtirsiniz: IP adresini, portu, kullanıcı adı ve şifreyi girer, seçilen proxy sağlayıcısının desteklediğine bağlı olarak SOCKS5 veya HTTP türünü seçersiniz. Bu işlemden sonra profil, web sitesi için sanki kullanıcı fiziksel olarak seçilen şehirdeymiş gibi görünür — tarayıcı, "yerel" fiyatlarla taksi veya teslimat web sitesini açar.

Daha sonra, manuel olarak veya anti-detect tarayıcıya entegre edilmiş otomasyon senaryoları aracılığıyla (birçok hizmet, kod olmadan basit makroları destekler) web sitesine girip kontrol noktalarını girip fiyatı kaydetmek veya sayfanın ekran görüntüsünü almak kalır. Birkaç bölge için, farklı IP'lere bağlı ayrı tarayıcı profilleri tutmak ve bunlar arasında programlı olarak geçiş yapmak uygundur.

Daha büyük ölçekli izleme için — günde birkaç kez birkaç şehirde onlarca bölgeyi izlemek gerektiğinde — manuel mod etkili olmaktan çıkar ve otomatik veri toplamaya geçmek gerekir; bu konuda aşağıda bahsedilecektir.

Otomatik veri toplama için örnek script

Ekibinizde kodla çalışmaya istekli bir geliştirici veya analist varsa, otomatik fiyat toplama işlemini Python kullanarak requests kütüphanesi ile ve bölgeler arasında proxy rotasyonu ile kurabilirsiniz. Aşağıda, bölge koordinatlarını yerleştirerek ve isteği gerekli bölge üzerinden proxy ile geçirerek teslimat hizmetinin API'sini sorgulama mantığının basitleştirilmiş bir örneği verilmiştir.

import requests
import time

# Şehir bölgelerine göre kontrol noktaları listesi
districts = [
    {"name": "Merkez", "lat": 55.7558, "lon": 37.6173},
    {"name": "Uyku Bölgesi A", "lat": 55.8300, "lon": 37.4500},
    {"name": "Uyku Bölgesi B", "lat": 55.6200, "lon": 37.7100},
]

# Gerekli bölgeye bağlı proxy'ler
proxies = {
    "http": "http://login:password@proxy-host:port",
    "https": "http://login:password@proxy-host:port",
}

def get_delivery_price(lat, lon):
    url = "https://example-delivery-service.com/api/price"
    params = {"lat": lat, "lon": lon}
    headers = {"User-Agent": "Mozilla/5.0"}
    response = requests.get(url, params=params, headers=headers, proxies=proxies, timeout=10)
    return response.json().get("price")

results = []
for district in districts:
    price = get_delivery_price(district["lat"], district["lon"])
    results.append({"district": district["name"], "price": price, "timestamp": time.time()})
    time.sleep(5)  # İstekler arasında bekleme süresi, limitleri aşmamak için

print(results)

Gerçek bir görevde, proxy'leri havuz seviyesinde döndürmek gerekir — böylece farklı bölgeler farklı IP'lerden sorgulanır ve aynı uç noktaya yapılan istekler bir adresten çok sık gelmez. Bu, yasaklanma riskini azaltır ve veri örneklemesini zaman içinde daha kararlı hale getirir.

Veri güncelleme sıklığı ve depolama

Taksi ve teslimat fiyatları gün boyunca değişir, bu nedenle verilerin tek seferlik bir görüntüsü analiste pek bir şey söylemez. Optimal sorgulama sıklığı, göreve bağlıdır: yoğun saatlerde fiyatları her 15-30 dakikada bir sorgulamak yeterli olur ve diğer zamanlarda bir veya iki saatte bir sorgulamak yeterlidir. Bölgelere göre "temel" fiyat haritası oluşturmak için, talep etkisini dışlamak amacıyla günde bir veya iki ölçüm almak yeterlidir.

Toplanan verileri yapılandırılmış bir biçimde saklamak en uygunudur — "tarih ve saat", "bölge", "hizmet", "fiyat", "talep katsayısı" alanlarına sahip bir tablo. Bu format, küçük hacimler için Google Sheets tablolarına veya tam kapsamlı BI araçlarında panolar oluşturmak için bir veritabanına kolayca yüklenebilir. Tarihsel verileri saklamak, onları yeniden yazmaktan daha önemlidir — çünkü zaman içindeki dinamikler, tekil ölçümlere göre daha fazla analitik değer sunar.

Büyük veri toplama hacimlerinde (birkaç şehir, onlarca bölge, birkaç hizmet) verileri saatler ve haftanın günleri boyunca nasıl saklayıp birleştireceğinizi önceden düşünmek önemlidir — bu, talep ve fiyatlandırma tahmin modelleri oluşturmanıza olanak tanır, sadece dağınık rakamların arşivini oluşturmak yerine.

Fiyat izleme sırasında yaygın hatalar

İlk ve en yaygın hata — tüm şehir bölgeleri için aynı IP adresini kullanmaktır. Bu, sadece yasaklanma riskini artırmakla kalmaz, aynı zamanda hizmetin belirli bir konum için güncel değerler yerine ortalama veya önbelleğe alınmış fiyatlar vermesine neden olabilir.

İkinci hata — duraksız çok sık istekler yapmaktır; bu, hızla geçici yasaklamalara yol açar. Taksi hizmetlerinin dolandırıcılık karşıtı sistemleri, yalnızca istek sayısını değil, aynı zamanda davranış kalıplarını da izler: gerçek bir kullanıcı, bir dakikada aynı noktadan 50 kez yolculuk fiyatını kontrol etmez.

Üçüncü hata — uygulama ile web sitesi arasındaki fiyat farkını göz ardı etmektir. Birçok taksi ve teslimat hizmetinin mobil uygulaması, web versiyonundan farklı tarifeler gösterir; bu, farklı algoritmalar veya yalnızca uygulamada görünen promosyonlar nedeniyle olabilir. Analiz yalnızca web verilerine dayanıyorsa, sonuçlar çoğu kullanıcının uygulama üzerinden sipariş verdiği gerçek durumu yansıtmayabilir.

Dördüncü hata — ölçümler arasındaki kontrol noktalarının karşılaştırılamamasıdır. Eğer bugün bölgenin koordinatları bir adresten alınmışsa, yarın aynı bölgedeki başka bir adresten alınırsa, fiyat farkı piyasanın değişiminden değil, sadece farklı bir başlangıç veya varış noktası nedeniyle açıklanabilir.

Sonuç

Şehir bölgelerine göre taksi ve teslimat fiyatlarının sistematik izlenmesi, işletmelere somut avantajlar sağlar: rakiplerin eylemlerine hızlı bir şekilde tepki verme, talebi daha doğru tahmin etme ve kapsama alanları ile tarifeler hakkında mantıklı kararlar alma imkanı. Güvenilir veriler elde etmenin ana şartı — taleplerin, gerekli şehir ve bölgeye fiziksel olarak bağlı IP adreslerinden gelmesidir; aksi takdirde hizmetler yanlış veya ortalama fiyatlar verecektir.

Eğer farklı bölgelerde taksi veya teslimat fiyatları hakkında düzenli veri toplama planlıyorsanız, rezidans proxy'leri ile başlamanızı öneririz; bu proxy'ler, en gerçekçi verileri ve en düşük yasaklama riskini sağlar. Özellikle taksi ve teslimat mobil uygulamalarıyla ilgili görevler için, dolandırıcılık karşıtı sistemler tarafından sıradan kullanıcı trafiği olarak daha iyi algılanan mobil IP'leri de göz önünde bulundurmak gerekir.