AI personalization in beauty: where matching breaks down
AI personalization in beauty breaks down more often not in the model, but at the data junction: customer questionnaire, product card, and inventory live in different systems and update at different frequencies.
The algorithm calculates correctly, but receives contradictory features — and the output looks random.
Empty recommendation outputs are the most common failure. As soon as availability, exclusion of unwanted ingredients, and match with a previous purchase are added to skin type, the intersection of conditions becomes zero, and the block honestly remains empty.
What helps is not loosening filters, but setting priorities: which conditions are mandatory, and which yield, so that the selection can be filled with relevant products.
Selecting cosmetics by skin type requires unambiguous features. If for one product the skin is labeled as oily, for an analog — as combination, and susceptibility to reaction is placed in free-form description text, they cannot be compared with each other.
We bring features to a single reference dictionary and fix in advance what matters more in a conflict: the declared property, the composition, or reviews.
Outdated stock in the selection and duplicate product cards are two sides of the same problem: product data lags behind reality.
The customer receives a recommendation for an item that is not in stock, or sees three cards for the same product and does not understand what to choose.
Linking the catalog with inventory and rules for collapsing duplicates close both situations — the output stops diverging from both availability and assortment.
Next we examine how this is closed: from feature preparation to rules that keep the selection from becoming empty.
Measurable effect: where exactly the result is visible
Output fill rate is the first metric: the share of sessions where the system returned a suitable product, and the average length of the selection. An empty output is not "no data", but a lack of features: skin type, sensitivity, current care, order history.
When the profile is filled, fill rate reaches a plateau and the placeholder in the block is not shown.
The share of orders with a selection counts additions from the recommendation block, not from the catalog or search. The metric is honest: if you moved the block higher, additions did not grow if the matching is weak. With working matching, this block becomes the entry point for new customers.
The effect of personalization is also visible in inverse metrics: cosmetic returns and support requests. Accounting for ingredient intolerance and compatibility with current care reduces the share of returns for the reason "did not suit".
We check the quality of care product matching separately — by matching composition and purpose with the profile.
We calculate by block events (impression, click, add, purchase) in product analytics (Google Analytics and analogues), comparing with a control group without recommendations. This way the contribution of matching is visible separately from seasonality and promotions.
Recommendation output formats and their limitations
Recommendation formats differ not by interface, but by how the system makes a decision. In practice, this is a trade-off between explainability, cold start, and quality on the long tail of the catalog.
Below are four schemes that are actually chosen between, with applicability conditions and limitations of recommendation output.
| Option | When it fits | Limitations |
|---|---|---|
| Rules and filters by questionnaire | Strict contraindications, narrow catalog, an explainable reason needed for each output | Does not see relationships between features; rules grow with the assortment and require manual support |
| Matching by similar profiles | Interaction history has accumulated, novelty of offers matters | Cold start; mass scenarios crowd out niche ones; choice is hard to explain to the customer |
| Model on purchase history | Long histories, repeat visits, labeled outcomes | Sensitive to data bias, needs drift control and regular retraining |
| Hybrid recommendation scheme | Audience is heterogeneous, catalog is growing, both rules and ranking are needed | Harder to develop and maintain, requires recalculation of data marts and quality monitoring |
More often, the hybrid scheme converges: rules and filters by questionnaire act as a limiting layer — they cut off contraindicated and incompatible items — and on top goes ranking by similar profiles and history.
Then the limitations of recommendation output become manageable: for each item the reason for showing is preserved, disputed cases are investigated by logs, and a new product gets a chance to enter the output without accumulated statistics.
Step-by-step implementation: from data audit to launch
We break the work down so that each stage produces a verifiable artifact: a data schema, a feature set, a working output, and a comparison protocol. A step is not considered complete until the result is reproducible on historical data.
- Customer data audit. We inventory sources — questionnaires, order history, support requests, in-app behavior. We calculate field completeness, missing value share, and staleness rate: a skin type questionnaire lives for months, while a cart lives for days.
- Feature schema for matching. We describe what is calculated per customer (skin type, sensitivity, reaction to past purchases, recency of visit) and per product (composition, purpose, compatibility), and how they are linked. Prohibitions — allergies, incompatible combinations — are kept separate from ranking so the model cannot bypass them.
- Output assembly. We limit the candidate list, add diversity, and form a short explanation "why this fits".
- Backtest on history. Metrics are the share of hits in the top of the output and accuracy on repeat purchases. Here we also catch drops on rare categories before they reach users.
- Comparative output test. Control group, fixed traffic shares, a predetermined period, and a decision metric. We look not only at card transitions, but also at returns: growth in impressions without growth in repeat purchases does not pass the test.
- Launch recommendations in the app. We roll out traffic gradually; for customers without history — a separate set of rules for popular and compatible items.
- Handover and support. Quality metrics on a monitoring dashboard, scheduled retraining, rollback to the previous output version with one setting. We document the feature schema and the incident investigation procedure.
Configurations, schemas, and regulations: what remains with you
Personalization remains manageable only if its settings are with you, not in correspondence with a contractor.
We hand over a working kit: configurations, data schema, moderation rules, access policies, and update regulations — with it, the system can be developed by your own forces without coming back to us for every edit.
- Recommendation output configuration — signal weights (view, add to cart, repeat purchase), rules for mixing "similar" and "complementary" blocks, limit on showing one brand in the feed.
- Catalog data schema — required card fields, property reference (skin type, shade, restrictions), order of index updates when the assortment changes.
- Recommendation moderation rules — stop lists of products and categories, ban on output at zero stock, priority of health restrictions over commercial blocks.
- Customer data access policies — role separation, anonymization in analytical exports, retention periods and deletion on request.
- Model update regulation — retraining frequency, acceptance metrics (share of top hits, share of empty outputs), rollback procedure to the previous version.
- Documentation and monitoring — metric descriptions, output quality dashboard, instructions for the on-call engineer, acceptance checklist after edits.
The kit remains working without us: your team edits moderation rules itself, and retraining is launched according to the regulation, not on a support request.
Case study: care product matching for a store chain
A cosmetics store chain came with a uniform output: care product matching was built by category and total revenue, so a person with dry sensitive skin saw the same bottles as someone with oily skin.
About a third of sessions included the selection, and returns for "did not suit" consumed a noticeable share of orders. This is a cosmetics personalization case where the bottleneck turned out to be not the model, but the data.
What was changed
The composition was broken down to ingredients by INCI and verified against the Open Beauty Facts reference, linking it to skin profile, hair type, and restrictions: allergies, pregnancy, concurrent use of retinoids.
Compatibility rules were moved to a separate layer — the catalog and matching logic update independently and do not diverge.
Feedback was also closed: rejections, repeat purchases, and "suitable/not suitable" ratings go into the profile, and the selection is explained to the buyer — which ingredients and why they are suggested.
Metrics before and after launch
| Metric | Before | After |
|---|---|---|
| Sessions with an addition from the selection | ~30% | 62% |
| Items from the selection in an order | 1.1 | 2.3 |
| Returns for "did not suit" | baseline | 1.8 times lower |
| Catalog processing after upload | manually, days | automatically, overnight |
Rebuilding features after a catalog update takes a night, and an output without a reason explanation is not published — this filters out false combinations like an acid with a retinoid.
For a cosmetics marketplace, recommendations provide an additional effect: the seller sees which ingredients are missing from the assortment.
How does AI personalization in beauty differ from manual matching?
Manual matching is a set of merchandiser rules: "dry skin + request for moisturizing → show line X". Such links usually live in an Excel spreadsheet or in the catalog admin panel and cover a few dozen scenarios.
In beauty, a catalog is thousands of SKUs with dozens of features: skin type, texture, active ingredients, shade, compatibility restrictions. Rules do not scale to such volume: part of the catalog does not participate in output at all.
AI personalization in beauty is structured differently. The system builds a feature vector separately for the product and for the customer's request, so catalog coverage is not limited by pre-written links.
A new product enters the selection immediately after its card attributes are filled — the speed of selection updates is determined by data completeness, not by merchandiser workload.
The transparency of a recommendation is ensured by an explanation for each output: you can see which features matched, which weight fired, and what pushed the product down.
The merchandiser manages not the logic, but the rules layer — a stop list by ingredient, a ban on an incompatible pair, priority of a line in a segment. The rule is applied on top of the model and does not break the rest of the output.
The main difference from manual matching is the reaction to changes. Seasonal rotation, a new active ingredient, or a line going out of stock are reflected by editing one rule, not by rebuilding the table of links.
The control metrics here are the share of the catalog actually participating in output, and the time from a data change to when recommendations account for it.
Tech team doubts: data, quality, support
Tech team doubts are usually the same: there is little customer data, behavior on new profiles is unpredictable, and output quality is not confirmed by anything.
Below is how each point is closed at the level of the data schema and matching rules, rather than by a "verbal" regulation: what goes into the profile, what is considered a stop condition, and by what sign deterioration is visible.
What to do if the customer profile is almost empty?
We rely on what is already there: skin type, reaction to past procedures, request history. Unfilled fields are marked as unverified and do not participate in the calculation instead of substituting an average value.
How does the system behave with a new customer without history?
Cold start is closed by a starter set based on questionnaire data and scenarios from similar profiles. Then feedback recalculates the weights, and the output moves from a general set to a personal one.
How are contraindications taken into account in matching?
Restrictions live in a separate reference and are checked before output formation. If there is no acceptable option, the system returns fewer items, but does not substitute a contraindicated one.
What confirms the quality of recommendations?
There is a control set of profiles with an expected result — it is run on every rule change. We look separately at the share of rejected outputs and returns to matching: these are early signs of deterioration.
What is included in post-launch support?
Response regulations, review of restriction references, and pre-described criteria under which matching is rebuilt from scratch rather than adjusted on live customers.
Let's discuss the task and come back with an estimate and plan
To make the estimate substantive rather than "by eye", at the start we need a breakdown of your data by catalog and buyer behavior.
Let's start with a conversation: describe the personalization task — what is currently happening with product matching, where the buyer leaves without a purchase, and which approaches have already been tried.
What is useful to prepare for the first meeting:
- catalog export: SKUs, categories, composition, properties for different skin and hair types, description texts;
- which behavior signals are collected — views, add-to-cart, repeat purchases, rejections;
- whether there is order history linked to profile and segments, and for what period;
- which channels need to be covered: website, app, emails, consultant work on the floor;
- restrictions on personal data: what can be stored, where, and for how long;
- which systems already operate — catalog, customer records, previous recommendation matching;
- who on the customer side makes decisions and checks output quality.
In response, we will come back with an estimate and work plan: stages, team composition, data volume for the start, quality metrics, and how they are checked before launch.
If there is little purchase history, we will propose a collection scheme and a first launch on a limited set of categories — this way the result is visible earlier and risks are lower.
As a personalization contractor, we take on both the development of AI solutions and post-launch support: we monitor output quality and additionally train models on new data. Describe the task — we will come back with an estimate and plan.
