Shelf data by CSV or API: what to ask before you connect it

What shelf data is

Shelf data describes what shoppers see on retail apps and sites. One row records one product at one location at one moment: its price and MRP, whether it was available, and where it appeared in search. Stack up rows over days and you can see how a shelf moves: when a price changed, when a product went out of stock, when a rival arrived.

E-commerce teams check price and availability before account reviews. Analysts compare stock and prices across pin codes. Category managers compare their range with competitors. Each needs consistent records with dates and sources.

CSV or API: which one you need

A CSV file is a spreadsheet-style export. It suits teams that work in Excel, Google Sheets or a business intelligence tool, and who review data on a weekly or daily rhythm. It is easy to open, share and archive, and needs no engineering help.

An API lets your own systems request the data automatically, so it can flow into a dashboard, a data warehouse or an internal tool without someone downloading a file. It suits teams with an analyst or developer who will build on it, and who want records to arrive on a schedule.

Choose by who will use the data and how often. If one person reviews a weekly file, a CSV is enough, and an API adds work without adding value. If several systems need the same numbers every day, an API saves repeated effort. Check the data catalogue for the delivery options available for each dataset.

Questions to ask any shelf-data provider

Before connecting a feed to anything that matters, put these questions to the provider, and expect specific answers.

• What does one row contain, and can I see the page it came from?
• Which shopping apps and which pin codes are read, and how often? Ask for what is fetched, not what is merely on record.
• What happens when a reading fails or an app does not publish a field? A gap should appear as a gap.
• Which fields are read for each app? Some apps do not show stock on search pages, so a stock column may be empty there.

Coverage, freshness and gaps

Coverage is where feeds most often disappoint, because it is easy to overstate. A provider may hold records from a large number of retailers and fetch from a smaller set. The two numbers are different and both should be published. Ask for the count of retailers actually read, and for the age of the latest successful reading for the app you care about.

Freshness matters as much. Prices move within a day, so a record needs its time. A feed that refreshes daily can describe yesterday's shelf but not this afternoon's flash discount. Ask how often each app is read and treat claims of real-time data with caution unless the cadence is stated.

Then look at gaps. A good feed reports what it could not read. It degrades to less information, never to wrong information. If an app does not publish stock on its search results, the right answer is a blank with a reason, not a guess.

Using the records well

Start with a small list of products and pin codes that matter, and get comfortable with the shape of the data before scaling up. Keep the product, pack size, app, pin code and time together in every view, because a price without its location is easy to misread. When a number surprises you, check its source before you act.

Remember what the data cannot do. It records what was displayed, not why. It is not sales data, and it does not measure lost sales from a stock gap. It pairs well with your own sales figures, which supply the meaning the shelf record lacks. For metrics built on these rows, see digital share of shelf and discount depth.

What Rewalto provides

Start with the data catalogue. Each entry describes its fields, coverage, freshness and current availability. Check those details before choosing a dataset; a field described in this guide may not be available for every source.

The API documentation explains access, authentication and credits. Check Watches for the current status of recurring updates. The older shelf plans and monthly shelf-audit service are no longer offered.

Review the usage rights on the dataset entry before sharing records with clients. Access to data does not by itself grant permission to resell it.

Your first weeks with a feed

A feed is easiest to trust when you have checked it yourself. In the first week, choose a few products you know well and compare the feed's rows with what you see when you open the app at the same pin code. Look at the price, the MRP, the availability and the position. Where they match, note it. Where they differ, check the source behind the row and see which is right and why.

In the second week, look at gaps. Find the rows where a field is empty and confirm that the reason is stated. A blank stock field for an app that does not publish stock is expected. A blank that nobody can explain is a question for your provider, and the quality of the answer tells you a great deal about the feed.

In the third week, start using the data for one small decision, such as a weekly check of stock at your top pin codes before an account review. Keep the decision modest so the risk of a data problem stays low. Once your team trusts the rows for that, widen the scope.

Build your analysis so that it can survive a change of source. Keep the raw rows unedited, do your calculations in a separate step, and record which version of the definitions you used. When a provider adds an app or changes a field, you will want to see exactly what moved and why, rather than wonder whether your own spreadsheet drifted.

Finally, agree who owns the feed inside your company. A feed with no owner is a subscription that stops being used. One named person, a weekly look, and a short note of what changed is enough to keep the data useful.

Before connecting a source to a dashboard, inspect a record from the period you expect to use. Check how empty fields are represented, whether dates include a time zone, and how the source identifies a product or pack change. Then try an empty response and an error response. Your dashboard should show that it has no current reading rather than quietly keeping an older value on screen. Agree how long your team will retain the records and who checks the connection when its output changes.

Common questions