From a Blank CSV Cell to a Reproducible Web-Data Bug Report

A spreadsheet full of blanks is not yet a useful bug report. It tells the next person that something went wrong, but not whether the source page changed, the request failed, the parser missed a field, or the export discarded a valid value. Those are different problems, and repeating the whole collection job can make the evidence harder to compare.
This guide describes a small evidence packet for a public-web data export. It uses a fictional shop-page example, not a customer incident or a measured product benchmark. The aim is to let another person reproduce the failure without handing over credentials or collecting more data than the investigation needs.
Start with one failed field, not the whole dataset
Suppose a row contains a product name but an empty price. Write down the exact expectation: “For this product variant, the public page displayed a price at the observation time, and the exported price column should retain that value and its currency.” Do not start with “the scraper is broken.” A source page may legitimately show “contact us” instead of a price, or require a shipping location before showing a total.
Keep one representative failed row and, if available, one successful row produced by the same workflow. Record which column differs. If the two rows refer to different variants, currencies, tax treatments, or account states, they are not a controlled comparison. Say so before proposing a fix.
Separate the four stages
Treat the workflow as four stages: request, rendered page, extracted fields, and exported record. Preserve a small observation at each boundary. A successful HTTP response does not prove that the requested product was displayed; a page can return an access notice or a soft error with status 200. Equally, a correct value in a browser does not prove that a separate collection process saw the same page.
For the request, record the destination and time. For the page, retain a relevant screenshot or permitted response excerpt. For extraction, record the field name and the rule that was applied. For export, retain the output row and schema version. This makes it possible to identify the first stage where the expected information disappeared.
Use an evidence record with explicit unknowns
A simple record can contain these fields:
• Case identifier: a local label, such as demo-price-001.• Observed at: a timestamp with a time-zone offset.• Source page: the public page URL, with secret query values removed.• Page context: language, currency, account state, and product variant.• Route context: direct or proxied, requested region, and separately observed region if checked.• Expected result: the field and its expected meaning.• Actual result: the value or a precise missing-data reason.• Evidence files: screenshot, minimal response excerpt, and output row.• Software context: parser or job version and export schema version.
Use “not observed” when a fact was not checked. Do not turn an unknown region into the provider's requested region, or a missing number into zero. Zero is a value with a meaning; it is not a generic failure marker.
Run a small comparison before a large retry
Create a baseline with the existing configuration. Then change one relevant variable. If a parser rule is suspected, keep the saved input fixed and run the old and new rules against it. If the live page behaves differently between routes, keep the language, account state, and page URL fixed while comparing a small number of requests.
Avoid changing route, browser language, cookies, parser version, and timeout together. A successful result after five simultaneous changes does not identify which change helped. For live requests, respect the site's access conditions and response limits. A challenge, rate-limit response, or sign-in requirement is an observation to record, not a reason to keep retrying until the result looks convenient.
Keep routing claims narrow
A proxy can change the network path associated with a request. It does not automatically change a logged-in account's country, the browser's language, GPS permission, or an address entered at checkout. If the experiment concerns one of those settings, record it separately.
BestProxy is a residential proxy provider and the publisher of this guide. We mention routing because it can be one variable in a reproducibility record, not because every missing field requires a proxy. Check current product documentation and your own configuration before relying on particular locations or session behaviour. This article makes no claim that a specific route will resolve an access restriction or produce a correct price.
Remove secrets before sharing
A reproducible packet should not be a credential dump. Remove cookies, authorisation headers, proxy usernames and passwords, API keys, and personal account details. Review query strings as well as obvious password fields. A screenshot may expose a logged-in name or an account menu even when the relevant product section looks harmless.
Keep any unredacted diagnostic material separately with restricted access. For the shareable version, preserve field names and non-sensitive structure so the report remains understandable. If replacing a secret changes the behaviour, explain that a private configuration step is required; do not publish the secret to make the example easier to run.
State what would count as a fix
Define success before rerunning the job. For a parser change, success might mean recovering the price and currency from the saved example while keeping the successful comparison row unchanged. For an export change, it might mean preserving an existing numeric value without rounding or converting an empty field to zero.
Also check a meaningful negative case: a page that truly has no price should remain explicitly missing. Otherwise, a patch can make every row look complete while silently inventing data. Keep the old and new outputs together and note the code or configuration version used for each.
Close with the next decision
A good report ends with a narrow next step: update the selector, correct the export mapping, investigate an access response, or leave the value unknown because the source does not disclose it. It should also say which explanation remains untested. That is more useful than a large spreadsheet with a single “failed” label.
Disclosure and image source
Written by the BestProxy team with AI assistance. The examples above are illustrative and contain no customer results. The cover is a screenshot of the official BestProxy homepage, captured on 19 October 2026; statements visible in that screenshot are vendor descriptions, not independent measurements.
BestProxy website