Case study · Health & Beauty
Try the glasses on before the glasses arrive
An eyewear brand was sending out four pairs for every three it kept, because nobody can tell from a photograph whether a frame suits their face. We built browser-based AR try-on with real fit measurement.
Engagement · Product build & rollout
AR built to reduce returns, not to win an award.
- Industry
- Eyewear & accessories
- Solution
- Virtual try-on and fit guidance
- Platform
- Shopify
- Engagement model
- Dedicated product team
- Scope
- AR try-on, fit measurement, catalogue
- Delivery
- In browser, no install
- Constraint
- Face data never leaves the device
- Target
- Reduce returns
Outcomes
What try-on actually changed
AR is usually a marketing feature. Here it had to pay for itself in logistics.
-
−43%
Return rate
Customers see the frame on their own face at the correct scale and get a fit recommendation based on measured face width, so far fewer frames arrive and turn out to be wrong.
Measured across returns as a share of orders, six months after launch
-
+27%
Conversion on try-on sessions
Customers who use try-on convert well above those who do not, and the feature is used in the majority of product sessions because it needs no install.
Measured comparing sessions with and without try-on usage
-
3.4×
Frames viewed per session
Trying a frame takes two seconds once the camera is running, so customers explore the catalogue properly instead of shortlisting from photographs.
Measured across product views per session after launch
Context
Selling something that has to suit your face
Eyewear has the return economics of fashion and the fit requirements of a medical device.
The business
A direct-to-consumer eyewear brand selling prescription and non-prescription frames online.
The starting point
Product photography and a home try-on programme that shipped several frames per customer, most of which came back.
The trigger
Return shipping and reconditioning were consuming a large share of gross margin, and the home try-on programme could not scale with the catalogue.
What they wanted
Virtual try-on that works in the browser with no app, plus genuine fit guidance rather than a novelty overlay.
Constraints
Face data is sensitive and must not leave the device · it has to work on mid-range phones, not just flagships · frames must appear at true scale or the feature misleads · the catalogue changes seasonally.
System
What it runs at today
The try-on experience as it runs today.
-
0
Apps to install
Runs in the browser
-
−43%
Returns
Against the prior rate
-
On-device
Face processing
Nothing uploaded
-
3.4×
Frames viewed
Per session
The engineering problem
Four things that make AR try-on fail
Most implementations are a toy, and customers can tell within seconds.
-
Requiring an app install
Asking a customer to install an app to try on a pair of glasses loses almost all of them. The feature then gets blamed for low usage.
What we did
Browser-based AR using the device camera directly, so try-on starts from the product page with a single tap.
-
Frames that are not at true scale
An overlay that sizes the frame to look good rather than to be correct actively increases returns, because it flatters every frame equally.
What we did
Face measurement from the camera feed used to render frames at true physical scale, so a frame that is too wide looks too wide.
-
Uploading someone's face to a server
Face data is sensitive, and customers are right to be cautious. Server-side processing is also slower and more expensive.
What we did
All face detection, measurement and rendering on-device. No image or measurement leaves the phone.
-
Only working on expensive phones
AR that needs a flagship device serves the customers least likely to need convincing.
What we did
Performance budgeted for mid-range hardware, with graceful degradation to a static fit recommendation rather than a broken experience.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Capture
- Camera feed
- Face detection
- On-device only
Everything about the customer's face stays on the customer's phone.
-
Measurement
- Face width
- Pupillary distance
- True scale
Real measurement, which is what makes the fit advice worth anything.
-
Rendering
- Frame models
- True-scale overlay
- Tracking
Frames rendered at physical scale and tracked with head movement.
-
Fit guidance
- Frame dimensions
- Recommendation
- Catalogue filtering
Measured face against frame dimensions, filtering the catalogue to what fits.
True scale is the whole design. An overlay that is not measured is a filter, and filters do not reduce returns.
Solutions
What we built
Try-on designed to inform rather than impress.
-
Browser AR
Camera-based try-on with no install.
-
Face measurement
Width and pupillary distance, on-device.
-
True-scale rendering
Frames at physical dimensions, tracked.
-
Fit recommendation
Measured face against frame dimensions.
-
Catalogue filtering
Browse only what will fit.
-
Privacy design
Nothing transmitted, nothing retained.
Key capabilities
What it does day to day
Six capabilities in the try-on experience.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Browser try-on | Customer | Instant | Camera-based try-on with no install |
| Face measurement | On-device | Per session | Face width and pupillary distance measured locally |
| True-scale rendering | Automatic | Real time | Frames rendered at physical dimensions |
| Fit recommendation | Automatic | Per customer | Frame sizes that suit the measured face |
| Catalogue filtering | Customer | Per session | Browse only frames that will fit |
| Graceful degradation | Automatic | By device | Static fit guidance where AR is not viable |
Integrations
How the moving parts plug in
Camera on, measured, fitted — in the browser.
Product page
- Try onOne tap
- Camera permissionExplained first
- No install
On-device
- Face detected
- Measurements takenWidth and PD
- Frame renderedAt true scale
Decision
- Fit recommendationBased on measurement
- Catalogue filteredTo what fits
- Compare framesTwo seconds each
Explaining the camera permission before requesting it roughly doubled acceptance — a product detail worth more here than any rendering improvement.
Security & data
What protects the customer
Face data is biometric data, and it should be treated as such.
-
On-device processing
No image, video or face measurement is ever transmitted or stored server-side.
-
Clear permission
The camera request is explained in plain language before the browser prompt appears.
-
No biometric storage
Measurements are used in session and discarded; nothing persistent is retained.
-
Honest rendering
True-scale rendering, so the feature informs the customer rather than flattering the product.
The brief
The feature had to pay for itself in logistics
Virtual try-on is usually justified as engagement. We took this on with a harder target: reduce the return rate, which was the brand's biggest cost.
That target drove every technical decision — true scale rather than flattering overlay, real measurement rather than a filter, and no app install standing between the customer and the feature.
- Browser-based, no app install
- True-scale rendering from real face measurement
- All face processing on-device
- Graceful degradation on weaker hardware
What the build had to respect
- 01Face data that must never leave the device
- 02Mid-range phones, not just flagships
- 03True scale, or the feature misleads
- 04A catalogue that changes every season
Process
We validated the measurement before building the experience
If the measurement is wrong, a beautiful try-on increases returns.
-
Measurement validation
On-device face measurement tested against physical measurements across a range of faces and devices before any UI existed.
-
Device budget
Performance targets set for mid-range hardware, with the degradation path designed up front.
-
Frame modelling
A repeatable pipeline for turning new season frames into true-scale models without a specialist.
-
Permission design
The camera request flow tested specifically, because acceptance gates everything.
-
Return measurement
Returns tracked by try-on usage from launch, so the effect could be proven rather than assumed.
Technology
On-device AR over a Shopify catalogue
Web AR, with the commerce staying where it belongs.
AR
- WebGL rendering
- On-device face detection
- True-scale calibration
Commerce
- Shopify
- Storefront API
- Frame metadata
Content
- Frame model pipeline
- Seasonal catalogue updates
- Dimension data
Quality
- Device matrix testing
- Measurement validation
- Return attribution
Business impact
What changed for the brand
Three outcomes within two seasons.
-
Returns down 43%
The single largest cost line in the business, cut nearly in half.
-
Conversion up 27%
On sessions where try-on was used.
-
Catalogue properly explored
3.4× more frames viewed per session.
The result
Fewer frames posted out, far fewer posted back
Returns are down 43%, which was the number the project was commissioned against, and conversion on try-on sessions is up 27%.
The home try-on programme still exists but is now the exception rather than the default, which changed the cost structure of the business.
- Return rate down 43%
- Conversion up 27% on try-on sessions
- 3.4× more frames viewed per session
- No app install, no face data uploaded
What we hold to on AR commerce
- 01Attach AR to a cost line, not to engagement
- 02True scale or do not bother — a filter increases returns
- 03Keep biometric processing on the device
- 04Design the permission request as carefully as the feature
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate