Your engine will never be better than your catalogue

A search that finds nothing is almost always diagnosed as an engine problem. The tool gets changed, an option is paid for, and six weeks later the results are the same — which is logical, since nothing that produced the problem has been touched.

An engine only knows what is written in the records. If a product has no description, if it is named by its supplier reference, if it exists three times under three spellings, no algorithm will make up the difference — it will rank information that does not exist extremely well.

This article is about catalogue work: who owns product data, what to do with the supplier file that changes shape every month, the variant explosion, the withdrawn product, the photograph, and the weekly hour that stops the whole thing rotting. The companion article covers the engine itself — typos, synonyms, filters, availability before relevance — and none of that is repeated here.

It carries no chart. The only quantity it discusses is the number of your incomplete records, and that is a fact about your catalogue rather than about the market.

A product’s name in a catalogue is almost always the supplier’s name, and the customer almost never uses it. They search with the everyday word, often shorter, sometimes a brand that has become a common noun, very often mixing languages.

This market adds a difficulty imported catalogues ignore: the same product is searched for in French, in Arabic, and in Arabic written in Latin characters as it sounds. Three spellings for one thing, and a catalogue carrying only one of them is invisible to two thirds of searches.

The answer is not to rename products — the supplier’s name serves ordering and matching deliveries. It is to add a field that does not display and that the engine reads: the other ways of saying the same thing. Three or four entries per product are enough, and they are not invented at a desk.

They are collected, and the source is free: what people actually typed. The log of searches returning nothing holds customers’ words in their exact forms, and an hour spent reading it fills that field better than a meeting. It is the same gesture as reading unread messages, applied to a different log.

The same item in four sizes and three colours can be twelve products or one product with twelve variants, and that choice, made without thinking at the start, decides the catalogue’s legibility for good.

Twelve separate products give a search that displays almost the same thing twelve times, which drowns other items and makes the range look narrower than it is. The customer scans twelve identical lines and concludes there is nothing else.

A product with variants is almost always the right choice, and it has one condition: what distinguishes the variants must be a field, not part of a name. “Blue shirt L” and “Blue shirt XL” are two names; a shirt with a colour and a size is a product that can be filtered, counted and restocked.

The exception is worth knowing because it is common here: when variants have very different prices or do not sell to the same people, they behave as distinct products and are better treated as such. The useful rule is to group what the customer regards as one thing, and separate the rest.

Price is the field that changes most often and the one whose error is paid for fastest. A catalogue whose prices lag by a week produces orders that have to be renegotiated one by one, and that renegotiation costs more than the order’s margin.

The difficulty is rarely technical. It is that the price exists in several places — the till, the supplier file, the site, the shelf label — and nobody has declared which one is authoritative. Each corrects their own, and the four quietly diverge.

The rule is the same as for any shared data: one place is the source, the others receive a copy they may not change. Which place matters less than the fact that it is declared, and the right choice is nearly always where the price is really set, which is where money is taken.

A weekly check on a sample is enough to hold the rest. Twenty products at random, price compared between source and site, five minutes. That control does not prevent errors, it finds them while they are still small, which is the only thing a control can do.

What we take on is bounded: reading the log of searches that found nothing with you, establishing the conventions page, writing the transformations for supplier files, and handling the first batch of records — the one that carries the sales — with the person who knows the products.

We do not write descriptions for a catalogue whose owner cannot say what distinguishes two neighbouring items. This is not a comfort requirement: a description written without that knowledge is a paraphrase of the name, it occupies the place of a real record, and it gives the engine text with no information, which degrades ranking instead of improving it.

We do not sell a recommendation engine to a shop with a few hundred references. Below a certain volume, a hand-written list — the products that go together, decided by somebody who sells — is better, is corrected in a minute, and costs nothing. The threshold is arguable; the principle is that an algorithm needs more choices than a person does to be useful.

Finally, we will not promise a quantified sales gain. What a better catalogue produces depends on traffic, on range and on prices, and a figure recorded elsewhere would tell you nothing. What we measure with you is the share of searches that find nothing, before and after, and it is the only measure of this work that belongs to you.