AI Virtual Try-On for Shopify Fashion and Jewelry Stores: The 2026 Agency Build Guide

Marco runs Kindred Coastline, a $9M ARR women’s swim brand on Shopify Plus with 320 SKUs. Returns sat at 31 percent. He’d shipped two try-on pilots in eighteen months and ripped both out inside six weeks. The first tanked PDP load from 1.8s to 4.6s. The second’s images looked uncanny enough to spike tickets asking whether the brand used real models. Marco called Thursday. “We’re losing customers and the trust play. Do we kill it?”

The audit said something he didn’t expect. The provider wasn’t the problem on either pilot.

The reference photo pipeline was, and the consent UX had been bolted on as an afterthought. This is the post we wrote after the third pilot stuck.

Where try-on actually moves conversion (and where it doesn’t)

The category numbers are pretty consistent across the eleven Shopify brands we’ve shipped try-on for since late 2024.

Apparel sees 12 to 22 percent conversion lift on participating SKUs and 18 to 30 percent return-rate reduction; the variance is driven by reference photo quality, not by which provider you picked. Swim, denim, and fit-driven categories sit at the top of the range while loose-cut casualwear sits at the bottom.

Jewelry and eyewear are different animals. Jewelry sees 35 to 50 percent conversion lift because the customer can’t tell from a flat product image how a 22-inch chain falls on their actual neck, or how a 4mm hoop reads against their face. Eyewear sits closer to 8 to 15 percent because shoppers are already used to digital fitting from Warby Parker and friends.

Footwear is where most agencies overestimate, because sizing matters too much and the try-on doesn’t predict fit. We’ve stopped recommending it for footwear unless it’s paired with a separate measurement-and-fit model. Accessories that don’t sit on a body (bags, watches not worn on the wrist in the image) see almost no lift either; we’d skip the build.

The 2026 stack we keep shipping

The architecture has stabilized in the last 18 months. We’ve stopped reinventing this.

At the top, a Shopify Theme App Extension that drops an App Block onto the merchant’s PDP. The block renders the try-on entry button and the generated-image carousel. Merchant drops it into the product template through the theme editor, no theme code edits required. Shopify’s Theme App Extensions documentation covers the block schema and the asset pipeline.

Below that, a thin proxy app on Cloudflare Workers handles the provider API call, customer consent state, and image caching. Cold-start latency matters because the try-on call is in the user’s critical path. The provider does the actual image generation, and we’ve shipped against Wannaby, Pictofit, Mirrorsize, Lalaland, and a custom SDXL plus IP-Adapter stack.

A CDN-backed image cache sits between the provider and the storefront. Same customer plus same product equals same cached image. This cuts your provider bill by 40 to 60 percent and trims second-view latency to near-zero.

Customer state lives in two places. A Shopify customer metaobject holds consent and retention preferences. The actual reference photo lives on the provider side with a 72-hour TTL unless the customer opts into longer retention. Don’t store biometric photos on your own infrastructure if you can avoid it.

Picking a provider for fashion versus jewelry versus eyewear

Provider choice depends on category and on whether you want managed infrastructure or you’re willing to run your own model.

Wannaby and Pictofit cover sunglasses, watches, and bracelets best. Pose detection on the face and wrist is solid. Pricing usually lands at $0.04 to $0.12 per generated image at agency volume.

Mirrorsize and 3DLOOK lean toward body measurement and size prediction more than image generation. If your KPI is fewer returns and your category is apparel, this might be the better wedge. The output is a sizing recommendation rather than a visual try-on, which sounds boring but moves return rate harder than most try-on visuals do. We’ve shipped both to swim and denim clients with strong results on the return-rate KPI.

Lalaland is a model-image generator, not a true try-on, useful for catalog imagery and for adding body diversity to PDPs without reshoots. We sometimes pair it with a separate try-on tool.

Custom SDXL plus IP-Adapter plus a pose LoRA is the build path. We’ve shipped this on three clients with strong in-house ML teams. Setup cost is real (six to ten weeks of work) but the per-image cost drops to $0.005 and you keep the IP. Worth it above 50,000 try-ons a month, not below.

The decision flow we run with clients on the first call: is your monthly try-on volume above 50K? If no, buy. If yes, build, but only if you have at least one full-time ML engineer who isn’t already overcommitted.

The Shopify integration patterns we use on app blocks and PDPs

The technical integration is more standardized than the provider choice.

The App Block schema declares one section setting (the try-on entry copy) and one block setting (the SKU eligibility metaobject), bound so the merchant can mark eligible SKUs without writing code. The Liquid in the block reads product.metafields.tryon.eligible and renders the button only if true.

The widget itself is a small React or vanilla-JS bundle, code-split, lazy-loaded on intersection observer, and hosted on the Shopify CDN via the theme app extension asset pipeline. Total JS payload sits at 92 to 118KB minified plus gzipped across the clients we’ve shipped.

For data, the widget pulls variant info via the Storefront API, specifically variant images, option values, and the metafield that holds the try-on reference asset key, avoiding the Admin API in the storefront path because rate limits are tighter and customer-account scoping is fiddlier.

On Hydrogen or a headless front end, the pattern shifts. We drop the App Block, ship a React component, and proxy the provider call through a Cloudflare Worker in front of the Storefront API.

Shopify Functions come up a lot here. Don’t gate add-to-cart on try-on completion with a Function unless the brand explicitly wants that. They almost never do once they understand the conversion hit.

The reference photo pipeline that decides the output quality

This is the part agencies underestimate.

Try-on quality is 70 percent reference photo and 30 percent everything else. We measured this directly on Marco’s third pilot by running the same provider against three different reference sets. The “uncanny” generation outputs that killed Marco’s second pilot came from a reference set shot under three different lighting conditions with two different photographers.

The pipeline we now require on every project: 3 to 5 reference stills per SKU, locked lighting setup (one softbox, one fill), neutral background, model in a fixed pose with arms slightly away from torso. Resolution at 2048 by 3072 minimum. RAW captures only. Background removal as a separate step using a model trained for fashion, not a general-purpose remover.

Body diversity matters more than most teams plan for. We push every client to shoot 5 body types as the canonical reference set (petite, small, medium, large, plus), and the closer the customer matches the canonical reference, the less uncanny the output. Skipping plus-size references is the single most common reason a fashion try-on ends up with support tickets about misrepresentation.

We also lock the post-production rules. No skin smoothing on references. No background blur. The reference set should look like the customer’s expected output, not a fashion shoot.

Marco’s third pilot used a reference set built to this spec, and generation quality scored 4.1 out of 5 on a 200-customer panel, up from 2.3 on the second pilot.

Privacy and consent UX under GDPR and biometric data laws

This is the section most agencies skip in their pitch deck. It’s the section that actually shows up in legal review.

Biometric data classification covers any identifiable physical likeness. Your customer’s uploaded photo qualifies under GDPR (Article 9 special category), CCPA (sensitive personal information), and Illinois BIPA. BIPA is the real exposure because of the private right of action and statutory damages; we’ve seen retail BIPA settlements in the seven-figure range since 2023.

The consent UX comes before any photo upload, not after. We use a two-step pattern: a brief explainer modal naming the data category, retention window, and purpose, followed by an explicit checkbox the customer ticks before the camera or file picker opens. Pre-checked boxes are not consent under GDPR.

Retention defaults matter, with our default at 72 hours for the input photo and indefinite for the generated output (the customer’s choice to save). Shorter input retention (like 60 minutes) is supported via a provider TTL, while longer retention requires a separate opt-in screen.

The deletion plumbing routes through Shopify’s Customer Account API and the provider’s deletion endpoint, both firing on customer request and on account deletion. Test this in staging before launch. One client got a GDPR request three days after going live and discovered the provider’s endpoint was returning 200 without actually deleting.

The compliance surface is real, but the implementation is bounded. Spend the two weeks on it during the build, not the eighteen months on damage control afterward.

The performance budget we hold the PDP to

A try-on widget that tanks PDP performance loses more revenue than it creates. We hold every build to a strict budget.

Largest Contentful Paint stays under 1.8 seconds on 4G. The widget cannot block the LCP image. We lazy-load the JS bundle on intersection observer (the widget mounts when the entry button enters the viewport). The provider API call fires only on user intent, never on page load.

JS payload caps at 120KB compressed; we’ve seen agencies ship 400KB bundles and the PDP suffers. Bundle audit on day one and every release.

Image generation latency is the bigger user-perception problem. Provider API responses range from 2.4 to 8 seconds for a fresh generation, so we show a progress indicator with realistic copy (“Generating your fit, about 6 seconds”) and never block the rest of the PDP. The customer keeps scrolling, reading reviews, and adding to cart while the image generates.

Caching cuts second-view latency to under 200ms because we store the generated image at the CDN edge, keyed on customer ID plus variant ID. About 35 percent of try-on views are repeat views for the same customer and product. Google’s Largest Contentful Paint guide on web.dev covers the underlying thresholds we hold the PDP to.

KPIs the team should actually watch

Five numbers, weekly.

Try-on conversion lift, measured by comparing visitors who completed a try-on against a matched control group of visitors who saw the entry button but didn’t click. Don’t compare against site-wide average, the selection bias destroys the analysis.

Return rate on try-on-completed orders, baselined against the previous 60 days for the same SKU and filtered on the “fit” return reason code if your returns app exposes it.

Try-on completion rate, defined as customers who hit the entry button divided by customers who got a generated image and viewed it. A drop below 60 percent here usually means your reference photos are weak or your latency budget is busted.

Time-to-first-image at p50 and p95, with p95 being the more diagnostic number. If your p95 is above 12 seconds, the customer thinks the feature is broken even when p50 is fine.

Cost per try-on completion, which is your provider bill divided by your completion count, watched monthly because it drifts with cache hit rate.

Marco’s dashboard now shows all five at the start of every Monday standup. Swim conversion lift sits at 18 percent, return rate dropped from 31 to 22 percent in 90 days, and completion rate is steady at 71 percent. The CFO stopped asking whether to kill the build.

What we keep telling clients

Try-on is a real conversion lever in 2026 for fashion, jewelry, and eyewear, not a hype build. We’ve seen it work on enough Shopify catalogs to be confident.

The wins don’t come from the model. They come from the reference photo pipeline, the consent UX, and the performance budget. Pick any provider that meets your category requirement, then put the engineering hours into those three things. The provider becomes a swap-out commodity within a year; the pipeline and the consent state do not.

Marco at Kindred Coastline made all three changes on the third pilot. Swim conversion went up. Returns went down. Tickets asking whether the brand was using real models went away.

If you’re scoping a try-on build right now, the question to ask isn’t which provider. It’s whether your team has the reference-shoot budget, the compliance bandwidth, and the PDP perf headroom to do it right. If two of three are missing, push the build a quarter.

Questions we get every week

Can we use the customer’s selfie or do we need a body-template? Both patterns work. Selfies generate more accurate results for jewelry and eyewear because face-and-neck geometry is unique. Body-template (customer picks a model that matches their body type) works better for apparel because fit math is more sensitive to pose than identity. Most fashion brands run body-template by default with selfie as an opt-in upgrade.

How do we handle plus-size accuracy without offending anyone? You shoot plus-size references with the same lighting and pose discipline as your other references, and let the customer self-select their body type in the consent flow. The mistake is using “extended sizes” as a separate tab; the right pattern is a single selector with five to seven body types as equal options. Output quality follows the references, and missing references is what offends, not the model.

What’s the actual provider cost per try-on at our volume? Under 5,000 try-ons a month, expect $0.08 to $0.18 per generation. Between 5K and 50K, $0.04 to $0.10. Above 50K, negotiate to $0.02 to $0.04 or build your own.

Will this work on a non-Dawn theme? Yes, the App Block pattern works on any Online Store 2.0 theme that exposes the product template as a JSON template. About 92 percent of the Shopify themes in active use as of early 2026 qualify. Older 1.0 themes need a code-injection fallback that we ship occasionally, but we usually push the client to a 2.0 theme refresh first.

If you’re scoping a try-on build on Shopify, send us your category, monthly PDP traffic, and return rate at monkeyman.agency/contact and we’ll send back a 5-day architecture review with the exact provider and reference-photo plan we’d ship.