When a Try-On Shows the Wrong Color, the Color Was Dropped Somewhere
- On one store, 5 multi-color products rendered in a single color; now each color renders as itself.
- In a bag test, 23 of 33 color choices would have rendered the wrong color before the fix.
- A saved try-on was keyed to the product, not the color, so switching colors showed the old one.
Conclusion: a multi-color product is really several products that share one title, and the shopper's picked color is an input the try-on has to carry from start to finish. It was being dropped at three stages: the catalog read one photo per product (so the item rendered in its lead color), a bag's reference photo always came from the gallery's first color, and a cached look was keyed to the product rather than the color. Drop the color at any one stage and the render quietly falls back to the default. We made color a first-class input at each stage. On one live store 5 multi-color products were rendering as a single color, and in a separate test 23 of 33 color choices across 7 bags would have sent the wrong color (our data).
Where did the color go?
Color is different from fit. Fit is one judgment at the end; color has to survive every hop, or it reverts with no error. The three places it was lost:
- The photo we read: one photo per product, so a multi-color item rendered in its lead color.
- The reference we sent: a bag's strap photo always came from the gallery's first color.
- The look we saved: a cached try-on was keyed to the product, not the color picked.
What did we change?
| Where color was lost | What we changed | Result in our tests |
|---|---|---|
| One product photo read for every color | Read which color each photo shows; use the picked color | 5 products on one store now render every color as itself |
| Bag reference photo taken from the lead color | Send only a reference photo that matches the shopper's color | 23 of 33 bag choices would have been wrong before |
| Saved look keyed to the product | Give each color its own saved look | Switching colors now shows the new color, no re-render |
- Bag color choices rendering the wrong color, before the fix: 23 of 33 (7 bags, one store)
- Bag color choices rendering the wrong color, after the fix: 0 of 33
- Stages where a picked color could revert to the default: 3 (read, send, cache)
Front and back views match the picked color too. If a color has no back photo, the shopper gets one correct view instead of a mismatched pair.
What can any store check this week?
- Open a multi-color product page and confirm the gallery swaps to the selected variant's image.
- Check your try-on or AR tool renders the color the shopper picked, not the default.
- Name colors in your listing so a tool can read them from the photo or the variant.
- Test any change with a holdout (see: how to measure virtual try-on lift).
FAQ
Why does a virtual try-on show the wrong color?
Usually the tool reads one photo per product, or caches the result by product, so a multi-color item falls back to its default color. The fix is to carry the picked color through every stage.
How many products did this affect in Ello's tests?
On one live store, 5 products sold in several colors were rendering every color as one. In a separate test, 23 of 33 color choices across 7 bags would have sent the wrong color (our data).
Does switching colors cost another try-on?
No. Each color now has its own saved look, so a shopper can switch colors and see each one without re-rendering. The try-on is recorded as the color they actually picked.
What should a store check on its own site?
Open a multi-color product page and confirm the main image swaps to the selected variant, and that any try-on renders that color. If it shows the default, the color is being dropped somewhere.
Sources
- Ello public changelog, 2026-10-03 to 2026-10-04 (our data) [C]: color-aware catalog reads (5 products on one store), color-matched bag reference photos (23 of 33 choices), and color-specific saved looks.