Problem

Many sites “have analytics” and still cannot answer basic questions. The problem is usually the event model, not the script tag.

Context / users

This is a service page backed by a smaller but real implementation in the portfolio. Analytics is isolated, mounted once, and allowed explicitly through the app security model.

Solution

I treat analytics as application design. Define what matters, instrument it deliberately, and keep the tracking layer separate from the UI layer.

• Service-facing case study integrated into a reusable data-driven project system
• Measurement-aware portfolio implementation with a dedicated client-only analytics wrapper
• Server-generated metadata and share cards for route-level SEO consistency
• Structured-data support and canonical metadata as part of the measurement baseline
• Security-header and nonce handling that keeps third-party script loading explicit
• A portfolio framing that connects analytics to websites, SEO, reporting, and optimization work

Architecture

The case study lives inside the shared `/projects/[slug]` system driven by `lib/projectsData.js`. The measurement-related implementation follows a clean boundary: analytics is loaded client-side through a dedicated wrapper, mounted from the root layout, and permitted through a nonce-based CSP in middleware.

Engineering Details

• • Kept analytics behind a dedicated wrapper component instead of scattering third-party script logic across pages
• • Loaded analytics client-side with SSR disabled so instrumentation does not complicate server rendering
• • Mounted analytics once in the root layout, which avoids per-page duplication and keeps the app shell responsible for instrumentation
• • Used middleware-generated nonces and CSP headers so script execution is explicit rather than permissive
• • Generated project metadata from route data, which keeps SEO and content structure consistent across case-study pages
• • Used a shared case-study renderer so service pages and build pages follow the same architectural spine

Stack

Outcome

• Made analytics and measurement strategy a visible part of the λstepweaver service stack instead of leaving it implied
• Created a reusable place in the portfolio to explain measurement work in technical terms
• Demonstrated measurement-aware implementation habits in the portfolio itself, even without exposing client GA properties
• Kept the public proof honest: the repo shows architecture and implementation patterns, not confidential client dashboards or production analytics accounts

Tradeoffs / Limits

• • This repo does not expose a public GA4 property, GTM container, event schema, or Looker Studio dashboard
• • The current public proof is architectural rather than outcome-rich; there are no before/after metrics or sanitized dashboard screenshots yet
• • Because this is a service page inside the main portfolio repo, it reads less like a standalone project than entries tied to a shippable app
• • Jest is configured at the repo level, but no analytics-specific tests are visible in the public implementation
• • The credibility ceiling stays lower until the page includes a concrete artifact such as an event map, implementation snippet, or reporting example

Why It Matters

It shows that I think about instrumentation as part of the system, not as an afterthought.