The Same AR Build Pays Back on a Product Page and Fails on a Microsite

Take an AR experience that works. Good tracking, sensible lighting, fast on a mid-range phone. Put it on a campaign microsite and it will be retired within a few months. Put the identical build on the product detail page and it can still be earning in three years. The code did not change. The placement did, and placement is the variable that decides whether any of this money comes back.

This is not a subtle effect at the margins. It is the difference between a fixed cost amortised over a six week burst and the same fixed cost amortised over every qualified visitor to that product, indefinitely.

The microsite makes you buy every visit twice

A microsite has no traffic of its own. Every person who sees the experience arrived through paid media, a QR code on packaging, an email, or a social post, and every one of those routes has an acquisition cost attached. You pay to build the experience, then you pay again for each person who reaches it, and the second cost never stops while the campaign runs.

Worse, the audience you buy is cold by definition. They were doing something else, they were interrupted, and now they are being asked to grant camera permission to a domain they have never seen. Drop-off at that permission prompt is severe and it is not a design problem you can fix with a better button. It is what happens when you ask for hardware access before establishing why.

The product page inverts every part of this. The visitor arrived on their own, through search or a link or a previous session. They are already looking at the thing. They already have the specific question the experience answers, which is whether it will suit them or fit their space. Camera permission granted at that moment is granted by someone with a reason, and the difference in acceptance is the whole ball game.

	Campaign microsite	Product detail page
Traffic source	Bought, every visit	Existing, already qualified
Visitor intent when they arrive	Interrupted	Actively evaluating the product
Camera permission acceptance	Low, no established reason	Higher, the question is already formed
Lifespan of the build	Ends with the campaign	Runs until the product is delisted
What it is measured on	Reach, dwell, shares	Conversion rate, return rate, revenue per session
Who owns it afterwards	Usually nobody	The ecommerce team, by default

The last row is quietly the most important one. A microsite has no owner once the campaign closes, so nothing updates it, a browser release eventually breaks something, and it dies without anyone deciding to kill it. A product page component sits inside a system that someone is already responsible for keeping working.

What the product page demands in return

Product page placement is harder than microsite placement, which is the real reason teams avoid it. A microsite can be a heavy standalone thing with its own loading screen and nobody complains. A product page has a performance budget, an existing template, a merchandising team, and a conversion rate that people watch daily. You cannot drop a large 3D payload into that and expect a warm reception.

That means the experience has to load lazily behind a deliberate tap rather than on page load, degrade to the normal gallery on any device that cannot support it, and add nothing measurable to the initial render. It also means it has to work without an install, because sending someone from a product page to an app store is sending them away from the buy button. The tradeoffs here are covered properly in the comparison of WebAR against app-based AR and when each is justified, and for anything sitting on a commerce page the browser route is almost always the answer.

There is a content requirement too, and it is the one that stops rollouts. A microsite needs a handful of hero products modelled to a high standard. A product page rollout needs an asset for every product on which the button appears, and an answer for what happens on the products where it does not. Planning for producing 3D assets for AR across a real catalogue is the difference between a feature that covers your range and a feature that covers nine items and looks broken everywhere else.

Why teams keep choosing the microsite anyway

Because of how the money is shaped, not because anyone believes the microsite is better. Campaign budgets are annual, discretionary, and available now. Product page changes require engineering time on a roadmap that is already full, sign-off from a team whose job is to protect conversion rate, and a longer approval path. The microsite is not the better option, it is the reachable one.

The second reason is measurement. A campaign can be reported on impressions, dwell time and shares, all of which are available immediately and all of which look good. A product page feature is measured on conversion and returns, which take longer to read and can come back flat. Choosing the microsite is often a choice to be judged on friendlier numbers.

Recognise that trade for what it is. If the goal genuinely is launch noise at an event, a short-lived activation is the right tool and it should be scoped and priced as disposable. The guide to what immersive brand experiences are and why so many get forgotten makes the same split, and the mistake is not building activations, it is building one and expecting it to behave like a feature.

A route that gets you onto the page

1. Pick three to five products where the customer's objection is visual: scale, finish, or how it looks on them. These are your evidence, not your rollout.
2. Build the experience as a component that the product template can call, not as a standalone site. Even for a pilot, this decision costs little now and saves the rebuild later.
3. Gate it behind an explicit tap, lazily loaded, with the standard image gallery as the fallback on unsupported devices.
4. Agree the measurement before launch: conversion rate and return rate for those products, against a holdout, over a period long enough to be readable.
5. Only then discuss catalogue coverage, because the asset pipeline is the expensive commitment and it should follow the evidence rather than precede it.

What to do next

Look at where your last immersive project lived, and whether anyone currently owns it. If the honest answer is a microsite with no owner, the lesson is about placement rather than about AR.

For the next one, start from the product page constraint and work backwards: what can load in that budget, what fallback the unsupported devices get, and which products have a visual objection worth answering. The practical patterns for that sit in the guide to building immersive product demos that live on commerce pages, and the delivery and asset questions are where the AR and VR immersive marketing work usually begins. Build for the page you already have traffic to, and the campaign version comes free later if you still want it.