Fragen Sie ein Datenteam, was ihre Web-Datenerfassung kostet, und Sie hören etwas über Gigabyte, Request-Zahlen, Credits und Erfolgsraten. Fragen Sie das Finanzteam, was es wissen möchte, und die Antwort ist einfacher: Was kostet uns ein nutzbarer Datensatz, und steigt oder sinkt dieser Wert? Die beiden Gespräche treffen sich selten, weil die Zahlen, die Ingenieure verfolgen, die Pipeline beschreiben, nicht das, was sie hervorbringt.
Kosten pro sauberem Datensatz schließen diese Lücke. Es sind die Gesamtkosten eines Erfassungsauftrags geteilt durch die Datensätze, die die Validierung bestanden haben, also jene, die man tatsächlich in einen Bericht, ein Modell oder ein kundenseitiges Produkt aufnehmen würde. Dieser Leitfaden definiert die Kennzahl präzise, zeigt, wohin das Geld wirklich fließt, arbeitet ein Beispiel durch und ordnet die Hebel nach ihrer Wirkung.
Die wichtigsten Erkenntnisse
- Messen Sie die Kosten pro sauberem Datensatz: Gesamtkosten geteilt durch Datensätze, die die Inhaltsvalidierung bestanden haben, nicht durch Requests oder HTTP-Erfolge.
- Bei Monitoring-Aufträgen fügen Sie die Kosten pro nützlicher Änderung hinzu. Die meisten erneuten Abrufe bestätigen, dass sich nichts geändert hat, sodass eine Änderung um ein Vielfaches teurer sein kann als ein Datensatz.
- Das Abrechnungsmodell entscheidet, welche Verschwendung wehtut. Bandbreiten-Abrechnung bestraft schwere Seiten; Abrechnung pro Erfolg bestraft unnötige Abrufe.
- Eine mediane Startseite wiegt etwa 2,5 MB, wovon nur 22 KB HTML sind. Nur das abzurufen, was tatsächlich geparst wird, ist bei bandbreitenabgerechneter Erfassung oft die größte einzelne Einsparung.
- Berichten Sie die Kennzahl monatlich, pro Auftrag, mit ihren Bestandteilen. Eine Zahl, die das Finanzteam nachverfolgen kann, ist eine Zahl, für die es Budget gibt.
Die Kennzahl sorgfältig definieren
Drei Definitionen leisten den Großteil der Arbeit.
Gesamtkosten sind alles, was der Auftrag verbraucht hat: Proxy-Bandbreite oder API-Credits, Rechenleistung, Speicher und, wenn man ehrlich ist, die Ingenieurszeit, die für den laufenden Betrieb aufgewendet wurde.
Ein sauberer Datensatz ist einer, der die Validierung bestanden hat: erforderliche Felder vorhanden, Werte in plausiblen Bereichen, und eine Seite, die tatsächlich die angeforderte Seite war und keine Sperrseite, keine Challenge und keine leere Hülle. Eine Antwort mit HTTP 200 ist erst dann ein sauberer Datensatz, wenn sie diese Prüfungen besteht; die Lücke zwischen beiden ist Thema von der stillen Fehlerrate.
Eine nützliche Änderung ist beim Monitoring entscheidend. Wenn Sie einen Preis täglich erneut abrufen und er sich zweimal im Monat ändert, hat der Datensatz, für den Sie an den anderen 28 Tagen bezahlt haben, nichts Neues bestätigt. Kosten pro nützlicher Änderung erfassen, worum es beim Monitoring wirklich geht.
Wissen, wie abgerechnet wird
Dieselbe Pipeline kann teuer oder günstig sein, je nach Abrechnungsmodell, weil jedes Modell etwas anderes zählt.
| Abrechnungsmodell | Wofür Sie bezahlen | Was es teuer macht |
|---|---|---|
| Residential-Proxy-Bandbreite | Bytes durch das Gateway | Schwere Seiten, Rendering, Wiederholungen, die Daten übertragen |
| Scraping-API-Credits | Erfolgreiche Antworten | Abrufe, die nicht nötig waren |
Beim Residential-Gateway von Shifter zählt jedes gesendete oder empfangene Byte, einschließlich Headern, und fehlgeschlagene Requests zählen, wenn vor dem Fehler bereits Bytes übertragen wurden. Bei der Web Scraping API kostet ein erfolgreicher Request einen Credit, unabhängig davon, ob JavaScript-Rendering aktiviert ist, fehlgeschlagene Requests und zielseitige Fehler kosten nichts, und automatische Wiederholungen innerhalb eines Aufrufs zählen als dieser eine Aufruf. Bei Bandbreiten-Abrechnung kann eine gerenderte Seite, die jedes Bild und Skript nachlädt, also weit mehr kosten als ihr HTML; bei Abrechnung pro Erfolg kostet sie gleich viel.
Der Größenunterschied ist erheblich. Der Web Almanac 2025 des HTTP Archive stellte fest, dass die mediane Startseite auf dem Desktop 2,86 MB und auf Mobilgeräten 2,56 MB wog, während das mediane HTML in beiden Fällen 22 KB betrug. Wer nur das HTML oder einen dahinterliegenden JSON-Endpunkt parst, bekommt für die meisten Bytes einer vollständig gerenderten Seite nichts.
Ein durchgerechnetes Beispiel
Betrachten Sie einen Monitoring-Auftrag über einen Monat. Die untenstehenden Zahlen sind illustrativ, gewählt, um die Rechnung zu zeigen, und der Satz von $3 pro GB ist für das Beispiel eine runde Zahl, kein Angebot.
| Eingabe | Wert |
|---|---|
| Gesendete Requests, einschließlich Wiederholungen | 120.000 |
| Durchschnittliche Bytes pro Request | 450 KB |
| Erfolge auf HTTP-Ebene | 108.000 |
| Datensätze, die die Validierung bestanden haben | 97.000 |
| Gültige Datensätze, die sich von der letzten Kopie unterschieden | 6.800 |
| Bandbreitensatz | $3,00 pro GB |
| Rechenleistung | $40 |
Führt man den Rechner unten aus, ergibt sich:
| Kennzahl | Wert |
|---|---|
| Gesamtkosten | $202,00 |
| Kosten pro Request | $0,0017 |
| Kosten pro sauberem Datensatz | $0,0021 |
| Kosten pro nützlicher Änderung | $0,0297 |
| Stille Fehlerrate | 10,2% |
| Bytes pro sauberem Datensatz | etwa 557 KB |
Zwei Dinge stechen hervor. Jede nützliche Änderung kostet etwa vierzehnmal so viel wie jeder saubere Datensatz, weil die meisten Abrufe bestätigen, dass sich nichts bewegt hat. Und einer von zehn HTTP-Erfolgen brachte nichts Verwertbares hervor.
Ändern Sie nun eine Sache: Hören Sie auf, vollständige Seiten zu rendern, und rufen Sie nur das HTML oder JSON ab, das der Parser benötigt, wodurch der Durchschnitt von 450 KB auf 60 KB pro Request sinkt. Alles andere bleibt gleich. Die Gesamtkosten sinken auf $61,60, die Kosten pro sauberem Datensatz auf $0,0006 und die Kosten pro nützlicher Änderung auf $0,0091, eine Reduzierung um mehr als zwei Drittel durch eine einzige Änderung in der Art, wie Seiten abgerufen werden.
Der Rechner besteht aus wenigen Zeilen:
from dataclasses import dataclass
@dataclass
class Run:
requests: int # every request sent, including retries
bytes_transferred: int # everything through the proxy, failures included
responses_ok: int # HTTP-level successes
records_valid: int # records that passed content validation
records_changed: int # valid records that differed from the last copy
price_per_gb: float # your plan's rate
compute_cost: float = 0.0
people_cost: float = 0.0 # engineering time spent on this job, if you count it
def unit_economics(run):
bandwidth = run.bytes_transferred / 1e9 * run.price_per_gb
total = bandwidth + run.compute_cost + run.people_cost
return {
"total_cost": round(total, 2),
"cost_per_request": round(total / max(1, run.requests), 5),
"cost_per_clean_record": round(total / max(1, run.records_valid), 4),
"cost_per_useful_change": round(total / max(1, run.records_changed), 4),
"silent_failure_rate": round(1 - run.records_valid / max(1, run.responses_ok), 3),
"bytes_per_clean_record": int(run.bytes_transferred / max(1, run.records_valid)),
}Bei einem über Credits abgerechneten Auftrag ersetzen Sie die Bandbreitenzeile durch erfolgreiche Antworten multipliziert mit Ihrem Preis pro Credit. Der Rest der Rechnung bleibt gleich.
Die Hebel, grob nach Wirkung geordnet
1. Hören Sie auf, Unverändertes abzurufen. Beim Monitoring sind unveränderte erneute Abrufe meist der größte Kostenposten. Besuche nach der tatsächlichen Änderungshäufigkeit jeder Seite zu planen und, wo Websites es unterstützen, bedingte Requests zu nutzen, reduziert Abrufe, ohne Änderungen zu verpassen. Die Methode ist in kostenbewusster Crawl-Planung beschrieben, und wie man echte Änderungen von Rauschen unterscheidet, in Änderungserkennung im großen Maßstab.
2. Rufen Sie weniger pro Seite ab. Bei Bandbreiten-Abrechnung: Rendering vermeiden, sofern die Daten es nicht erfordern, Bilder, Schriften und Medien blockieren, wenn gerendert werden muss, JSON-Endpunkte bevorzugen und Kompression aktiviert lassen. Die vollständige Liste findet sich in Proxy-Bandbreitenkosten senken.
3. Beheben Sie stille Fehler. Jede Sperrseite, Challenge oder leere Hülle, die als Erfolg durchgeht, kostet gleich viel wie ein guter Datensatz und bringt nichts hervor. Validieren Sie Inhalte, zählen Sie Fehler pro Ziel und beheben oder verlangsamen Sie die Ziele, die diese verursachen.
4. Extrahieren Sie aus stabilen Quellen. Wartung ist ein realer Kostenfaktor. Selektoren, die bei jedem Redesign brechen, verbrauchen Ingenieurszeit, weshalb strukturierte Daten über ein Jahr gesehen günstiger sind, als es bei einem einzelnen Durchlauf scheint; siehe HTML-Parsing beenden.
5. Passen Sie das Abrechnungsmodell an das Ziel an. Schwere Seiten, die gerendert werden müssen, können bei Abrechnung pro Erfolg günstiger sein; leichte HTML- oder JSON-Ziele sind meist bei Bandbreiten-Abrechnung günstiger. Gemischte Portfolios nutzen oft beides. Die weitergehende Abwägung wird in Build vs. Buy für Web-Scraping-Infrastruktur behandelt.
Berichterstattung an das Finanzteam
Eine Kennzahl zählt nur, wenn sie konsistent berichtet wird. Einmal im Monat, pro Auftrag, veröffentlichen Sie:
- Gesamtkosten, aufgeteilt in Bandbreite oder Credits, Rechenleistung und, falls mitgezählt, Personal.
- Saubere Datensätze und Kosten pro sauberem Datensatz.
- Bei Monitoring-Aufträgen: nützliche Änderungen und Kosten pro nützlicher Änderung.
- Stille Fehlerrate und Bytes pro sauberem Datensatz als die beiden führenden Indikatoren.
- Die wichtigste Änderung seit dem Vormonat und deren Grund.
Über ein Quartal beibehalten, verwandelt dies Web-Daten von einer undurchsichtigen Infrastrukturposition in einen Stückkostensatz, der budgetiert, mit dem Kauf der Daten anderswo verglichen und verteidigt werden kann.
Fazit
Gigabyte und Request-Zahlen beschreiben Aufwand. Das Finanzteam interessiert sich für den Output: was ein nutzbarer Datensatz kostet, und beim Monitoring, was eine echte Änderung kostet. Definieren Sie saubere Datensätze über die Validierung, nicht über Statuscodes, zählen Sie jede Kostenart, die der Auftrag verursacht, und berichten Sie das Ergebnis pro Auftrag jeden Monat.
Die Hebel sind selten exotisch. Seltener abrufen, wo sich nichts ändert, weniger pro Seite abrufen, aufhören, für Seiten zu bezahlen, die erfolgreich aussehen, es aber nicht sind, und aus Quellen extrahieren, die nicht brechen. Jeder davon zeigt sich direkt in einer Zahl, die jeder im Raum lesen kann.
Quellen und Referenzen
- HTTP Archive, Web Almanac 2025: Page Weight. Median-Seiten- und HTML-Gewicht, Crawl vom Juli 2025.
- Shifter, Residential Proxies bandwidth and billing und Web Scraping API errors and limits Dokumentation.