Search that understands intent
Product Search and Recommendations
On most stores, a large share of searches return nothing, and almost everyone who sees an empty result leaves. This is the engineering work of fixing that: semantic search over your catalogue, synonyms, and recommendations that use what your shoppers actually do.
What Product Search and Recommendations covers
On most stores a large share of searches return nothing, and almost everybody who sees an empty result leaves rather than trying a different word. That is not a search box problem. It is a catalogue problem wearing a search box.
Product search and recommendations work therefore starts with your data: attributes that are inconsistent, synonyms nobody recorded, and categories that made sense to whoever set them up years ago. Semantic search over a catalogue in that state returns confidently wrong answers, which is worse than returning none.
We have no published case study for this work, and we are not going to borrow one from our commerce projects to fill the gap. What we can offer is a scoped first phase against a number you already track, so the question of whether it worked has an answer rather than an opinion.
Is this the right fit?
A fit when
- A measurable share of your site searches return no results
- Shoppers search in their own words and your catalogue uses different ones
- The catalogue is large enough that browsing is not a realistic path
- Recommendations today are manual or from a plugin nobody has tuned
- You already have traffic, so improving conversion beats buying more of it
The wrong choice when
- The catalogue is small enough to browse comfortably, where good navigation is cheaper and better
- Product data is thin or inconsistent, which has to be fixed before any search can work
- You have no analytics, so there is no way to tell whether it helped
- You want a chatbot on the store, which is a different piece of work
What you get
Semantic search
Retrieval that matches meaning rather than exact words, so a shopper searching for what a product does finds it even when your catalogue names it something else.
Catalogue preparation
Product data cleaned, enriched and embedded. Usually the largest part of the work, and the part that decides whether the rest is any good.
Recommendations
Related and complementary products from your own behaviour data, with rules you control for margin, stock and what must never be recommended together.
Search analytics
What people search, what returns nothing, and what they do next. This is a merchandising tool in its own right, separate from the search itself.
Evaluation before launch
A test set of real queries with expected results, scored before and after. Without this, "better search" is an opinion.
Cost and latency control
Caching, embedding reuse and a fallback to conventional search, so a provider outage degrades the experience instead of breaking the store.
How it runs
-
Search log analysis
We start with what people already search on your store and what currently fails. That tells us the size of the opportunity before you commit to anything.
-
Catalogue and evaluation set
Product data prepared, and a scored set of real queries built so improvement can be measured rather than asserted.
-
Build and tune
Retrieval, ranking and recommendation rules, tuned against the evaluation set rather than against whoever is loudest in the review meeting.
-
Launch behind a switch
Released so it can be compared against your current search and turned off instantly. Nothing goes live without a way back.
Built with
The platform and the tools around it. Nothing here is chosen because it is new.
- OpenAI
- Claude
- pgvector
- Pinecone
- Elasticsearch
- PostgreSQL
- Redis
- Shopify
- WooCommerce
Questions we get asked
How do we know it is actually better?
A scored evaluation set of real queries from your own logs, run before and after. If it does not improve the score, it does not ship.
What does it cost to run?
Embeddings are generated once and reused, and queries are cached, so ongoing cost is far lower than people expect. We instrument spend from day one rather than letting you find it on an invoice.
What happens if the provider goes down?
The store falls back to conventional search. A shop that cannot be searched because an external service is unavailable is not an acceptable design.
Does this work with Shopify or WooCommerce?
Yes. It sits alongside the platform rather than replacing it, and the storefront keeps working exactly as it does now if the feature is switched off.
Is our product data good enough?
Often not at first, and that is worth knowing early. The search log analysis tells us, and if the answer is that data preparation is the real project, we will say so rather than building on top of it.
Tell us what you are building.
Send the problem and any constraints you already know about. You get a scope, an approach, and a real cost range - written by a person.