Try-On Engine Email and Intent Capture
How a virtual try-on engine captures intent and email as system outputs. Implementation lives in the capture guide; this page owns the engine capability.
The lifecycle report says 1,700 shoppers used virtual try-on last week. The email platform received 284 new profiles. One number describes activity, the other describes people the brand can contact, and nobody can say which profiles tried the navy dress twice before leaving.
The preview worked. The useful record did not survive it.
A virtual try-on engine captures intent by recording the product-specific actions around a preview, then captures email by joining an eligible shopper identity to that record. Its outputs are not merely an image and an address. They are a timestamped intent event, product context, consent state, and changing purchase status that another system can act on.
That output layer is part of the virtual try-on engine. Without it, try-on remains an engaging product-page experience. With it, the store can recognize an unfinished decision after the tab closes.
A completed preview should leave product context and an eligible lifecycle state, not an isolated image. Editorial image in Classic Antla disposable-camera style.
The engine should produce intent before it asks for identity
An email field cannot create intent. It can only identify a shopper who has already shown some.
That sequence matters because a completed try-on is more deliberate than an ordinary product view. The shopper selected a garment, supplied a usable photo, waited for generation, and inspected a personal result. Repeat generations, color changes, and a return to the product page add more evidence. None proves that she will buy, but each tells the lifecycle team more than a browser loading a URL.
The engine therefore needs to preserve the stages of the interaction as distinct events:
| Engine event | What it says about the shopper | Output value |
|---|---|---|
| Try-on opened | The feature earned attention | Measures discoverability, not purchase intent by itself |
| Photo accepted | The shopper invested effort | Separates a casual click from a real attempt |
| Preview completed | A personal product evaluation occurred | Creates the core intent event |
| Variant tried or retried | Interest narrowed or deepened | Preserves color and product preference |
| Email identified | The event can be joined to a known profile | Makes eligible follow-up possible |
| Order matched | The decision reached purchase | Suppresses recovery and closes measurement |
Treating all six as try_on_user throws away the sequence. It also creates awkward audiences. Someone who opened the tool and abandoned the upload should not receive the same treatment as someone who generated three views of one jacket and requested a saved result.
Across more than 500,000 Antla try-ons, shoppers who completed a preview converted at 3.8%. That is a conversion rate among try-on users, not the store-wide rate and not proof that every order was caused by the preview. For an engine designer, the practical point is that completion defines a cohort worth measuring separately from exposure or opening.
Email is an identity bridge, not the whole output
A lifecycle platform needs to know who showed intent. It also needs to know what that intent concerned and whether the person is eligible for a particular message.
The email output should therefore join identity to the existing event rather than create a new, context-free subscriber. At minimum, the joined record answers:
- which Shopify product and variant were tried
- when the preview completed
- how many relevant attempts occurred in the session
- where the email was collected
- what the shopper agreed to receive
- whether a matching order has appeared since
This is a capability boundary, not a form-building recipe. Button placement, value-exchange copy, consent controls, event mapping, and testing belong in the implementation guide for capturing email from Shopify virtual try-on. The engine’s job is to make sure those interface choices produce one coherent lifecycle record.
The distinction prevents a common reporting mistake. If the email platform records a signup while analytics records an anonymous try-on, the marketer sees two actions and cannot confidently connect them. The engine should carry a session or event identifier through the identity step, then associate earlier events when the shopper provides an address. One person, one product decision, one changing state.
Permission is data the engine must preserve
An email address is technically addressable. That does not automatically make it marketable.
The engine may need an uploaded photo to provide the requested preview. A shopper may separately ask for the result by email. Promotional email is another purpose again. Combining those actions into one vague acceptance state leaves the lifecycle team with an address it cannot safely interpret.
Shopify’s customer privacy guidance gives merchants a starting point for understanding privacy policies, cookie banners, data-sharing opt-outs, and regional controls. Exact legal requirements vary by market, message type, and merchant practice, so qualified counsel should review collection language, retention, and deletion policies. At a system level, the engine should be able to preserve:
- consent status by channel
- the source and time of the choice
- the wording or policy version presented
- withdrawal or suppression state
- retention and deletion status for personal media
The generated image deserves its own rule. A marketer usually needs the product ID, event, secure result link, and permission state. Klaviyo or an ad platform rarely needs a portable copy of the shopper’s photo. Sending the image everywhere because it exists is not personalization. It is uncontrolled duplication with an unusually memorable file attached.
Data minimization makes the engine more usable. Keep the lifecycle payload compact, keep personal media behind appropriate access controls, and give each destination only what its job requires.
The useful output changes after capture
A static list says, “These people tried something on.” An engine state says, “This shopper tried this variant, is eligible for email, has not purchased yet, and the signal remains fresh.”
The second description can change. That is the important part.
| Current engine state | Lifecycle meaning | Required response |
|---|---|---|
| Completed, anonymous | Strong product intent without known email | Measure on site, no email route |
| Identified, service only | Known identity without promotional permission | Deliver the requested service only |
| Identified, opted in, no order | Eligible unresolved intent | Make the record available for relevant follow-up |
| Purchased | Intent converted | Stop recovery for the item |
| Consent withdrawn | Channel is no longer eligible | Suppress future marketing |
| Intent expired or item unavailable | The original decision is no longer actionable | End or revise the route |
Purchase matching is what turns capture into a feedback loop. A profile that remains permanently marked not purchased will eventually receive a reminder for a dress already in its owner’s wardrobe. The engine should treat non-purchase as a temporary observation, then update it when Shopify supplies an order or when the relevance window expires.
Shopify’s ecommerce optimization guide recommends breaking broad conversion into actionable funnel stages. Apply the same discipline here. Measure try-on completion, identity capture, valid email eligibility, matching purchase, suppression, and expiry separately. A single signup rate hides whether the engine is capturing valuable product decisions or merely collecting addresses.
Postscript is one destination for opted-in SMS once identity exists. The engine should still decide whether the channel is eligible before a phone number becomes a marketing contact.
Klaviyo receives a usable event, not a marketing strategy
Once the output reaches Klaviyo, the event should appear on the correct profile with product identifiers, timestamp, consent state, and current purchase status. Durable profile properties and individual try-on events should remain distinguishable. A shopper can try several products, while consent status belongs to the person.
The Klaviyo Help Center documents profiles, events, forms, integrations, and flows. Those mechanics sit downstream from the engine capability. The engine does not need to dictate one campaign, subject line, or delay. It needs to deliver an event reliable enough that the lifecycle team can choose among them.
That boundary is healthy. One merchant may send a requested saved look and nothing more. Another may use valid marketing permission for a product-specific follow-up. A Shopify Plus team may route events through a broader customer-data architecture. The same engine output can support all three because product context, identity, permission, and outcome were preserved separately.
At higher traffic volumes, small mismatches become expensive quickly. The next article on a Shopify Plus virtual try-on engine covers event reliability, theme governance, and operating the system at scale.
Once the event is trustworthy, the separate path from try-on intent into remarketing and conversion can decide when and where to use it.
Judge the capability by what remains after the preview
A lifecycle marketer can evaluate the engine without auditing every line of implementation. Take a sample of completed try-ons and ask five questions:
- Can each completion be tied to the exact product and variant?
- When email appears, does it join the prior event rather than start a second history?
- Can the system distinguish service delivery from marketing permission?
- Does a matching purchase update the state and stop recovery?
- Can expired intent, withdrawn consent, and personal media be handled according to policy?
If the answer to any of these is no, the engine has produced a partial output. More campaign automation will distribute the gap rather than fix it.
The Antla email capture feature gives Shopify merchants a way to exchange additional try-on value for an address inside the experience. Its strategic value is not the field itself. It is the connection between a known shopper, the garment she evaluated, and what happened next.
Questions lifecycle teams ask
How do I capture emails from virtual try-on on Shopify?
Use the try-on experience to offer a clear, consent-based value exchange, such as another preview or delivery of a saved result. The engine should join the submitted email to the existing product-specific event and preserve consent and purchase state. For form timing, fields, consent language, and integration steps, use the detailed Shopify email capture guide linked above.
What data does virtual try-on collect from shoppers?
A virtual try-on engine can process an uploaded photo and record interaction events such as opening, photo acceptance, completed generation, product or variant tried, timestamp, and repeat attempts. If a shopper identifies herself, the engine can also associate email, consent state, and later purchase status. Merchants should collect and retain only data needed for disclosed purposes.
Is email required for the engine to work?
No. The engine can generate a preview, record anonymous intent, measure product interaction, and support the current shopping session without an email address. Email adds an identity bridge for eligible post-visit communication. It should not be treated as a technical requirement for producing the first promised result.
Leave a record the lifecycle team can trust
The most interested moment on a fashion product page should leave more than a rendered image. It should produce a small, interpretable record of the product decision, then add identity only when the shopper chooses to provide it.
About the author: Aaron founded Antla so the most interested moment on a fashion site would leave a usable record, not just a pretty picture.
Start with one product set and trace every completed preview through identity, permission, purchase, and suppression. To make those outputs part of your Shopify store, add Antla from the Shopify App Store.