← Kembali ke blog

Berapa Biaya Memantau 10.000 Produk per Bulan: Perhitungan Lalu Lintas dan Pemilihan Proxy

Membahas berapa banyak trafik yang sebenarnya dibutuhkan untuk memantau 10.000 produk per bulan, cara memilih jenis proxy sesuai dengan volume, dan tidak membayar lebih untuk pengambilan harga pesaing.

📅23 September 2026

Penjual Wildberries dan Ozon seringkali menganggarkan biaya untuk proxy "secara kasar" — dan baik membayar 3-4 kali lipat, atau membeli paket yang terlalu murah, yang habis dalam seminggu. Mari kita bahas bagaimana cara menghitung volume lalu lintas untuk memantau 10.000 produk per bulan, jenis proxy apa yang harus dipilih untuk beban seperti itu, dan di mana Anda bisa menghemat tanpa kehilangan kualitas data.

Mengapa memantau 10.000 produk, bukan 100

Jika Anda memiliki 100-200 produk, Anda bisa memeriksa harga pesaing secara manual sekali sehari. Namun, ketika katalog tumbuh menjadi ribuan SKU, dan pesaing mengubah harga 5-10 kali sehari (terutama selama promosi Wildberries dan Ozon), pemantauan manual menjadi tidak mungkin — data menjadi usang lebih cepat daripada Anda dapat mengumpulkannya.

10.000 produk adalah volume tipikal untuk penjual menengah dengan beberapa kategori atau agensi yang melakukan pemantauan untuk 5-10 klien secara bersamaan. Untuk skala seperti itu, otomatisasi diperlukan: skrip atau layanan pengambilan data yang siap pakai, yang meminta data dari kartu produk, halaman kategori, dan API marketplace puluhan ribu kali sehari. Dan di sini muncul pertanyaan utama — melalui apa kita mengirim permintaan ini, agar tidak mendapatkan pemblokiran IP hanya dalam dua jam kerja.

Wildberries, Ozon, dan Avito secara aktif melindungi diri dari pengambilan data: mereka memasang captcha, mengurangi kecepatan respons, dan memblokir IP dari pusat data secara massal. Oleh karena itu, anggaran untuk pemantauan bukan hanya biaya server dan pengembangan, tetapi juga pos pengeluaran terpisah untuk proxy, yang sering kali paling tidak terduga, jika dihitung "secara kasar".

Berapa banyak permintaan yang benar-benar diperlukan dalam sebulan

Langkah pertama dalam menghitung anggaran adalah memahami berapa banyak permintaan HTTP yang secara fisik perlu Anda lakukan. Ini tergantung pada frekuensi pembaruan harga yang Anda masukkan dalam strategi pemantauan.

Frekuensi pembaruan Permintaan per produk per bulan Permintaan untuk 10.000 produk
1 kali sehari 30 300.000
4 kali sehari 120 1.200.000
Sekali per jam (24 kali sehari) 720 7.200.000

Untuk sebagian besar penjual di Wildberries dan Ozon, 4-6 pembaruan sehari sudah cukup — ini mencakup perang harga pagi dan sore tanpa beban berlebihan pada kumpulan proxy. Pemantauan setiap jam hanya diperlukan di niche yang sangat kompetitif (elektronik, kosmetik) selama acara besar seperti "Black Friday".

Rumus perhitungan lalu lintas

Lalu lintas yang "berat" pada proxy tergantung tidak hanya pada jumlah permintaan, tetapi juga pada apa yang Anda ambil: kartu produk secara keseluruhan (halaman HTML dengan gambar dan skrip) atau hanya respons JSON dari API marketplace.

Rumus:

Lalu lintas (GB) = Jumlah permintaan × Rata-rata berat respons (KB) / 1.048.576

Rata-rata berat respons sangat bervariasi tergantung pada metode:

  • Permintaan ke API kartu produk (JSON) — 15-60 KB per respons
  • Halaman HTML lengkap kartu produk — 300-900 KB per respons
  • Halaman kategori/pencarian dengan paginasi — 500-1500 KB per respons

Jika Anda mengambil data langsung melalui API internal marketplace (yang lebih disukai — lebih sedikit berat, lebih cepat kecepatan, risiko captcha lebih rendah), untuk 10.000 produk dengan 4 pembaruan sehari kita mendapatkan 1.200.000 permintaan × 40 KB ≈ 45,8 GB lalu lintas per bulan. Jika mengambil halaman HTML lengkap, volume permintaan yang sama "berat" sudah 600-900 GB — perbedaan 15-20 kali hanya karena metode pengumpulan data.

Proxy Data Center, Residensial, dan Seluler: apa yang harus dipilih

Jenis proxy secara langsung mempengaruhi baik biaya maupun persentase permintaan yang berhasil (success rate). Untuk pemantauan marketplace, ini sangat penting: semakin sering proxy diblokir, semakin banyak percobaan ulang dan semakin tinggi penggunaan lalu lintas yang sebenarnya melebihi rumus perhitungan.

Jenis proxy Success rate di WB/Ozon Kapan digunakan
Proxy Data Center 40-60% (mudah diblokir secara massal) Pemantauan frekuensi rendah, pengujian, katalog kecil
Proxy Residensial 85-95% Pilihan utama untuk 10.000+ produk, pemantauan harian
Proxy Seluler 90-98% Pemantauan frekuensi tinggi di niche yang ketat, menghindari perlindungan yang ketat

Proxy data center tampak menguntungkan dari segi biaya per GB, tetapi dalam praktiknya untuk Wildberries dan Ozon, success rate mereka turun setelah beberapa jam pengambilan data yang aktif — marketplace menghitung rentang IP dari penyedia hosting dan memblokir akses secara massal. Akibatnya, Anda membayar untuk lalu lintas yang digunakan untuk percobaan ulang, bukan untuk permintaan yang berhasil.

Proxy residensial menggunakan IP nyata dari pengguna rumah, sehingga dianggap oleh marketplace sebagai pengunjung biasa situs. Untuk pemantauan yang stabil dari 10.000 produk, ini adalah keseimbangan optimal antara harga dan keandalan. Proxy seluler memberikan tingkat keberhasilan yang lebih tinggi, tetapi biasanya lebih mahal — mereka sebaiknya digunakan secara selektif, untuk kategori yang paling bermasalah atau selama periode puncak promosi.

Tiga skenario perhitungan anggaran

Mari kita bahas tiga skenario tipikal untuk memantau 10.000 produk, untuk menunjukkan bagaimana metode pengumpulan dan frekuensi pembaruan mempengaruhi total volume lalu lintas.

Skenario 1: Pemantauan hemat melalui API

4 pembaruan sehari, pengambilan data melalui API internal marketplace (JSON, ~40 KB per respons), proxy residensial dengan success rate 90%.

  • Permintaan dasar: 1.200.000 per bulan
  • Dengan mempertimbangkan 10% percobaan ulang: 1.320.000 permintaan
  • Lalu lintas: 1.320.000 × 40 KB ≈ 50,4 GB per bulan

Skenario 2: Beban rata-rata dengan pengambilan halaman HTML

6 pembaruan sehari, pengambilan kartu produk lengkap (HTML, ~500 KB per respons) untuk mendapatkan tidak hanya harga, tetapi juga stok, ulasan, posisi dalam pencarian.

  • Permintaan dasar: 1.800.000 per bulan
  • Dengan mempertimbangkan percobaan ulang (15%): 2.070.000 permintaan
  • Lalu lintas: 2.070.000 × 500 KB ≈ 987 GB per bulan

Skenario 3: Pemantauan frekuensi tinggi di musim puncak

Pembaruan setiap jam (24 kali sehari) melalui API, ditambah pengambilan halaman kategori untuk melacak posisi dalam hasil pencarian, proxy seluler untuk kategori yang bermasalah.

  • Permintaan ke produk: 7.200.000 per bulan (sekitar 40 KB)
  • Permintaan ke halaman kategori: 300.000 per bulan (sekitar 800 KB)
  • Lalu lintas: (7.200.000 × 40 KB) + (300.000 × 800 KB) ≈ 274,7 + 228,9 ≈ 503,6 GB per bulan

Perbedaan antara skenario secara jelas menunjukkan: metode pengumpulan data mempengaruhi anggaran lebih besar daripada frekuensi pembaruan. Beralih dari pengambilan HTML ke penggunaan API dapat mengurangi penggunaan lalu lintas 10-20 kali dengan volume produk yang sama dan frekuensi pemeriksaan yang sama.

Bagaimana mengurangi penggunaan lalu lintas tanpa kehilangan data

Ada beberapa teknik praktis yang memungkinkan Anda menjaga anggaran pemantauan tetap terkendali tanpa kehilangan relevansi data.

  1. Ambil data dari API, bukan HTML. Jika marketplace memberikan data melalui API internal (ini dapat ditentukan dengan menganalisis permintaan jaringan di browser saat membuka kartu produk), gunakan itu — berat respons turun 10-20 kali.
  2. Pisahkan produk berdasarkan prioritas. Tidak semua 10.000 SKU sama pentingnya. Produk-produk unggulan dengan persaingan tinggi pantau setiap jam, yang lainnya — 1-2 kali sehari. Ini mengurangi total volume permintaan sebesar 40-60%.
  3. Cache data statis. Nama, deskripsi, dan karakteristik produk jarang berubah — cukup untuk mengumpulkannya sekali seminggu. Hanya harga dan stok yang perlu diperbarui setiap jam.
  4. Atur rotasi proxy dengan bijak. Perubahan IP yang terlalu sering pada setiap permintaan meningkatkan jumlah captcha dan percobaan ulang. Rotasi setiap 5-10 permintaan dari satu IP biasanya memberikan keseimbangan yang lebih baik antara anonimitas dan success rate.
  5. Kompresi lalu lintas melalui gzip. Pastikan skrip atau layanan pengambilan data Anda mengirimkan header Accept-Encoding: gzip — ini mengurangi berat respons JSON sebesar 60-70%.

Kesalahan umum dalam perhitungan anggaran

Saat merencanakan anggaran untuk memantau 10.000 produk, penjual sering melakukan kesalahan yang sama, yang mengakibatkan pemborosan atau, sebaliknya, kekurangan lalu lintas di tengah bulan.

  • Tidak mempertimbangkan percobaan ulang. Saat bekerja dengan proxy data center, hingga 40-50% permintaan dapat berakhir dengan captcha atau pemblokiran — penggunaan lalu lintas yang sebenarnya bisa 1,5-2 kali lebih tinggi dari yang diperkirakan.
  • Memantau semuanya dengan frekuensi yang sama. Jika 10.000 produk diperbarui setiap jam "hanya untuk berjaga-jaga", anggaran akan meningkat berkali-kali tanpa manfaat nyata bagi bisnis.
  • Lupa tentang musiman. Selama periode diskon (11.11, "Black Friday", Tahun Baru) pesaing mengubah harga lebih sering, dan bersamaan dengan itu jumlah permintaan ulang Anda meningkat karena perlindungan marketplace yang lebih ketat terhadap pengambilan data.
  • Hanya menghitung lalu lintas berdasarkan rumus, tanpa cadangan. Bijaksana untuk menyisihkan 20-30% cadangan lalu lintas di atas volume yang diperkirakan untuk mengantisipasi perubahan struktur halaman marketplace atau peningkatan sementara dalam captcha.

Checklist sebelum memulai pemantauan

  • Menentukan frekuensi pembaruan harga untuk berbagai kelompok produk (VIP / biasa / prioritas rendah)
  • Mengetahui apakah bisa mengambil data melalui API marketplace daripada halaman HTML
  • Menghitung volume dasar lalu lintas berdasarkan rumus "permintaan × berat respons"
  • Menambahkan cadangan 20-30% untuk percobaan ulang dan captcha
  • Memilih jenis proxy untuk tugas: residensial untuk volume utama, seluler — untuk kategori yang bermasalah
  • Mengatur rotasi IP yang bijaksana (tidak untuk setiap permintaan, tetapi setiap 5-10 permintaan)
  • Mengaktifkan kompresi gzip dalam permintaan untuk mengurangi berat respons
  • Menyisihkan anggaran tambahan untuk periode puncak promosi dan diskon

Kesimpulan

Anggaran untuk memantau 10.000 produk per bulan bukanlah angka tetap, tetapi hasil dari keputusan konkret: seberapa sering memperbarui harga, melalui apa mengambil data, dan jenis proxy apa yang digunakan. Perhitungan yang tepat dari lalu lintas berdasarkan rumus "jumlah permintaan × berat respons" dengan mempertimbangkan cadangan untuk percobaan ulang memungkinkan untuk memahami biaya nyata pemantauan sebelumnya dan menghindari kejutan yang tidak menyenangkan di tengah bulan.

Untuk pemantauan yang stabil di Wildberries, Ozon, dan Avito dalam volume menengah dan besar, kami merekomendasikan untuk memulai dengan proxy residensial — mereka memberikan tingkat keberhasilan yang tinggi dengan biaya lalu lintas yang dapat diterima. Jika kategori produk tertentu terkena perlindungan yang lebih ketat dari marketplace, sambungkan secara selektif proxy seluler khusus untuk mereka, bukan untuk seluruh katalog sekaligus — ini akan memungkinkan Anda mengontrol anggaran tanpa kehilangan kualitas data.