Content architecture
The schema separates reusable specifications from campaign copy and optional conversion controls.
Read the vehicle schema →Implementation case study · Personal prototype
One vehicle content model, multiple marketing views.
EV Landing Lab demonstrates how structured CMS content can support offer listings, detail pages, comparison content, and an optional lead form.
Problem and scope
Vehicle specifications, pricing, and campaign copy need to stay consistent across multiple pages. This prototype puts those fields in Sanity and reuses them in Astro templates instead of maintaining each offer page by hand.
My project scope: the vehicle schema, CMS queries, page templates, comparison view, and lead-form integration. This is a personal implementation sample; no client conversion results or production scale are claimed.
How the implementation works
- Model: a Sanity vehicle document contains copy, image, price, specifications, inventory status, CTA settings, and a lead-form toggle.
- Fetch: GROQ queries retrieve published vehicle data from the configured public dataset during the Astro build.
- Generate:
getStaticPaths()creates a detail route from each vehicle slug; listing and comparison templates read the same document type. - Capture: the optional form posts to Formspree with vehicle, page path, source, and three UTM fields populated from the current URL.
Tradeoff: build-time rendering delivers the content in HTML, but a CMS edit needs a successful rebuild before it appears on the site. A publishing webhook or deployment trigger is not documented in this repository.
Inspect the evidence
Routes and rendering
The detail template maps CMS slugs to build-time pages and conditionally renders specifications, CTA, and form.
Read the detail template →Content reuse
The comparison query sorts vehicles by title and renders their structured specifications side by side.
Read the comparison implementation →QA and defect resolution
A source review found attribution code accessing fields on pages where the CMS had disabled the form. A guarded helper and focused regression checks now cover that case.
Read the defect-to-verification walkthrough →Delivered behavior and limits
The repository implements reusable offer views and a configured form submission path. It does not contain a verified lead-delivery report, conversion dashboard, traffic baseline, or evidence of conversion lift.
- UTM capture covers the current page URL; attribution is not persisted across navigation.
- The form offers Phone and Text preferences without collecting a phone number. That requires a product decision before production use.
- Required-field validation for vehicle documents and missing-slug handling need hardening.
- Production readiness still requires browser QA, authorized test submissions, delivery verification, and confirmed analytics events.
Next outcome to measure: record a baseline for publishing a new offer, then measure time to publish and content discrepancies across the three views. Conversion measurement should follow only after the submission and analytics paths are validated.