Filter and search: so that the buyer reaches the product in the catalog for thousands of items

Almost always in the characteristics. The module builds a filter from attributes: if they are empty in half of the products, and in the other half the same parameter is named in three ways, duplicates and empty lines appear in the list of values. The buyer makes one click, gets three items instead of thirty or more, does not use the filter. Therefore, the work begins with a dictionary of characteristics for each large category, and not with the module settings. A fair margin: A filter doesn't add demand to an unsearched product—it just removes the barrier between the intent and the card.

It will collapse if you leave it without rules. Each selected parameter creates an address, combinations multiply, and a catalog of several thousand products is capable of generating hundreds of thousands of almost identical pages. Working rule: only those combinations for which there are real requests remain open, the rest receive canonical per category and are closed from bypassing. For scale: even without any facet, we recorded 33,493 sitemap entries for 8,690 unique addresses. We immediately warn about a side effect - after cleaning, the number of pages in the index drops for some time. This is a normal course of events, not a deterioration.

Not necessarily. The gear store we measured held 54,302 products and 635 categories and had a first response of 413.8ms, a full HTML load of 511.1ms. The second store with a catalog of 5,561 items with a tenfold smaller volume and a light HTML of 153.8 KB gives the first answer in 801.2 ms: it's not about the number of products, but about the indexes of the base, the cache, and how many requests the theme makes. Let's clarify the limit right away: our dimension is the server part. What a particular buyer will see depends on their device, network and the weight of the pictures in the category.

Don't show a blank page at all. The minimum is counters next to each value: a person sees the number of items before a click and simply does not enter an empty sample. The second layer is a "nothing found" page with a named filter that filters out the most and a button to remove it. A technical detail: the count for counters in a large catalog must be cached separately from the page, otherwise each click recalculates the count for all values ​​— and the filter, which was supposed to speed up the selection, starts to slow down the page.

Because of the recording format. In the database, the article is with a hyphen, the buyer enters without it - or vice versa, with a space in the middle or in another case. It is necessary to normalize from both sides: we clean both what was entered and what is in the database, and we keep the result as a separate field for searching. Next — search by part of the name and resistance to typos. This is the cheapest of the improvements that generally affect sales in a large catalog. The limit here is obvious: the search helps someone who already knows the name or article number. A buyer who is still choosing needs categories and a filter.

Really, and this is usually what the project is all about. The procedure is as follows: we analyze the descriptions with a parser one category at a time, get a list of the found values, read it by hand - at this step, both the print and the units of measurement in three variants always come out - and only after that we fill in the attributes. No one will say how long it will last until the audit, so the stage is a separate line in the estimate and a separate line in the calendar. If some of the items have no parameters in the text at all, we honestly say how many there are, and you decide whether to add them manually or leave them out of the filter.

10-25 working days. Layout: audit and feature dictionary days 1–3, attribute tuning 3–8, address filter and rules 2–5, search 2–4, sampling rate 1–3, acceptance 1–2. The deadline is postponed by exactly one thing - the second stage. If the attributes are populated and named the same, this is a setup and optimization at the bottom of the range. If they need to be extracted from the descriptions of several thousand items, the main time will be spent on this. The second reason for the shift in our memory is non-technical: the decision about which parameters to put in the filter is made by someone from your side, and without this person, the stage stands still.

Because it is not determined by the number of goods, but by the state of the characteristics, which cannot be seen from the outside. Two stores with the same catalog of 6,000 items can differ in the amount of work by many times: in one the attributes are established and it remains to assemble the facet, in the second everything lies in the text of the descriptions. Calling a fork for inspection is either to frighten someone whose work is short, or to promise an amount that will not be enough. Therefore, first, a free audit of the catalog in 2-4 working days with the document in hand, then the amount and term by stages with dates, the contract, the invoice, the act.