Apa Itu DataDome? Bagaimana Cara Kerja Deteksi Bot dan Mengapa Scraper Diblokir

Scraper berfungsi dengan sempurna saat pengujian.

Kemudian, saat Anda mengarahkannya ke situs web asli, Anda mendapatkan:

403 Forbidden.

Atau CAPTCHA.

Atau halaman tersebut dimuat di Chrome tetapi menampilkan hasil yang sama sekali berbeda dari skrip Anda.

Anda mengganti alamat IP. Alat tersebut berfungsi untuk beberapa permintaan, lalu diblokir lagi.

Inilah jenis masalah yang dirancang DataDome untuk dihadapi oleh lalu lintas otomatis.

Hal penting yang perlu dipahami adalah bahwa DataDome tidak sekadar bertanya:

"Apakah IP ini mencurigakan?"

Deteksi bot modern jauh lebih mirip dengan:

"Apakah alamat IP, koneksi jaringan, peramban, perangkat, pola permintaan, dan sesi ini semuanya masuk akal jika digabungkan?"

Perbedaan tersebut menjelaskan mengapa mengganti proxy terkadang membantu, mengapa sering kali tidak, dan mengapa scraper yang terlihat sempurna normal di tingkat HTTP tetap bisa gagal.

Panduan ini menjelaskan cara kerja DataDome, sinyal apa saja yang dapat digunakannya, seperti apa bentuk pemblokiran DataDome, mengapa browser dan skrip berperilaku berbeda, serta di mana proxy, otomatisasi browser, dan API pengikisan data berperan dalam konteks ini.

Apa Itu DataDome?

DataDome adalah platform perlindungan terhadap bot dan penipuan daring yang digunakan oleh situs web, aplikasi seluler, dan API untuk membedakan pengguna yang sah dari lalu lintas otomatis atau berbahaya.

Pemilik situs web menggunakan sistem seperti DataDome untuk mengurangi aktivitas seperti:

• pengambilan data tanpa izin (scraping);
• serangan credential stuffing;
• upaya pengambilalihan akun;
• pembuatan akun palsu;
• penyalahgunaan inventaris;
• penipuan pembayaran;
• pemindaian kerentanan otomatis;
• bot agresif;
• agen AI yang tidak diinginkan.

Bagi seseorang yang mengumpulkan data web publik, DataDome berada di sisi lain dari persamaan ini.

Permintaan Anda mencapai situs web yang dilindungi, tetapi sebelum aplikasi memutuskan konten apa yang akan dikembalikan, DataDome dapat mengevaluasi permintaan tersebut dan menentukan apakah permintaan tersebut tampak sah, mencurigakan, atau otomatis.

Hasilnya bisa berupa:

Izinkan

Permintaan berlanjut seperti biasa.

Pemeriksaan Perangkat

Dilakukan verifikasi tambahan terhadap browser/perangkat.

CAPTCHA

Klien menerima tantangan interaktif.

Blokir

Permintaan ditolak.

Itulah sebabnya dua permintaan untuk URL yang persis sama dapat menghasilkan respons yang sama sekali berbeda.

URL-nya tidak berubah.

Klienlah yang berubah.

Cara Kerja DataDome

Model sederhana yang berguna terlihat seperti ini:

Klien → situs web yang dilindungi/DataDome → keputusan deteksi → situs web

Tahap deteksi adalah tempat terjadinya sebagian besar masalah scraper.

DataDome dapat mengevaluasi sinyal dari berbagai lapisan koneksi, bukan hanya mengandalkan satu indikator sederhana.

Lapisan-lapisan tersebut antara lain:

Lapisan	Contoh sinyal
Jaringan	Alamat IP, ASN, reputasi jaringan
TLS	Sidik jari TLS dan karakteristik koneksi
HTTP	Header, konsistensi header, properti permintaan
Browser	Sidik jari browser dan lingkungan
Perangkat	OS, perangkat keras, dan sinyal eksekusi
JavaScript	Hasil pemeriksaan sisi klien
Sesi	Cookie dan kesinambungan antar-permintaan
Perilaku	Waktu dan pola interaksi
Reputasi	Aktivitas sebelumnya yang terkait dengan infrastruktur

Tidak ada satu baris pun yang secara mutlak membuktikan bahwa suatu permintaan bersifat otomatis.

Nilainya terletak pada perbandingan antara semua lapisan tersebut.

Alamat IP perumahan dengan sidik jari browser yang tidak masuk akal tetap bisa terlihat mencurigakan.

User-Agent yang tampak sempurna namun berasal dari klien TLS yang tidak konsisten tetap bisa terlihat mencurigakan.

Browser asli yang menghasilkan ratusan permintaan yang sangat berulang tetap bisa terlihat mencurigakan.

Itulah perbedaan mendasar antara sistem anti-bot modern dan sistem pemblokiran IP lama.

Deteksi DataDome: Lapisan Utama

1. Reputasi IP

Reputasi IP tetap penting.

Sebuah alamat IP mungkin memiliki riwayat.

Misalnya, suatu infrastruktur dapat memperoleh reputasi buruk jika lalu lintas yang bersifat menyalahi aturan atau jelas-jelas otomatis dalam jumlah besar berasal darinya.

DataDome dapat mempertimbangkan apakah lalu lintas berasal dari:

• infrastruktur hosting yang dikenal;
• rentang alamat pusat data;
• proxy bersama;
• proxy perumahan;
• jaringan proxy publik gratis;
• alamat yang sebelumnya dicurigai.

Namun, reputasi IP hanyalah salah satu indikator.

Inilah mengapa pernyataan seperti:

"Gunakan proxy residensial dan DataDome tidak akan dapat mendeteksi Anda."

menyesatkan.

Alamat residensial dapat membuat permintaan jaringan tampak lebih mirip lalu lintas konsumen biasa.

Namun, hal itu tidak dapat secara otomatis membuat bagian lain dari permintaan tersebut menjadi konsisten.

2. Header HTTP

Browser mengirimkan kumpulan header yang dapat dikenali.

Alat otomatisasi juga mengirimkan header.

Hal yang menarik bukanlah sekadar apakah suatu permintaan berisi User-Agent

.

Melainkan apakah permintaan tersebut masuk akal secara keseluruhan.

Misalnya, bayangkan sebuah klien yang mengaku sebagai versi Chrome terbaru, namun mengirimkan kumpulan header yang biasanya tidak sesuai dengan browser tersebut.

Secara individual, setiap nilai mungkin tampak masuk akal.

Namun, jika digabungkan, mungkin tidak.

Deteksi bot modern dapat mencari ketidakkonsistenan semacam ini.

Hanya mengubah:

User-Agent: Mozilla/5.0...

tidak akan mengubah pustaka HTTP sederhana menjadi Chrome.

3. Sidik Jari TLS

Sebelum data HTTP dipertukarkan melalui HTTPS, klien membuat koneksi TLS.

Klien yang berbeda dapat menghasilkan karakteristik TLS yang berbeda pula.

Sebuah browser, pustaka HTTP Python, klien baris perintah, dan runtime lainnya mungkin membangun koneksi terenkripsi dengan cara yang berbeda.

Pola-pola tersebut dapat dirangkum menjadi sidik jari.

Dokumentasi DataDome secara khusus merujuk pada sidik jari TLS, termasuk informasi JA3 dan JA4, sebagai bagian dari data yang dapat digunakan saat mengevaluasi lalu lintas.

Hal ini menimbulkan masalah penting bagi pengaturan scraping yang sederhana.

Header HTTP Anda mungkin menyatakan:

Chrome di Windows

padahal koneksi jaringan di baliknya sama sekali tidak mirip dengan versi Chrome yang Anda klaim sedang digunakan.

Mengubah header HTTP tidak secara otomatis mengubah tumpukan TLS di baliknya.

Inilah salah satu alasan mengapa spoofing berbasis HTTP saja pada akhirnya menemui batasannya.

4. Sidik Jari Browser

Begitu JavaScript dapat dijalankan, sistem deteksi anti-bot memiliki akses ke lingkungan yang jauh lebih kaya.

Browser asli memaparkan sejumlah besar informasi tentang dirinya sendiri dan perangkat yang menjalankannya.

Sinyal-sinyal potensial mencakup karakteristik yang berkaitan dengan:

• versi browser;
• sistem operasi;
• perangkat keras;
• CPU;
• memori;
• lingkungan grafis;
• API browser yang didukung;
• perilaku rendering;
• dukungan fitur;
• artefak otomatisasi.

Bagian yang sulit dalam otomatisasi bukanlah menghasilkan satu nilai yang meyakinkan.

Melainkan menghasilkan ratusan nilai yang saling konsisten.

Misalkan sebuah browser otomatis mengklaim berjalan pada satu sistem operasi, tetapi bagian lain dari lingkungannya berperilaku seperti sistem operasi lain.

Atau karakteristik perangkat keras yang dilaporkan tidak sesuai dengan perangkat yang diklaim.

Atau otomatisasi memodifikasi properti sidik jari umum tetapi membiarkan sinyal sekunder tetap tidak berubah.

Browser tersebut mungkin terlihat meyakinkan jika Anda memeriksa lima properti yang jelas.

Sistem deteksi tidak harus berhenti pada lima properti tersebut.

5. Mendeteksi Browser Headless dan Otomatis

Playwright, Puppeteer, dan Selenium sangat berguna.

Namun, mereka juga tidak tak terlihat.

Menjalankan Chromium memberi scraper Anda mesin browser yang sesungguhnya, yang memecahkan banyak masalah yang tidak dapat diatasi oleh klien HTTP dasar:

• eksekusi JavaScript;
• rendering;
• cookie;
• API browser;
• konten dinamis;
• status navigasi.

Namun, “mesin browser yang sesungguhnya” tidak berarti “tidak dapat dibedakan dari pengguna biasa.”

Kerangka kerja otomatisasi dapat menimbulkan perbedaan yang dapat diamati.

Dokumentasi deteksi DataDome sendiri secara eksplisit mencantumkan kategori deteksi untuk browser otomatis dan headless, termasuk browser yang dijalankan oleh Puppeteer, Selenium, dan Playwright.

Artinya, arsitektur sederhana ini:

Playwright + proxy

tidak boleh dianggap sebagai solusi anti-bot universal.

Arsitektur ini mungkin berfungsi sempurna di satu situs web, tetapi gagal dengan cepat di situs web lain.

6. JavaScript dan Device Check

DataDome juga dapat meminta verifikasi tambahan dari klien.

Salah satu mekanismenya adalah Device Check.

Alih-alih langsung menampilkan CAPTCHA yang terlihat, JavaScript dijalankan di dalam browser dan mengevaluasi lingkungan.

Menurut DataDome, Device Check-nya mengumpulkan ratusan sinyal dan melakukan berbagai pemeriksaan yang bertujuan untuk mendeteksi kerangka kerja otomatisasi, lingkungan palsu, dan akses terprogram.

Bagi pengunjung asli, hal ini mungkin terjadi tanpa gangguan yang jelas.

Bagi scraper, hal ini menciptakan perbedaan penting antara:

klien HTTP

dan:

browser yang mampu menjalankan logika sisi klien yang diharapkan

Jika scraper Anda hanya mengunduh HTML awal dan mengabaikan segala sesuatu yang terjadi di browser, scraper tersebut mungkin tidak akan pernah dapat mereproduksi interaksi lengkap yang diharapkan oleh situs yang dilindungi.

7. Deteksi Perilaku

Sebuah browser yang secara teknis meyakinkan tetap bisa berperilaku aneh.

Pertimbangkan dua sesi.

Sesi A

Seorang pengguna:

• membuka halaman produk;
• menghabiskan 14 detik untuk membaca;
• membuka halaman lain;
• menggulir;
• kembali;
• melakukan pencarian;
• membuka hasil pencarian.

Sesi B

Sebuah crawler:

• meminta produk 1;
• 300 ms kemudian meminta produk 2;
• 300 ms kemudian meminta produk 3;
• mengulangi hal ini ratusan kali.

Kedua sesi tersebut dapat menggunakan Chrome.

Keduanya dapat menggunakan alamat IP perumahan.

Perilaku keduanya jelas berbeda.

Deteksi perilaku memungkinkan sistem anti-bot untuk mempertimbangkan pola daripada permintaan individu.

Hal ini sangat penting terutama pada skala besar.

Sebuah scraper yang berhasil sekali tidak selalu berarti scraper tersebut dapat menangani 100.000 permintaan.

8. Konsistensi Sesi

Situs web modern bersifat stateful.

Cookie, status browser, alamat IP, dan riwayat permintaan semuanya merupakan bagian dari sebuah sesi.

Otomatisasi menjadi lebih mudah dideteksi ketika elemen-elemen tersebut saling bertentangan.

Contohnya:

• alamat IP terus berubah sementara cookie sesi yang sama tetap ada;
• identitas browser berubah di tengah-tengah sesi;
• navigasi tiba-tiba melompat ke sumber daya yang tidak terkait;
• cookie yang diharapkan dari langkah sebelumnya tidak pernah muncul;
• setiap permintaan berperilaku seperti pengunjung baru.

Inilah mengapa memutar alamat IP secara membabi buta untuk setiap permintaan terkadang justru membuat scraper kurang meyakinkan, bukan lebih meyakinkan.

Rotasi berguna.

Kontinuitas berguna.

Pilihan yang tepat bergantung pada beban kerja.

Seperti Apa Bentuk Pemblokiran DataDome?

DataDome tidak harus merespons setiap permintaan yang mencurigakan dengan cara yang sama.

Ada beberapa hasil yang mungkin Anda temui.

Respons 403

Tanda yang paling jelas adalah respons HTTP 403 Forbidden.

Namun, jangan berasumsi bahwa setiap kode 403 di internet berasal dari DataDome.

Selalu periksa respons yang sebenarnya.

Halaman CAPTCHA

Alih-alih halaman tujuan, respons mungkin berisi tantangan dari DataDome.

Pemeriksaan Perangkat

Browser mungkin melakukan verifikasi yang tidak terlihat sebelum akses dilanjutkan.

Hal ini sangat membingungkan saat melakukan debugging karena halaman tersebut pada akhirnya mungkin berfungsi di browser biasa Anda tanpa Anda pernah melihat CAPTCHA.

Halaman pemblokiran

Lalu lintas yang dianggap cukup mencurigakan dapat menerima respons pemblokiran langsung.

Perilaku berbeda di Chrome dan scraper Anda

Ini adalah salah satu petunjuk terkuat bahwa masalahnya bukan pada URL itu sendiri.

Jika:

Chrome → konten

tetapi:

permintaan/cURL/skrip khusus → tantangan

perbedaan tersebut kemungkinan terletak pada klien, identitas jaringan, eksekusi peramban, atau sesi.

Mengapa Mengubah Alamat IP Saja Tidak Cukup

Proxy mengubah bagian penting dari permintaan:

dari mana lalu lintas tersebut tampak berasal.

Hal itu sangat berharga.

Namun, hal itu tidak secara otomatis mengubah:

• implementasi HTTP Anda;
• sidik jari TLS;
• lingkungan peramban;
• eksekusi JavaScript;
• sidik jari browser;
• cookie;
• waktu permintaan;
• perilaku navigasi;
• logika sesi.

Pertimbangkan seluruh tumpukan (full stack):

**IP

• TLS
• HTTP
• browser
• perangkat
• sesi
• perilaku**

Proksi terutama mengubah lapisan pertama.

Hal itu bisa cukup jika reputasi IP menjadi alasan kegagalan permintaan.

Namun, hal itu tidak cukup jika beberapa lapisan tidak selaras.

Proksi Pusat Data vs Proksi Perumahan dengan DataDome

Tidak ada "proksi DataDome" yang universal.

Jenis proxy yang berbeda memecahkan masalah jaringan yang berbeda pula.

Proksi pusat data

IP pusat data cepat, murah, dan sangat berguna untuk banyak beban kerja otomatisasi.

Kelemahannya pada situs web konsumen yang sangat terlindungi adalah bahwa asal jaringan mereka lebih mudah diklasifikasikan sebagai infrastruktur hosting.

Ini tidak berarti setiap permintaan dari pusat data akan diblokir.

Artinya, alamat IP itu sendiri mungkin memberikan bukti yang lebih sedikit bahwa klien tersebut menyerupai konsumen biasa.

Proksi perumahan

Proksi perumahan merutekan permintaan melalui alamat IP yang terkait dengan koneksi internet konsumen.

Hal ini dapat memberikan profil jaringan yang lebih sesuai untuk beban kerja yang melibatkan situs web publik yang ditujukan kepada konsumen.

Namun, alamat IP perumahan tidak sama dengan pengguna manusia.

DataDome secara eksplisit mendokumentasikan model yang mampu mengidentifikasi lalu lintas otomatis yang dialihkan melalui proksi perumahan.

Oleh karena itu, cara yang berguna untuk memandang proksi perumahan adalah:

identitas jaringan yang lebih baik

bukan:

pengelakan otomatis perlindungan bot

Proksi ISP

Proksi ISP dapat menawarkan sesi yang stabil sambil menggunakan ruang IP yang terkait dengan ISP konsumen.

Untuk alur kerja yang memerlukan identitas konsisten selama sesi yang lebih lama, stabilitas tersebut dapat menjadi nilai tambah.

Sekali lagi, bagian klien lainnya tetap penting.

Mengapa Rotasi Proksi yang Terus-Menerus Dapat Berakibat Buruk

"Lakukan rotasi lebih sering" terdengar seperti saran yang jelas.

Namun, hal itu tidak selalu benar.

Bayangkan sebuah sesi situs web yang berlangsung selama lima menit.

Pengguna asli biasanya akan mempertahankan identitas jaringan yang sama selama sebagian besar sesi tersebut.

Jika otomatisasi Anda mengubah negara atau jaringan setiap tiga permintaan sambil mempertahankan cookie dan sesi akun yang sama, kombinasi tersebut bisa terkesan tidak wajar.

Untuk beberapa beban kerja, rotasi sesi memang tepat.

Untuk yang lain, sesi yang tetap (sticky sessions) menghasilkan perilaku yang lebih konsisten.

Strategi proxy harus sesuai dengan struktur aplikasi yang Anda akses.

Bagaimana dengan Alat Pemecah CAPTCHA?

CAPTCHA tidak selalu menjadi langkah awal dalam proses pengambilan keputusan DataDome.

CAPTCHA bisa jadi merupakan salah satu respons setelah deteksi lain telah menandai sesi tersebut sebagai mencurigakan.

Perbedaan ini penting.

Memecahkan CAPTCHA tidak secara otomatis memperbaiki:

• sidik jari browser yang mencurigakan;
• tumpukan TLS yang tidak konsisten;
• reputasi IP yang buruk;
• perilaku sesi yang tidak wajar.

DataDome telah secara terbuka membahas deteksi CAPTCHA farm dan lingkungan otomatis bahkan setelah tantangan tersebut berhasil diselesaikan.

Jadi, menganggap penyelesaian CAPTCHA sebagai satu-satunya masalah berarti mengabaikan sistem yang lebih besar di sekitarnya.

Mengapa Sebuah Scraper Bisa Berfungsi Hari Ini dan Gagal Besok

Ini adalah sumber kebingungan umum lainnya.

Tidak ada yang berubah dalam kode Anda.

Tiba-tiba, tingkat keberhasilan menurun.

Hal itu tidak selalu berarti situs target telah merancang ulang situs webnya.

Sistem manajemen bot terus-menerus mengubah logika deteksinya.

Variabel lain juga berubah:

• reputasi IP terus berkembang;
• versi browser diperbarui;
• kebijakan situs web berubah;
• volume lalu lintas meningkat;
• pola permintaan Anda berubah;
• target mengaktifkan perlindungan yang lebih ketat untuk titik akhir tertentu.

Oleh karena itu, melakukan scraping terhadap sistem anti-bot modern merupakan masalah operasional, bukan masalah konfigurasi satu kali.

DataDome dan Playwright

Playwright berguna ketika sebuah situs web memerlukan eksekusi browser yang sesungguhnya.

Playwright dapat memuat JavaScript, berinteraksi dengan halaman, dan mempertahankan status browser.

Hal ini membuatnya jauh lebih mumpuni daripada pustaka permintaan HTTP sederhana untuk situs web modern.

Namun, Playwright tidak secara otomatis membuat lalu lintas tampak seperti perilaku manusia.

Situs yang dilindungi mungkin masih mengevaluasi:

• karakteristik browser;
• artefak otomatisasi;
• identitas jaringan;
• sesi;
• frekuensi permintaan;
• perilaku.

Inilah mengapa scraper Playwright bisa berhasil pada tahap pengembangan namun menjadi tidak dapat diandalkan saat diterapkan dalam skala besar.

Otomatisasi browser memecahkan masalah eksekusi browser.

Namun, hal ini tidak menyelesaikan setiap lapisan anti-bot di sekitar browser.

DataDome dan Puppeteer

Prinsip yang sama berlaku untuk Puppeteer.

Penggunaan Chromium memberikan lingkungan klien yang jauh lebih kaya bagi crawler dibandingkan dengan HTTP mentah.

Hal ini berguna untuk:

• aplikasi yang dirender di sisi klien;
• halaman dinamis;
• navigasi JavaScript;
• konten yang dimuat setelah HTML awal;
• aplikasi yang memerlukan cookie atau status browser.

Namun, browser, alamat IP, dan perilaku tetap harus membentuk sesi yang koheren.

Puppeteer adalah kerangka kerja otomatisasi browser.

Ini bukanlah lapisan penyamaran.

Stack Scraping yang Sebenarnya Penting

Daripada bertanya:

"Proxy mana yang bisa melewati DataDome?"

akan lebih bermanfaat jika kita memikirkannya berdasarkan lapisan.

Masalah	Lapisan yang relevan
Reputasi IP buruk	Proxy/jaringan
Lokasi salah	Proxy bertarget geografis
Diperlukan JavaScript	Browser/rendering
Konten dinamis	Browser/rendering
Ketidakkonsistenan TLS	Tumpukan HTTP/browser
Ketidaksesuaian sidik jari browser	Lingkungan browser
Ketidakstabilan sesi	Manajemen cookie/sesi
Pola permintaan yang berlebihan	Arsitektur perayapan
CAPTCHA/tantangan	Penanganan tantangan
Pemeliharaan anti-bot yang terus-menerus	Infrastruktur perayapan yang dikelola

Hal ini membuat proses pemecahan masalah menjadi jauh lebih cepat.

Anda tidak perlu lagi mencoba menyelesaikan setiap masalah dengan mengganti proxy.

Tiga Cara Mengumpulkan Data dari Situs yang Dilindungi DataDome

Untuk pengumpulan data yang sah, di mana Anda diizinkan mengakses situs target, secara umum terdapat tiga arsitektur.

1. Membuat scraper sendiri

Anda mengendalikan semuanya:

• klien HTTP;
• peramban;
• proxy;
• sesi;
• logika percobaan ulang;
• penguraian;
• penampilan;
• pemantauan.

Keuntungan:

Kontrol maksimal.

Kekurangan:

Pemeliharaan maksimal.

Pendekatan ini masuk akal jika alur kerja Anda cukup unik sehingga membenarkan kepemilikan seluruh tumpukan teknologi.

2. Gunakan proxy dengan browser atau scraper Anda sendiri

Arsitektur:

scraper Anda → jaringan proxy → target

Hal ini memungkinkan Anda tetap mengendalikan aplikasi sambil mengalihdayakan infrastruktur jaringan.

Ini berguna jika masalah utama Anda meliputi:

• reputasi IP;
• penargetan geografis;
• konkurensi;
• rotasi jaringan;
• sesi yang stabil.

Proksi Residensial Geonode, misalnya, mendukung penargetan geografis serta konfigurasi sesi rotasi dan sesi tetap.

Namun, aplikasi Anda tetap bertanggung jawab atas segala hal di atas lapisan proksi.

3. Gunakan API Pengikis

Arsitektur:

aplikasi Anda → API pengikisan → target

Alih-alih mengelola browser, pemilihan proxy, dan infrastruktur ekstraksi sendiri, Anda mengirimkan URL ke layanan yang dirancang untuk pengumpulan data web.

Pendekatan ini sering kali lebih sesuai ketika kebutuhan sebenarnya adalah:

"Berikan saya konten halaman."

bukan:

"Saya ingin mengelola tim infrastruktur anti-bot/browser."

Scraper API dari Geonode, misalnya, dapat mengembalikan konten halaman yang telah dirender dalam format HTML atau Markdown serta menyediakan rendering JavaScript, infrastruktur proxy yang dikelola, penargetan geografis, pemrosesan batch, dan crawling.

Perbedaan pentingnya terletak pada kepemilikan kompleksitas.

Dengan proxy:

Anda mengendalikan seluruh tumpukan (stack).

Dengan API pengikisan:

platform pengikisan mengelola lebih banyak bagian dari tumpukan tersebut.

Tidak ada model yang secara universal lebih baik.

Keduanya memecahkan masalah teknik yang berbeda.

Proxy vs Browser vs API Penggoresan

Solusi	Mengganti IP	Menjalankan JS	Mengelola browser	Mengelola ekstraksi	Perawatan oleh Anda
Hanya proxy	Ya	Tidak	Tidak	Tidak	Tinggi
Playwright + proxy	Ya	Ya	Anda	Anda	Tinggi
Puppeteer + proxy	Ya	Ya	Anda	Anda	Tinggi
API Pengikisan	Dikelola	Ya, jika didukung	Dikelola	Dikelola	Lebih rendah

Inilah mengapa menyarankan seseorang untuk "cukup menggunakan proxy residensial" adalah saran yang tidak lengkap.

Terkadang itulah yang sebenarnya mereka butuhkan.

Terkadang, proxy hanyalah salah satu bagian dari masalah yang jauh lebih besar.

Cara Memecahkan Masalah pada Blok DataDome

Saat permintaan mulai gagal, jangan mengubah sepuluh hal sekaligus.

Lakukan diagnosis pada lapisan tersebut.

Masalah: Berfungsi di browser, gagal di skrip

Area yang mungkin perlu diselidiki:

• Eksekusi JavaScript;
• Perbedaan klien HTTP/TLS;
• sidik jari browser;
• cookie;
• status sesi.

Mengubah alamat IP mungkin tidak berpengaruh jika kegagalan berasal dari klien.

Masalah: Awalnya berfungsi, kemudian diblokir

Periksa:

• laju permintaan;
• pola navigasi berulang;
• rotasi IP/sesi;
• masalah reputasi IP yang semakin parah;
• konsistensi sesi.

Permintaan pertama dan permintaan ke-seribu tidaklah sama.

Masalah: IP pusat data gagal, IP perumahan berfungsi

Reputasi jaringan kemungkinan besar menjadi faktor penting dalam pengambilan keputusan.

Hal itu tetap tidak membuktikan bahwa sinyal-sinyal lain diabaikan.

Masalah: Proksi perumahan juga gagal

Jangan langsung menyimpulkan bahwa proksi perumahan tersebut buruk.

Selidiki:

• sidik jari browser/klien;
• karakteristik TLS;
• persyaratan JavaScript;
• cookie;
• pola permintaan;
• desain sesi.

Masalah: CAPTCHA muncul berulang kali

Lingkaran CAPTCHA dapat menandakan bahwa sesi secara keseluruhan tetap terlihat mencurigakan.

Anggap tantangan tersebut sebagai gejala, bukan penyebab utamanya.

Masalah: Hasil berbeda di negara yang berbeda

Periksa apakah:

• situs itu sendiri berperilaku berbeda berdasarkan lokasi geografis;
• ketersediaan konten berubah;
• status cookie tetap konsisten;
• geolokasi IP sesuai dengan sesi yang dimaksud.

Apakah DataDome Mendeteksi Proksi Perumahan?

Bisa.

Hal ini secara eksplisit tercantum dalam dokumentasi deteksi DataDome.

Namun, itu tidak berarti setiap permintaan proksi perumahan diblokir.

Jika demikian, pengguna sah yang terhubung melalui jaringan konsumen bersama akan menimbulkan masalah false-positive yang sangat besar.

Pernyataan yang lebih akurat adalah:

Alamat IP perumahan hanyalah salah satu indikator, bukan bukti bahwa pengunjung tersebut adalah manusia.

Sistem deteksi modern menggabungkannya dengan bukti-bukti lain.

Apakah DataDome Mendeteksi Playwright?

DataDome mendokumentasikan model deteksi yang mencakup browser yang diintegrasikan melalui kerangka kerja otomatisasi, termasuk Playwright, Puppeteer, dan Selenium.

Hal itu tidak berarti setiap sesi Playwright secara otomatis diblokir.

Artinya, asumsi:

"Playwright menggunakan browser asli, sehingga tidak dapat dideteksi"

adalah salah.

Apakah DataDome Menggunakan Fingerprinting Browser?

Ya.

Fingerprinting browser dan perangkat merupakan bagian dari arsitektur deteksi DataDome.

Hal ini memungkinkan sistem membandingkan informasi yang diekspos oleh browser dan lingkungan eksekusi, alih-alih hanya mengandalkan pengenal sederhana seperti header User-Agent.

Apakah DataDome Menggunakan Fingerprinting TLS?

Dokumentasi DataDome merujuk pada sidik jari TLS dan merekomendasikan sidik jari JA3 dan JA4 sebagai sinyal yang tersedia untuk integrasi API perlindungan mereka.

Hal ini penting karena koneksi TLS dibuat sebelum logika aplikasi web biasa melihat permintaan tersebut.

Oleh karena itu, sebuah scraper dapat memiliki header HTTP yang diedit dengan sempurna namun tetap mengekspos sidik jari jaringan tingkat rendah yang berbeda.

Apakah DataDome Menggunakan Pembelajaran Mesin?

DataDome menggambarkan model deteksi ancamannya sebagai berbasis pembelajaran mesin dan terus diperbarui.

Pembelajaran mesin bukanlah sihir.

Nilai praktisnya di sini adalah kemampuan untuk menggabungkan banyak sinyal dan pola, alih-alih mengandalkan satu aturan statis seperti:

blokir IP setelah 100 permintaan.

Apakah DataDome Dapat Memblokir Agen AI?

Ya.

Pasar manajemen bot semakin meluas melampaui scraper tradisional ke arah agen AI dan crawler LLM.

DataDome kini secara eksplisit mendukung identifikasi dan otentikasi bot komersial serta agen AI, sementara lalu lintas otomatis yang tidak terotentikasi dapat dikenakan kebijakan deteksi ancaman yang dimilikinya.

Hal ini kemungkinan akan menjadi semakin penting seiring dengan semakin banyaknya sistem AI yang menjelajahi dan berinteraksi langsung dengan situs web.

Bisakah Anda Mengelabui DataDome?

Ini biasanya bukanlah pertanyaan teknis yang tepat.

Tidak ada header, jenis proxy, atau flag browser permanen yang dapat membuat sistem deteksi modern tidak berfungsi.

Konfigurasi yang berhasil untuk satu endpoint pada volume lalu lintas tertentu mungkin akan gagal:

• pada endpoint lain;
• pada skala yang lebih besar;
• dengan versi browser lain;
• setelah model deteksi berubah.

Untuk beban kerja data web yang sah, pertanyaan yang lebih berkelanjutan adalah:

Bagian mana dari tumpukan scraping saya yang menyebabkan permintaan diklasifikasikan sebagai otomatisasi, dan apakah saya ingin mengelola lapisan tersebut sendiri?

Terkadang jawabannya adalah infrastruktur jaringan.

Gunakan pengaturan proxy yang sesuai.

Terkadang jawabannya adalah proses rendering.

Gunakan browser.

Terkadang jawabannya adalah seluruh tumpukan operasional.

Gunakan API pengikisan yang dikelola.

Dan terkadang jawaban yang tepat adalah menggunakan API resmi atau sumber data resmi lainnya sebagai gantinya.

DataDome vs Cloudflare

DataDome dan Cloudflare memang memiliki tumpang tindih di beberapa segmen pasar manajemen bot, namun keduanya tidak boleh dianggap sebagai produk yang identik.

Cloudflare menawarkan platform infrastruktur yang luas, yang mencakup CDN, DNS, WAF, mitigasi DDoS, dan kemampuan manajemen bot.

DataDome lebih berfokus secara spesifik pada deteksi bot dan penipuan online di situs web, aplikasi seluler, dan API.

Namun, dari sudut pandang pengembang scraper, pelajarannya serupa:

perlindungan anti-bot modern beroperasi di berbagai lapisan.

Strategi yang efektif tidak dapat hanya mengandalkan perubahan pada satu header HTTP saja.

DataDome vs CAPTCHA

DataDome bukanlah layanan CAPTCHA.

CAPTCHA hanyalah salah satu respons yang mungkin setelah deteksi.

Sistem yang sebenarnya menentukan apakah seorang klien mencurigakan berada di tahap sebelumnya.

Perbedaan ini penting karena pengembang sering kali menghabiskan banyak usaha untuk mencoba "memecahkan CAPTCHA" sambil mengabaikan sinyal-sinyal yang menyebabkan tantangan tersebut muncul.

Pertanyaan yang lebih tepat adalah:

Mengapa sesi ini ditantang sejak awal?

Kapan Proksi Residensial Cocok Digunakan

Proksi residensial berguna ketika lapisan jaringan menjadi faktor penting.

Contohnya meliputi beban kerja yang sah yang melibatkan:

• konten publik yang spesifik secara geografis;
• hasil pencarian yang disesuaikan dengan lokasi;
• penetapan harga regional;
• ketersediaan produk;
• riset pasar;
• pengumpulan data web terdistribusi.

Proksi ini sangat berguna ketika Anda ingin mempertahankan kendali penuh atas scraper Anda sendiri.

Proksi Residensial Geonode menyediakan perutean IP residensial dengan penargetan geografis dan perilaku sesi yang dapat dikonfigurasi.

Namun, proksi harus tetap menjadi apa adanya:

infrastruktur jaringan.

Ini bukan browser.

Ini bukan sistem CAPTCHA.

Ini bukan mesin pengikis data.

Dan ini tidak secara otomatis memperbaiki sidik jari yang rusak.

Kapan Layanan Pengelolaan API (Scraper API) Lebih Masuk Akal

Layanan Pengelolaan API (Scraper API) menjadi pilihan menarik ketika pemeliharaan anti-bot mulai mendominasi pengembangan.

Anda setidaknya harus mempertimbangkan API terkelola (managed API) ketika tim Anda menghabiskan lebih banyak waktu untuk:

• pembaruan peramban;
• logika percobaan ulang;
• orkestrasi proxy;
• rendering;
• ekstraksi;
• penanganan sesi;
• permintaan yang gagal;

daripada waktu yang dihabiskan untuk menggunakan data itu sendiri.

Dengan Geonode Scraper API, sebuah aplikasi dapat mengirimkan URL dan menerima HTML atau Markdown yang telah diekstraksi, sementara layanan tersebut mengelola rendering dan infrastruktur proxy di balik permintaan tersebut.

Pertimbangannya cukup jelas:

Membuatnya sendiri memberikan kontrol yang lebih besar.

Menggunakan API menghilangkan pekerjaan terkait infrastruktur.

Pilihlah berdasarkan apa yang sebenarnya dibutuhkan oleh produk Anda.

Pertanyaan yang Sering Diajukan

Apa itu DataDome?

DataDome adalah platform perlindungan terhadap bot dan penipuan daring yang dirancang untuk mengidentifikasi lalu lintas otomatis dan berbahaya di situs web, aplikasi seluler, dan API.

Bagaimana DataDome mendeteksi bot?

DataDome menggabungkan berbagai sinyal, termasuk reputasi IP, sidik jari HTTP dan browser, karakteristik TLS, informasi perangkat, pola perilaku, serta model deteksi berbasis pembelajaran mesin.

Mengapa DataDome memblokir scraper saya?

Jarang ada satu alasan tunggal yang berlaku secara universal. Alamat IP, klien HTTP/TLS, lingkungan peramban, dukungan JavaScript, konsistensi sesi, atau perilaku permintaan semuanya dapat menjadi faktor penyebab.

Apakah DataDome menggunakan CAPTCHA?

Ya, CAPTCHA dapat menjadi salah satu respons terhadap lalu lintas yang mencurigakan. DataDome juga dapat melakukan Pemeriksaan Perangkat (Device Check) yang tidak terlihat atau langsung memblokir permintaan.

Apa itu Pemeriksaan Perangkat DataDome?

Pemeriksaan Perangkat adalah mekanisme verifikasi tambahan yang menjalankan pemeriksaan di sisi klien tanpa harus melibatkan interaksi pengguna yang terlihat. Mekanisme ini mengevaluasi sinyal perangkat dan eksekusi, serta dapat mengizinkan, menantang, atau memblokir klien tergantung pada hasilnya.

Apakah mengubah User-Agent dapat melewati DataDome?

Mengubah User-Agent hanya memodifikasi satu nilai HTTP. Hal ini tidak secara otomatis mengubah koneksi TLS, lingkungan browser, sidik jari perangkat, cookie, atau perilaku.

Dapatkah DataDome mendeteksi Chrome headless?

DataDome secara khusus mendokumentasikan kategori deteksi untuk browser headless dan otomatis, termasuk browser yang diotomatisasi melalui Puppeteer, Selenium, dan Playwright.

Apakah DataDome dapat mendeteksi Playwright?

DataDome dapat mengidentifikasi karakteristik yang terkait dengan otomatisasi browser, termasuk lingkungan yang digerakkan oleh Playwright. Penggunaan Playwright tidak secara otomatis berarti sesi akan diblokir, tetapi hal tersebut tidak boleh dianggap secara inheren tidak terdeteksi.

Apakah DataDome dapat mendeteksi Puppeteer?

Ya, DataDome mendokumentasikan model deteksi yang mencakup otomatisasi berbasis Puppeteer dan Puppeteer Extra Stealth.

Apakah DataDome dapat mendeteksi proxy residensial?

DataDome memiliki model deteksi terkait lalu lintas yang dialihkan melalui proxy residensial. Alamat IP residensial tetap dapat berguna karena mengubah identitas jaringan, tetapi hal itu tidak secara otomatis membuat lalu lintas otomatis menjadi sah.

Apakah proxy residensial lebih baik daripada proxy pusat data untuk situs yang dilindungi DataDome?

Proxy residensial dapat memberikan identitas jaringan yang lebih mirip dengan lalu lintas konsumen biasa, yang mungkin berguna pada situs yang ditujukan untuk konsumen. Pilihan yang tepat tetap bergantung pada target, beban kerja, dan lapisan deteksi lainnya.

Apakah saya memerlukan browser untuk melakukan scraping pada situs yang dilindungi DataDome?

Tidak semua halaman yang dilindungi memerlukan browser. Namun, situs web yang mengandalkan rendering sisi klien atau Device Check mungkin memerlukan eksekusi JavaScript yang sebenarnya dan status browser yang tidak dapat disediakan oleh klien HTTP dasar.

Mengapa saya mendapatkan kesalahan 403 dari DataDome?

Kode 403 dapat menandakan bahwa permintaan tersebut diklasifikasikan sebagai mencurigakan atau otomatis. Pastikan bahwa respons tersebut benar-benar berasal dari DataDome sebelum menyimpulkan bahwa sistem anti-botlah yang menjadi penyebabnya.

Mengapa halaman tersebut berfungsi saat diakses secara manual tetapi tidak saat menggunakan Python?

Browser biasa dan pustaka HTTP Python menghasilkan lingkungan jaringan, TLS, HTTP, JavaScript, dan browser yang sangat berbeda. Sistem anti-bot dapat mendeteksi beberapa perbedaan tersebut.

Mengapa scraper saya berfungsi untuk beberapa permintaan lalu berhenti?

Penyebab yang mungkin termasuk deteksi perilaku, pola frekuensi, perubahan reputasi IP, atau sesi yang tidak konsisten. Sistem anti-bot dapat mengevaluasi aktivitas dari beberapa permintaan sekaligus, bukan menilai setiap permintaan secara terpisah.

Apakah rotasi proxy dapat mengatasi masalah DataDome?

Tidak jika hanya mengandalkan rotasi proxy saja.

Rotasi mengubah identitas jaringan. Namun, hal ini tidak secara otomatis mengubah sidik jari browser, klien TLS, lingkungan JavaScript, atau perilaku permintaan.

Apakah API Pengikisan lebih baik daripada proxy?

Keduanya mengatasi masalah yang berbeda.

Gunakan proxy jika Anda ingin mengontrol scraper Anda dan terutama membutuhkan infrastruktur jaringan.

Gunakan API Pengikisan jika Anda ingin infrastruktur browser, proxy, rendering, dan ekstraksi dikelola untuk Anda.

Kesimpulannya

Hal terpenting yang perlu dipahami tentang DataDome adalah bahwa tidak ada yang namanya "sinyal bot" tunggal.

Deteksi anti-bot modern menganalisis berbagai lapisan.

Sebuah permintaan bukan sekadar alamat IP.

Melainkan:

sebuah alamat IP
yang membuat koneksi TLS
yang mengirimkan header HTTP
dari browser atau aplikasi
dalam sebuah sesi
dengan riwayat
dan pola perilaku.

Semakin selaras unsur-unsur tersebut satu sama lain, semakin koheren tampilan klien tersebut.

Itulah mengapa mengganti alamat IP dapat menyelesaikan satu masalah namun meninggalkan lima masalah lainnya tanpa penyelesaian.

Itulah mengapa Playwright mengatasi eksekusi JavaScript tanpa menyelesaikan setiap masalah deteksi.

Dan itulah mengapa API scraping yang dikelola (managed) ada sejak awal.

Jika Anda membutuhkan kendali penuh, bangunlah stack-nya sendiri dan gunakan proxy sebagai infrastruktur jaringan.

Jika Anda terutama membutuhkan konten web yang andal tanpa harus mengelola browser dan orkestrasi proxy, gunakan API pengikisan.

Yang terpenting adalah mengetahui lapisan mana yang sebenarnya ingin Anda perbaiki.