One-Time Enrichment vs Continuous Catalog Operations

A catalog cleanup project has a start date, an end date, and a celebration when it ships: duplicates merged, attributes filled, everyone moves on. Eighteen months later, someone runs the numbers again and finds the catalog is nearly as messy as before the project started. This isn’t a sign the project failed. It’s a sign the project was scoped to fix a snapshot, and a catalog isn’t a snapshot — it’s a moving target that a one-time effort was never built to keep up with.

Why a one-time project can’t hold

The forces that created the mess in the first place don’t stop when a cleanup finishes. New supplier feeds keep arriving, each capable of introducing new duplicates. Existing suppliers keep changing their file formats, triggering schema drift. Products get reclassified, discontinued, and replaced. A cleanup project fixes the data as it existed on the day of the project. It does nothing about the data that arrives the next day, and the next, indefinitely.

This is the same underlying pattern behind classification drift: a taxonomy or a catalog that’s correct today degrades continuously unless something is actively monitoring and correcting it, not periodically overhauling it.

The two models compared

	One-time enrichment project	Continuous catalog operations
Scope	Fix current backlog	Fix backlog, then keep monitoring
Trigger	Scheduled project, or a crisis	Every new supplier feed, every change
Team experience	Intense burst of effort, then decay resumes	Steady state, no crisis to schedule around
Catalog trajectory over time	Sawtooth: clean → decay → clean → decay	Improves or holds steady
Cost pattern	Large, periodic — see clearing a 5,000-SKU backlog	Smaller, ongoing

The sawtooth pattern in the one-time model is the real cost, and it’s usually invisible in project planning because each cleanup gets budgeted and staffed as if it’s the first and only one needed.

What continuous actually requires, structurally

It’s not simply “do the cleanup more often.” Continuous operations means identity resolution and validation run on every incoming feed as it arrives, not on a schedule. It means drift detection is always watching, not something someone remembers to check quarterly. It means the catalog gets smarter with each new supplier onboarded, rather than more fragile — because every new piece of data is being reconciled against what’s already known, in real time, instead of accumulating for the next scheduled fix.

Deciding which model you’re actually running

If your organization has budgeted a “catalog cleanup” as a project with a start and end date more than once, that repetition is itself the evidence: the underlying model is one-time, and the mess will return, because nothing changed about how new data is handled between projects.

Tired of scheduling the same cleanup project every year or two? Book a 30-minute call.

FAQ

Why does a catalog get messy again after a cleanup project? +

A one-time cleanup fixes the data as it existed on the project’s completion date. It doesn’t address new supplier feeds, format changes, or reclassifications that continue arriving afterward, so decay resumes unless something continuously monitors and corrects new data.

What does continuous catalog operations require that a one-time project doesn't? +

Continuous catalog operations requires identity resolution and validation running on every incoming feed as it arrives, ongoing drift detection rather than a periodic check, and a process that treats new supplier data as routine input rather than a future backlog.

Related reading

• Detecting and fixing classification drift
• What is schema drift?
• Clearing a 5,000-SKU backlog