Why content personalization runs into manual rules
Manual configuration of blocks usually starts with visitor segments: city, referral source, device type, order history. While there are three or four conditions, the rule tree is still readable.
As soon as a behavioral attribute or a new product category is added, the number of combinations grows multiplicatively — and maintaining such a scheme turns into separate ongoing work.
Segments live longer than the assortment. A category was renamed, a product went out of stock, a new line appeared — the rule continues to reference the old set and shows an empty or irrelevant shelf.
No one deliberately goes to disable it; the error surfaces in reports when the wrong visitors have seen the block for weeks.
The second bottleneck is page context. A block is configured for the entire template, so the same selection of materials on the site appears on the review, on the product page, and in the delivery section.
Content personalization in this form answers the question “who came,” but not the question “why they are on this page.”
Then editorial gets stuck. Between publishing a material and it entering the selection, there is a manual cycle: approve, create a rule, check, roll out. While it goes through, the topic has already cooled.
There is also no feedback: the rule doesn’t know the block isn’t opened and continues to be shown at the same frequency.
In sum, a predictable ceiling emerges: the more segments and materials, the more expensive maintenance, and the more the output lags behind the actual catalog state.
Let’s break down how this is closed — by a model that assembles the selection itself and updates based on behavior, not edits in the admin panel.
What changes after implementing AI material selection
While the selection is assembled by an editor, the effect of personalization is limited by their time: ten manual links per week is a ceiling that doesn’t scale with traffic.
Automated selection removes the limitation — material affinity is calculated from what has been read and from the visitor profile, selection runs on top of the search index on Elasticsearch, and the editorial team moves from manual assembly to configuring rules and handling exceptions.
What we record with measurements a few weeks after launch:
- Share of deeper-site transitions. Before implementation, about 80% of visitors ended the session on the first material; after, every third goes to a second and third material.
- Page depth. 2.1 pages per session turns into 3.2–3.5: visitor engagement grows through relevant links, not pop-up banners.
- Time to prepare selections. Hours of manual work on the “read also” block are reduced to 10–15 minutes: editorial only approves or removes what the system suggests.
- The failure class “we show everyone the same thing.” The storefront stops being static: a new visitor sees popular content, a returning one sees a continuation of the topic, not the same list.
- Editorial offload. Freed-up hours go into new materials, not manual interlinking of sections.
We conduct measurements on our own projects and compare comparable windows before and after launch to separate the effect of automated selection from seasonality and one-off publications. This shows what personalization specifically delivered and what came from external factors.
Selection scenarios: rules, models, hybrid scheme
The selection scheme is chosen not by the model’s “newness” but by the volume of accumulated data and catalog diversity. Display rules give an explainable and reproducible result, but transfer poorly to new content: every combination of conditions has to be added manually.
A behavioral selection model removes this routine, but runs into cold start and rare materials. Therefore, in practice, five working options are compared — from manual segments to a ready-made external selection service.
| Option | When it fits | Limitations |
|---|---|---|
| Manual rules and segments | Catalog is stable, few criteria, need fully explainable display | Number of combinations grows faster than traffic; new material doesn’t enter selection without editing rules |
| Behavioral model based on actions of similar visitors | There is accumulated history and a noticeable share of repeat visits | Cold start, rare materials without statistics, sensitivity to log completeness |
| Model based on the material’s own attributes | Content is updated constantly, no history for it yet | Requires filled card attributes; with empty fields, selection becomes formal |
| Hybrid scheme with reranking | Traffic is mixed: some visitors are new, some are returning | Harder to operate: need control over layer weights and monitoring of discrepancies between them |
| Ready-made selection service | Need fast launch and no resource for own model | Limited logic configuration, data transfer outside, dependency on someone else’s export format |
Reasonable to start with rules and measuring their return, and move to hybrid recommendations as action history accumulates.
Rules are not discarded — they remain the frame and priorities within which the model reranks the output, and metrics show which layer actually influences behavior.
How we implement content personalization: from audit to launch
Personalization more often breaks not on the model but before it: if event logs lack the traffic source and goal markup, and features are collected after the block is displayed, the model shows beautiful numbers on the training set and zero effect on live traffic.
Therefore, the sequence of work is fixed — first we determine what can be predicted at the moment of display, and only then we build the selection system.
-
Website data audit. We analyze which signals are already collected: view events, search, request history, session context. We check the share of empty fields, gaps in records, and the delay between an action and its appearance in storage. Result — a feature map: what is available at decision time and what arrives too late.
-
Goal and feature scheme. We fix what we optimize — click, page depth, or request — and separate features by availability time so future data doesn’t get into training.
-
Assembly and training. We prepare the data mart, train several variants, and compare them on a holdout period. We take not the best on one spike, but the stable one across several slices.
-
Shadow model launch. The system calculates recommendations on live traffic, but visitors see the previous logic. We look at the share of discrepancies and assess how much more relevant the model’s suggestions are than the current ones.
-
Control group. We split traffic into control and test and check the lift on the target metric along with no drop on the others. This separates real effect from seasonal fluctuations.
-
Phased rollout. The traffic share grows in steps, with automatic rollback to the previous logic if metrics go beyond specified boundaries.
-
Handover to support. We hand over configurations, retraining regulations, a metrics panel, and training for the customer’s team — the system can be developed without us.
Artifact package: schemes, accesses, regulations, documentation
Personalization lives not in code but in rules and parameters: the set of signals, their weights, display thresholds, role permissions.
Therefore, together with the system, we hand over a package by which your engineers can operate it, change selection logic, and decommission it without our support. Below is what remains in your hands.
- Data and flow scheme: which events are collected (views, search, comparison, orders), where profiles are stored, what enters the selection data mart and with what delay.
- Description of features and ranking logic: which signals participate, how weights are calculated, what is shown to a new user without history.
- Selection service configuration: mode switches, display thresholds, exception and manual pinning rules, points where parameters change without rebuilding.
- Access policies and roles: who sees raw events, who edits weights and thresholds, who only reads reports, how the change log is maintained.
- Model update regulation: retraining frequency, checklist before rollout, metrics at which an update is blocked.
- Rollback regulation: how to return the previous version, in what time, who makes the decision, and what happens to already displayed blocks.
- Observability: which metrics are collected, which thresholds count as degradation, who receives notifications and how.
- System documentation: component map, integration schemes, environment descriptions, launch and acceptance procedure.
- Instructions for editorial: how to set promotional selections, how they coexist with automation, and how to remove a manual rule.
Case study: how page depth grew on a news portal
What was and what changed
The editorial team assembled “read also” blocks manually: the duty editor once per shift placed 5–6 links for each material; selections took 3–4 hours.
Page depth held at 1.8 pages, 6% of transitions went to related materials, and on long feeds the links repeated — the reader hit the same texts.
Selection was split into two layers: semantic similarity of texts — by vectors of headline and lead; behavioral — by the reader’s session history.
Fresh materials received an increasing weight, those stuck at the top received a decreasing one, and the editor kept 2–3 manual positions per block. Response was measured by transitions and read-throughs, not impressions.
Metrics on the control group
Measurements were conducted on a control group: 10% of traffic received the previous manual selections for two weeks, the rest received personalized ones.
Page depth grew from 1.8 to 3.1 pages, the share of transitions to related materials — from 6% to 19%, returns within 24 hours — by a third. Selection assembly decreased from 3–4 hours per shift to 20–30 minutes: the editor only approves or removes suggested links.
The product owner of Vecherniy Gorod puts it this way: “We expected growth in page depth, but something else turned out to be more important — the editorial team stopped spending a shift on manually assembling links and focused on texts.
Personalization does not argue with the editorial agenda: an editor’s pin is always higher than machine ranking.”
How does a recommendation model differ from display rules?
Display rules are a set of manually recorded conditions: if a visitor came from search and has already viewed a category, we show a block with similar materials; if the cart has been empty for more than a minute — a delivery block.
The logic is deterministic: any output can be explained, reproduced, and debugged, and the block’s behavior doesn’t change without editing the configuration.
The problem starts with catalog growth and the number of segments. There are more and more conditions, priority conflicts appear between them, and each new section requires another manual edit.
After several iterations, no one can say why a specific visitor was shown exactly this block — the rules work but stop scaling.
The recommendation model builds connections between materials and visitors based on actual behavior: views, transitions, favorites, retention time.
These connections are recalculated regularly, so new material enters the output by itself, and combinations the analyst didn’t plan are found in the data.
Here the difference in approaches becomes measurable: rules answer “what we decided in advance,” the model answers “what behavior confirmed.”
The price of the model is data and discipline.
You need a volume of events sufficient for stable connections, cleaning of noisy signals and protection against manipulation, an update regulation, and quality monitoring: if audience tastes shift, the output degrades quietly, without errors in logs.
Plus cold start — for a new visitor there are no signals yet, and here the same rules provide backup.
In practice, the approaches don’t compete. Rules remain the framework: hard constraints, stop content, mandatory blocks. The model works within this contour and recalculates personalization — we accumulate events and gradually give it the part of output where it wins on metrics.
FAQ on data, models, and load
Before starting, the customer checks approximately the same things: whether accumulated behavior history is enough, what to do with personal data, how personalization will fit into the current site and whether page response time will drop.
We answer not with general words but with a calculation on your data — event volume, share of users with history, catalog structure, integration point: markup, server layer, or request to the selection storage.
Below are answers to doubts that most often surface before signing the work plan. If your case doesn’t match the typical one, describe the task — we’ll come back with an estimate and scheme.
There is little behavior history — does it make sense to launch?
Yes. At the first stage, output is built on content features and segmentation rules, and behavioral signals are connected as they accumulate.
Until then, the system works in cold start mode: it shows what is in demand within the segment and gradually replaces these blocks with personalized ones.
How does the system handle personal data?
Only pseudonymized identifiers, events, and aggregates go into the model — not names, phone numbers, or addresses. Retention periods and deletion procedures are fixed in the documentation, and a user deletion request clears their history and triggers feature recalculation.
Will this fit into the current site and slow it down?
The selection is served from prepared storage rather than recalculated on every page view, so response time doesn’t grow.
Integration goes into existing templates; if the external component is unavailable, rollback to a static block is triggered — the page is served in full, without a personalized selection.
How can we make sure personalization works?
We launch in stages: part of traffic goes to the new logic, part to the current output. We compare groups by page depth, second-level transitions, and target action — this removes the influence of seasonality and novelty effect.
What is included in support after launch?
We monitor the share of empty outputs and selection quality, including after changes in assortment or catalog structure. Retraining occurs on schedule and by trigger when metrics diverge from expected; before release, we run regression on historical data.
Let’s discuss the task and come back with an implementation plan
Personalization project evaluation starts not with model choice but with your data: without behavior history, section markup, and understanding of target metrics, any architecture remains a guess.
Therefore, to start, a minimal but concrete set of inputs is needed — from it we calculate the scope of work and risks, not average market figures.
- analytics export for a representative period: view, transition, search, favorites events;
- list of site sections and blocks where content should change per user, with priority;
- target metrics: what we consider success — session depth, repeat visits, conversion to request;
- constraints: what cannot be changed in the current layout and content management system, requirements for storage and pseudonymization of personal data;
- decision owner on your side — with them we will agree on disputed points without delays;
- current data scheme: where materials come from and how often they are updated.
In response, you receive not an overview presentation but a working document: a phased implementation plan with checkpoints, team composition for each stage, a list of requirements for your infrastructure, and boundaries — what is included first and what is consciously deferred.
Describe the task and send what you already have — we’ll come back with an estimate and implementation plan.
