The "because you bought" rail feels out of season: woollen-wear suggestions in April, rakhi items in November, last year's phone model beside this year's. New products never appear in the rail at all, and sellers complain about it. Nothing errors, no alert fires, but the recommendation click-through has been sliding a little every week for months.
An item-item recommender that worked well at launch. The similarity table was computed once during the launch sprint, saved as a file or a database table, and the serving path has been reading it ever since. No recompute job was ever scheduled — the task lived in someone's head, and that someone changed teams. The catalogue, the season, and customer baskets have all moved on since the snapshot. Linked modules: 1.12 (recommendation systems intro), 1.10 (time discipline).
An item-item similarity table is a photograph of co-purchase behaviour during its training window, and baskets drift: festivals come and go, seasons flip, new brands arrive, habits change. A frozen table keeps serving the photograph. Worse, any item launched after the snapshot has no column in the old matrix, so no similarity path can ever reach it — the newest catalogue is structurally invisible to the rail. The failure is silent by nature: stale recommendations are valid outputs, so nothing crashes. The only symptom is the slow click-through decline, which is easy to blame on anything else. Confirm the diagnosis in one step: find the build date of the similarity artefact and compare it with today.
Recompute the table on a schedule — nightly or weekly is enough for most catalogues — and version each build. Before swapping a new table in, compare old versus new offline on the latest time split so a bad build cannot replace a good one. Give items launched since the last build a content-based fallback (category, brand, price band) so they appear somewhere while their purchase history accumulates. Add a freshness check at serve time: if the table's build date is older than the cadence allows, page the owning team.
Treat every similarity table as a perishable data product with an owner, a recompute cadence, and a monitored build date — not as a launch artefact. Track recommendation click-through and the share of the catalogue actually recommended on a dashboard; both decline under staleness. Review the cadence before major festival seasons, when baskets drift fastest. In handovers, list the recompute job explicitly — this failure is usually an orphaned cron job, not a modelling error.
Q: "Your recommender's click-through declined 15 percent over a quarter with no code change. Walk me through your diagnosis." Strong answer: check the similarity artefact's build date first, explain basket drift and the invisible-new-items effect, and propose a recompute cadence with a freshness alert plus an old-versus-new offline comparison before each swap. Reaching for "the model needs more features" before checking staleness is the weak answer.