Catalog Debt on a Marketplace: Where It Comes From and Who Pays

Catalog debt on a marketplace is the pile of product pages that fail your own standards, created by nobody's decision, which is why no budget line and no owner exist for it.

A catalog decays at the same rate it grows, and the spending that would stop it has no line in any budget. Two years in, you have tens of thousands of product pages that nobody owns.

This article breaks down:

• Which 7 problems hide behind a bad catalog?
• Which 2 numbers turn catalog debt into a budget line?
• Which 3 ways can you fund a catalog cleanup?
• Why does a cleanup never reach the third quarter?

Key insights

• Every broken page belongs to somebody else, so the whole pile belongs to nobody. That is an ownership problem wearing the costume of a data problem.
• Add one column: did this offer sell in the last quarter? Four thousand of those hundred thousand did. Fifty person-days instead of five years, and only that number survives a committee.
• Averages hide the work. Eighty-five percent coverage across two categories can mean four offers in ten have no value at all in the one that matters.
• A seller has no reason to improve an offer that already sells. So fund the selling core yourself and leave the tail to the visibility incentive.

Why does catalog debt have nobody's signature on it?

Every other debt in your company has a signature: a loan has a contract, technical debt has an architect's decision. Catalog debt has no signature, because no decision created it.

Every broken page comes out of the same sequence: the seller filled in as much as they knew how to, validation let the rest through, and the person who could have finished it had something else to do.

Two things follow from the missing signature, and both cost you money.

The first: it is not in the budget. There is no line called "catalog repair." There is one for seller onboarding, one for the product data team, one for platform development.

The debt lives between them, so it goes first in every round of cuts, and nobody notices.

The second matters more: it has no owner, and neglect is not the reason. This page belongs to the seller who created it.

That one to the manager who onboarded them. A third to the team that raised the category standard six months later and invalidated two thousand offers that had been correct the day before.

Every single case belongs to somebody else, so the whole thing belongs to nobody. A set without an owner is nobody's task.

The sentence for the committee, instead of "we have a data quality problem": until the debt has a name and a number, it is not a project. It is a topic that comes back to every meeting and leaves without a decision.

Which 7 problems hide behind a bad marketplace catalog?

"A bad catalog" is not one thing you can fix, because seven separate phenomena hide under that heading. Each has a different cause, a different cost, and a different person who can repair it.

The practical conclusion: two of these items only the seller can repair, because only the seller has the data and the photos. Three only you can repair, because they cover whole sets of offers.

Two are mostly a job for automation. Split budget and schedule along the same lines.

A single project called "catalog cleanup" falls apart in its first week, because it throws three kinds of work into one queue.

Who should own catalog debt: onboarding or the data team?

The classic friction runs between the person who onboarded the seller and the team answering for product data. The onboarding manager says their job ends when sales go live.

They are right: they are measured on time to first sale. The product data team says it will not fix somebody else's files.

They are right too: they answer for the standard, the tree, and the dictionaries; they have a queue of their own, and they never ordered these offers. Friction like this does not end in goodwill.

It ends in a decision about money.

There is a less obvious layer underneath. Often the seller cannot repair it either.

Once your team touches a shared product page, the write permission on some fields usually passes to you. And sometimes the author of a weak page left long ago, while whoever holds better data has no access to it.

Now the order of magnitude, because it explains the rest. In large rollouts, the backlog runs into tens of thousands of product pages, and practitioners from such projects talk about the order of a hundred thousand.

Assume six minutes per page: read the standard, find the value, type it in, save. A hundred thousand pages is 10,000 hours, roughly 1,250 person-days, or five person-years.

Nobody has five person-years in a budget, so nobody volunteers for that responsibility. The missing owner is not a question of character.

It is a question of scale.

The conclusion: the owner of this debt can be neither the person who creates it nor the person who inherits it. It has to be whoever answers for the result of the channel, because only that person can move money between onboarding, the data team, and visibility.

Which 2 numbers turn catalog debt into a budget line?

A debt with no number does not exist in the budget. Two measures are enough, and only one is obvious.

The first: field coverage per category. It is the share of offers in a category with the field filled in, counted per language, because a field completed in English is empty on the German market.

PIM systems measure completeness exactly this way: the share of required fields filled in for a given channel and language.

The value sits in the breakdown. An example.

In power tools, you have 12,000 offers and the "power" field filled in on 7,200 of them, which is 60%. In footwear, you have 30,000 offers and the "outer material" field filled in on 28,500, which is 95%.

Together, that is 35,700 offers out of 42,000, or 85%. An average of 85% looks like a minor touch-up, while in power tools, four offers in ten have no value in the field.

The second matters more: split the offers into those with active sales and all the rest. That one column changes the class of the problem.

Take the same hundred thousand pages and check how many had at least one sale in the last quarter. Say 4,000.

Repairing all of it is the five person-years calculated above: a multi-year program. Repairing those 4,000 is 4,000 × 6 minutes = 400 hours, or 50 person-days: a team of four for two and a half weeks.

The same backlog, two different decisions, a twenty-five-fold difference. Only the second of those numbers survives a committee.

Hence the rule, in one sentence: clean up by sales. Build the second queue out of the categories you are investing in right now.

Otherwise, you are only repairing the past.

Which 3 ways can you fund a catalog cleanup?

1. Repair at the point of entry

Hours for data written into seller onboarding.

The cheapest of the three, because the debt never comes into existence. An example.

A seller joins with 2,500 offers. Eight hours on the mapping and the file before publication takes care of the whole batch at once.

The same 2,500 offers repaired later, at six minutes per page, come to 250 hours. That is over thirty times the work for the same result.

The data quality literature says the same thing more generally: only removing the cause of an error gets permanently cheaper, never its effects. The condition: those hours have to be booked as a cost of acquiring supply.

Otherwise, the first pressure on speed cuts them to zero.

2. Your own data team

Expensive, and the only model that works on strategic categories and on everything a seller will not repair: categories, duplicates, pages left by sellers who are gone.

The condition: a mandate to write into other people's fields and a priority queue driven by sales rather than tickets. A team without that mandate produces requests.

3. Moving the cost onto the seller through visibility

Field coverage feeds into where the offer ranks.

It works best of the three, because it works on self-interest rather than goodwill.

And one thing has to be said honestly. A seller has no reason to improve an offer that is already selling.

The visibility incentive is therefore strongest where the repair is worth least to you: in the tail that does not sell anyway. What follows is a division of labor.

You fund the selling core yourself and leave the tail to the incentive.

Why does a catalog cleanup never reach the third quarter?

Three reasons.

1. No owner. Covered above.

With no name attached, there is nobody to ask about progress.

2. No bulk tooling. If the only route is page by page in the panel, 4,000 offers is 50 person-days.

The same correction as an operation on a filtered set is a day of work plus a review. On top of that, a rule that runs only at the point of entry never touches the backlog even once: catalog rules.

3. No visible loss. A broken page does not generate an invoice, does not call you, and does not take up space in a warehouse.

It is nowhere in the profit and loss account, so it loses to anything with an amount next to it.

The antidote is cheap: this debt does not belong in a project backlog; it belongs in the standing set of channel metrics. One number once a month, in the same report as turnover and conversion: how many offers with active sales fail today's category standard, and by how much that number moved since last month.

A metric that climbs in front of the board finds an owner on its own.

What separates catalog debt you chose from debt forced on you?

One distinction saves your priorities. The debt you chose covers fields left optional, weak descriptions, photos with no requirements.

It carries for years, and its deadline is your decision. Debt forced by a change in the rules comes with somebody else's deadline and somebody else's scope, so it is a separate operation, with phases and a ceiling on the turnover you may switch off: a compliance migration.

Do not mix the queues: the first will drink the budget of the second.

What does catalog debt change about the rest of your marketplace?

1. Seller onboarding stops being a sales process

It gets an hourly budget for data and a limit past which the offer does not go live. It is the only place where repair costs less than the debt.

2. Raising a standard needs a plan for the backlog

Each time you raise the bar, a new layer of debt appears the same day.

3. The debt metric goes into the channel report

One number, one owner, once a month.

4. Where the neighbouring topics live

Four neighbouring decisions have chapters of their own: retiring what does not sell, merging duplicates, requirements going forward, and who has the right to write into a field. Team staffing belongs to the chapter on organization.

5. A bad catalog comes back as money

A buyer who was misled sends the goods back: a €1,000 cart at a 12% commission is €120 of your revenue and €880 for the seller; the return takes away both and opens the question of fault. That is, who pays for a refund and the commission on a refunded order.

How do you size catalog debt with 3 numbers and 1 name?

Do not commission an audit. Ask for four answers, each on a single slide.

1. How many offers fail their own category standard today? One number, plus the breakdown by category, because the average lies.
2. How many of those had at least one sale in the last quarter. That is your real scope of work and the only number worth showing the board.
3. How many of those come from sellers who still work with you. The rest you cannot order from anyone: what is left is your own team or automation.
4. Whose name stands next to the number from point two in the monthly report. If there is none, you do not have a data problem. You have an ownership problem.

Three questions for the platform vendor, with a request to see each on screen:

• A bulk operation on a filtered set. Changing the category on five thousand offers, with a preview before saving and a way to undo it.
• A category standard run against an already published catalog. Ask directly whether it flags the offer or takes it off the storefront.
• A field coverage report sliced by category, by seller, and by language, with a column for "had a sale in the period." Without that column, every cleanup starts from the alphabet.

Which mistakes do operators make about catalog debt?

1. Debt with no name on it

A task split across two teams belongs to zero teams: it comes back at every review and never moves by a single percent.

2. Cleaning up by the alphabet, or from the oldest pages

The team works honestly for a month; nothing shows in sales, so it is the first thing cut from the next budget.

3. Repairing page by page instead of set by set

Four thousand offers are 50 person-days in the panel and about a day as a bulk operation. Without bulk tooling, you are buying permanent headcount for a one-off job.

4. Raising the standard without a plan for the backlog

The entry metric looks excellent, and the catalog that sells stays as it was the day before.

5. Counting on the seller for an offer that already sells for them

There is no incentive there, and every email asking for a correction lowers the response to the next one.

What do you still have to settle about your own catalog debt?

This is a method for assigning ownership and measuring. We will not give amounts, because the cost of your hour, your repair rate and your number of pages are yours.

What we show is a calculation you can run on your own data in one afternoon, and that is a stronger position than somebody else's table.

Three things are deliberately missing here. We do not settle how many attributes to require.

We do not settle staffing. We only say that the owner needs authority over the budget.

And one reservation at the edge of our competence. Some empty fields are a requirement from the rules on product data rather than a quality question, and then neither the deadline nor the scope is yours.

Which fields and categories are covered is something to confirm with a lawyer.

Summary: What turns catalog debt into something you can fix?

A name and a number, in that order. The number comes from one column most reports leave out: whether the offer sold in the last quarter.

It turns a five-year programme into fifty person-days and is the only version of the problem a committee will fund. The name has to sit high enough to move money between onboarding, the data team, and visibility, because the three repairs are funded in three different places.

Then keep the number in the monthly channel report rather than in a backlog, because a metric that climbs in front of a board finds an owner on its own.

Count how many offers fail your own category standard and how many of those sold in the last quarter. Building a marketplace where a bulk fix on a filtered set is a day's work rather than fifty?

Talk to us about the build.

Frequently asked questions on marketplace catalog debt

What is catalog debt on a marketplace?

The product pages that fail your own standard, piled up by nobody's decision. Seven separate problems hide under that heading, each with a different cause and a different person who can repair it: two only the seller can fix, three only you can, and two are work for automation.

Who should own catalog debt?

Whoever answers for the result of the whole marketplace channel. The onboarding manager is measured on time to first sale, and the data team answers for the standard, so neither can own it without moving money that is not theirs to move.

How do you prioritise a catalog cleanup?

By sales, and never by the alphabet or by age. Take the offers that fail the standard, keep the ones with a sale in the last quarter, and start there.

Build the next queue out of the categories you are investing in now; otherwise, you are only repairing the past.