TaskFlow — PostHog Product Analytics Pipeline preview
Situation
An analytics portfolio usually starts from a ready-made CSV; this one starts earlier — with instrumenting the app
Task
Define events without PII leaks, get them into the analytics tool, and turn raw events into decisions
Action
Typed event catalog, PII scrubbing; A/B with chi-square, uplift, Wilson CI, SRM; SQL mirror, Streamlit dashboard, CI, Docker
Result
Onboarding test on a seeded stream: completion 55.9% → 70.8% (+26.6%, χ² = 40.10, p < 0.0001, SRM p = 0.90), and 6.3% of completed signups reach a paid upgrade
Stack
PythonPostHogFastAPIStreamlitpandas / matplotlibpytest / ruffDocker
Source View on GitHub → Repo is private — available on request Updated: Nov 1, 2026
On this page
  1. Situation
  2. Task
  3. Actions
  4. Pipeline
  5. What it demonstrates
  6. Result
  7. Limitations
  8. Documentation

TaskFlow — PostHog Product Analytics Pipeline

▶ Data-flow diagram — self-contained HTML, opens in a browser — no install, no build

Situation

Most analytics portfolios start with a ready-made CSV. This project starts earlier — with instrumenting an application: define events without PII leaks, get them into the analytics tool, and turn raw events into decisions. The pipeline runs the whole cycle — generate traffic, capture events, analyze, dashboard, and deploy.

Task

I needed to work from instrumentation rather than a handed-over export, so I owned the event plan, the capture path, and the analysis and dashboard that turn raw events into decisions.

Actions

Pipeline

app/                Demo SaaS (FastAPI + Jinja2): routes + server-side capture
  analytics/        typed event catalog · PostHog wrapper (PII scrub) · feature flag
scripts/            simulate_events.py — 30 days of realistic funnel traffic
analysis/           funnel · cohort · A/B · revenue/LTV · time-to-convert · feature-usage · SQL
dashboard/          interactive Streamlit dashboard

What it demonstrates

  • Instrumentation: a typed event catalog as the single source of truth; server-side capture; PII scrubbing.
  • A/B: feature flag → onboarding variant; chi-square, uplift, Wilson CI, SRM check.
  • Metrics: funnel, Day-N cohort retention, time-to-convert, revenue/LTV, first-feature → upgrade.
  • SQL mirror: the same metrics as SQL — a reference for BI and interviews.
  • Engineering: pytest + ruff in CI, Dockerfile, render.yaml for one-click deploy.

Result

The value is in the completeness of the cycle. The typed event catalog and PII scrubbing separate production instrumentation from a demo: events are defined in one place, PII does not leak, and the metrics reproduce in both Python and SQL. One repo covers the full analytics lifecycle — instrument → generate → analyze → dashboard → deploy.

  • Onboarding: completion 55.9% → 70.8% (+26.6% relative), χ² = 40.10, p < 0.0001 at SRM p = 0.90 — uneven buckets do not explain the effect.
  • Money and speed: 6.3% of completed signups reach a paid upgrade (107 of 1,709) for $1,712 of revenue at $1.00 ARPU; the median signup-to-first-core-action time is 2.0 h.

Limitations

Traffic comes from a simulator, not real users: the event stream is seeded, so every number above demonstrates the methods rather than a production result. The value is the instrumentation discipline and the complete cycle, where every step reproduces.

Documentation

Need this reasoning applied to your data?

Tell me the task — I'll come back with a plan: what data it needs, what we test, and how long it takes. I reply within a day.

Discuss a task →