Harga taksi dan pengiriman di kota yang sama dapat berbeda dua hingga tiga kali lipat tergantung pada daerah, waktu dalam sehari, dan kepadatan jalan. Bagi perusahaan logistik, agregator, dan pengecer, ini adalah data yang sangat penting — model penetapan harga, perkiraan permintaan, dan keputusan untuk meluncurkan layanan di lokasi baru dibangun berdasarkan data ini. Namun, mengumpulkan data ini tidaklah mudah: layanan taksi dan pengiriman mengaitkan harga secara ketat dengan geolokasi pengguna dan secara aktif memblokir pengumpulan informasi secara otomatis.
Mengapa bisnis perlu memantau harga berdasarkan daerah
Harga taksi dan pengiriman di aplikasi dibentuk secara dinamis: algoritma mempertimbangkan permintaan di daerah tertentu, waktu dalam sehari, cuaca, dan kepadatan pengemudi serta kurir. Rute yang sama di pusat kota dan pinggiran dapat memiliki harga yang berbeda bahkan di layanan yang sama. Bagi bisnis, ini membuka beberapa tantangan praktis.
Perusahaan logistik menggunakan data harga pesaing untuk menyesuaikan tarif mereka sendiri secara real-time. Jika pesaing menurunkan harga pengiriman di daerah tertentu, adalah bijaksana untuk bereaksi sebelum pelanggan mulai beralih secara massal. Agregator taksi dan car-sharing menganalisis dinamika harga berdasarkan daerah untuk mengidentifikasi zona permintaan tinggi dan mendistribusikan pengemudi. Pengecer dan layanan pengiriman makanan (seperti Yandex.Eda dan SberMarket) memantau biaya pengiriman pesaing untuk mengatur zona pengiriman gratis dan jumlah minimum pesanan dengan benar.
Kategori pengguna yang terpisah adalah analis mobilitas perkotaan dan perusahaan riset yang membangun peta "ketidaksetaraan harga" antara daerah. Data semacam itu membantu pengembang menilai aksesibilitas transportasi dari bangunan baru, dan membantu pemerintah kota mengidentifikasi zona dengan kekurangan layanan transportasi. Tanpa pengumpulan data yang sistematis berdasarkan daerah, tidak ada dari tantangan ini yang dapat diselesaikan — pemeriksaan harga secara manual hanya memberikan gambaran yang terdistorsi, karena harga berubah setiap beberapa menit.
Mengapa layanan memblokir pengumpulan data berdasarkan geolokasi
Layanan taksi dan pengiriman melindungi data harga mereka karena beberapa alasan. Pertama, penetapan harga dinamis adalah rahasia dagang dan keunggulan kompetitif yang mudah disalin jika mengetahui tarif terkini di semua daerah. Kedua, permintaan massal dari satu alamat IP menciptakan beban pada server dan mendistorsi statistik permintaan yang sebenarnya, sehingga sistem anti-fraud secara agresif memblokir permintaan semacam itu.
Secara teknis, perlindungan dibangun pada beberapa tingkat. Aplikasi menentukan geolokasi tidak hanya berdasarkan GPS, tetapi juga berdasarkan alamat IP — jika permintaan dari alamat IP Moskow datang dengan koordinat Novosibirsk, sistem menandainya sebagai mencurigakan. Ada juga batasan permintaan dari satu IP dalam satu unit waktu: melebihi ambang batas dapat menyebabkan pemblokiran sementara atau pemberian harga yang jelas tidak akurat. Tingkat ketiga adalah fingerprinting perangkat dan browser, yang membedakan pengguna nyata dari skrip berdasarkan banyak parameter: resolusi layar, daftar font, perilaku kursor.
Itulah sebabnya skrip sederhana dengan satu alamat IP dengan cepat mendapatkan pemblokiran atau data yang terdistorsi. Untuk pengumpulan harga yang stabil di puluhan daerah di satu kota, apalagi di beberapa kota, dibutuhkan infrastruktur yang meniru permintaan pengguna nyata dari berbagai titik — dan di sini tidak bisa lepas dari proxy yang terikat pada geolokasi yang diperlukan.
Data apa yang perlu dikumpulkan dan dari platform mana
Sebelum mengatur pengumpulan data, penting untuk menentukan indikator apa yang diperlukan untuk analitik. Untuk taksi, ini biasanya: biaya dasar perjalanan untuk rute standar, koefisien permintaan tinggi, waktu penjemputan mobil, dan ketersediaan kelas ekonomi/nyaman/bisnis di daerah tertentu. Untuk pengiriman — biaya pengiriman untuk jumlah pesanan tertentu, jumlah minimum untuk pengiriman gratis, waktu tunggu kurir, dan keberadaan zona cakupan secara umum.
Sumber data utama di Rusia dan negara-negara CIS adalah aplikasi dan situs web agregator taksi besar, layanan pengiriman makanan dan produk, serta marketplace dengan logistik mereka sendiri. Jika tujuannya adalah analisis perbandingan, sebaiknya mengumpulkan data secara bersamaan dari beberapa layanan pesaing di daerah dan rentang waktu yang sama, jika tidak, perbandingan akan menjadi tidak akurat: harga di berbagai layanan berfluktuasi secara asinkron.
Penting untuk mencatat daftar titik kontrol sebelumnya — alamat atau koordinat tertentu di setiap daerah, yang akan digunakan untuk membangun rute. Tanpa titik tetap, data tidak dapat dibandingkan satu sama lain: membandingkan harga perjalanan dari pusat ke daerah tidur dengan harga perjalanan di dalam satu daerah tidak ada artinya untuk analisis dinamika dari waktu ke waktu.
Metode pengumpulan: manual, otomatisasi, API
Ada tiga pendekatan utama untuk mengumpulkan data harga. Pemantauan manual — seorang karyawan membuka aplikasi, mengubah titik keberangkatan, dan mencatat harga. Ini adalah opsi yang berfungsi untuk penelitian sekali, tetapi sama sekali tidak cocok untuk analitik reguler: harga berubah setiap menit, dan pemeriksaan manual 20 daerah di tiga layanan akan memakan waktu berjam-jam.
Pendekatan kedua adalah otomatisasi melalui skrip browser atau browser headless, yang meniru tindakan pengguna: membuka situs, memasukkan alamat, dan membaca harga dari layar. Metode ini lebih mudah diskalakan, tetapi memerlukan penghindaran perlindungan dari bot dan penyesuaian terus-menerus terhadap perubahan antarmuka situs.
Ketiga — bekerja melalui API internal aplikasi mobile, yang sering kali lebih mudah digunakan daripada antarmuka web, tetapi memerlukan simulasi yang lebih tepat dari header permintaan dan sering kali terikat pada otorisasi. Terlepas dari metode yang dipilih, untuk mendapatkan harga yang realistis di daerah tertentu, permintaan harus datang dari alamat IP yang secara fisik terletak di kota tersebut, dan idealnya — di daerah yang sesuai atau setidaknya subjek.
Peran proxy dalam pengumpulan data yang terarah secara geografis
Proxy dalam tugas pemantauan harga berdasarkan daerah tidak menyelesaikan masalah anonimitas, tetapi masalah keandalan data. Layanan taksi dan pengiriman menunjukkan harga yang berbeda tergantung dari mana permintaan fisik datang. Jika mengumpulkan harga di St. Petersburg dengan alamat IP dari Moskow, sistem akan memberikan kesalahan geolokasi atau menunjukkan tarif yang tidak akurat, yang tidak sesuai dengan pasar nyata di kota yang diperlukan.
Untuk tugas ini, proxy residensial adalah yang paling cocok — mereka menggunakan alamat IP nyata dari penyedia rumah dan memungkinkan pemilihan kota atau wilayah tertentu, yang sangat penting saat membandingkan puluhan daerah. Berbeda dengan alamat server, IP residensial tidak masuk dalam daftar hitam sistem anti-fraud layanan taksi, karena terlihat seperti pengguna biasa dari jaringan seluler atau rumah.
Untuk pemantauan aplikasi mobile (bukan versi web), proxy mobile menjadi pilihan yang baik — mereka menggunakan IP dari operator seluler, yang secara tradisional dianggap lebih terpercaya oleh sistem anti-bot, karena sering kali tersembunyi di balik ribuan pelanggan nyata (NAT), dan pemblokiran alamat semacam itu mempengaruhi banyak pengguna biasa, yang dihindari oleh layanan.
Proxy pusat data juga dapat diterapkan — misalnya, untuk mengumpulkan data dari halaman web publik tanpa keterikatan ketat pada geolokasi, di mana kecepatan lebih penting daripada kesesuaian yang tepat dengan jaringan kota. Namun, untuk harga taksi dan pengiriman, di mana geolokasi menentukan hasil permintaan secara langsung, solusi residensial dan mobile memberikan data yang jauh lebih stabil dan realistis.
Jenis proxy mana yang harus dipilih: perbandingan
Untuk menentukan pilihan, berguna untuk membandingkan jenis proxy berdasarkan parameter kunci yang penting untuk pemantauan harga berdasarkan daerah.
| Jenis Proxy | Akurasi Geotargeting | Risiko Pemblokiran | Cocok untuk |
|---|---|---|---|
| Proxy Residensial | Tinggi, hingga kota/daerah | Rendah | Situs dan aplikasi taksi, pengiriman, analisis mendetail berdasarkan daerah |
| Proxy Mobile | Tinggi, terikat pada operator dan wilayah | Sangat rendah | Pemantauan melalui aplikasi mobile taksi dan pengiriman |
| Proxy Pusat Data | Rendah, tanpa keterikatan geolokasi yang tepat | Di atas rata-rata | Pengumpulan data umum, di mana geolokasi tidak kritis |
Dalam praktiknya, banyak tim analitik mengombinasikan pendekatan: menggunakan proxy residensial untuk pengumpulan harga awal di situs dan proxy mobile untuk memverifikasi data dari aplikasi, karena harga di sana kadang-kadang berbeda dari versi web.
Pengaturan langkah demi langkah untuk pengumpulan data
Jika perusahaan tidak memiliki pengembang tetap, pengaturan pemantauan reguler dapat dilakukan melalui kombinasi browser anti-detect dan proxy, tanpa perlu menulis kode. Pendekatannya adalah sebagai berikut: buka browser anti-detect (Dolphin Anty, AdsPower, Multilogin, atau Octo Browser), buat profil terpisah untuk setiap kota atau daerah yang perlu dipantau.
Dalam pengaturan profil, tentukan proxy yang terikat pada wilayah yang diperlukan: masukkan alamat IP, port, login, dan kata sandi, pilih jenis SOCKS5 atau HTTP tergantung pada apa yang didukung oleh penyedia proxy yang dipilih. Setelah itu, profil akan terlihat bagi situs seolah-olah pengguna secara fisik berada di kota yang dipilih — browser akan membuka situs taksi atau pengiriman dengan harga "lokal".
Selanjutnya, Anda dapat secara manual atau melalui skenario otomatisasi yang terintegrasi dalam browser anti-detect (banyak layanan mendukung makro sederhana tanpa kode) mengunjungi situs, memasukkan titik kontrol rute, dan mencatat harga, atau mengambil tangkapan layar halaman untuk pemrosesan selanjutnya. Untuk beberapa daerah, nyaman untuk memiliki profil browser terpisah dengan keterikatan pada IP yang berbeda, beralih di antara mereka sesuai jadwal.
Untuk pemantauan yang lebih besar — ketika perlu memantau puluhan daerah di beberapa kota beberapa kali sehari — mode manual menjadi tidak efektif, dan sebaiknya beralih ke pengumpulan otomatis melalui skrip, yang akan dibahas di bawah ini.
Contoh skrip untuk pengumpulan otomatis
Bagi mereka yang memiliki pengembang atau analis dalam tim yang siap bekerja dengan kode, pengumpulan harga otomatis dapat dibangun di Python menggunakan pustaka requests dan rotasi proxy berdasarkan wilayah. Di bawah ini adalah contoh sederhana dari logika polling API layanan pengiriman dengan substitusi koordinat daerah dan pemrosesan permintaan melalui wilayah yang diperlukan.
import requests
import time
# Daftar titik kontrol berdasarkan daerah kota
districts = [
{"name": "Pusat", "lat": 55.7558, "lon": 37.6173},
{"name": "Daerah Tidur A", "lat": 55.8300, "lon": 37.4500},
{"name": "Daerah Tidur B", "lat": 55.6200, "lon": 37.7100},
]
# Proxy yang terikat pada wilayah yang diperlukan
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) # jeda antara permintaan, untuk tidak melebihi batas
print(results)
Dalam tugas nyata, proxy perlu diputar pada tingkat pool — agar daerah yang berbeda di-query dari IP yang berbeda, dan permintaan ke endpoint yang sama tidak terlalu sering datang dari satu alamat. Ini mengurangi risiko pemblokiran dan membuat pengambilan data lebih stabil dari waktu ke waktu.
Frekuensi pembaruan dan penyimpanan data
Harga taksi dan pengiriman berubah sepanjang hari, jadi snapshot data sekali tidak akan banyak membantu analisis. Frekuensi optimal polling tergantung pada tugas: untuk analisis jam sibuk, cukup dengan memantau harga setiap 15–30 menit selama jam sibuk dan sekali setiap satu atau dua jam di waktu lainnya. Untuk membangun peta "harga dasar" berdasarkan daerah, satu atau dua pengukuran per hari pada waktu yang sama sudah cukup untuk menghilangkan pengaruh permintaan.
Menyimpan data yang dikumpulkan dengan cara yang terstruktur adalah yang paling nyaman — tabel dengan kolom "tanggal dan waktu", "daerah", "layanan", "harga", "koefisien permintaan". Format semacam itu mudah diunggah ke Google Sheets untuk volume kecil atau ke database untuk membangun dasbor yang lengkap di alat BI. Penting untuk menyimpan data historis, bukan menimpanya — justru dinamika dari waktu ke waktu yang memberikan nilai analitis terbesar, bukan pengukuran titik.
Dalam pengumpulan volume besar (beberapa kota, puluhan daerah, beberapa layanan), sebaiknya merencanakan sebelumnya bagaimana menyimpan dan mengagregasi data berdasarkan jam dan hari dalam seminggu — ini akan memungkinkan untuk membangun model perkiraan permintaan dan penetapan harga di masa depan, bukan hanya arsip angka yang terpisah.
Kesalahan umum saat memantau harga
Kesalahan pertama dan paling umum adalah menggunakan alamat IP yang sama untuk polling semua daerah di kota. Ini tidak hanya meningkatkan risiko pemblokiran, tetapi juga dapat menyebabkan layanan memberikan harga rata-rata atau yang di-cache alih-alih nilai yang aktual untuk lokasi tertentu.
Kesalahan kedua adalah permintaan yang terlalu sering tanpa jeda, yang dengan cepat mengarah pada pemblokiran sementara akun atau IP. Sistem anti-fraud layanan taksi melacak tidak hanya jumlah permintaan, tetapi juga pola perilaku: pengguna nyata tidak memeriksa harga perjalanan 50 kali berturut-turut dalam satu menit dari titik yang sama.
Kesalahan ketiga adalah mengabaikan perbedaan antara harga di aplikasi dan di situs web. Banyak layanan taksi dan pengiriman menunjukkan tarif yang berbeda di aplikasi mobile dibandingkan dengan versi web, karena algoritma yang berbeda atau promosi yang hanya terlihat di aplikasi. Jika analisis dibangun hanya berdasarkan data web, hasilnya mungkin tidak mencerminkan gambaran nyata bagi sebagian besar pengguna yang memesan melalui aplikasi.
Kesalahan keempat adalah ketidakcocokan titik kontrol antara pengukuran. Jika hari ini koordinat daerah diambil dari satu alamat, dan besok dari alamat lain di daerah yang sama, perbedaan harga dapat dijelaskan bukan oleh perubahan pasar, tetapi hanya oleh titik awal atau akhir rute yang berbeda.
Kesimpulan
Pemantauan sistematis harga taksi dan pengiriman berdasarkan daerah kota memberikan keuntungan konkret bagi bisnis: kemampuan untuk bereaksi cepat terhadap tindakan pesaing, memprediksi permintaan dengan lebih akurat, dan membuat keputusan yang beralasan tentang zona cakupan dan tarif. Syarat kunci untuk mendapatkan data yang dapat diandalkan adalah permintaan harus datang dari alamat IP yang secara fisik terikat pada kota dan daerah yang diperlukan, jika tidak, layanan akan memberikan harga yang tidak akurat atau rata-rata.
Jika Anda berencana untuk membangun pengumpulan data reguler tentang harga taksi atau pengiriman di berbagai daerah, kami merekomendasikan untuk memulai dengan proxy residensial dengan keterikatan geolokasi yang tepat pada kota yang diperlukan — mereka memberikan data yang paling realistis dan risiko pemblokiran yang minimal. Untuk tugas yang terkait khusus dengan aplikasi mobile taksi dan pengiriman, sebaiknya juga mempertimbangkan IP mobile, yang lebih diterima oleh sistem anti-fraud sebagai lalu lintas pengguna biasa.