Virtual Try-On Metrics: What to Measure After Go-Live

Most virtual try-on projects are judged by a single indicator: conversion. It is a shortcut that hides more than it reveals. Without a well-defined set of virtual try-on metrics before go-live, the team is left with a chart that goes up or down and no clue as to why. This guide organises what to measure at each stage — from discovering the tool to repeat purchase — and how to instrument it in each operating mode, by photo or live in the browser.

Why virtual try-on does not fit the standard funnel

A try-on button is not a buy button. It is an intermediate, optional step the customer uses to resolve a specific doubt — usually about shade. When the only number in the report is the page's conversion rate, three different things get stuck together: how many people discovered the tool, how many managed to use it and how many changed their decision because of it.

Separating those layers is what makes action possible. If few people discover it, the problem is button placement. If many open it and few complete, the problem is technical or about usability. If many complete and nothing changes in the cart, the problem is the shade range — or the journey after the try-on.

Virtual try-on metrics in four layers

1. Discovery and activation

Start with the basics: try-on open rate (sessions that opened the tool over sessions on the product page) and completion rate (those who opened it and got to see a product rendered on their own face). The gap between the two is where friction lives: camera permission denied, photo rejected, slow loading, confusing instructions.

Segment by device and by traffic source. Desktop and mobile usually behave very differently, and top-of-funnel paid traffic rarely engages the way search traffic for a product name does.

2. Engagement inside the tool

This is where the richest — and most ignored — signals live. Worth tracking:

• Number of shades tried per session. A single try-on indicates confirmation; five or six indicate exploration — and heavy exploration in a category is a request for help choosing.
• Most-tried shades versus best-selling shades. The mismatch points to colours that attract in the range but do not convince in the mirror, or the other way round.
• Time to first render and mid-session abandonment.
• Use of combinations, when the customer builds more than one product in the same session.

In the browser SDK, which covers thirteen makeup products plus the Full Look in live camera mode or photo mode, these events exist on the front-end and it is up to the team to decide which ones to send to their own analytics. In the photo mode of the virtual makeup try-on, the call is server-side, so the record of which product was rendered is already in your application log.

3. Commercial impact

This is the layer the steering committee wants to see, but it only makes sense with a comparison group. Compare those who used the try-on with those who visited the same page and did not, in the same period:

• add-to-cart rate;
• conversion rate;
• average order value and items per order;
• share of new or long-tail SKUs in the mix.

Two honest caveats. First: anyone who opens the tool has already shown higher-than-average intent, so part of the difference is self-selection, not a causal effect. Second: results vary with each brand's catalog, traffic and channel — figures published by other companies serve as a market reference, never as an inherited target. If you want to truly isolate the effect, run an A/B test with the tool switched off for a slice of the traffic, by category, during a period without campaigns.

4. Post-purchase

Virtual try-on usually pays for itself after checkout. Track the return and exchange rate by shade between those who tried and those who did not, the volume of customer service contacts about colour and repeat purchase of the same SKU within 60 or 90 days. Repeat purchase of the same shade is the cleanest signal that the customer got it right.

Instrumentation: what changes between photo and live mode

The two formats generate different data, and that needs to be clear in the measurement plan. The photo API receives the image, returns the render and leaves a trail on the server: every call is a reliable event, easy to cross with an order. The SDK's live mode runs locally in the browser, without uploading the image — which is great for privacy and means the metric is born from front-end events that you fire yourself. The practical difference between the two approaches is detailed in virtual try-on by photo versus AR.

In either case, use a session identifier that is consistent across the tool, the cart and the CRM. Without that key, none of the metrics in the third and fourth layers can be calculated.

Three frequent reading errors

1. Comparing periods with different campaigns. Black Friday against an ordinary week does not measure try-on, it measures media.
2. Looking only at the average. Lipstick and foundation behave differently; the average hides the category that is doing badly.
3. Measuring late. If the open event was not instrumented before launch, the first month becomes an estimate.

A minimum measurement plan

Before going live: define the events (opened, rendered, switched shade, added to cart), the session key and the comparison segment. In the first weeks: look at opens and completions, fix friction. From the second month: bring in conversion, order value and mix. Over the quarter: returns and repeat purchase. Anyone who wants to see the response formats and design the instrumentation carefully will find everything in the API documentation.

Want to build this dashboard with your own operation's data? Create your account and your API key or talk to the MaIA team to design the pilot.