virtual makeup try-on to reduce returns
Virtual Makeup Try-On to Reduce Returns: Fewer Wrong Shades, Fewer Exchanges
Wrong-shade purchases are the most expensive kind of beauty return. Here is how to use virtual makeup try-on to reduce returns across the product page, checkout and post-purchase flows — and what to measure before and after.
Most conversations about makeup try-on stop at conversion. The number that quietly eats margin, though, sits on the other side of the order: the shade that looked right on a screen and wrong on a face. Using virtual makeup try-on to reduce returns means treating the preview not as a marketing toy but as a decision aid placed exactly where the shade choice happens — and then measuring whether the choice got better.
This matters more for colour cosmetics than for almost any other category. A lipstick that arrives two tones off is not defective, it is simply not the one. The customer pays nothing for the exchange, but the brand pays the reverse logistics, the restocking, the lost second sale and, often, the customer.
Why wrong-shade purchases happen
Screens do not agree with each other
A swatch photographed under studio light, re-encoded for the web and rendered on an uncalibrated phone screen is already three transformations away from the pigment in the tube. The customer is not comparing the product to their skin; they are comparing a rectangle of colour to a memory of their skin.
Shade names describe the product, not the person
"Nude 03", "Warm Beige", "Rosewood" are catalog language. They tell the customer nothing about how the shade behaves against their own undertone. Without a reference point, people default to the shade name they bought last time from a different brand — which is how a customer ends up with four nudes and keeps one.
Reviews help, but only for people who look like the reviewer
Photo reviews are the closest thing most e-commerces have to a try-on. They work when the customer finds someone with a similar tone and undertone. In a catalog with dozens of shades and uneven review coverage, that match is rare.
Virtual makeup try-on to reduce returns: where to place it
The preview only affects returns if it appears before the shade is locked in. Three placements do most of the work.
On the product page, next to the shade selector
The shade selector is where the mistake is made, so that is where the preview belongs. When the customer taps a shade, the rendered result should change with it. Treat the preview as part of the selector, not as a modal buried behind a secondary button. The practical patterns for this are covered in detail on the MaIA Try-On page.
In the pre-checkout nudge
For customers who add a colour product to the cart without ever opening a preview, a single prompt — "see this shade on your photo before you order" — gives a last chance to switch. A shade swap in the cart is a saved return.
In the exchange flow itself
This is the placement most teams skip. When a customer starts a return because the shade was wrong, that is the moment they are most motivated to get it right. Offering a preview inside the return form, with the alternative shades from the same line, turns a refund into an exchange. The revenue is kept and the customer learns the tool exists.
Choosing the right form for the job
MaIA Try-On exists in two forms, and they fail differently if you put them in the wrong place.
The API is photo-based: your application sends a photo and the product — lipstick or foundation — and receives the rendered image back. It works anywhere you can make an HTTP call: product pages, a WhatsApp flow, a CRM email landing page, an in-store tablet. It is the right choice when the preview has to live outside a modern browser session or when you want to store and reuse the rendered image.
The browser 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 and lip liner — plus a combined Full Look. It runs in live camera mode, rendering locally in the browser with nothing uploaded, or in photo mode, with any #RRGGBB colour, self-hosted by the brand. For a product page where the customer wants to compare five nudes in thirty seconds, live camera mode removes the friction of uploading a photo each time. If you are weighing the two approaches, we compared them in photo-based virtual try-on vs AR try-on.
One constraint worth stating plainly: the eleven products beyond lipstick and foundation, and the Full Look, are SDK-only local previews. Do not design an email or WhatsApp journey that assumes the API renders them.
Calibration is what makes the preview trustworthy
A preview that renders a generic red does not reduce returns — it creates a second disappointment. Palettes in a MaIA Try-On project are calibrated to the brand's real products, so the shade the customer sees corresponds to the SKU they will receive. Before launch, budget time for:
- a clean mapping between each SKU and its palette entry, including discontinued shades you still sell through;
- a review pass with someone who has seen the physical products, comparing rendered output against the real item on several skin tones;
- a rule for what happens when a shade is out of stock, so the preview never sells something the warehouse cannot ship.
Measuring the effect honestly
Resist the temptation to attribute every improvement to the preview. A workable method:
- Baseline first. Pull return and exchange rates by SKU and by reason code for at least one full season before launch. If your reason codes do not separate "wrong shade" from "did not like", fix that first.
- Split by exposure. Compare orders where the customer opened a preview against orders where they did not, on the same SKUs and the same period.
- Watch the shade-switch rate. How often does a customer change their selected shade after a preview? That is the clearest early signal that the tool is doing its job.
- Check the exchange-vs-refund mix. Previews in the return flow should move volume from refund to exchange.
Any published figure from another company reflects that company's catalog, traffic and channel mix. Your own baseline is the only number that tells you what the preview did for you.
Ready to test it against your own shade range? Create an account and get an API key, or talk to our team about an early-access SDK project.
Frequently asked questions
Does virtual makeup try-on actually lower return rates?
It can, when the preview sits where the shade decision is made and the palette matches the real SKUs. The size of the effect depends entirely on your catalog, traffic and channel mix, so measure it against your own pre-launch baseline rather than against someone else's published figure.
Should the preview use the API or the browser SDK?
Use the photo-based API when the preview has to run outside a browser session — WhatsApp, email landing pages, in-store tablets — or when you want to store the rendered image. Use the browser SDK, in early access, when customers are comparing many shades quickly on a product page in live camera mode.
Which products can be previewed?
The API renders lipstick and foundation on a submitted photo. The browser SDK covers thirteen products — lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter and lip liner — plus a combined Full Look, as local previews in the browser.
Do customer photos get uploaded in live camera mode?
No. In the SDK's live camera mode the rendering happens locally in the browser and nothing is uploaded. The photo-based API, by contrast, receives an image and returns the rendered result.
How long does palette calibration take?
It depends on how many SKUs you have and how clean your product data is. The work is mapping each shade to its palette entry and reviewing the rendered output against the physical products on several skin tones — plan for that review before launch rather than after.