Il listino prezzi del fornitore di proxy è strutturato in modo tale che confrontare i fornitori sembra un compito semplice: un gigabyte costa $1, un altro $8 — considera, la differenza è otto volte. Nella pratica, il team che ha acquistato un gigabyte per un dollaro paga regolarmente per i dati raccolti più di quello che ha speso otto. La ragione non è nel marketing e non ci sono commissioni nascoste: il prezzo per gigabyte semplicemente non è l'unità in cui viene misurato il tuo compito. Non stai acquistando traffico — stai acquistando registrazioni estratte con successo, e tra queste due grandezze c'è una catena di moltiplicatori, che sono diversi per ogni progetto.
Il conto arriva non per ciò che hai calcolato
Una scena tipica: avevi pianificato di raccogliere un milione di schede prodotto, avevi previsto 200 KB per pagina, ottenendo così 200 GB e un budget di circa millecinquecento dollari. Dopo un mese nel tuo pannello personale — 900 GB e un conto tre volte superiore al preventivo. Nessuno ti ha ingannato: sono cambiate tre cose che non erano nel calcolo.
Il divario tra il prezzo e il conto si scompone sempre nelle stesse componenti. Vale la pena analizzarli singolarmente — poi la formula si comporrà da sola.
Tre moltiplicatori tra il prezzo e il conto
1. Quanto pesa realmente una pagina
La stima di "200 KB" è presa dalla testa e si riferisce al solo HTML. Il peso reale dipende da come recuperi la pagina. La risposta HTML grezza di un negozio moderno è solitamente di centinaia di kilobyte. Ma una pagina completamente renderizzata in un browser headless con tutti gli script, i font, le immagini e l'analitica pesa già 2–5 MB. La differenza tra i due modi di ottenere gli stessi dati è un ordine di grandezza, e ricade interamente sul tuo traffico.
I calcoli di settore di solito operano con un intervallo di 1–3 MB per una raccolta non ottimizzata e 100–300 KB per una ottimizzata. Tra questi due modi — non "un po' di risparmio", ma una differenza di dieci volte sullo stesso progetto.
2. Quale percentuale delle risposte è realmente utile
Il secondo moltiplicatore è il tasso di successo, la percentuale di richieste che hanno restituito contenuti utili. Captcha invece di una pagina, 403, una struttura vuota senza dati, reindirizzamento a una pagina di errore — tutto questo è traffico pagato che non ha fornito alcuna registrazione.
L'aritmetica è semplice e spietata: numero di richieste = registrazioni necessarie ÷ tasso di successo. Con un successo del 95% per un milione di registrazioni, servono 1,05 milioni di richieste. Con il 70% — già 1,43 milioni. Con il 60% — 1,67 milioni. Quindi, il calo del tasso di successo dal 95% al 60% aggiunge quasi il 60% al conto, a parità di prezzo per gigabyte.
3. Retry, timeout e traffico accessorio
In aggiunta a questo si sovrappone il traffico accessorio dell'infrastruttura stessa. Qui la differenza tra un stack maturo e uno assemblato in fretta è enorme: su piattaforme gestite ben collaudate, i retry consumano circa lo 0,1–3% in più, mentre su un pipeline Scrapy fatto in casa — il 5–15%, e la percentuale cresce con la scala. Una logica di retry aggressiva, che colpisce un dominio bloccato cinque volte di seguito, può facilmente trasformare queste percentuali in decine.
Una metrica che non mente
Riuniamo tutto in un'unica grandezza. Non bisogna contare i dollari per gigabyte, ma il costo di mille registrazioni estratte con successo:
- Prezzo per 1000 registrazioni = (peso medio della risposta in GB ÷ tasso di successo) × (1 + percentuale di retry) × prezzo per GB × 1000
Il valore di questa formula è che rende confrontabili offerte non comparabili. Un pool economico con un tasso di ban del 40% e uno costoso con un tasso di ban del 5% si trovano finalmente sulla stessa asse. È significativo che anche i fornitori stessi siano arrivati a questa metrica nell'ultimo anno: nei materiali di settore si sente sempre più spesso la formulazione "prezzo diviso per tasso di successo", e non il semplice prezzo per gigabyte.
Come si traduce in denaro
Prendiamo un milione di registrazioni, una pagina media di 500 KB e traffico residenziale a $8/GB — una tipica media di mercato. Cambiamo solo il tasso di successo:
- 95% di successo — 1,05 milioni di richieste, circa 525 GB, circa $4.200
- 70% di successo — 1,43 milioni di richieste, circa 715 GB, circa $5.720
- 60% di successo — 1,67 milioni di richieste, circa 835 GB, circa $6.680
La differenza è quasi $2.500 sullo stesso prezzo. E ora confrontiamo due offerte che nel listino prezzi sembrano cielo e terra. Fornitore A: $2/GB, ma mantiene il 55% di successo sul tuo obiettivo. Fornitore B: $6/GB e 92% di successo. Con gli stessi 500 KB e un milione di registrazioni, A produce circa 910 GB e $1.820, mentre B — circa 545 GB e $3.270. Qui A è davvero più economico, e questo è un risultato onesto: con una grande differenza di prezzo, un basso tasso di successo non sempre erode il vantaggio.
Ma aggiungi a A un tasso di retry del 15% contro il 3% di B, aggiungi il rendering headless, che viene attivato proprio perché il pool economico restituisce più spesso una pagina di errore invece di contenuto — e il peso della pagina di A sale a 1,5 MB contro 500 KB di B. Ricalcolo: A — circa 3,1 TB e $6.200, B — circa 560 GB e $3.370. La situazione si è invertita. Ecco perché la domanda "chi ha il gigabyte più economico" non ha un senso autonomo: la risposta dipende dal tuo obiettivo, dal tuo stack e dal tuo tasso di ban.
Perché gli scraping API vengono considerati diversamente — e come confrontarli
Una difficoltà separata è che parte del mercato non vende affatto gigabyte. Gli scraping API e i web unblocker addebitano per le richieste, e le tariffano in base alla complessità. L'ordine dei prezzi del 2026 per 1000 pagine appare così:
- HTML semplice: ScrapeOps circa $0,19, ScraperAPI circa $0,49, Scrape.do circa $0,58, ScrapingBee circa $0,66, Bright Data circa $1,00
- Con rendering JS (di solito 5 crediti invece di uno): ScrapeOps circa $0,95, Scrape.do circa $2,90, ScrapingBee circa $3,30, ScraperAPI circa $4,90, Bright Data circa $5,00
- Siti sotto protezione anti-bot (10–25 crediti): ScrapeOps circa $1,90, Scrape.do circa $4,45, ScraperAPI circa $5,96, ScrapingBee circa $6,60, Bright Data nella gamma $8–15
Nota la differenza all'interno di un singolo fornitore: per ScraperAPI una pagina semplice e una pagina sotto protezione differiscono di dodici volte. La tariffa "per richiesta" appare più prevedibile rispetto ai gigabyte fino a quando l'obiettivo non si sposta dalla prima categoria alla terza — e questo avviene senza il tuo intervento, per decisione del proprietario del sito.
Questo si riporta a un asse comune con la solita formula: costo per richiesta ÷ tasso di successo × 1000. Dopo di che l'offerta "$3,30 per 1000 pagine JS" e l'offerta "$6 per gigabyte di traffico residenziale" possono finalmente essere messe a confronto. Un'analisi più ampia degli approcci stessi — API ufficiale, dataset pronto o il tuo parser — è stata trattata separatamente; qui è importante solo la loro comparabilità in termini di denaro.
Misura in una sola serata
La formula è inutile senza i tuoi numeri, e la buona notizia è che ottenerli è un lavoro di poche ore. Un pilota su 1000 richieste sui tuoi URL reali fornisce tutto il necessario.
- Prendi un campione rappresentativo degli obiettivi — non la homepage principale, ma quelle schede, categorie e risultati che intendi raccogliere in produzione. Il tasso di successo sulla homepage non predice nulla.
- Fissa separatamente quattro contatori: risposte valide con dati, errori HTTP, captcha e challenge, "duecento vuoti" — codice 200 senza contenuto utile. L'ultima categoria è la più insidiosa: formalmente è un successo, ma di fatto è spazzatura pagata.
- Registra il volume effettivo di traffico dalle statistiche del fornitore, non dalle tue stime. La discrepanza tra il peso calcolato e quello effettivo della pagina è di solito la prima scoperta di tale pilota.
- Conta i retry come una riga separata, e non mescolarli nel numero totale di richieste.
- Ripeti con un secondo fornitore nello stesso giorno. Il tasso di successo fluttua insieme all'umore dei sistemi anti-bot, e le misurazioni disperse su una settimana non possono essere confrontate.
Se il pilota ha mostrato un basso tasso di successo, non affrettarti a cambiare fornitore: prima vale la pena capire il motivo. L'analisi delle fonti tipiche del problema è raccolta nel materiale su come diagnosticare un basso tasso di successo dei proxy, e il monitoraggio regolare delle stesse metriche dovrebbe diventare una routine. Spesso il problema si rivela essere nei header, nel timing o nel fingerprint TLS del client, e non nella qualità dell'IP.
Quattro leve che muovono il numero più di uno sconto
Quando la metrica è calcolata, diventa chiaro dove è più sensibile. Uno sconto del 10% sul prezzo è la leva più debole disponibile.
Peso della risposta. Il guadagno più rapido. Raccogliere solo ciò che serve riduce il traffico di 2–10 volte. Se il browser headless è obbligatorio, blocca a livello di intercettazione delle richieste immagini, font, media e script di terze parti — il contenuto non ne risente, ma il volume diminuisce drasticamente. Attiva la compressione e le richieste condizionali tramite ETag: una pagina che non è cambiata dall'ultimo passaggio dovrebbe costarti una risposta 304, e non un megabyte.
Successo. Ogni dieci punti percentuali di successo nell'intervallo 60–95% — sono decine di percento sul conto. Qui non si tratta di soldi, ma di ingegneria: un corretto fingerprint del client, un ritmo ragionevole, il giusto tipo di IP per un obiettivo specifico.
Mix di tipi di proxy. Far passare tutto il traffico attraverso un pool residenziale è l'errore più comune e costoso. Una parte significativa degli obiettivi si presta perfettamente a proxy di data center, che costano un ordine di grandezza in meno; gli indirizzi residenziali dovrebbero essere spesi solo per ciò che realmente li richiede. La routizzazione in base all'obiettivo, e non all'abitudine, riduce le spese per i proxy del 60–70%.
Disciplina dei retry. Ritardo esponenziale, limite di tentativi, rinuncia ai retry su codici che non possono essere risolti con un retry. La differenza tra il 3% e il 15% di traffico accessorio è la differenza tra un'infrastruttura ordinata e la sua assenza. L'aspetto pratico della questione è trattato nel materiale su ottimizzazione del consumo di traffico tramite proxy.
Cosa rimane al di fuori del traffico
Il quadro completo delle spese è più ampio del conto dei proxy, e questo è importante tenerlo a mente quando si sceglie tra "raccogliere da soli" e "comprare pronto". Per un progetto della scala di un milione di pagine al mese, le stime di settore per una soluzione self-hosted sono le seguenti: traffico residenziale $500–1500, tempo ingegneristico $1000–2000, infrastruttura $300–500. Totale $2000–4400 al mese — e questo prima di scrivere la logica di business vera e propria. Con una tariffa per ingegnere di circa $100 all'ora, alcuni giorni spesi a riparare selettori rotti costano più di un mese di conto per i proxy.
Questo non è un argomento contro la raccolta autonoma — è un argomento per considerare le ore di ingegneria come una riga di budget allo stesso modo dei gigabyte. Anche il modello di tariffazione dovrebbe essere scelto consapevolmente: per sessioni lunghe e stabili, il pagamento per un IP dedicato si rivela spesso più vantaggioso rispetto a quello per megabyte.
In breve
Il prezzo per gigabyte non è il prezzo dei dati, ma il prezzo di uno dei quattro fattori. Confrontare i fornitori in base a questo è come scegliere un'auto in base al prezzo di un litro di benzina, senza chiedere il consumo. L'unità di lavoro di confronto è una sola: quanto costa mille registrazioni estratte con successo sui tuoi obiettivi, con il tuo peso della risposta, il tuo tasso di successo e i tuoi retry.
Calcola questo in un pilota di mille richieste, prima di sottoscrivere un abbonamento annuale. Spesso si scopre che l'offerta più economica nel listino prezzi ti costa più di tutte le altre — e che il più grande margine di risparmio non si trova nelle trattative per uno sconto, ma in una ventina di righe di codice che disattivano il caricamento delle immagini.
```