You know, sometimes the script just writes itself.
Several months ago, we did a webinar on recommender systems. The idea was to talk about a bunch of recommender strategies, and how one algorithm might not rule them all. So obviously we made a Lord of the Rings reference (anyone who has been to one of our offsites knows that Brandywine is indeed a river). In one promo video, they even took my bald, French-bearded head and put it in a Middle-Earth setting, like some kind of crystal meth Gandalf. (This is how we keep AI busy so that it can’t take over the world.)
The thing is, while we were doing all that, we were adding another recommender to the stack. The intuition behind this one was pretty simple: a recommender can be seen as a classifier that looks at customer features and product features, and predicts a score for each Customer x Product combination: is this customer likely to want this product? Customers can be characterized by a bunch of features, as can products, and the final layer is essentially a classifier trained on whether or not customers have bought products.
The submodule that calculates the customer features is called a customer tower, and the one that calculates the product features is the product tower… you can see where I’m going with this, can’t you?
Yep, Two Towers.
This isn’t a new idea, by the way. A bunch of major companies use variations of this two-tower recommender strategy. What we did was put a bit of our spin on it.
The Customer Tower: Reusing the SOLUS Customer Genome
For one thing, we already had a mechanism to calculate customer features, namely the customer genome. It incorporated socio-demographics, online and non-transactional behaviour, prior history of response to outreaches, and preferences around product, transaction type, channel, day/time etc. Not only did it cover a lot more facets than an engagement-driven embedding would (especially those that matter in domains such as BFSI, like socio-demographics), it was also pre-computed, so it saved on compute.
The Product Tower: Embeddings for Products and Attributes
Which left the product tower. Here, we used embeddings (see here for a tutorial introduction), but not just for the product, also for product attributes. This is because, in domains such as fashion retail, you and I could buy two subtly different shirts, but the fact that we’re essentially buying more or less the same thing is useful. Additionally, for product catalogs where products are described by tags, we added an optional embedding layer. At the other end of the spectrum, where there are very few product attributes and just customer engagement history to go by, embeddings are the way to go as well.
Also, since we had all those other recommenders sitting there, we added features around whether or not a product was recommended by the other strategies as well.
Which left the classifier layer that would put product and customer features together, identify examples where the product was purchased by a customer and ones where it wasn’t, and then build a model. Well, we had that already in our predictive scores module.
Et voila! Behold a new recommender inside SOLUS!
From Model to Business Problem: Why Compute Is the Real Challenge
The recommender itself is a fairly simple thing: the components are all easy to build or already built, and the existing SOLUS exoskeleton makes it easy to integrate it into the workflow. And the performance is pretty good too.
The real challenge lies in the compute. Imagine a 10M customer base with 100k recommendable products: the size of the result has an uncomfortable number of zeroes in it. Which is where we move from solving the ML problem to solving the business problem: why predict scores for everyone and everything, and not just focus on relevant subsets? For instance, we could focus on customers most likely to transact in the near future, or on products with some recent transaction history, and reduce the size of the problem by orders of magnitude.
Why This Approach Works
By scoring every viable customer–product pair on genuine likelihood-to-buy rather than crude popularity or last-purchase heuristics, the two-tower recommender surfaces products that fit each individual’s actual profile. And because the customer tower draws on the full genome (socio-demographics, channel and timing preferences, prior response to outreach) rather than engagement clicks alone, it can make relevant recommendations even to customers with thin transaction histories, which is exactly where cold-start problems usually kill engagement. The product tower’s attribute- and tag-level embeddings mean a shopper who liked one shirt gets shown genuinely similar-but-fresh alternatives instead of near-duplicates, keeping recommendations varied enough to stay interesting. Folding in signals from the other recommenders lets the model reconcile competing strategies into a single ranked list, so customers see a coherent set of suggestions rather than conflicting ones.
The net effect is more clicks, higher conversion, and, because outreach lands on the right people at the right time through the right channel, fewer irrelevant messages eroding trust. That’s the same putting-recommenders-to-work problem we’ve written about before: engagement compounds rather than fatigues over time.
Where This Goes Next
The nice thing about this approach is that it is extensible. For instance:
I could have a dataset with product images, use a computer vision algorithm to generate image tags, generate embeddings based on the tags, and then plug it in. This allows me to not just create a richer product master, but also make effective use of it in the recommender.
And since any AI/ML blog post that doesn’t mention LLMs can be accused of heresy (nowadays, everybody expects the Spanish Inquisition), here goes: I could have a bank of creatives, and some history of what customers responded to in the past. Embeddings for these creatives can become the second tower, tags describing the tonality can form additional features, and the rest of the problem works the same way. You could then deconstruct the result and provide advice to marketing decision makers on what kinds of creatives work for what kinds of customers.
All of these additional problems are also currently in the SOLUS pipeline. Watch this space!
