The default advice in the WordPress ecosystem for product recommendation engines has become to throw AI at the problem, and it costs you performance and cloud budget at the same time. I have watched developers build TikTok-style deep learning models for a boutique shop with 200 products. That is expensive overkill and, frankly, poor architecture.
The Spotifys and Netflixes of the world have distorted what people think a recommender system has to be. A WooCommerce store is not solving their problem. Most of the time what you need is a reliable leaderboard and a few gradient-boosted trees (GBDTs), not a hybrid deep learning network.
The reality of candidate generation
Most recommendation systems open with candidate generation, cutting millions of items down to a few hundred. In WordPress that is usually a WP_Query or some custom SQL. With a small catalog, candidate generation is filtering by category or tag and nothing more. And when the context is a hard filter like “Price < $50", there is no vector search worth building. There is a database index worth optimizing.
Finding the items is the easy half. Ranking them is where most product recommendation engines fall apart, because they ignore two axes of complexity: observable outcomes and subjectivity.
1. Observable outcomes vs. catalog stability
At IKEA a purchase is a hard signal. Someone buys the sofa, they voted with their wallet, and you have a strong baseline to rank against. A high churn marketplace such as a second-hand site works nothing like that: items disappear the moment they sell, so a long-term leaderboard has no stable inventory to sit on. Ranking there has to come from feature-based models that predict conversion probability straight from attributes like brand or condition instead of popularity.
2. When taste is subjective
Ask whether preferences in your category converge or diverge. At Staples they converge, because nearly everyone wants the cheapest high quality ink, so one ordering serves almost every visitor. On Spotify taste diverges, and my favorite track is your immediate skip. If your WooCommerce store sells office supplies, deep personalization is wasted effort and a plain “Top Sellers” widget will probably beat the complex ML model.
The pragmatic stack: GBDTs over deep learning
When you genuinely need machine learning, gradient-boosted trees are the pragmatic choice for tabular e-commerce data. They train faster, they are easier to debug, and they do not need a VP-level cloud budget. They also do well on engineered features such as price point, location and device type, which is the shape the data already has in a store.
A mistake I run into constantly: hacking the related products output by querying the database on every page load. That is a bottleneck you build on purpose. Transients or a dedicated indexing service belong there instead.
<?php
/**
* Naive Approach: Direct Querying on every page load
* This kills performance as the catalog grows.
*/
function bbioon_get_naive_recommendations( $product_id ) {
$args = array(
'post_type' => 'product',
'posts_per_page' => 4,
'post__not_in' => array( $product_id ),
'orderby' => 'rand', // This is a race condition for slow performance
);
return new WP_Query( $args );
}
Rather than the random ordering above, hook into woocommerce_related_products and serve a pre-calculated score cached in a transient. That is how product recommendation engines survive a Black Friday surge without taking the server down with them.
<?php
/**
* Better Approach: Filter-based ranking with Transients
*/
add_filter( 'woocommerce_related_products', 'bbioon_rank_by_trend_score', 10, 3 );
function bbioon_rank_by_trend_score( $related_posts, $product_id, $args ) {
$transient_key = 'bbioon_recs_' . $product_id;
$ranked_ids = get_transient( $transient_key );
if ( false === $ranked_ids ) {
// Here you would implement your GBDT-based logic or simple score sorting
// For this example, we'll assume a 'trend_score' meta field exists
$ranked_ids = bbioon_calculate_trending_logic( $related_posts );
set_transient( $transient_key, $ranked_ids, HOUR_IN_SECONDS );
}
return $ranked_ids;
}
I wrote up how the WooCommerce platform handles this kind of architectural change in a post on the Zagreb Developer Meetup, where the core platform shifts came up.
If product recommendation engines are eating your dev hours, I can take it over. I have been working with WordPress since the 4.x days.
Stop chasing architectures you don’t need
Deploying the most complex model available is not the goal. Reading the constraints of your own terrain is. If your catalog is stable and your signals are clear, keep it simple. High churn or weak signals push you toward feature-based ML models. Either way, stop treating your WooCommerce site like it is Netflix, because the server and the client both pay for that. Diogo Leitão’s analysis on RecSys complexity is worth reading for the theory behind it.
