Collaborative filtering recommends products based on patterns in customer behavior. Instead of relying only on product attributes such as category, brand, or price, it asks a practical question: which customers behave similarly, and what did one customer interact with that another customer has not seen yet?
For a WooCommerce store, this can produce recommendations such as “Customers who bought this also bought…” or “Recommended for you.” The system learns from events including product views, searches, add-to-cart actions, purchases, wishlist additions, and review activity.
What collaborative filtering means
Collaborative filtering uses the behavior of many customers to make recommendations for an individual customer. The products do not need to share the same category, attributes, or keywords. The relationship comes from customer activity.
For example, suppose the following customers purchase these products:
- Customer A buys a pour-over coffee maker and a paper filter pack.
- Customer B buys a pour-over coffee maker, a paper filter pack, and a digital scale.
- Customer C buys a pour-over coffee maker and a digital scale.
A recommendation system can identify that customers who purchase the coffee maker often purchase the digital scale. The scale may be recommended to a new customer who has purchased the coffee maker, even if the product catalog does not explicitly define the two products as related.
The two common approaches
User-based collaborative filtering
User-based filtering finds customers with similar behavior and recommends products those customers interacted with. If two customers have viewed and purchased many of the same products, a product purchased by one may be recommended to the other.
This approach is easy to explain to stakeholders, but it can become expensive or unreliable when a store has millions of customers or many customers with very little activity.
Item-based collaborative filtering
Item-based filtering finds products that frequently appear in the same customer journeys. It can recommend products that are commonly viewed, added to carts, or purchased alongside the current product.
Item-based recommendations are often a strong fit for WooCommerce product pages because they are relatively stable and can be calculated in advance. A product page for a camera, for example, can display frequently co-purchased memory cards, batteries, or compatible bags.
Behavior is not all equal
A recommendation engine should distinguish between different types of activity. A product view indicates interest, but a completed purchase usually provides stronger evidence. An add-to-cart event is meaningful, although it does not always indicate a final preference.
A practical event hierarchy might look like this:
- Completed purchase: strongest signal for product affinity.
- Add to cart: strong intent, but not a confirmed purchase.
- Wishlist addition: useful preference signal where available.
- Product view: weaker signal that may represent browsing or comparison.
- Search interaction: useful context, especially for active shopping sessions.
Agencies should also account for negative or corrective signals. A product that was viewed once and immediately followed by a return should not receive the same treatment as a product purchased repeatedly. Cancellations, refunds, out-of-stock events, and explicit recommendation dismissals can be excluded or assigned lower importance.
How this fits into WooCommerce
Collaborative filtering typically needs a reliable event pipeline rather than only the current contents of the WooCommerce database. Useful data sources include orders, order items, product views, search events, cart events, customer accounts, and consent-aware session identifiers.
For purchase-based recommendations, an agency can begin with WooCommerce orders and order items. A scheduled process can create product relationships from recent orders and write the results to a custom table, object cache, or external recommendation service. The storefront then requests recommendations using the current product ID, customer ID, or session ID.
A simple item-based workflow is:
- Collect completed order and product interaction events.
- Remove excluded orders, test orders, refunded transactions, and products that should not influence recommendations.
- Group products that appear in the same customer journey or order.
- Count and rank the relationships, applying stronger weight to recent or higher-intent events.
- Store the top related products for fast retrieval.
- Filter the result at display time by stock status, catalog visibility, customer eligibility, and current cart contents.
The display layer should not assume that a previously calculated relationship is still valid. A product may be out of stock, discontinued, restricted by customer role, or incompatible with the current cart. Recommendation retrieval and storefront eligibility checks should remain separate steps.
Practical recommendation placements
Product pages
Use item-based relationships to show products frequently purchased or viewed with the current product. This is usually the easiest placement to test because the context is clear and the recommendation can be generated from the product ID.
Cart and checkout
Cart recommendations can identify complementary products, but the engine should avoid suggesting products already in the cart. For a subscription store, the recommendation logic should also understand whether an item is compatible with the customer’s current subscription frequency.
Order confirmation and post-purchase email
After a purchase, recommendations can focus on replenishment, accessories, or products frequently bought by customers with a similar order history. Timing matters: a replacement filter may be appropriate several weeks after a coffee equipment purchase, while an accessory may be useful immediately.
Account dashboards
Logged-in customers provide more history than anonymous visitors. An account dashboard can show recommendations based on previous orders, but it should provide an understandable way to dismiss or ignore suggestions. Personalization should not make it difficult to find ordinary account functions.
Cold-start problems
Collaborative filtering needs activity. A new product has no interaction history, and a new visitor has no known behavior. These are known as item and user cold-start problems.
Use fallback rules when there is insufficient data:
- For new products, use category, attribute, brand, or manually curated relationships.
- For new visitors, use current-session behavior, popular products, bestsellers, or campaign context.
- For low-volume stores, combine store-wide purchase relationships with merchandising rules.
- For seasonal catalogs, apply a time window so old behavior does not dominate current demand.
A hybrid system is generally more practical than a pure collaborative-filtering system. Product metadata handles cold-start cases, while behavioral relationships improve relevance when enough activity exists.
Common implementation mistakes
Using raw co-purchase counts
A product that sells frequently will appear related to many other products simply because it is popular. Normalize or rank relationships so that popularity does not overwhelm meaningful associations. Also consider the difference between a product bought by nearly everyone and a product that is unusually common among buyers of a specific item.
Ignoring time
Customer behavior changes. A recommendation based on three-year-old orders may be inappropriate for a fashion catalog, a seasonal business, or a store with frequent product replacements. Use a defined lookback window or reduce the influence of older events.
Recommending unavailable products
Always check WooCommerce stock status, purchasability, catalog visibility, and product status before rendering a recommendation. Do not rely only on the data captured when the relationship was calculated.
Leaking sensitive behavior
Recommendations can reveal more than intended. A shared household computer, a B2B account, or an account used by multiple staff members may produce misleading or sensitive suggestions. Avoid displaying personal purchase history in public contexts, and document how events are collected, retained, and associated with customers.
Overpersonalizing low-confidence data
One accidental click should not radically change a customer’s storefront. Require enough evidence before making strong recommendations, and provide broad fallback content when confidence is low.
Measuring recommendation quality
Revenue is useful but incomplete. Track the performance of each placement and compare it with a control group or existing merchandising logic.
- Recommendation click-through rate measures whether the placement attracts attention.
- Add-to-cart rate shows whether recommended products create shopping intent.
- Conversion rate measures completed purchases associated with recommendations.
- Average order value shows whether recommendations increase basket size.
- Attach rate measures how often a recommended item is purchased with the anchor item.
- Margin contribution helps prevent a revenue increase from reducing profitability.
- Coverage shows what percentage of products or customers receive meaningful recommendations.
Use an experiment design that avoids counting every purchase from a customer who happened to see a recommendation. For example, randomly assign eligible visitors to a recommendation treatment or control group, define the attribution window in advance, and evaluate results by device, customer status, traffic source, and product category.
A sensible WooCommerce rollout
Start with a narrow, explainable use case such as “frequently bought together” on product pages. Use completed orders, exclude refunds and test data, and generate relationships on a schedule rather than calculating them during every page request.
Once the data pipeline is reliable, add recent views, cart events, customer-level recommendations, and placement-specific rules. Keep a fallback for every request and log which recommendation source was used, such as collaborative, catalog-based, bestseller, or manually curated.
For debugging, store enough context to answer practical questions without exposing unnecessary personal data: the placement, anchor product, recommendation source, model or rule version, returned product IDs, and eligibility filters applied. This makes it possible to explain why an item appeared and to compare changes across deployments.