Data quality checks every retail analyst should run

Most bad retail analysis isn't caused by bad math. It's caused by bad data that nobody checked. Data quality checks are the routine tests you run on a dataset before analyzing it: is it complete, are there duplicates, do the values make sense, and does it describe the stores and products you think it does? They take an hour and save weeks.

The myth is that clean data arrives clean. It rarely does, and assuming it does is how confident conclusions end up resting on a doubled file or a missing week.

Which checks should run before any analysis?

A short, repeatable list catches most problems. Run it every time, even on a dataset you've used before.

1. Completeness. Count stores and days in each period. A store with 24 days of data in a 31-day month has a gap, and that gap will look like a sales drop.
2. Duplicates. Look for identical rows, or for a store-day that appears twice. Double-loaded files are one of the most common errors in retail data.
3. Store counts over time. Chart the number of reporting stores by week. Sudden jumps or drops usually mean onboarding, closures or feed issues rather than business changes.
4. Negative and zero values. Negative units on a store-day often come from returns or voids. A long run of zeros in a steady seller often means a data gap.
5. Price sanity. Divide dollars by units for each item and look for values far outside the normal range. A soda at $45 a unit is a keying or pack error.
6. Item mapping. Check that every UPC maps to a category and brand. Unmapped items quietly fall out of every total.

None of these needs special software. A spreadsheet and some patience will do.

Why do negative units appear, and what should you do?

Because returns, voids and corrections are real transactions. A shopper returns an item, or a cashier voids a line, and the register records a negative. Usually these are small and offset by sales on the same day.

The problem comes when a large negative lands on a day with few sales, or when a correction for last week's error posts this week. That can push a store-day below zero or make a normal week look weak. The fix is to look at negatives in context. Small ones can stay. Large ones that clearly correct a prior error should be matched with the original, where the data allows.

Don't simply delete all negatives. Doing so inflates sales, because it keeps the original purchase and discards the return.

What should happen when a check fails?

Stop and investigate before analyzing. That's the whole point. If a store's data is missing for a week, decide whether to exclude that store from the comparison, fill the gap with a flagged estimate, or wait for the data to arrive. Write the decision down.

Then tell the people who'll read the analysis. A short note, such as "three stores excluded for incomplete data in week 12," lets readers judge the result. Hiding the fix is worse than the original problem.

Finally, report the issue upstream. Recurring errors, such as a store whose feed double-loads every month, should be fixed at the source. Otherwise you'll run the same repair forever. The broader concept of data quality, covering accuracy, completeness and consistency, is a useful frame for those conversations.

Isn't this the data provider's job?

Partly. Providers run their own checks, and good ones catch most issues before data ships. But every dataset passes through several hands, and every handoff is a chance for errors. Filters, joins and date conversions on your side can introduce problems that didn't exist upstream.

The analyst is the last line of defense. A simple checklist, run every time, is cheap insurance. It also builds confidence. When someone questions a result, you can show exactly what was checked and what was changed.

Aggregated reporting from NRS Insights is built from store-level scan data where these checks come first. The July 2026 same-store sales report is the most recent example.