Most lists of augmented reality marketing examples are showreels: a lipstick try-on, a furniture placement app, a QR-triggered packaging animation. Useful as inspiration, useless as a build brief. The examples worth studying are the ones you can take apart — what tracking method holds the illusion together, which device surface it runs on, where the 3D assets came from, and what the experience does when tracking drops on a mid-range handset in a badly lit shop aisle.
That last question is where published AR campaigns tend to separate. The recurring failure is not a weak concept; it is capture-to-render quality and device coverage. Both are computer-vision and pipeline problems, not creative ones.
What are the main categories of AR marketing example?
Four families cover almost everything published under this label, and each rests on a different tracking primitive.
| Example type | Tracking method | Typical surface | Where it breaks |
|---|---|---|---|
| Virtual try-on (cosmetics, eyewear) | Face landmark detection and pose estimation | Web AR in-browser | Occlusion, glasses already worn, low-light front cameras |
| Product placement (furniture, appliances) | Plane detection and world tracking | Native app (ARKit / ARCore) | Featureless floors, reflective surfaces, drift over distance |
| Packaging activation | Image-marker tracking from the printed artwork | Web AR via QR entry | Low-contrast or glossy print, partial occlusion of the marker |
| Out-of-home / event | Marker or geo-anchored world tracking | Native app or kiosk | Crowds, changing daylight, moving anchor surfaces |
Note what the table implies about ambition. Face and image-marker examples are constrained problems with a fixed reference geometry, which is why they survive on web AR. Markerless world tracking asks the device to build and hold a model of an unknown room, and that is where a demo shot on a flagship phone stops resembling what a customer sees.
Web AR or native app?
Web AR wins when the entry point is a link, a QR code, or a social ad, and the tracking task is bounded — a face, a printed marker, a single small object. No install step, so the funnel does not leak. It loses when the experience needs persistent world tracking, high-polygon assets, depth occlusion, or sustained frame rates, because browser runtimes give you less of the sensor and GPU pipeline than ARKit or ARCore do natively.
A useful rule from the build side: if the concept requires the object to stay convincingly anchored while the user walks around it, assume native. If the object only has to sit correctly relative to a face or a package, assume web AR and test the assumption on the cheapest handset in your audience.
The two numbers that decide it
Engagement dwell time, try-on-to-add-to-cart conversion, and return-rate reduction on fit-sensitive SKUs are the outcomes AR marketing teams typically report. They are worth tracking, but they are not the go/no-go test. The go/no-go test is two cost-side numbers, known before commitment:
- Device coverage — what share of your target audience’s handsets sustain stable tracking at an acceptable frame rate, measured on real devices rather than a simulator.
- Asset cost per SKU — what production-grade 3D content actually costs to model, texture, and validate, multiplied by the catalogue size you intend to cover.
An AR marketing example is only worth copying if both numbers are on the table. A campaign that renders beautifully on 12% of the audience’s phones and needs a bespoke 3D model per colourway is a demo with a media budget attached.
Telling a shippable concept from a demo
Ask three things of any example you are shown. Was it filmed on one device, or is there evidence of a tested device matrix? Does the tracking degrade gracefully — a 2D fallback, a static product image, a clear prompt — or does it simply fail? And does the asset pipeline scale to the whole catalogue, or was one hero SKU hand-built for the shoot?
We see the same pattern across vision work generally: the interesting engineering sits in detection, pose estimation, and robustness under bad input, not in the render. Those are computer vision problems, and the build-side choices behind them — marker versus markerless, web versus native, coverage targets — belong to augmented reality engineering.
Before signing off on an AR concept, the question to answer is not whether it looks good in the pitch video. It is what percentage of your customers’ phones can hold the illusion for thirty seconds.
