Virtual Try-On for Black Friday: Getting the Operation Ready for the Peak

In November, your store takes in a single day the traffic of several weeks. Part of that audience has never bought from the brand, doesn't know how your shades are numbered and has very little time to decide. That is exactly where virtual try-on for Black Friday stops being a nice feature on the page and becomes conversion infrastructure: either it holds up under the peak and answers "does this shade suit me?" quickly, or it becomes one more element that loads slowly and gets in the way.

This article is about operational preparation, not about the idea of trying makeup on online. The focus is what has to be decided in October so the button works in November.

Why Black Friday is a different kind of test

Outside peak season, the people who use virtual try-on tend to be already interested, browsing without any rush. On Black Friday, three things change at once.

The audience is colder

Many shoppers arrive through an ad or a coupon, with no familiarity with the catalog. The shade question comes before any interest in the brand, and tolerance for friction is low: sign-up, app download, a confusing permission prompt — any extra step kills the session.

The volume is concentrated

The peak doesn't spread out neatly. It clusters into a few hours, usually around the moments when offers change. Any component that depends on a server call has to be sized for that window, not for the monthly average.

A mistake costs twice

A wrong shade bought on promotion turns into a return in December, when the support team is already saturated and the campaign's margin has already been booked. Removing doubt at the moment of purchase is cheaper than fixing the problem afterwards.

Choose the format before you choose the page

MaIA Try-On exists in two forms, and they behave differently under peak load.

The photo-based API

The customer sends a photo, the product — lipstick or foundation — is rendered on it with the palette calibrated to the brand's real SKUs in the project, and the finished image comes back. It is the simplest path to integrate: it works in any channel that can send one image and display another, including customer service flows and pages served by your back end. Since every try-on is a request, the peak volume has to be accounted for in your credit balance.

The browser SDK

The SDK, in early access since September 2026 and granted per account, runs thirteen products (lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter and lip liner) plus the combined Full Look, in live camera mode — with the render happening locally in the browser, with no upload — or in photo mode, with any #RRGGBB colour, self-hosted by the brand. For the peak, the relevant characteristic is that the live try-on happens on the customer's device: a usage peak does not turn into an equivalent peak of server calls. The trade-off is that the SDK is granted per account and has to be requested in advance, not downloaded the night before.

If you are still comparing the two paths, it is worth reading the comparison between photo-based virtual try-on and AR try-on before you lock the scope.

Virtual try-on for Black Friday: the preparation checklist

Freeze the palette in October

Colour calibration is the work that cannot happen at the last minute. List the SKUs that will be on offer, include the backup shades that come in if one sells out, and validate the render with the product team. A palette approved in October means that in November nobody touches colour with the store live.

Define the fallback before the incident

Decide what the page shows if the try-on fails to load: the product photo in that shade, the undertone description, a shortcut to customer service. A silent fallback is better than a broken component. Write it as a front-end rule, not as an improvisation.

Plan credits with room to spare

Credits are bought. Estimate try-on volume from the traffic projected for the pages where the button will live, not from total site traffic, and leave margin for the day the campaign performs above expectations. Review the balance in the middle of peak week, not only at the start.

Shrink the question before the try-on

Shoppers who arrive cold don't know where to begin. A short profiling step — skin tone, undertone, skin type from a selfie — shortens the list of shades worth trying. That is what selfie-based skin and hair analysis delivers as JSON, with a confidence score per field, so your front end can decide what to suggest. Worth remembering: the result describes visible attributes of the photo, it is not a medical assessment and does not replace a professional.

Test on a bad connection

The peak also brings modest devices and unstable connections. Test on weak 4G and on older phones, not only on the team's desktop. The experience that matters is the worst one, not the best one.

What to measure during and after

During the campaign, track a handful of things in near real time: try-on open rate on the pages that are on offer, request or loading errors, and credit balance. Afterwards, look at what the operation taught you: which shades were tried most and didn't convert (a signal of stockout or price), which were tried and bought, and whether December returns fell on the pages with try-on active compared with the ones that went without.

None of this predicts a specific number for your brand. Results vary with catalog, traffic and channel, and the reading only makes sense when comparing pages and periods within your own store.

Start with the smallest scope that works

A peak campaign is not the moment to launch everything. Pick one category, a dozen SKUs and one try-on format; make that slice work well and expand after the new year. You can see the photo-based format on the MaIA Try-On page and start the technical side by creating your account and API key in the API documentation — or talk to the team to discuss the scope of your campaign.