Is Your Data Ready for Machine Learning?

Readiness depends on the prediction, not the data

Almost every business that asks us whether its data is ready for machine learning is really asking a different question: will this project be a waste of money? That is a fair worry, and the answer cannot be given in the abstract.

A 60-person wholesaler with eight years of orders in its accounting system may be perfectly ready to forecast demand for its top 200 products and completely unready to predict which customers are about to leave, because nobody ever recorded why accounts went quiet. Same company, same database, two very different answers.

So the first step is never to look at the data. It is to write down the decision the model is meant to improve.

Start with the decision you want to improve

A usable machine learning problem fits into one sentence with three parts: what we want to predict, when we need to know it, and what we will do differently once we do.

For example: predict which invoices will be paid more than 30 days late, at the moment the invoice is issued, so the credit team can phone those customers in the first week. That sentence tells you the target (late or not), the prediction point (invoice date) and the action (an early call). It also tells you what data you need, which is the useful part.

If you cannot write the sentence, no amount of data will rescue the project. If you can, the checklist below becomes easy to answer.

The checklist

1. The outcome is recorded. Somewhere in a system there is a field that says, reliably, whether the thing happened. Not inferred from someone's memory.
2. You have enough examples of the outcome. Not enough rows in total, enough cases of the interesting result. Ten thousand invoices with 40 late ones is a thin dataset.
3. The history covers the patterns you care about. Seasonal businesses need at least two full seasons, preferably three.
4. Inputs exist at prediction time. Every field you plan to use must have been known at the moment the prediction would have been made.
5. Records join up. The same customer, product or site carries a consistent identifier across the systems you need.
6. Definitions have not quietly changed. If 'active customer' meant something different before a 2024 CRM migration, you need to know.
7. You can get the data out. An export, an API or database access, not a PDF report.
8. You are allowed to use it. Personal data used for a new purpose needs a lawful basis and possibly a data protection impact assessment.
9. Someone understands it. A person who can explain what the odd codes mean and why March 2022 looks strange.

Score yourself honestly. Seven or more is a good position. Four or fewer usually means the first project is a data project, not a model.

How much history is enough?

People expect a single number here, and there is not one. These rough rules of thumb come from our own projects and are meant as a starting point for a conversation, not a guarantee.

Notice that the limiting factor is rarely the raw row count. It is almost always the rare outcome, or a piece of context nobody wrote down.

The problems we find most often

• Systems that overwrite history. A CRM holds each deal's current stage, not the date it moved between stages, so you cannot reconstruct what was known at the time.
• Only the successes are recorded. A lender stores details of approved applications and deletes the rest, which makes it impossible to learn what a rejection looked like.
• Key fields typed as free text. Reasons for returns written as 'damaged', 'dmg', 'arrived broken' and 'see email'.
• Spreadsheets doing the real work. The pricing logic lives in a workbook with merged cells and colour coding that means something to one person.
• A migration nobody documented. Customer IDs reissued, product codes changed, and the old system switched off.

None of these is fatal. Each one costs time, and it is far cheaper to find them in week one than in week eight. Our longer piece on data quality problems that cost money goes further into the operational side.

A short data audit before any model

At SpiderHunts we rarely quote a machine learning build without first doing a fixed-scope data audit, usually around two weeks. We extract the relevant tables, profile every field, check how outcomes are recorded, and build the simplest possible baseline, often a rule a sensible manager would use.

The output is a short report: what is usable, what is missing, what a model could realistically achieve against that baseline, and what it would cost to close the gaps. Sometimes the report says the baseline rule is good enough and you should not build anything. That is a useful result too. It is the same approach our data science work starts from.

When the honest answer is not yet

If the outcome is not recorded, or history is overwritten, the right move is to fix data capture now and revisit the model in six to twelve months. A few small changes to forms and systems today make next year's project dramatically cheaper, which we cover in collecting the right data now for the model you want next year.

In the meantime, a well-designed report or a handful of rules often captures most of the value. Machine learning is worth doing when the pattern is too complicated for rules and the decision is repeated often enough to matter. For the wider picture, our machine learning guide walks through the whole process.

Frequently asked questions