---
name: convention-analytics
type: convention
description: "Conventions for web analytics and consent in Aled's system — the consent posture chosen by site type (personal/portfolio vs commercial), the tracking approach that follows from it, and what requires human action. Read before setting up or changing analytics on any site so the consent posture is picked by site type without re-deciding each time. Follows the convention-github/vercel/sanity/mux pattern; a first draft, grown as analytics setups are repeated."
---

# convention-analytics

How analytics and consent are set up across Aled's sites. Follows the same pattern as `convention-github` and the other tool conventions — this is a first draft that records the operating line, not the final word. Grown as analytics setups are repeated across the ventures.

## The rule: consent posture is chosen by site type

The consent posture — whether a site carries a cookie-consent banner or runs cookieless with none — is decided by the **type of site**, not re-argued per project:

* **Personal / portfolio sites → cookieless, no banner.** A cookieless analytics setup that sets no cookies and collects no personal data needs no consent banner, so a portfolio site runs clean with no interruption to the visitor. Default tool: **PostHog in cookieless mode** (the meirionpritchard.com setup, A1-115 Option 2). Applies to the personal/portfolio sites — meirionpritchard.com, aledpritchard.com, and peers.
* **Commercial sites → consent banner.** A commercial site (a store, a product, a client site) runs a **proper cookie-consent banner** (A1-115 Option 1/3) so it can use the capabilities that need cookies. Applies to madebyneud/BARA, careerOS, and A1 client sites.

Pick the site type first; the posture and default tooling follow from it.

## Why the split — the trade-off the cookieless path imposes

The cookieless, no-banner path is clean and privacy-first, but it gives up capabilities that need cookies or a persistent identifier: **no reliable A/B testing, and unreliable session replay**. For a portfolio site that does not run experiments, that loss is costless — so cookieless is the right default there. A commercial site *does* need A/B testing and dependable session replay to optimise conversion and revenue, so the commercial default preserves those capabilities, and the price of preserving them is the consent banner. The banner is not friction for its own sake — it is what buys back the cookie-dependent capabilities a commercial site relies on.

So the default is not "banner everywhere" or "cookieless everywhere": it is cookieless where the cookie-dependent capabilities are not needed (portfolio), and banner where they are (commercial).

## What requires human action

* **Choosing to deviate from the default for a specific site** — running a portfolio site with a banner, or a commercial site cookieless — is the operator's call, recorded as a per-project decision on the relevant ticket / decision log, not something a setup run decides on its own.
* **The consent-banner copy and the legal basis** on a commercial site are the operator's to confirm before go-live.

## Notes

* This default was stated by Aled while setting up meirionpritchard.com analytics (2026-07-07), where it existed only as a per-project decision on A1-115; folded to canon here so future analytics setups pick the consent posture by site type without re-deciding (surfaced APP-460).
* Where a commercial site's conversion tracking spans several tools (e.g. Meta Pixel + Shopify + GA4), verifying it end-to-end is its own task — see the venture's tracking-verification ticket, not this convention.