In the previous article on RecSys Studio we went through how to load your own recommendation algorithm into Gravity Field and prove it on revenue: the ways to connect it, how a launch runs, which metrics to watch. That answers the question “how does a model get into production”.
This article is about the next step. The algorithm is loaded: what do you do with it, and how do you combine it with what the platform offers — filters, merchandising rules, a mix of algorithms across slots, output preview and A/B tests. In short: how to get from “our model is in production” to a manageable output you can rebuild around business goals in minutes, without retraining the model.
Why this matters: two typical situations
The algorithm already exists — your ML team built it
You have a model trained on your own data and for your own specifics: seasonality and size grids in fashion, component compatibility in electronics and DIY, purchase regularity in e-grocery. It knows your catalogue better than any universal model, and its offline ranking metrics look good — but the shopper still does not see it.
Then the infrastructure work begins: which pages and which blocks show the result, how the model is wired to the storefront and the product feed, what a new user sees if the model returns nothing, how the new logic is compared with the current one and how its contribution to orders and revenue is calculated. Build that separately for every model, and “roll out recommendations” becomes a project measured in weeks — with some of the models never leaving the analysts’ notebooks.
Rules and filters need to be changed quickly
Even when the algorithm is already running, requests keep arriving that it cannot handle by itself: promote the summer sale until the end of August; drop private label from this block because it is about supplier brands; put the two promo bestsellers in the first positions; do not recommend products the shopper has already bought.
If rules like these live inside the model’s code or in your own delivery service, every request from a category manager turns into an engineering ticket and a release. By the time the change reaches production, the promotion may be over. It should be the other way around: rules, filters and extra settings changed in the interface in minutes, by a marketer or a merchandiser, with no model retraining.
Both situations share a common denominator: product recommendations have two goals, and different layers answer for them. Relevance is the algorithm’s job. Stock, margin, promotions and private-label limits are the job of the rules on top of it. That is exactly how responsibility is split in Gravity Field: through RecSys Studio you load your algorithm, and the platform provides everything else — delivery on the site, filters and merchandising rules, preview, A/B tests and revenue reporting. The model stays yours, while managing the output becomes configuration rather than development.
In brief: what RecSys Studio is
RecSys Studio is an environment for running your own algorithms (BYOA — Bring Your Own Algorithm) inside the Gravity Field platform. The split of responsibility is simple: your algorithm decides which products to offer and in what order, and Gravity Field turns that output into a manageable scenario — with pages, blocks, audiences, delivery rules and A/B tests.
There are two ways to connect an algorithm:
- Pre-computation — recommendations are calculated in advance on the Gravity Field side and published for delivery.
- Real-time API — Gravity Field calls your model’s API at request time.
An “algorithm” here does not have to be an ML model: rule sets and attribute-based matching work too. And if you have no model of your own but do have particular logic you want to test, the Gravity Field team can build a specialised algorithm for it.
Versioning is a capability in its own right. Every version of the model is registered in the catalogue with its own number, and a new version can be rolled out in an A/B test against the current one. You raise the traffic share going to the new version only when it wins on conversion, orders and revenue — not on offline ranking metrics.
A detailed walkthrough of the connection is in the article on running your own algorithms: scenarios by industry, the order of work, data requirements. From here on, this article is only about what to do with an algorithm that is already loaded.
Why relevance alone is not enough
A model optimises what it was trained on: clicks, conversion, the accuracy of predicting the next purchase. It knows nothing about the warehouse being full of last season’s collection, about margin differing across a category, about a promotion contract signed with a supplier, or about the share of private label in the output needing to be capped — or, conversely, increased.
That is fine. Hard-coding constraints like these into the model itself is bad practice: business conditions change faster than a model can be retrained. Today you are clearing the summer collection; a month later you are promoting new autumn arrivals. The right architecture puts relevance on the algorithm’s side and business logic into rules that can be switched on and off in minutes.
That is how output management works in Gravity Field: filters and merchandising rules are applied on top of any algorithm — one built into the platform or your own, connected through RecSys Studio.
Filters and rules: managing the output without retraining the model
Preset filters
Ready-made filters are switched on in the strategy settings and solve standard tasks based on user behaviour and page context: exclude recently viewed or purchased products, show only products from the current product’s category, include or exclude products with the same attributes (brand, colour, season), and on the search page show only products matching the query.
One important detail is relaxation logic. If a strict condition does not yield enough products, the filter does not break the widget — it relaxes step by step: first the system looks for a full match on the category path (“Clothing > Men’s > Trousers”), then trims the last level and searches again. The same applies to attributes: for a “brand + colour + season” list, season is dropped first, then colour, while brand stays a required condition. If there are still too few products, a fallback algorithm kicks in, and the widget gets filled either way. For the shopper that means a recommendation block will not end up empty because a filter was too narrow.
Merchandising rules: Include, Exclude, Pin
Custom rules give you control over the output by any field of the product feed — category, brand, price, discount, season, private-label flag:
- Include — keep only products matching the condition in the output. For example, only discounted items from the summer collection.
- Exclude — remove products by condition. For example, drop private-label products from a block that promotes supplier brands.
- Pin — fix a specific product in a specific position. The highest-priority rule: the slot goes to that product regardless of what the algorithm decided.
Rules can be applied to the whole output or to individual slots, and they can be combined: include kefir in every slot but exclude private-label kefir. A single strategy supports up to 30 rules; different rules are combined with AND, while within one rule you can use OR.
This is how the standard merchandising tasks get solved: clearing stock (Include by discount and season on some of the slots), promoting new arrivals and collections, guaranteeing that promo products appear (Pin in the first positions), managing margin (Include by high-margin categories in the most visible slots).
Pin deserves care: if a pinned product runs out of stock, the slot can end up empty. And filters and rules must not contradict each other — including a category in a filter and excluding the same category in a rule means an empty output.
Dynamic filters
A class of its own: real-time rules passed directly in the recommendation request and working on current-session data — show products more or less expensive than the one being viewed, filter the output by the brand the user selected in the listing filters. That is how recommendations adapt to context that is only known in the moment.
One widget, several algorithms
A recommendation block usually runs on a single algorithm. In Gravity Field that limitation is removed at two levels.
The first is the “algorithm per slot” feature: different positions in the widget can be assigned to different algorithms. Slots 1–3 might carry personal recommendations based on the user’s interests, slots 4–6 “bought together”, and the rest popular products from the category. The most personal recommendations land in the most visible positions, and the block stops looking uniform. The system deduplicates products across slots, and if one algorithm returns nothing (a personal one for a new user, say), the slot is filled by the default algorithm.
The second level is mixing your own algorithms with the platform’s. A model connected through RecSys Studio does not replace the Gravity Field recommendation engine — it complements it: some positions can come from your model, some from the built-in engine, some from another model of yours. You could mix personal recommendations with higher-margin products and new arrivals in a single widget. The mix is compared with the current strategy in an A/B test, and whichever version is better for the shopper and the business is the one that stays.
For a team developing recommendations, this changes the pace of experimentation itself: the hypothesis “what if the top of the block came from our model and the tail from popular products” is tested by configuring a strategy, not by running a separate engineering project.
Speed of launch: preview instead of a release
The classic problem with any output rules is “we configured it, published it, and only then saw that the filter was too narrow”. In Gravity Field there is an intermediate step between configuration and publication — the recommendation strategy preview.
In the preview you set the context: the user and session identifier, the page type (product page, category, cart), a specific SKU or category — and you see the output the strategy will assemble in exactly that context, taking the algorithm, filters, pins and fallback logic into account. You can check the strategy on a user with purchase history and on a new one, on a high-traffic category and on a thin one with few products.
The working cycle looks like this: assemble a base strategy with the algorithm and the critical filters — look at the preview — add filters — preview again — add merchandising rules — preview again — publish the best version and launch an A/B test, for example “with rules versus without rules”. Each iteration takes minutes and needs neither a release nor engineering involvement.
Analytics: how much money each strategy brought in
The final link is reporting. Every recommendation strategy in Gravity Field appears in the strategy report with business metrics:
- Direct Revenue — revenue from products the user clicked in the widget and then bought, plus its share of total site revenue;
- Direct Revenue (All Variants) — the same, accounting for product variants: a click on a size L t-shirt followed by a purchase of size M counts;
- Assisted Revenue — revenue from all purchases in the session after an interaction with the widget;
- Direct Revenue per 1000 — direct revenue per 1,000 viewable impressions, the main metric for comparing strategies against each other;
- CTR, click-to-purchase conversion, Visibility — the widget funnel: is it seen, is it clicked, is there a purchase after the click;
- Fallback % and Empty % — how often the backup logic fires and whether the strategy’s constraints are too tight.
The key report setting is the attribution window: Session, 1, 7, 14 or 30 days. In e-grocery and FMCG a purchase from recommendations happens in the same session; in furniture or electronics the decision ripens over weeks — and judging those categories by a session window means underestimating the contribution of recommendations several times over. Being able to look at the performance of each strategy across different attribution windows is precisely what teams used to standard web analytics reports are missing: no other tool on the market offers this depth of recommendation analysis across metrics and attribution windows.
For end-to-end analytics there is an xlsx export at the level of individual purchases — with SKU, product group, order amount and attribution type — so you can test hypotheses in your own BI system.
That closes the loop: a merchandising rule stops being “we set it up and we believe in it” and becomes a testable hypothesis. Switch on Include by sale, compare in an A/B test, look at Direct Revenue in the right attribution window — and keep the version that brings in money.
How it looks in practice
Picture a fashion retailer that needs to clear the summer collection by August without wrecking its margin.
- The data team connects its own ranking model, which accounts for seasonality and margin, through RecSys Studio.
- In the strategy, the first widget slots are given to that model and the tail to popular category products via “algorithm per slot”.
- An Include rule for “summer season + discount” is applied to some of the slots, and two sale bestsellers are pinned to visible positions.
- The strategy is checked in the preview — on a user with history and on a new one, across different categories.
- An A/B test is launched against the current strategy; the decision is made on Direct Revenue and conversion in a 7-day attribution window.
None of these steps required a separate engineering project — and in a month, when the task changes to promoting autumn arrivals, the output can be rebuilt just as quickly.
Conclusion
RecSys Studio removes the main barrier in front of your own recommendation algorithms — the infrastructure one: the model connects to a ready-made system of delivery, targeting, A/B tests and reporting. Filters and merchandising rules add the language of business goals on top of relevance: stock, margin, promotions, new arrivals — with no model retraining. Strategy preview and “algorithm per slot” provide the speed: hypotheses are assembled and tested in minutes, including mixes of several algorithms in one widget. And reporting with attribution windows shows how much money each strategy brought in.
The current limitations are worth keeping in mind: connecting a new algorithm still happens together with the Gravity Field team, a strategy has limits (up to 3 filters and up to 30 rules), and blunt instruments like Pin require care. But it is exactly this combination — your own algorithm plus a manageable output plus fast validation — that lets you develop recommendations as a product rather than as a series of one-off integrations.
If you already work with Gravity Field, contact your account manager to discuss connecting your algorithm and configuring output rules. If you are still evaluating, request a personal demo: we will show RecSys Studio and the merchandising tools on examples from your industry.
