←back to projects
May 2026/Fullstack/professional

AR WebAR Product Marketing

This project reframes product marketing as an interaction-system challenge: users should move from poster scan to product context and conversion CTA with minimal friction, while runtime stability remains predictable on mobile browsers.

project links
Repositoryrepo
Domain
Fullstack
Role
Product Engineer and AR Experience Builder
Output
Web App
Category
AR-Enhanced Product Experience
Project Framing

A source-backed case study built for recruiter review

This reading path makes the problem choice, evidence quality, user framing, execution decisions, and proof trail visible without overstating what the sources support.

Project Type
professional

AR-first WebAR campaign experience with product-specific scan targets and route-based conversion flow for Apple-themed digital marketing demos.

Orientation
Hybrid

Produces a reviewer-friendly AR campaign blueprint that shows how interaction flow, runtime fallback, and content variation can be managed in one implementation.

Core Stack
React · TypeScript · Vite · MindAR

Vite + React + TypeScript frontend with route-based sessions (`/`, `/scan`, `/after-scan`), MindAR runtime for image-target tracking, and product-specific content registry.

Why This Problem Mattered

Problem framing before execution

The case-study layer starts with why this problem was selected and how the context justified investment.

Problem Framing Map

Issue

AR campaign experiences often fail at transition quality between scan, product context, and conversion action.

Context

The repository positions WebAR as a practical marketing demo where route flow and product-asset contracts matter as much as 3D rendering itself.

Why Selected

It is a strong case because it demonstrates concrete interaction architecture decisions for AR in a browser-first setup without inflating unsupported impact claims.

Problem statement

AR campaign demos often break when marker handling, product selection, and post-scan conversion paths are not treated as one coherent flow.

Solution thesis

Built a route-based WebAR experience with product query contracts, per-product marker assets, and explicit after-scan CTA handoff.

Research and Evidence

What supports the narrative

Evidence is surfaced with its source type and credibility note so the recruiter can quickly see what is directly backed versus intentionally constrained.

Flow architecture evidence
public

The README explicitly defines intro, scan, and after-scan routes with query-driven product selection.

Credibility: Directly traceable to the repository README and route contract section.
Open supporting public source
Runtime resilience evidence
public

Model-loading fallback and marker-generation workflow are documented as part of operational behavior.

Credibility: Corroborated by README runtime notes and repository file structure.
Open supporting public source

Credibility Notes

  • ●Public copy is limited to documented architecture, route contracts, and runtime behavior.
  • ●No conversion-rate, campaign-lift, or production traffic metric is claimed because repository sources do not provide those outcomes.
Who The User Was

User framing stays explicit

When formal research artefacts are not available, the page still explains who the work served and why that user framing is justified by the existing sources.

Primary user
Mobile visitors scanning campaign markers to view product-specific AR interactions.

The route and product-ID contract is explicitly designed around this scan-first journey.

Operational stakeholder
Campaign operators needing predictable marker assets and post-scan CTA handoff behavior.

Marker-generation workflow and after-scan flow are documented as operational controls.

Decision Flow

How design thinking translated into decisions

The goal is to show the trace from research and insight to concrete product or system decisions, then to the outcomes those decisions supported.

Design Thinking Flow

Each step keeps the movement from evidence to action explicit before the rationale expands it.

  1. Step 1
    Journey decomposition

    Separated intro, scan, and conversion into dedicated routes to reduce context overload.

    Signal: Interaction architecture is treated as a first-class system decision.
  2. Step 2
    Product contract framing

    Defined product IDs and marker locations as explicit contract inputs.

    Signal: Multi-product AR behavior becomes scalable without route duplication.
  3. Step 3
    Fallback-first reliability

    Documented runtime fallback when model resources fail or are unavailable.

    Signal: Demo stability is protected even when ideal rendering paths are not met.

Decision Rationale

Each decision keeps the path from insight to execution visible before ending on the outcome signal.

Route segmentation
Insight

AR sessions become fragile when onboarding, scan runtime, and conversion are mixed in one state surface.

Decision

Used dedicated pages for each stage (`/`, `/scan`, `/after-scan`).

Outcome

Flow becomes easier to validate and reason about for demo and QA.

Query-based product selection
Insight

Hardcoding one product path would limit campaign extensibility.

Decision

Adopted `?product=<productId>` contract for product-specific AR sessions.

Outcome

Single scan route can serve multiple product contexts with consistent behavior.

Solution and System Execution

Execution choices and delivery details

This section preserves the technical and operational substance: architecture, responsibilities, trade-offs, and implementation quality signals.

System Design

Vite + React + TypeScript frontend with route-based sessions (`/`, `/scan`, `/after-scan`), MindAR runtime for image-target tracking, and product-specific content registry.

Source-backed Impact

Produces a reviewer-friendly AR campaign blueprint that shows how interaction flow, runtime fallback, and content variation can be managed in one implementation.

Responsibilities

  • ●Defined product-level URL contract and AR route choreography
  • ●Implemented marker/runtime fallback behavior for safer demo reliability
  • ●Structured content and asset registry for multi-product campaign scaling

Stack Decisions

  • ●Used MindAR + Three.js to preserve image-target AR behavior in web runtime
  • ●Used query-driven product selection to avoid duplicating route logic
  • ●Kept flow route-based for cleaner conversion-state handoff

Trade-offs

  • ●Accepted mobile-browser AR constraints to keep deployment lightweight
  • ●Prioritized deterministic product flow over broad feature expansion

Challenges

  • ●Keeping AR runtime stable across product-specific marker assets
  • ●Designing graceful fallback when model or marker resources are incomplete
Execution Visuals

Architecture and outcome snapshot

This visual layer keeps execution readable: how the system or delivery flow was structured and which source-backed outcomes mattered most.

Execution Flow

  1. Step 1
    Route-Oriented Journey

    Designed a three-step route flow from intro to scan to conversion handoff.

    Signal: User progression is explicit and testable.
  2. Step 2
    Product-Scoped Runtime

    Mapped product IDs to marker and content assets for deterministic scan behavior.

    Signal: Same runtime supports multiple campaign variants.
  3. Step 3
    Fallback Safety

    Added documented fallback when optional 3D model assets are unavailable.

    Signal: Demo remains functional under partial asset readiness.

Outcome Snapshot

  • Product Matrix
    5 product IDs

    Defined in README route contract

  • Journey Steps
    3 route stages

    Intro, scan, and after-scan handoff

  • Ops Readiness
    Marker generation script

    `npm run markers:generate` documented

Outcomes and Proof

What was delivered and what can be verified

Outcome claims remain conservative and source-backed, while proof records and recruiter-safe links surface the strongest verification trail available.

Validation Signals

  • ●README documents five product IDs and scan URL examples.
  • ●Marker generation and smoke test commands are included in the project documentation.

Source-backed Outcomes

  • ●Five product IDs are explicitly supported in the scan contract
  • ●Three dedicated user-flow routes are documented for intro, scan, and conversion handoff
  • ●Marker generation workflow is scripted with `npm run markers:generate`
Retrospective and Limits

What the project proves, and what it does not

Strong case studies show both what was learned and where the current evidence stops.

Retrospective

Next iteration should add empirical device QA evidence and controlled latency traces per product marker.

Evidence Limits

  • ●Current sources do not provide production campaign outcomes or user-behavior analytics.
  • ●Device QA claims remain bounded to documented target-policy notes, not broad hardware certification.

Lessons

  • ●Campaign AR products need explicit URL and asset contracts early
  • ●Fallback behavior is as important as primary visual polish in demo systems