Why AI-based cosmetics selection fails on real-world data
The questionnaire describes the skin at the time of completion: type, sensitivity, whether there is flaking.
A month later on a retinoid, the barrier changes — the same profile already yields an incorrect recommendation, while the model confidently repeats its previous conclusion.
Skin condition depends on season, humidity, hormonal background, and medication intake: a static profile does not contain these variables, so AI-based cosmetics selection stumbles at the very first step.
The second trap is the composition. A product name lives for years, but the formula changes: the manufacturer rearranges ingredients in the list, changes the concentration of the active substance and preservatives.
Verification is based on the product card, not the current labeling, so the accuracy of care recommendations drops where the user has changed nothing. We match the composition against the ingredient database CosIng and batch labeling, not the storefront description.
Third is the “similar buyers bought” logic. Purchase history does not equal need: gifts, repeat purchases by inertia, a product bought once and discontinued due to irritation. The model reads these signals as preference and reinforces an already made recommendation error.
Ingredient compatibility is a separate layer. A retinoid and an acid in the same routine, benzoyl peroxide next to vitamin C, copper peptides at acidic pH: harmless on their own, together they cause irritation and roll back results.
If each product is evaluated on its own, incompatible ingredients quietly end up in the same regimen.
Below we break down how this is addressed: a dynamic skin profile, formula versioning, and conflict checking before output.
What changes after implementation: accuracy, returns, support
The first measurable effect is the share of matches to skin needs. Before implementation, the recommendation relied on the skin type stated in the questionnaire and did not account for sensitivity to actives, concentrations, and application order.
Matching compares the composition with the skin profile, lifestyle, and products already in use, so the share of customers who remain on the selected line after a month grows rather than falls by the third week.
Returns are the second metric visible in numbers. The main reason for returns in skincare is skin reaction: irritation, dryness, flare-up.
When matching filters out incompatible combinations (acids together with retinoids, alcohol in the base for couperose) and limits concentration for those just starting, the share of returns due to “did not suit” decreases — measured by return reason codes, not by total revenue.
Repeat purchases grow because the recommendation covers not one product but the entire care regimen: cleansing, active, moisturizing, protection.
The customer returns for the next step, and the metric is calculated honestly — the share of repeat orders in the group that received matching compared with the group without it.
The load on consultants changes qualitatively, not only quantitatively. Typical questions about compatibility and application order are handled automatically; complex cases remain for the consultant — reactions, combinations with medications, pregnancy.
Response time drops from minutes of waiting in chat to seconds, and this is noticeable in the share of inquiries abandoned before receiving an answer.
All four metrics are captured on the same cut: the effect of implementing recommendations, returns, repeat purchases, support load, and response speed. This shows what exactly produced the shift, rather than “it got better overall.”
Comparison of recommendation approaches: questionnaire, history, composition
The questionnaire describes the skin at the time of completion, purchase history describes past behavior, and composition analysis describes the product itself.
None of these sources alone provides a correct recommendation, and the difference between approaches shows up in edge cases: sensitive skin, allergy to a specific component, simultaneous use of actives.
| Approach | When it fits | Limitations |
|---|---|---|
| Questionnaire-based rules | First launch, no order history | Does not see skin reactions; answers are approximate |
| Matching by purchase history | Regular customer, repeat orders | Reinforces past mistakes; does not know reasons for discontinuation |
| Composition and contraindication analysis | Sensitive skin, allergies, active conflict | Requires complete composition markup in the product card |
| Hybrid scheme with constraint checking | Broad range of products and actives | Linked reference books of components and limitations |
In the hybrid scheme, rules and composition analysis work as a hard filter: a product with an unsuitable component does not appear in the output regardless of how highly the model rated it.
Purchase history is applied only to those that passed selection — it sets order, not the right to be shown. This removes the main risk: a recommendation that suits the skin type but contradicts a health limitation.
The bundle relies on a composition reference in INCI format and on rules “component — contraindication — skin condition.” Limitations are stored separately from ranking: they can be revised without rewriting the matching logic, and every exclusion is explainable — you can see which filter triggered.
How care matching is built: stages and quality control
Care matching is not “a model that recommends a cream,” but an ingredient reference, a feature schema, and compatibility rules verified by practicing consultants.
Therefore the work proceeds from data to rules and only then to the computational part: if this order is violated, the system confidently recommends acids over a retinoid, and the client receives a stream of returns and distrust in the service.
- Data audit. We analyze what already exists: product cards, INCI compositions, active concentrations, purpose, age and skin condition restrictions. We record which fields are missing and where to get them — manufacturer cards, descriptions, consultant markup.
- Ingredient dictionary. We reduce different spellings of the same substance to one identifier and group them by action: moisturizing, exfoliation, antioxidants, barrier protection. Without normalization, “niacinamide” and its synonyms in different cards remain different substances, and compatibility rules stop working.
- Feature schema. We describe the user profile and product profile in comparable features: skin type, sensitivity, tendency to reactions, photodamage, texture format. The schema determines which questions are worth asking at all and which answers do not change the recommendation.
- Setting up rules and the computational part. We write compatibility and contraindication rules explicitly and with versioning — they matter more than any weights. The computational part ranks allowable options within the safe corridor rather than replacing it.
- Validation against consultant markup. We run a set of profiles through the system and compare with decisions by practicing specialists. We analyze discrepancies by cause: incomplete dictionary, disputed rule, weak feature.
- Quality acceptance. We agree on metrics before launch: share of recommendations without composition conflicts, agreement with the consultant on a control sample, share of profiles for which the system honestly asks for clarification instead of guessing.
- Handover. We provide documentation on the dictionary and rules, the procedure for updating them when new actives appear, and a report on where the system falls short of the consultant.
Acceptance is based not on “like it or not,” but on pre-agreed checks: if a rule conflicts with specialist markup, it does not go into production until reviewed. Next we describe what exactly remains with the client after launch.
What we hand over: compatibility rules and regulations
A model without fixed rules quickly diverges from the catalog: a new ingredient or brand appears — and the output starts recommending combinations that a cosmetologist would not approve.
Therefore, along with working matching, we hand over a set of artifacts by which the solution can be developed and checked without us.
- Data schema — which fields describe the product, skin type, and limitations, how they are related, and which are mandatory when adding an item.
- Ingredient dictionary — canonical names and synonyms of trade formulations, substance groups (acids, retinoids, exfoliants), concentration thresholds after which the conclusion changes.
- Compatibility rules — “ingredient × ingredient” and “ingredient × skin condition” matrices with three levels: suitable, use with caution, do not combine, and justification for each prohibition.
- Policy for access to customer history — what we store, for how long, in what anonymized form, and which employees see personal records.
- Solution documentation — how the recommendation is formed, where the data comes from, where the limits of applicability are, and which cases the system deliberately does not take on.
- Update regulation — who adds a new ingredient, within what timeframe, how the rule is checked, and how it is rolled back if an error has already entered the output.
- Set of reference scenarios — control skin profiles and compositions against which we compare the result after every rule change.
- Instructions for your team — how to make changes without a developer and what to do in case of a disputed combination.
The rules live separately from the code: a new limitation is added by your technical specialist, not a developer, and this does not require rebuilding the model.
During acceptance, we go through the artifacts together with your team, review two or three disputed scenarios, and record who is responsible for updates going forward.
Case study: how a skincare store chain reduced returns
A skincare store chain: consultants selected products by skin type and composition manually, relying on memory and paper notes.
The question “will a cream with acids suit me if my evening routine already has retinol” went to the technologist in chat, while the customer in the store was left to choose by packaging.
Such matching produced returns due to “did not suit” and weak repeat purchases among those who came for the first time.
What was changed
We assembled a product database with composition markup by INCI, skin type, and strict restrictions on active ingredient compatibility.
The matching tool compares the customer profile — skin type, sensitivity, reactions, what is already on the shelf — with product cards and returns 2-3 options with an explanation: why this one fits and what should not be mixed with it.
The consultant sees the same explanation in the interface, so answers stopped diverging between shifts and locations.
Metrics before and after
- share of returns due to “did not suit” — from 12% to 4%;
- repeat purchases in the first quarter after the first — from 21% to 34%;
- response time for matching — from 4 minutes to 20 seconds, including compatibility checking;
- share of inquiries to a consultant for basic matching — from 68% to 25%, consultants are busy with complex cases;
- share of baskets with a conflict of active ingredients — from 9% to 1%.
An entire class of failures disappeared: a purchase where the composition is incompatible with what the person already uses no longer goes through silently.
Returns stopped being a matter of the seller's politeness — every discrepancy becomes an edit in the product card, and matching improves for all customers at once.
How does a skin type recommendation differ from composition checking?
Skin type is a description of the condition: oiliness, tendency to dryness, reactivity, clogged pores. From the questionnaire and photo, the model builds a profile and selects the care base — cleansing, moisturizing, texture.
This answers the question “what suits the skin condition,” but says nothing about what will happen if several products are combined into one regimen.
Composition checking works at the ingredient level: retinol and acids in one regimen, benzoyl peroxide with retinoids, vitamin C and niacinamide in high concentrations, alcohols and essential oils on reactive skin.
Component compatibility is not visible in the card of an individual product — it only appears in the assembled set, so it is not the product that needs checking but the combination.
A separate layer is the cumulative effect. Active substances add up across products: acid in a toner in the morning plus serum in the evening, a retinoid from cream and from mask.
The total weekly dose grows, the skin becomes irritated, and the person blames the “wrong cream” instead of the regimen.
Therefore, in AI-based cosmetics selection, checks proceed sequentially. First, products unsuitable by skin type and goal are filtered out.
Then, within the selected set, we calculate component compatibility and the total load of active substances, distribute them across times of day and days, and allow for a skin adaptation period. Without the second stage, a skin type recommendation looks neat but remains unsafe.
Technical doubts: data, markup, skin sensitivity
During task discovery, clients ask the same five questions, and almost all of them are not about the model but about data and rules.
Below are short answers: where contradictory recommendations come from, what to do with incomplete composition, how to account for past allergies, how to change rules without rebuilding, and how to maintain quality after launch.
Why does the system give contradictory recommendations?
Matching is a chain of rules: skin type, health restrictions, compatibility of active components. Each conclusion stores a reference to the source and the rule that triggered.
In a conflict, priority is set explicitly and visible in the check log — instead of “the model decided so.”
What to do if composition data is incomplete?
Incompleteness is the norm, not a failure: some manufacturers do not publish the full formulation. In that case, the answer is built from known components, while unknown ones are marked as unverified and honestly shown to the user. Gaps in the catalog are filled as data becomes available.
Are past allergies taken into account?
Yes, as a hard restriction, not a preference. The component stop list is assembled from the questionnaire and reaction history, applied before ranking, and overrides any recommendation — even if the product is ideal for the skin type. In disputed cases, the system suggests a simpler composition.
Can rules be updated without rebuilding the model?
Yes. Compatibility rules and stop lists live separately from the model, as reference books. Updating a composition or a medical recommendation is an edit to the reference book, not retraining: the change takes effect immediately, and rebuilding is not needed.
How is quality checked after launch?
We keep a set of reference questionnaires with a known correct answer and run it after every rule change. A discrepancy with the reference is a signal to stop the rollout. Plus analysis of real inquiries: disputed answers are added to the reference set.
Let's discuss the task: what data is needed to start
The conversation about care matching moves into practical territory when data appears: without a real assortment and actual customer behavior, a recommendation by skin type and composition remains a hypothesis.
You do not need to collect everything for the first conversation — it is enough to understand what already exists in the system and what will need to be prepared. Below is what to bring so that we come back with an estimate and a plan, not with general questions.
- Catalog export in tabular form: categories, purpose, skin type, item volume — and most importantly, how fully the properties are filled in.
- Ingredient compositions for each item; if they are missing or stored with suppliers, composition analysis will become a separate stage.
- Order history for several seasons: what is bought together, what is returned, how often customers come back.
- Customer inquiries: support questions, reviews, reasons for “did not suit” returns — an honest source of limitations.
- Your compatibility rules, if already described: which components should not be combined in one routine.
- Prohibitions and requirements: what must not be recommended for medical and legal reasons.
- Touchpoints where matching will appear: website, app, chat, consultant in the store.
In response, you will receive a data schema, a procedure for enriching the catalog, compatibility logic, and an implementation plan with validation metrics.
Describe the task and what you already have at hand — we will discuss the task concretely and come back with an estimate and a plan.
