analytics

# Analytics — the instrumentation layer This skill owns the **capture** side of analytics: deciding *what to track*, *how to name it*, *where the SDK lives in the codebase*, and *how not to leak PII or break consent law*. It produces three checkable artifacts — an event taxonomy, tracking code (GA4 and/or PostHog), and a consent wiring. Everything downstream of capture (charts, KPI choice, experiment stats, raw-event SQL, legal text) belongs to a sibling; see the routing table below. The order of work is fixed: **taxonomy → SDK wiring → consent gate → PII scrub → funnel + validation.** ## When NOT to use | The ask | Route to | | --- | --- | | Chart the captured data on a board | `dashboard` | | Decide *which* metrics matter (North Star, AARRR) | `kpi-framework` | | Scheduled stakeholder reports / exports | `reporting` | | Variant assignment, significance, experiment design | `ab-testing` (PostHog *experiments* live there; PostHog *event capture* lives here) | | Query a warehouse of raw events with SQL | `clickhouse-analytics` / `duckdb` / `sql` | | App error/trace/uptime telemetry (Sentry, OpenTelemetry) | `observability` | | Cookie-banner legal text, DPA, ROPA, subject rights | `gdpr-privacy` / `data-policy` | | Predict future values from a series | `forecasting` | The load-bearing line: `analytics` = events flow **in**; `dashboard`/`reporting` = events flow **out**. ## Decision: GA4 vs PostHog vs both | You need | Pick | | --- | --- | | Web/ads attribution, Google Ad...