Skip to content

web-presence analytics (Plausible) — operator activation

Riff #212 instrumented the agent-first web-presence with Plausible custom events to measure the brainstorm's KPIs (engagement + captured intent). The code is shipped but inert until you activate it — nothing is sent from dev, local, CI, or any build where the domain is unset. No cookies, no PII, no consent banner (chosen to fit the platform's GDPR/DSAR posture).

What's already in the code

  • src/lib/analytics.ts — injects the Plausible script only when VITE_PLAUSIBLE_DOMAIN is set at build time; exposes a typed track().
  • Emit points (the fixed taxonomy): | Event | Fired when | Props | |---|---|---| | nav_canvas | a chip or SiteNav item opens the agent canvas | intent, source (chip|nav) | | rag_prompt | a free-text RAG prompt is submitted (a chat turn) | lang | | contact_submit | the in-chat contact form submits successfully | source (chat) |
  • Dockerfile declares ARG/ENV VITE_PLAUSIBLE_DOMAIN (empty default).

Note: the CI build-arg wiring is intentionally not pre-added (step 3 below). Editing .gitlab-ci/services.yml re-triggers every frontend + service docker-build, and deploy-qual has no needs: (it blocks on the whole build stage) — so pre-wiring an inert feature would risk an unrelated latent build failure blocking deploys. The one-line add is part of activation instead.

To activate (operator, ~10 min)

  1. Provision a Plausible site. Plausible Cloud (~€9/mo) or self-host. Add a site whose domain matches the env you're tracking:
  2. qual: web-presence.qual.portugalodyssey.pt
  3. prod (later): portugalodyssey.pt
  4. Set the GitLab CI variable. Project → Settings → CI/CD → Variables → add PLAUSIBLE_DOMAIN_QUAL = the site domain from step 1 (Variable type, environment qual, not masked — it's a public domain, not a secret).
  5. Add the build-arg line to .gitlab-ci/services.yml, right after the public-fo Stripe/Maps block (graceful :-, never fails the build): 
    if [ "${FRONTEND_NAME}" = "web-presence" ]; then
  BUILD_ARGS="${BUILD_ARGS} --build-arg VITE_PLAUSIBLE_DOMAIN=${PLAUSIBLE_DOMAIN_QUAL:-}"
fi
    (This edit re-triggers all docker-builds once — expected.)
  6. Deploy. The merge rebuilds web-presence with the domain baked in; Plausible starts loading + receiving events on the next deploy-qual.
  7. Verify: open web-presence.qual.portugalodyssey.pt, click a hero chip, and confirm the event appears in the Plausible dashboard (Realtime).

For prod, repeat with a separate PLAUSIBLE_DOMAIN_PROD variable + a per-env build arg when prod first ships (mirrors the Stripe-key per-env pattern).

Why Plausible (not a first-party events table)

Decided 2026-05-27 (José): lowest-effort path to the measurable KPIs, no backend/migration, and the no-cookie privacy model means no consent-banner work and no DSAR surface. A first-party web_events lane was the considered alternative (full SQL ownership) — retained as a future option if event volume or custom analysis outgrows Plausible.