Virtual Try-On Pilot in 90 Days: Scope, Metrics and Decision Criteria

Most virtual try-on projects do not fail because of technology: they fail because nobody ever defined what was being tested. A well-built virtual try-on pilot does not set out to "launch the feature": it sets out to answer, within a fixed window, whether shade try-on moves a specific business metric and whether the colour operation is sustainable. This article proposes a 90-day structure designed for e-commerce, CRM and product teams that need to bring a well-founded decision to the committee.

Which hypothesis a virtual try-on pilot should test

Before choosing a tool, write the hypothesis in one sentence. Some examples we see at beauty brands:

• "Visits to the lipstick page that try a shade add to cart more often than those that do not."
• "Shade try-on reduces the shade questions that reach customer service."
• "Campaign traffic that lands on a try-on experience leaves more identified contacts than traffic that lands on a static landing page."

One hypothesis per pilot. If you try to validate conversion, retention and lead generation at the same time, you will end up with three ambiguous results instead of one clear one. Also define which result would make you drop the idea: that threshold, written down before you start, is what prevents political arguments in week 12.

Choosing the delivery form according to scope

MaIA Try-On comes in two forms, and each one serves different pilots.

Photo API

The shopper sends a photo, the product — lipstick or foundation — is rendered onto it and the image comes back ready to display. It is the fastest route when the pilot runs in a channel where you do not control the frontend: WhatsApp, a CRM flow, a campaign microsite, an in-store tablet. It does not require the frontend team to open up the e-commerce codebase. Palettes are calibrated against the brand's real products within a project, so the colour the shopper sees matches the SKU she is going to buy. You can see how it works on the virtual makeup try-on page.

Browser SDK (early access)

The SDK runs on the brand's domain and covers thirteen products — lipstick, foundation, blush, powder, under-eye concealer, eyeshadow, mascara, eyebrows, eyeliner, bronzer, contour, highlighter and lip liner — plus a combined Full Look. It works in live mode through the camera, with the render done locally in the browser and no image upload, or in photo mode, with any #RRGGBB colour. It is the option for a product page or full-look pilot, and it has been in early access since September 2026, granted per account. Important for planning: the other eleven products and the Full Look are exclusive to the SDK; the photo API covers lipstick and foundation.

If you are still comparing try-on approaches, the article on photo-based virtual try-on versus other try-on approaches helps place each one before committing sprints.

Minimum scope: catalog, channel and audience

A pilot does not need the whole catalog. It needs enough colour for the try-on to be useful and enough focus for the result to be readable.

• Catalog: one product family with many shades, ideally lipstick or foundation. Between 12 and 30 shades is usually enough for the shopper to find something close to what she is looking for.
• Channel: just one. Product page, paid campaign, WhatsApp or in-store. Mixing channels in the same pilot also mixes the causes of any variation.
• Audience: if the channel allows it, split the traffic. One group with shade try-on, another without. Without a comparison, any number from the pilot will be anecdotal.

Also document who approves the colour. Palette calibration is a product marketing task, not an engineering one: someone on the brand team must validate that each rendered shade represents the SKU.

Metrics and decision criteria

Measure in three layers, and agree with the team on how each one is calculated before week 1:

1. Adoption. What percentage of visits to the channel opens the try-on and how many shades each session tries. If adoption is low, the problem is almost always placement and call to action, not the render.
2. Behaviour. Add to cart, progression to checkout and conversion for the group that tried versus the group that did not. Also look at the most-tried shade versus the most-bought shade: that gap is direct input for buying and assortment.
3. Operations. Credit consumption, errors from poor-quality photos, brand team time spent approving palettes, support tickets about colour.

Avoid importing third-party conversion promises into your business case. Results vary with each brand's catalog, traffic and channel; the point of the pilot is to produce your own number, not to confirm someone else's.

A 90-day timeline

• Weeks 1–2: hypothesis, single metric, decision threshold, channel and product family selection. Account created and API key generated.
• Weeks 3–5: technical integration and palette calibration with the brand team. Internal tests with real photos of shoppers from the target segment.
• Weeks 6–10: live pilot with traffic split. No scope changes halfway through.
• Weeks 11–12: reading the results, cost per tried session, and the decision: scale to more SKUs and channels, adjust placement, or stop.

Common mistakes that cost the quarter

Hiding the try-on below the fold. Launching with unapproved shades. Not instrumenting events before opening traffic. And the most frequent: closing the pilot without a written criterion, which turns a business decision into a debate of opinions.

Ready to build yours? Create an account, purchase credits and generate your key in the API documentation, or talk to the B4A team to define the pilot scope together with your catalog.