Batas Lalu Lintas untuk Parsing Wildberries dan Ozon: Cara Menghindari Kehilangan Paket Proxy Bulanan dalam Semalam

Penjual menjalankan pengambil data harga pesaing semalaman, dan di pagi hari menerima pemberitahuan: lalu lintas habis, paket terpakai 90%. Situasi yang akrab? Seringkali bukan kesalahan pengambil data itu sendiri, tetapi kurangnya batasan di tingkat proksi dan skrip. Dalam artikel ini, kita akan membahas bagaimana lalu lintas "bocor" secara percuma, dan bagaimana menetapkan perlindungan agar paket bulanan proksi residensial atau mobile cukup hingga akhir periode perhitungan.

Mengapa lalu lintas habis dalam semalam

Pengambilan data di Wildberries, Ozon, atau Avito terlihat seperti tugas yang sederhana: kirim permintaan — dapatkan JSON dengan harga. Namun dalam praktiknya, lalu lintas tidak hanya digunakan untuk data yang berguna. Sumber utama pemborosan adalah:

• Pengunduhan gambar dan media. Jika pengambil data membuka halaman produk sepenuhnya melalui browser (dan tidak melakukan permintaan langsung ke API), ia secara otomatis mengunduh gambar, video, spanduk — ini bisa mencapai puluhan megabyte untuk satu kartu produk.
• Permintaan ulang karena captcha dan pemblokiran. Marketplace mengenali bot, mengeluarkan captcha atau larangan sementara IP, skrip melakukan permintaan ulang — lalu lintas terbuang percuma, dan data tidak diterima.
• Kurangnya caching permintaan. Tanpa logika "sudah diambil data dalam jam ini — jangan ulang" skrip dapat memeriksa kartu yang sama beberapa kali dalam semalam.
• Aliran paralel tanpa batasan. Menjalankan 50-100 aliran secara bersamaan tampaknya mempercepat pekerjaan, tetapi pada saat yang sama lalu lintas terbuang jauh lebih cepat daripada yang direncanakan, dan sebagian permintaan hanya diblokir.
• Pemilihan jenis proksi yang salah. Proksi residensial dan mobile biasanya dikenakan biaya berdasarkan volume lalu lintas (GB), berbeda dengan proksi pusat data, di mana biasanya pembayaran dilakukan berdasarkan jumlah IP atau waktu sewa. Jika pengambil data disetel pada kumpulan residensial tanpa kontrol — batas habis dengan cepat.

Kombinasi faktor-faktor ini menyebabkan skrip, yang dirancang untuk sebulan kerja, menghabiskan paket lalu lintas dalam satu sesi pengambilan data 10-20 ribu kartu produk.

Bagaimana lalu lintas dihitung pada berbagai jenis proksi

Sebelum menetapkan batas, penting untuk memahami apa yang sebenarnya Anda bayar. Berbagai jenis proksi menghitung pengeluaran dengan cara yang berbeda, dan ini secara langsung mempengaruhi strategi penghematan.

Jenis proksi	Penagihan	Risiko pemborosan	Kapan diterapkan
Proksi residensial	Berdasarkan volume lalu lintas (GB)	Tinggi tanpa batas	Pengambilan data dengan melewati perlindungan anti-bot marketplace
Proksi mobile	Berdasarkan volume lalu lintas atau waktu	Tinggi, lalu lintas lebih mahal	Pengambilan data versi mobile situs, melewati pemblokiran ketat
Proksi pusat data	Berdasarkan jumlah IP / waktu sewa	Rendah, lalu lintas biasanya tidak terbatas	Pengambilan data massal tanpa perlindungan anti-bot yang ketat

Jika Anda mengambil data dari Wildberries atau Ozon, di mana perlindungan terhadap bot aktif, IP residensial atau mobile hampir selalu diperlukan — alamat pusat data diblokir dengan cepat. Namun, karena penagihan berdasarkan lalu lintas, sangat penting untuk menetapkan batas sebelumnya.

Berapa banyak lalu lintas yang sebenarnya dibutuhkan untuk pengambilan data

Untuk menetapkan batas yang memadai, Anda perlu berpegang pada angka yang nyata, bukan pada perasaan. Perkiraan pengeluaran dalam praktik:

• Permintaan ke API kartu produk (JSON, tanpa gambar): 5-30 KB per kartu. Untuk 10.000 kartu — sekitar 50-300 MB.
• Pengunduhan halaman produk melalui browser headless dengan gambar: 1-3 MB per kartu. Untuk 10.000 kartu yang sama — 10-30 GB.
• Pemantauan harga setiap jam untuk 1000 SKU: dengan permintaan yang lebih ringan — sekitar 1-5 GB per hari, dengan pemuatan halaman penuh — 50-100 GB per hari.

Perbedaan antara pengambilan data "ringan" dan "berat" adalah puluhan kali. Oleh karena itu, langkah pertama untuk menghemat lalu lintas — matikan pengunduhan gambar, video, dan skrip pihak ketiga di tempat yang memungkinkan, dan bekerja langsung dengan API marketplace atau versi mobile situs yang lebih ringan daripada versi desktop.

Batasan di browser anti-deteksi dan manajer proksi

Bagi mereka yang mengambil data melalui browser anti-deteksi (misalnya, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) atau manajer proksi sendiri, cara termudah untuk membatasi pengeluaran — mengatur batas di tingkat profil dan akun penyedia proksi.

1. Masuk ke akun pribadi penyedia proksi dan cari bagian pengelolaan lalu lintas atau batasan untuk sub-pengguna/port.
2. Buat sub-akun atau port terpisah untuk pengambilan data — jangan gunakan kumpulan proksi yang sama untuk mengelola akun di Instagram atau TikTok. Pemisahan berdasarkan tugas segera menunjukkan ke mana lalu lintas pergi.
3. Atur batas harian atau per jam untuk lalu lintas di sub-akun ini — misalnya, 5 GB per hari daripada menghabiskan seluruh paket bulanan dalam satu sesi.
4. Di browser anti-deteksi, matikan pengunduhan otomatis gambar untuk profil yang digunakan hanya untuk pengumpulan data, bukan untuk melihat halaman secara visual.
5. Atur jadwal peluncuran profil sehingga pengambilan data tidak dilakukan dalam satu sesi panjang, tetapi dalam interval pendek dengan jeda — ini mengurangi risiko pemblokiran dan memberi waktu untuk melacak pengeluaran lalu lintas antara peluncuran.

Pendekatan ini sangat penting bagi agensi dan freelancer yang melakukan pengambilan data di beberapa marketplace secara bersamaan: tanpa pemisahan berdasarkan sub-akun, sulit untuk memahami proyek mana yang "memakan" lalu lintas.

Pembatasan lalu lintas di tingkat skrip dan API

Jika pengambil data ditulis sendiri dalam Python atau Node.js, batasan dapat dan harus disematkan langsung ke dalam kode — ini memberikan kontrol yang lebih tepat daripada pengaturan antarmuka penyedia proksi.

Contoh penghitung lalu lintas sederhana dalam Python menggunakan requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # batas 5 GB per hari
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("Batas harian lalu lintas telah habis, pengambilan data dihentikan")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# contoh panggilan
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Lalu lintas yang digunakan:", round(used_bytes / 1024 / 1024, 2), "MB")

Logika sederhana: skrip menghitung volume setiap respons dalam byte dan berhenti begitu batas yang ditentukan tercapai. Ini melindungi dari situasi di mana karena kesalahan dalam loop atau pengulangan permintaan yang tak berujung, skrip "menghabiskan" paket lalu lintas bulanan dalam beberapa jam.

Selain itu, sebaiknya tambahkan:

• Penundaan eksponensial saat terjadi kesalahan (retry dengan backoff) — alih-alih mengulangi permintaan segera saat captcha atau larangan, skrip menunggu interval yang meningkat (5 detik, 15 detik, 60 detik), yang mengurangi jumlah permintaan yang tidak berguna.
• Pembatasan jumlah aliran paralel — misalnya, tidak lebih dari 10-20 koneksi simultan melalui kumpulan proksi, agar tidak memicu pemblokiran dan tidak membuang lalu lintas secara percuma.
• Matikan pengunduhan sumber daya di browser headless — jika pengambilan data dilakukan melalui Selenium atau Puppeteer, di pengaturan browser Anda dapat memblokir pengunduhan gambar, font, dan CSS, hanya menyisakan respons HTML/JSON.

Pemantauan pengeluaran secara real-time

Batas tanpa pemantauan bekerja lebih buruk, karena Anda hanya mengetahui masalah setelah skrip dihentikan. Untuk mengontrol pengeluaran secara langsung:

• Aktifkan pemberitahuan di akun pribadi penyedia proksi tentang pencapaian 50%, 80%, dan 100% dari paket bulanan lalu lintas — sebagian besar layanan mendukung pemberitahuan semacam itu melalui email atau di Telegram.
• Jaga log sederhana di dalam skrip: catat dalam file atau basis data volume lalu lintas per jam, untuk melihat puncak pengeluaran dan dengan cepat menemukan sumber masalah.
• Pisahkan lalu lintas berdasarkan tugas melalui sub-akun atau label terpisah — terpisah untuk pengambilan data Wildberries, terpisah untuk Ozon, terpisah untuk Avito. Ini menyederhanakan analisis, proyek mana yang paling banyak menghabiskan lalu lintas.
• Bandingkan pengeluaran dengan volume data yang diharapkan: jika untuk 10.000 kartu menghabiskan 20 GB daripada yang diperkirakan 300 MB, berarti ada sumber daya tambahan yang dimuat atau permintaan ulang yang terjadi.

Daftar periksa kontrol anggaran lalu lintas

Kesalahan umum pemula

Dalam praktiknya, sebagian besar paket lalu lintas yang "habis" dapat dijelaskan oleh beberapa kesalahan umum:

• Menjalankan pengambilan data "semalaman tanpa pengawasan" tanpa batasan. Skrip berjalan 8-10 jam tanpa henti, dan jika di mana saja terjadi loop permintaan ulang, lalu lintas terbuang terus menerus hingga pagi.
• Satu kumpulan proksi umum untuk semua tugas. Mengelola akun di Instagram, pengujian iklan di Facebook Ads, dan pengambilan data Ozon menggunakan lalu lintas yang sama — tidak mungkin untuk memahami apa yang sebenarnya menghabiskan lalu lintas tersebut.
• Mengabaikan captcha. Alih-alih mengurangi frekuensi permintaan saat tanda-tanda awal captcha muncul, skrip terus menyerang situs dengan intensitas yang sama, menghabiskan lalu lintas untuk respons yang tidak berguna dengan kode kesalahan.
• Pemilihan proksi residensial di tempat yang cukup dengan proksi pusat data. Jika marketplace tidak memblokir IP pusat data secara ketat, membayar lebih untuk lalu lintas dari kumpulan residensial tidak dibenarkan — untuk tujuan yang kurang terlindungi, proksi pusat data dengan model penagihan yang berbeda sudah cukup.
• Kurangnya pengujian awal. Sebelum menjalankan pengambilan data penuh pada ribuan kartu, sebaiknya jalankan skrip pada 50-100 kartu dan ukur pengeluaran lalu lintas yang sebenarnya, untuk mengalikan pada seluruh volume.

Kesimpulan

Lalu lintas untuk pengambilan data "habis" bukan karena volume data, tetapi karena kurangnya kontrol: gambar yang tidak perlu, permintaan ulang saat pemblokiran, aliran paralel tanpa batasan, dan kumpulan proksi umum untuk semua tugas. Solusinya adalah membagi lalu lintas berdasarkan proyek, menetapkan batas harian di tingkat akun proksi, menyematkan penghitung pengeluaran ke dalam skrip itu sendiri, dan mengatur pemantauan dengan pemberitahuan sebelum paket benar-benar habis.

Jika Anda mengambil data dari marketplace dengan perlindungan aktif terhadap bot seperti Wildberries atau Ozon, kami merekomendasikan untuk menggunakan proksi residensial untuk melewati pemblokiran dan tambahan IP mobile untuk skenario yang paling sensitif terhadap perlindungan anti-bot — tetapi dalam kedua kasus, pastikan untuk menetapkan batas lalu lintas sebelumnya agar paket bulanan tidak habis dalam satu sesi semalaman.