Virtual Try-On Data for Merchandising: What Shade Sessions Reveal About Demand

Most beauty teams treat try-on as a conversion feature and stop there. But every session produces something merchandising rarely has: a record of what shoppers wanted to see on themselves before they decided anything. Virtual try-on data for merchandising is that record — the shades previewed, compared, abandoned and carried to cart — and it answers questions that sales reports answer too late, or never.

This article covers what the data actually is in a photo-based API integration versus a browser SDK, which signals are worth logging, and how to read them without turning curiosity into a forecast.

What the data looks like in each integration

The shape of your dataset depends on how try-on is delivered, so decide this before you design dashboards.

The photo-based API

With MaIA Try-On as an API, the shopper sends a photo, the lipstick or foundation is rendered on it, and the image comes back. Palettes are calibrated to the brand's real products inside a project, which means each request already carries a SKU-level identity — not an abstract hex code someone invented. Your server sees every call: which product, which shade, which session, in what order. That is the cleanest possible merchandising log, because it is server-side by construction.

The browser SDK

The SDK, in early access since September 2026, covers thirteen products — lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter, lip liner — plus a combined Full Look, in live camera mode or photo mode, with any #RRGGBB colour, self-hosted by the brand. In live camera mode the rendering happens locally in the browser and nothing is uploaded, so there is no server record of the frames. What you do have is your own front-end telemetry: the brand self-hosts, so the brand decides which events to emit to its analytics stack. If you want merchandising data from the SDK, you have to instrument it deliberately. If the difference between the two delivery models is still fuzzy for your team, the comparison in photo-based try-on vs AR try-on is a useful starting point.

Signals worth capturing

Resist logging everything. Five event types carry almost all the merchandising value:

• Shade previewed. Product, SKU, category, timestamp, session ID.
• Shade sequence. The order inside a session. The second and third shades tried tell you what the first one failed to deliver.
• Dwell. How long a shade stayed on screen before the next one. Long dwell on a shade that never converts is a different problem from a shade nobody opens.
• Last shade before exit or add-to-cart. The single most useful field in the set.
• Out-of-palette requests. In the SDK, any #RRGGBB colour is renderable. If shoppers keep pushing toward a tone your palette does not carry, that is an assortment gap stated in colour values.

Keep session IDs pseudonymous and separate from the image itself. You are building a merchandising dataset, not a face archive.

Turning virtual try-on data for merchandising into decisions

Assortment and gap analysis

Rank shades by previews, then by previews-per-conversion. A shade with heavy preview volume and weak conversion is usually either mis-described on the page or sitting next to a near-identical neighbour that wins the comparison. A cluster of out-of-palette colour requests around a tone family you do not stock is the clearest argument for a line extension you will ever get from first-party data.

Ordering the product page

Most shade pickers are ordered by SKU code or launch date, which is to say arbitrarily. Reordering by preview volume for the segment currently browsing puts the likely winners in the first row and shortens the comparison. The same logic applies to category pages and to the "shop the look" modules fed by a Full Look preview.

Stock and allocation

Preview volume moves before sell-through does, because previewing is free and buying is not. Treat it as a leading indicator to inspect, not a forecast to trust: shoppers try bold shades they would never purchase, and preview-heavy reds may convert into nude restocks. Use it to flag SKUs for human review ahead of a buy, not to size the buy automatically.

Launches and regional reads

For a new line, preview data exists from day one, while sales data needs weeks. Compare preview distributions across regions, channels and traffic sources before committing campaign budget to a hero shade chosen in a meeting.

Joining try-on with the beauty profile

Try-on tells you what was tried. It does not tell you who tried it. Pairing the session with a beauty profile from MaIA Scan — skin tone and undertone, skin type and condition, hair attributes, each with a confidence score — turns a flat preview count into a segmented one: which undertone groups gravitate to which shade family, where previews cross into the wrong depth range, which profiles never find a match and leave.

Two cautions. Only join profiles when the shopper has opted in, and store the profile as structured attributes rather than keeping the photo. And treat the attributes as visible characteristics of an image — they describe what the picture shows, not a diagnosis, and confidence scores exist precisely so low-certainty fields can be excluded from analysis.

A realistic first month

Week one: instrument the five events and ship them to the analytics tool you already use. Week two: build one table — shade, previews, previews-per-cart, last-shade-before-exit. Week three: pick the three worst offenders and change something concrete, like page order or shade naming. Week four: re-read the same table. Resist dashboards until you have acted on a plain table at least once; results vary with each brand's catalog, traffic and channel, and the only way to know yours is to measure your own.

Ready to start collecting the signal? Create an account and get your API key, or talk to the B4A team about SDK early access.