By Varun Mahajan, FounderPublished Last updated Part of the quick commerce data and api guide
What marketplace product data can tell you
Marketplace product data describes listings and the fields collected from them. Depending on the selected record type, that may include product identity, listed price, availability and source context. It can support a comparison of what was listed at a recorded time. It does not by itself establish units sold, market demand or why a price changed. The commerce datasets page shows the current coverage.
Begin with the decision: matching products, comparing equivalent packs, reviewing a recent listing or examining a price history. These tasks need different records. Check the commerce catalogue before designing the table you want to receive, and preserve the limits of the available fields.
A practical brief names the question before the metric. If the task is to compare pack prices, describe the exact variants and purchase conditions that would count as comparable. If the task is to review listing completeness, identify the fields being checked. Avoid asking a listing dataset to answer a sales question merely because its records include products and prices.
Choose listings or price history deliberately
A listing record describes a product entry under the conditions supplied with that record. A price history describes dated readings over a period. A current listing is not a history, and a historical series does not establish the product's present state. Check both the record type and its collection dates.
For a buying comparison, ask which recent records are available for your chosen products. For a change review, define the period and inspect gaps before calculating differences. Do not extend the earliest known price backwards or carry the last known price forward without clearly separating that assumption from the supplied data.
Document how repeated readings will be used. A sequence containing the same listed price can show that the recorded value stayed the same at those checks; it cannot establish that nothing changed between them. Similarly, a gap in history is not evidence of a stable price. Show the readings available for the period and state the limits of the conclusion drawn from them.
Keep identifiers and product details together
Names alone are a weak basis for matching. Similar names can describe different flavours, pack sizes or bundles; the same product can appear under different wording. Retain retailer and product identifiers where supplied, and inspect the product details before treating records as equivalent.
- Keep the original product name and the source reference.
- Review brand, variant, size and bundle details where available.
- Preserve identifiers exactly, including leading zeroes when they form part of an identifier.
- Mark uncertain matches for review rather than silently combining them.
An identifier helps locate a record within its stated system. It should not automatically be treated as a universal product identifier shared by every marketplace.
For an automated join, retain a reviewable match decision alongside the result. Separate an exact identifier match from a match based on name and pack description. If a product changes size or a listing is replaced, do not merge its history simply because the visible name is familiar. Keep the original records available to the reviewer and explain why they were connected.
Compare equivalent packs and price conditions
A lower displayed price may concern a smaller pack, a different bundle or a different condition of purchase. Before calculating a comparison, confirm that the selected records contain enough detail to explain those differences. If required information is absent, say that the comparison is incomplete.
Keep the original listed price separate from any unit-price calculation you make. State the quantity and conversion used, and avoid comparing incompatible units. Do not describe a calculated discount unless both the comparison price and its meaning are supported. A product title containing a quantity is useful evidence to inspect, not permission to guess missing pack information.
Make the price basis visible in the final table. If a source distinguishes a listed price from another price field, preserve that distinction instead of collapsing both into a generic number. Delivery charges, account-specific offers or other purchase conditions should not be assumed included when they were not supplied. State what the comparison covers and leave the rest outside its conclusion.
Check location, freshness and missing records
Review the catalogue's coverage basis and date alongside the records. If a result has a location basis, keep it visible. A marketplace-wide label does not establish that every seller, listing, variant or delivery location was checked. A large table can still miss the products your decision concerns.
Missing results have several possible explanations: an unmatched identifier, unavailable coverage, a field not supplied or a request problem. Do not collapse these into a claim that a product is delisted or unavailable. Treat an unexplained gap as unknown, not as a change.
Freshness has a practical consequence: the result may be appropriate for reviewing a past period but unsuitable for a decision that needs the present state. Decide how recent the records must be for your task, then check whether the available collection times meet that requirement. Do not relabel an old record as current because your application loaded it successfully today.
Build a comparison someone else can check
- Write the product set, sources, period and required fields before requesting data.
- Inspect the selected entry's status, coverage and published charging information.
- Review a bounded result for identifiers, pack equivalence and collection time.
- Separate confirmed matches from uncertain ones, and keep missing fields visible.
- Present the comparison with its source references, exclusions and limitations.
A useful output lets another person check why two rows were compared. Keep transformation rules with the result: how names were shortened, how units were converted and which records were excluded. Avoid turning an unresolved match into a confident recommendation because the table looks complete.
Review unusual values before creating a summary. A large price difference might reflect a different variant, a unit conversion error or a missing purchase condition. Keep the supplied value while investigating rather than silently removing an inconvenient row. If an exclusion is justified, record the rule consistently and explain whether it changes the population your summary describes. This makes the result reproducible without claiming that every unusual value is wrong.
Request records without overstating the conclusion
Applications can use the data API reference to select documented listing and history requests. Keep authentication on the server, review a published rate or quote before chargeable work, and account for pagination. A successful first page does not establish that the wider dataset has been retrieved.
Use the delivered records to answer the bounded question you specified. If the question requires evidence beyond the catalogue, describe the missing data to Finder rather than filling the gap with an inferred fact. For broader integration planning, read the India ecommerce data API guide: what it returns by pin code and marketplace, and what a read costs.
Report the limits of the records directly, including any product set that could not be matched reliably and any period with substantial gaps. A narrower, traceable comparison is more useful than a confident answer built on unsupported joins and missing context.
A handover should include the original question, selected records, collection period and comparison rules. State whether the result describes a single check or a sequence, and distinguish supplied fields from values calculated afterwards. Include unresolved matches and missing coverage even if the reader only asked for a summary. Those details let the next person decide whether the comparison can be reused for a different question or whether another bounded request is needed.
Questions worth settling
Does marketplace listing data show sales or demand?
No. Listing counts are not market share. Price changes are not proof of demand. Availability states do not explain supply-chain causes.
Is a missing price a zero price?
No. A missing price remains unknown; it is not a zero-price product. Recheck the source and scope before escalating an apparent change.
When is marketplace listing data insufficient?
It is insufficient when the decision requires verified sales, customer intent or a cause that the records do not contain. It may also be insufficient when the desired product set cannot be matched reliably or the relevant period has substantial gaps.