Pengambilan Data Walmart: Cara Memilih Proxy dan Mengatur Pengumpulan Data Tanpa Pemblokiran

1. Analisis reputasi IP

PerimeterX memeriksa setiap alamat IP di basis data server proxy, data center, dan VPN yang dikenal. Jika IP Anda ada di basis ini — Anda akan mendapatkan pemblokiran atau CAPTCHA. Walmart secara khusus menyaring IP dari penyedia cloud populer (AWS, Google Cloud, DigitalOcean) dengan ketat.

2. Analisis perilaku

Sistem ini melacak bagaimana pengguna berinteraksi dengan halaman: gerakan mouse, kecepatan scroll, klik. Parser yang menggunakan Selenium atau Puppeteer sering terdeteksi di sini — mereka membuka halaman terlalu cepat, tanpa jeda alami, dan tidak menggerakkan mouse.

3. TLS dan HTTP fingerprinting

PerimeterX menganalisis sidik jari TLS dari koneksi Anda (urutan cipher, ekstensi) dan header HTTP permintaan. Pustaka standar Python (requests, urllib) memiliki sidik jari unik yang mudah dikenali. Bahkan jika Anda mengganti User-Agent, sistem akan melihat ketidaksesuaian antara header dan browser nyata.

4. Tantangan JavaScript

Pada permintaan yang mencurigakan, PerimeterX mengirimkan kode JavaScript yang melakukan pemeriksaan di browser: ketersediaan Canvas API, WebGL, parameter layar, font yang terpasang. Parser HTTP sederhana (tanpa mesin browser) tidak dapat melewati pemeriksaan ini dan mendapatkan pemblokiran.

Jenis Proxy	Efektivitas untuk Walmart	Kecepatan	Biaya	Rekomendasi
Proxy Residensial	⭐⭐⭐⭐⭐ Bagus — IP pengguna nyata, minimal pemblokiran	Sedang (200-800 ms)	Tinggi (dari $7-15/GB)	Optimal untuk produksi
Proxy Seluler	⭐⭐⭐⭐⭐ Bagus — skor kepercayaan tinggi, pemblokiran jarang	Rendah (500-1500 ms)	Sangat tinggi (dari $50-100/bulan per IP)	Untuk kasus yang rumit
Proxy Data Center	⭐⭐ Buruk — kemungkinan pemblokiran tinggi (70-90%)	Tinggi (50-150 ms)	Rendah (dari $1-3/IP)	Tidak direkomendasikan
ISP Proxy	⭐⭐⭐⭐ Baik — IP residensial statis	Tinggi (80-200 ms)	Sedang (dari $30-80/bulan per IP)	Untuk tugas jangka panjang

Proxy Residensial — standar emas untuk Walmart

Ini adalah alamat IP dari penyedia internet rumah nyata (Comcast, AT&T, Verizon di AS). Walmart melihat mereka sebagai pembeli biasa, sehingga persentase pemblokiran minimal — sekitar 5-10% dengan pengaturan yang benar. Keuntungan utama — kumpulan alamat yang besar (jutaan IP), yang memungkinkan pengaturan rotasi yang efektif.

Kapan digunakan: memantau harga ribuan produk, pengumpulan data harian, proyek jangka panjang. Untuk parsing Walmart, proxy residensial adalah pilihan optimal dalam hal efektivitas dan biaya.

Proxy Seluler — keandalan maksimum

IP dari operator seluler (T-Mobile, Verizon Wireless) memiliki skor kepercayaan tertinggi di sistem anti-bot. Alasannya — satu IP digunakan oleh ribuan pengguna nyata (melalui NAT operator), sehingga memblokirnya = memblokir ribuan pembeli. Walmart hampir tidak memblokir IP seluler.

Kapan digunakan: jika proxy residensial tidak berhasil, jika perlu mem-parsing bagian yang sangat terlindungi (misalnya, harga untuk wilayah tertentu), jika anggaran memungkinkan. Proxy seluler memberikan hampir 100% permintaan yang berhasil, tetapi biayanya lebih mahal.

Proxy Data Center — tidak untuk Walmart

Alamat IP dari server di data center (AWS, OVH, Hetzner) segera dikenali oleh PerimeterX. Bahkan jika Anda membeli IP "bersih" yang sebelumnya tidak digunakan untuk parsing, sistem tetap melihat bahwa itu adalah data center, bukan penyedia rumah. Persentase pemblokiran — 70-90%.

Satu-satunya skenario penggunaan: pengujian parser pada volume data kecil (10-50 halaman). Untuk produksi, tidak cocok sama sekali.

Dengan proxy residensial:

• Ukuran rata-rata halaman produk Walmart: ~500 KB
• 10,000 produk × 500 KB = 5 GB lalu lintas per hari
• Lalu lintas bulanan: 150 GB
• Biaya pada $10/GB: $1,500/bulan
• Persentase permintaan yang berhasil: 90-95%
• Biaya nyata dengan mempertimbangkan pengulangan: ~$1,650/bulan

Dengan proxy data center (secara teoritis):

• Biaya 100 IP: ~$200/bulan
• Persentase permintaan yang berhasil: 10-30% (sisanya — pemblokiran)
• Perlu melakukan 3-10 percobaan untuk setiap produk
• Lalu lintas nyata: 15-50 GB (karena pengulangan)
• Kesimpulan: tugas tidak dapat dilaksanakan — IP cepat masuk dalam larangan, CAPTCHA di setiap langkah

Jika Anda perlu mengumpulkan data sekali untuk analisis pasar atau penelitian, Anda bisa mencoba pendekatan kombinasi:

• Gunakan proxy data center untuk pengumpulan URL produk awal (halaman kategori)
• Beralih ke proxy residensial untuk mendapatkan informasi detail tentang produk
• Biaya: ~$50-100 untuk tugas sekali jalan
• Waktu penyelesaian: 2-4 jam dibandingkan 10-20 jam dengan data center

Kriteria	Residensial	Data Center
Volume Data	Apa pun — dari 100 hingga jutaan halaman	Hanya volume kecil (hingga 1000 halaman)
Frekuensi	Parsing harian/mingguan	Hanya tugas sekali jalan
Kecepatan Penyelesaian	Stabil — tanpa penundaan untuk pengulangan	Tidak terduga — banyak pengulangan
Keandalan	Tinggi — 90-95% keberhasilan	Rendah — 10-30% keberhasilan
Biaya Kesalahan	Rendah — bayar hanya untuk lalu lintas yang berhasil	Tinggi — kehilangan waktu dan uang untuk pemblokiran

1. Rotasi untuk setiap permintaan (Rotating Proxies)

Setiap permintaan HTTP dilakukan melalui alamat IP baru. Ini adalah mode operasi standar dari sebagian besar penyedia proxy residensial.

Keuntungan:

• Risiko pemblokiran minimal — setiap IP melakukan 1-2 permintaan
• Pengaturan yang sederhana — penyedia mengelola kumpulan secara otomatis
• Dapat melakukan parsing secara agresif — ratusan permintaan per menit

Kekurangan:

• Masalah dengan sesi — jika situs menggunakan cookie, setiap permintaan = sesi baru
• Lebih lambat — untuk membangun koneksi baru memerlukan waktu 200-500 ms

Kapan digunakan: Untuk parsing halaman produk Walmart, di mana tidak diperlukan otorisasi dan sesi. Ini adalah strategi optimal untuk sebagian besar tugas pemantauan harga.

2. Sticky Sessions (sesi lengket)

Satu alamat IP digunakan untuk serangkaian permintaan dalam jangka waktu tertentu (biasanya 5-30 menit), kemudian beralih ke IP baru.

Keuntungan:

• Penyimpanan sesi dan cookie — dapat bekerja dengan keranjang belanja, otorisasi
• Lebih cepat — koneksi TCP digunakan kembali
• Perilaku yang lebih "alami" untuk sistem anti-bot

Kekurangan:

• Risiko pemblokiran lebih tinggi — satu IP melakukan 10-50 permintaan
• Perlu mengontrol batas — tidak lebih dari 30-50 permintaan dari satu IP

Kapan digunakan: Jika Anda perlu mem-parsing data yang memerlukan otorisasi (misalnya, harga untuk pengguna terdaftar), atau jika Anda mensimulasikan perilaku pembeli nyata (melihat kategori → produk → menambah ke keranjang).

3. Kumpulan IP statis dengan rotasi manual

Anda mengambil 50-100 IP residensial statis (ISP proxy) dan mengelola distribusi permintaan di antara mereka sendiri.

Keuntungan:

• Kontrol penuh — Anda tahu berapa banyak permintaan yang dilakukan oleh setiap IP
• Kecepatan maksimum — IP statis lebih cepat daripada yang berputar
• Dapat "memanaskan" IP — melakukan permintaan yang sah untuk meningkatkan reputasi

Kekurangan:

• Pengaturan yang rumit — perlu menulis logika distribusi permintaan
• Lebih mahal — ISP proxy biaya $30-80 per IP per bulan
• Risiko kehilangan IP — jika satu masuk dalam larangan, harus diganti

Kapan digunakan: Untuk sistem dengan beban tinggi dengan volume 100,000+ permintaan per hari, di mana kecepatan dan stabilitas sangat penting. Membutuhkan pengalaman dalam pengembangan parser.

Untuk memantau harga (parsing halaman produk sederhana):

• Jenis: Proxy berputar dengan rotasi untuk setiap permintaan
• Penundaan antara permintaan: 2-5 detik
• Paralelisme: 10-20 thread
• Geolokasi: AS (sebaiknya negara bagian di mana ada toko fisik Walmart)

Untuk parsing yang rumit (dengan otorisasi, keranjang):

• Jenis: Sesi lengket dengan durasi 10-15 menit
• Batas permintaan per IP: maksimum 30-40
• Penundaan antara permintaan: 3-7 detik (simulasi manusia)
• Paralelisme: 5-10 thread (kurangi agresi)

1. User-Agent dan header HTTP

Pustaka standar (Python requests, Node.js axios) mengirimkan header yang segera mengungkapkan bot. Misalnya, User-Agent: python-requests/2.28.1 — ini adalah 100% pemblokiran.

Apa yang perlu diganti:

• User-Agent — gunakan versi terbaru Chrome/Firefox
• Accept — harus sesuai dengan jenis konten
• Accept-Language — en-US untuk parsing Walmart AS
• Accept-Encoding — gzip, deflate, br
• Referer — halaman sebelumnya (kategori atau utama)
• Sec-Fetch-* — header Chrome untuk perlindungan CSRF

2. TLS Fingerprint (JA3)

Setiap klien HTTP memiliki sidik jari TLS unik — urutan cipher, ekstensi TLS, versi protokol. PerimeterX membandingkan sidik jari ini dengan User-Agent: jika Anda menulis "Chrome 120", tetapi sidik jari TLS berasal dari Python — Anda akan diblokir.

Solusi:

• Gunakan pustaka yang mendukung TLS kustom: curl-impersonate (Python), tls-client (Go)
• Atau gunakan browser nyata melalui Selenium/Puppeteer — mereka memiliki sidik jari TLS yang nyata

3. Tantangan JavaScript dan fingerprinting Canvas

PerimeterX dapat mengirimkan kode JavaScript yang memeriksa: apakah Canvas API, WebGL, font yang terpasang, ukuran layar, zona waktu tersedia. Parser HTTP sederhana tidak dapat menjalankan kode ini.

Solusi:

• Gunakan browser headless: Puppeteer, Playwright, Selenium
• Pastikan untuk mengaktifkan mode bypass deteksi: puppeteer-extra-plugin-stealth
• Acak parameter: ukuran jendela, zona waktu, bahasa browser

GET /ip/Product-Name/12345678 HTTP/1.1
Host: www.walmart.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Referer: https://www.walmart.com/browse/electronics/tv-video/3944_1060825
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
Connection: keep-alive

Jenis Permintaan	Penundaan antara permintaan	Maksimum permintaan dari satu IP	Paralelisme
Halaman produk	2-5 detik	30-50 halaman (dengan rotasi)	10-20 thread
Halaman kategori	3-7 detik	20-30 halaman	5-10 thread
Pencarian	5-10 detik	10-15 permintaan	3-5 thread
API-endpoints	1-3 detik	50-100 permintaan	20-30 thread

Jika Anda membuat permintaan tepat setiap 3 detik (3.000, 6.000, 9.000...), sistem anti-bot akan mengenali pola tersebut. Manusia nyata tidak dapat seakurat itu — mereka akan memiliki variasi: 2.8 detik, 3.4 detik, 2.9 detik.

Implementasi penundaan yang benar (Python):

import random
import time

# Salah — penundaan tetap
time.sleep(3)

# Benar — penundaan yang dirandomisasi
delay = random.uniform(2.0, 5.0)  # dari 2 hingga 5 detik
time.sleep(delay)

1. Adaptive rate limiting

Lacak persentase permintaan yang berhasil. Jika mulai menerima 403 atau CAPTCHA — secara otomatis tingkatkan penundaan dan kurangi paralelisme.

success_rate = successful_requests / total_requests

if success_rate < 0.8:  # kurang dari 80% berhasil
    delay_multiplier *= 1.5  # tingkatkan penundaan
    parallel_workers -= 2    # kurangi thread
elif success_rate > 0.95:  # lebih dari 95% berhasil
    delay_multiplier *= 0.9  # bisa mempercepat
    parallel_workers += 1

2. Distribusi berdasarkan waktu dalam sehari

Lakukan parsing pada jam-jam puncak aktivitas pengguna nyata (malam di AS, 18:00-22:00 EST). Pada waktu ini, lalu lintas Anda bercampur dengan yang sah, dan sistem anti-bot kurang agresif. Di malam hari (2:00-6:00 EST) perlindungan bisa lebih ketat, karena lebih sedikit pengguna nyata.

3. Memanaskan alamat IP

Sebelum memulai parsing massal, "panaskan" alamat IP dengan permintaan yang sah: buka halaman utama, beberapa kategori, lakukan pencarian. Ini menciptakan riwayat aktivitas dan meningkatkan skor kepercayaan IP.

# Urutan pemanasan untuk IP baru
1. GET https://www.walmart.com/  # halaman utama
2. Penundaan 3-5 detik
3. GET https://www.walmart.com/browse/electronics  # kategori
4. Penundaan 4-7 detik
5. GET https://www.walmart.com/search?q=laptop  # pencarian
6. Penundaan 3-6 detik
# Sekarang bisa mem-parsing produk target