Machine learning is everywhere, and crime data looks like an obvious target for it. Feed a model years of incident records, ask it where crime will happen next, and sell the answer as a “risk score” for a street or a postcode. Several products do exactly this.
CrimeMapsUK does not, and this article explains why. It is not because forecasting is hard to build - a basic model takes an afternoon. It is because the published data cannot honestly support it, and the failure modes are not just inaccurate. They are misleading in ways that look confident.
The data measures police activity, not crime
Everything on this site comes from published police records on data.police.uk. Those records are not a complete account of crime. They describe incidents that were reported to the police, recorded by a force, and then included in that force’s monthly publication.
Each of those three steps loses information unevenly. Many crimes are never reported, and reporting rates differ by offence type and by area. Recording practices differ between the 43 forces of England and Wales. Publication itself is not guaranteed - Greater Manchester Police published no street-level data for years, and other forces have paused publication without announcement.
A model trained on this data does not learn where crime happens. It learns where crime is reported, recorded, and published - which is a different thing, and the difference is largest exactly where predictions would matter most.
Too many variables, almost none of them in the data
Even setting the measurement gaps aside, a monthly figure for an area is the sum of many overlapping causes, and the published data labels almost none of them. A forecast has to untangle that sum, and the variables it would need are simply not there.
Some causes are ordinary rhythm. Recorded crime moves with seasons and weather: long summer evenings, dark winter commutes, a heatwave that fills parks and pub gardens. Others are one-offs that never repeat - a festival, a football fixture, a protest can each put a visible bump in one month’s figures for one place.
Some causes are about what an area is, not how risky it is. A retail park or a nightlife strip generates shoplifting and public-order records because that is where the people and the tills are. Footfall drives counts. And areas do not hold still: a new shopping centre or housing estate can change a neighbourhood’s whole crime profile within a couple of years, and nothing in the history warns a model that the ground has moved.
Some causes sit inside the measurement itself. Forces change their recording practice, and Home Office counting rules change what gets counted at all - either can move a force’s figures sharply with no change in actual crime. The anonymisation grid is revised too, so snap points can shift between releases, quietly moving records from one map cell to another. A publication pause, meanwhile, looks exactly like crime falling off a cliff.
And police activity is itself a variable. A proactive drugs operation is indistinguishable in the data from a drug-crime spike, because every stop and arrest creates a record. The area did not get more dangerous. It got more policed.
Put that together in one concrete case. A town’s records show drug offences tripling over three months. That could be a targeted operation, a recording change, a new late-night venue, festival season, or a real change in drug activity - and the published data contains nothing that separates them. A model will find a pattern anyway and attach a confident number to it. This is not a data-cleaning problem that more engineering fixes: at area level the confounders often are most of the movement in the figures. A confident postcode-level forecast built on these inputs is noise dressed as insight.
The feedback loop problem
Predictive policing tools have a well-documented failure mode. The model flags an area based on past records. Police attention shifts to that area. More attention produces more recorded incidents - not necessarily more crime, just more of it observed. Those new records feed the next round of training, which flags the same area more strongly.
The prediction confirms itself, and no accuracy metric run on the recorded data can detect the problem, because the recorded data is the thing being distorted. Audits of deployed systems have repeatedly found exactly this loop in practice, while the model’s reported accuracy looked fine.
We are a website, not a police force, but the same loop runs through property markets. A confident “risk score” steers buyers away from a postcode, which affects prices and who moves there, which affects the recorded data the score is built from. Publishing an invented number changes the thing it claims to measure.
Approximate points cannot support precise claims
Published locations are deliberately approximate: before release, every incident is snapped to one of a fixed set of anonymous map points, often a street centre or public landmark. Dozens of incidents from different addresses can share a single published point.
That anonymisation is good privacy practice, and it puts a hard floor under spatial precision. A model that outputs street-level risk from street-snapped inputs is manufacturing resolution that does not exist in the data. This is also why our own crime map uses a hex grid instead of address pins, and why neighbourhood reports describe a fixed 0.5 km circle rather than claiming to know what happened at any particular address.
Scores flatten what buyers actually need to know
Suppose the modelling problems were solved. A single “safety score” would still be the wrong product, because it hides the composition of the number.
Two areas can have identical totals where one is mostly shoplifting around a retail park and the other is burglary and violence on residential streets. Anyone deciding where to live needs that distinction, and a score erases it. The honest version of the answer is not a number - it is the category mix, the trend, where records cluster, and how the area compares with its surroundings, stated alongside what the data cannot show.
What we do instead
The approach across the site is the same:
- Show published records plainly. Counts, categories, outcomes, and trends, with the month window and source stated on every page and report.
- Aggregate honestly. Hex cells on maps, fixed circles in reports, district totals on area pages - shapes that match the real resolution of the data.
- Say what the data cannot show. Approximate locations, reporting gaps, and publication pauses are stated where they matter, not buried in a footnote. Where a force’s publishing has stopped, we decline to sell a report for that area rather than sell a misleading one.
- No scores, no rankings, no predictions. If a number would require inventing information the source does not contain, we do not publish it.
Questions to ask any crime-prediction product
If you are evaluating a tool that scores or forecasts crime for an area, a few questions separate careful work from confident noise:
- What exactly was the model trained on - reported crime, recorded crime, or published crime? Does the vendor know the difference?
- What is the claimed spatial resolution, and is it finer than the anonymised inputs? If so, where did the extra precision come from?
- How does it separate a police operation, a recording change, a new development, or a publication pause from a genuine change in crime? What variable would it learn that from?
- Can the score change the thing it measures - through policing decisions, pricing, or buyer behaviour - and does the vendor account for that?
- Would the vendor show you the raw published records next to their score, so you can check it yourself?
The published record, presented plainly, answers most questions a buyer or resident actually has. Where it cannot answer, the honest move is to say so - not to let a model fill the silence.