Sell a CSV dataset only after the exact buyer archive imports cleanly into a spreadsheet, a database tool and a small code workflow. A file that opens on the creator's machine can still fail because of an ambiguous delimiter, encoding, duplicate headers, mixed date formats or undocumented null values.
This release checklist is for analysts, researchers, directory builders and niche-data publishers. Its original asset is a three-import portability test tied to one versioned ZIP, so the product promise can be reproduced rather than guessed.
Define the Dataset Before You Price It
State the subject, geographic and time coverage, row count, refresh date, source category, permitted use and important exclusions. Separate observed fields from calculated fields. If a column contains an estimate, score or classification, describe the method and date instead of presenting it as raw fact.
Do not sell personal data, scraped confidential information or a list you lack the right to distribute. Privacy, database rights, contract restrictions and marketing rules vary by source and jurisdiction; obtain appropriate advice for the actual dataset.
Freeze a Release Manifest
| Release item | Record | Buyer-facing purpose |
|---|---|---|
| Identity | Product name, version, publication date and checksum | Identifies the purchased build |
| Shape | Row count, column count, delimiter and encoding | Makes import settings explicit |
| Schema | Column name, type, unit, allowed values and null rule | Prevents silent interpretation errors |
| Coverage | Geography, dates, inclusion and exclusion rules | Defines what the dataset can answer |
| Provenance | Source category and transformation notes | Supports responsible evaluation |
| License | Seats, projects, redistribution and update rights | Defines permitted use |
RFC 4180 documents the common CSV format and the registered `text/csv` media type. The W3C's CSV on the Web model recommends UTF-8, consistent rows, a header line and correct quoting for commas, line endings and double quotes. Treat those as a portable baseline, then document every deliberate variation.
Run the Three-Import Portability Test
Create the retail CSV from a clean export, not a manually corrected desktop copy. Import that exact file in three lanes:
- Spreadsheet: import explicitly rather than double-clicking. Confirm delimiter, non-ASCII characters, leading zeroes, long identifiers, dates and decimal values.
- Database tool: create columns from the data dictionary and reject rows that violate the declared type, uniqueness or null rules.
- Code workflow: parse the file with a standard CSV library, count rows and columns, verify headers and compare a small set of known records.
Record application versions, import settings, warnings, counts and results. Spreadsheet software may reinterpret identifiers or dates; the test should catch that without changing the underlying data merely to suit one application.
Package Data, Documentation and a Safe Sample
The buyer ZIP should contain the versioned CSV, README, data dictionary, license, changelog and checksum. Add a separate sample with the same schema but only data you are entitled to expose publicly. Mark whether sample rows are real, anonymized or synthetic.
Include two worked questions the dataset can answer and one it cannot. That boundary is more useful than a long feature list. If updates are included, say whether buyers receive a fixed snapshot, updates for a period or a subscription to future releases.
Verify Paid Delivery
Use PayRequest's CSV database sales page with protected file delivery to release the approved ZIP after confirmed payment. Put coverage, version, sample, license and update terms before checkout.
Complete one buyer-view order. Download the receipt file, verify its checksum, extract it in a clean folder and repeat the code count. The release is ready when a buyer can understand the schema, reproduce the imports and identify the exact licensed version without contacting support.