By Varun Mahajan, FounderPublished Last updated Part of the quick commerce data and api guide
Write down the question before choosing the dataset
A dataset can contain a lot of records and still miss the thing you need. Start with the decision: which products, places and period matter, what comparison you will make, and how recent the answer must be.
Turn that into a short request someone else could check. Product prices for selected delivery areas this week is more useful than all commerce data. A precise question makes it easier to see whether the catalogue entry fits or whether you need to ask for something else.
Find out what one record represents
Ask what a row means. Is it a product, a listing, a price check, a company or a document? Some datasets contain several rows for the same product because each source, location or date is different. Combining them without those distinctions can create duplicate counts or misleading averages.
Read the field descriptions and any supplied units. Check whether identifiers remain stable across updates, how missing values are represented, and which fields are optional. A sample is useful here, but a small sample alone cannot establish completeness.
Read coverage as a defined set
Coverage needs a boundary. Look for the sources, locations, categories and period actually included. A catalogue entry that names a source does not promise every page or product from that source.
Ask which parts were checked successfully and which were outside scope. Distinguish the registered universe from the measured set. A list of known locations may be much wider than the locations with a usable reading for the period you need.
Use your own must-have list as the comparison. Mark each item covered, missing or uncertain. That is a stronger buying decision than choosing the entry with the largest headline count.
Rewalto publishes its own boundary on the data coverage page: each live dataset, the sources it is read from and the pin codes held for prices and listings, with the date the catalogue was checked.
Separate freshness from the update promise
An update schedule describes the intended rhythm. The actual source date tells you what the current record describes. Both matter. A daily schedule does not establish that every source updated successfully today.
Look for the date of the latest usable reading, the period covered by the history and any known delay. Check whether the timestamp describes the source event, the collection or the export. Downloading a file today does not make the underlying data current.
Check what the history preserves
A current listing and a historical price series serve different jobs. A listing may show the latest known price but say nothing about changes before that reading. A historical series should retain dates and gaps so you can compare like periods.
Ask whether updates replace earlier values or add a dated record. Confirm that the history covers the product and location you care about, rather than assuming the earliest date in the catalogue applies to every item.
Use the sample to test your workflow
Try the sample in the system that will consume the data. Check dates, units, missing values, text encoding and repeated records. Make sure the output can be joined to your own product or company references without relying on names alone.
Test an ordinary record and an incomplete one. If your spreadsheet treats a missing price as zero, fix that before expanding the request. If an agent cannot distinguish an old result from a new one, keep the dates in its context and require it to state the limitation.
Verify availability, access and cost separately
Catalogue status, access permission and delivery readiness are separate questions. A planned entry is not ready to run. A preview can help you review shape and limits without promising a complete dataset. Check the current status before making an operational dependency.
Review the published charging unit or supplied quote before a paid action. Confirm what will be delivered, how pagination affects the request and where you will see the receipt. A free sample is not proof that a whole-dataset purchase is available.
If the entry does not answer your question, describe the gap precisely. Share the fields, sources, locations and period you need. That gives the team a useful request without treating an unconfirmed capability as an existing product.
Ask questions that have checkable answers
Instead of asking whether coverage is good, ask whether the dataset includes your required sources, places and period. Request the definition behind any count: distinct products, listings and repeated checks are different quantities. A large number is only useful when you know what was counted.
Ask what happens when a scheduled update fails. Does the entry keep an older record, mark a gap or report a failed check? Ask how corrections are represented and whether you can distinguish a changed value from a newly collected value.
Keep the answers with your analysis brief. If the dataset later changes its scope, the original brief explains what your earlier comparison relied on. This is especially useful when another person repeats the work after you have moved on.
Test a small result all the way through
A sample that opens in a spreadsheet has passed only the first check. Run it through the intended join, filter, chart or agent prompt. Confirm that the same records appear at the end, with the same dates and units. Check that a text identifier has not become a number or lost a meaningful leading character.
Choose a question you can answer directly from the supplied records, then compare your system’s answer with the records. If the output adds an explanation that is not supported, change the prompt or presentation before adding more data. An agent should be able to say that the available records do not answer part of the question.
Keep access credentials outside shared worksheets and prompts. Share the field descriptions and a permitted example when someone needs help with the integration. A complete delivery may contain information that should not be copied into a public issue or chat.
Handle an old or inconsistent result explicitly
If an entry’s headline says it updates regularly but the latest record is older than expected, treat that as a question to resolve. Do not silently change the date or assume the schedule guarantees freshness. Check the period requested, the source context and any supplied status explanation.
If two records disagree, first compare their product or company references, locations and dates. They may describe different things. When they really conflict, keep the disagreement visible and ask which source or correction rule applies. Choosing whichever value is more convenient makes the analysis harder to trust.
Review the fit when the decision changes
A dataset that supports an exploratory chart may not support an automated business action. Revisit coverage and freshness when the use changes, when new locations are added or when a result becomes part of a recurring report. The cost of a stale answer depends on what someone will do with it.
Keep a short acceptance note: the question, required fields, covered population, date window, important gaps and permitted use. Name the checks that would make the data unsuitable. This gives the next reviewer a reasoned decision rather than a vague label such as approved.
If the fit is poor, ask for a narrower delivery or a different source instead of forcing the existing records to answer a broader question. An honest gap can guide a useful request. It should not be hidden behind a confident chart.
Review the result before sharing it
Before making the final choice, ask the person using the result to explain the important gaps back to you. If they read an unchecked location as an empty market, the explanation needs work. Put the limitation beside the result, not only in the acquisition notes. Keep the acceptance record with the analysis so a colleague can repeat the checks later.
Choose your next step
Continue with not checked is not empty or marketplace product data. Visit Rewalto to review current data and access options.
Common questions
What does measured coverage mean?
It is the count Rewalto has actually measured for a dataset, such as the pin codes held, shown with the date it was measured. A coverage line without that date has not been measured.
Does a live dataset have data everywhere?
No. A catalogue listing describes the offer; it does not guarantee that every field or location has data. Check the measured set on the data coverage page against your own list.
How do I see the freshness of a dataset?
Each dataset page shows its last update and how often it updates. Compare the last update with how recent your answer must be, not with the schedule alone.