Web Data RFP Checklist: How to Write an RFP for Web Data Collection (2026)

Introduction

Many web data RFPs fail before a vendor reads them. They ask for "competitor prices from all major retailers" and leave every vendor to guess the sources, countries, fields and refresh rate. The result is five quotes that cannot be compared.

A web data RFP checklist is the list of requirements a buyer defines before inviting vendors to quote: scope, sources, countries, data fields, refresh frequency, volume, delivery format, QA and acceptance criteria, SLA, change handling, compliance and usage rights, and pricing model. With these fixed, vendor quotes become comparable and can be scored.

This guide is written for procurement managers and data leads. It is vendor-neutral: use it to write your RFP, whoever you invite. It draws on the RFPs our team has received directly in 2026 from consulting firms, FMCG and beverage groups, retailers and travel companies, and on the gaps we see most often in them. If you are still deciding which kinds of provider to invite, start with our How to Choose a Web Scraping Partner in 2026: A Buyer's Guide. This article covers the next step: writing the document itself.

Why a web data RFP is different from a software RFP

A software RFP buys a tool. A web data RFP buys an ongoing stream of records from websites you do not control. Three facts change how you write it:

• The sources change without notice. Retailers redesign pages, add bot protection and change URL structures. Your RFP must say what happens when a source breaks, not just what is delivered on day one.
• "Data" is not a deliverable until it is defined. "Price" can mean list price, promo price, member price, per-unit price or price after a coupon. Undefined fields are the main reason why quotes can't be compared.
• Cost depends on scope, not seats. The number of sources, countries, records and refreshes drives cost far more than the number of users. A precise scope gives you a precise quote.

In the RFPs we received in 2026, the authors were usually procurement teams working with a data owner in pricing, revenue management, strategy or data engineering. The best ones are co-written: procurement owns the process and terms, the data owner owns the requirement.

The 12-section web data RFP checklist

Use this web data RFP checklist as the backbone of your document. Each section answers a question every vendor would otherwise ask in a clarification round.

• Business objective and scope. One paragraph on the decision the data supports (e.g. weekly price positioning against five competitors). Include an explicit list of what is out of scope.
• Sources. Name every website, marketplace or app, with the exact domain or app store listing. Mark each as mandatory or optional, and ask vendors to flag any they consider not feasible or not permitted.
• Countries, regions and locations. List countries, languages and currencies. If prices vary by store, postcode or delivery zone, state how many locations you need and how they are chosen.
• Data fields. Attach a field dictionary: field name, definition, example value, mandatory or optional, and the rule for when a value is missing (see the table below).
• Refresh frequency and timing. Daily, weekly, hourly, or event-driven. Say what time zone the data must arrive in, and whether history or backfill is needed.
• Volume. Approximate products, listings, outlets or pages per source per refresh. Give a range and expected growth over the contract term.
• Delivery format and method. File format (CSV, JSON, Excel, Parquet), method (API, S3, Azure Blob, Google Cloud Storage, SFTP, email, dashboard), naming convention and schema-versioning rules.
• QA and acceptance criteria. How quality is measured, who checks it and what makes a delivery "accepted". Ask for the vendor's QA process and a sample QA report.
• SLA and support. Delivery-time commitment, completeness and accuracy targets, incident response, fix times for broken sources, support hours and escalation contacts.
• Change handling. How you add or drop a source, field or country mid-contract, how vendors price changes, and how you are told about source-side changes.
• Compliance, security and usage rights. Public data only, no personal data unless lawfully justified, respect for site terms, data-handling security, and what you may do with the data (internal use, client deliverables, resale, AI training).
• Commercials and pricing model. Ask for a quote in your preferred pricing model plus the vendor's own, with setup, run and change costs listed separately.

How to specify sources, countries and fields

This is the part most RFPs skip. A one-page field dictionary removes most clarification questions and makes quotes comparable. Here is an example for a retail price-monitoring RFP; adapt the fields to your use case.

Three tips from real RFPs we have answered in 2026:

• Give vendors URLs, not brand names. One retailer brand can mean a dozen country sites and apps.
• Separate the source list from the product list. Say whether vendors must collect the full catalogue or only a list of products you provide (your SKUs, EANs or URLs). The two scopes are priced very differently.
• Ask for a sample against your own spec. It tells you more than any slide deck.

QA, acceptance criteria and the SLA

Quality claims such as "high accuracy" mean nothing in a contract. Put measurable definitions in the RFP and ask each vendor to state its own targets against them. You set the bar; the vendor tells you what it will commit to in writing.

Define acceptance in three stages. Sample acceptance: the sample meets the field dictionary. Pilot acceptance: two to four weeks of production runs meet the metrics. Ongoing acceptance: monthly reporting against the SLA, with service credits or a remediation plan if targets are missed.

Web data pricing models compared

Vendors price web data in different ways, so a quote in one model is hard to compare with a quote in another. Describe the model you prefer in the RFP and ask each vendor to quote in it, plus its own model if different. The table below describes the common models only; it is not a price guide.

Whatever the model, ask vendors to list setup, monthly run, change-request and extra-source costs separately, so you compare total cost over the term, not headline rates. For how Actowiz structures its own plans, see our pricing page.

The web data vendor evaluation scorecard

Agree the criteria and weights before you open any proposal, and publish them in the RFP. Public-sector guidance such as the UK government's Assessing Competitive Tenders makes the same point: tenders should be assessed against award criteria and weightings set out in advance. The weights below are a starting point; change them to match your priorities.

Score each criterion from 1 to 5, multiply by the weight and add up the results. Have at least two people from different teams score each proposal on their own, then agree the final scores together. Image: web-data-vendor-scorecard.png (alt: "Weighted scorecard for evaluating web data vendors").

A realistic RFP timeline

For a multi-country, multi-source requirement, eight weeks from draft to signature is realistic.

Legal, compliance and usage-rights basics

Your legal team will decide what is acceptable for your organisation, but the RFP should require vendors to answer these points:

• Public data only. Data visible without logging in, collected in a way that respects each site's terms of service, robots.txt directives and rate limits.
• Personal data. State whether any personal data is in scope. Under the GDPR and similar laws, data about identifiable people needs a lawful basis. Most price and product projects need none; say so.
• Usage rights. Spell out whether you may share data with clients, publish aggregates, combine it with other datasets or use it to train models.
• Security. Ask how data is stored, transferred and deleted.
• Feasibility honesty. A credible vendor will tell you when a source is not feasible or not permitted. Treat "we can scrape anything" as a red flag.

For a deeper look, read our web scraping compliance guide. This article is general guidance, not legal advice.

Frequently Asked Questions

What should a web data RFP checklist include?

At minimum: business objective, source list, countries and locations, a field dictionary, refresh frequency, volume, delivery format, QA and acceptance criteria, SLA, change handling, compliance and usage rights, and your preferred pricing model.

How is an RFP different from an RFI for web data?

An RFI collects general information about vendors' capabilities to build a shortlist. An RFP gives a defined scope and asks for a priced, comparable proposal. For complex requirements, an RFI first can save time.

How many vendors should we invite?

Three to six is usually enough. Fewer limits competition; more creates scoring work without better options. Use the RFI or a buyer's guide to shortlist.

Which pricing model is best for web data?

No model is best everywhere. Per-record suits stable volumes, per-source suits few sources with many records, and subscription suits ongoing feeds that need budget certainty. Ask for quotes in one common model so you can compare.

Should we ask for a free sample in the RFP?

Yes. Ask each shortlisted vendor for a sample from two or three of your sources in your field dictionary. It is the fastest way to test quality, coverage and how well the vendor understood your brief.

What SLA terms matter most for web data?

Timeliness of delivery, completeness of mandatory fields, accuracy on spot-checks, and fix time when a source breaks. Ask for written targets, monthly reporting and a remedy if targets are missed.

Conclusion

You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!