GuidesBuild a routine

Analytics reporting with PostHog

Turn product data into a recurring brief that compares periods and recommends questions, not just numbers.

A dashboard tells you the number. A routine tells you the number changed, by how much, and what to look at next — on the same day every week, without anyone remembering to look.

What you get: a recurring analytics brief with period comparisons, notable changes, caveats, and next questions.

Prerequisites

  • A PostHog connection. PostHog uses OAuth with PKCE and requests openid, profile, email, insight:read, event_definition:read, and query:read — all read scopes.
  • A tool-capable model.

Configure it

Start from the template

Routines → New routine → Weekly or monthly analytics report. Suggested schedule: 0 9 * * 1.

Set reportingWindow — for example Previous calendar week — and reference it as {{reportingWindow}}.

Name the metrics, not the vibe

The single biggest quality lever is listing the metrics explicitly:

Report these, in this order, for {{reportingWindow}} and the equivalent prior period:
1. New signups
2. Activation rate (signup → first successful routine run)
3. Weekly active projects
4. Runs started, runs succeeded, run success rate
5. Top three error categories by count

Vague instructions produce a different report every week, which defeats the purpose of a recurring one.

Forbid invented causation

Add this constraint explicitly: report what moved and by how much; propose hypotheses only when they can be checked against another query; never assert a cause the data does not support.

Analytics routines fail in a specific way — a fluent narrative explaining a change that never happened. Asking for the query behind each figure makes that visible in the trace.

Approve read tools only

Discover tools on the PostHog connection and enable insight, event definition, and query reads. There is nothing in a reporting routine that needs write access.

Prove it, then activate

Run it manually and check the tool_call steps: does each headline number correspond to a query that was actually executed? Then activate.

Tuning

  • Monthly instead of weekly. 0 9 1 * * runs at 09:00 on the first of the month. Update reportingWindow to match, or the prose and the data disagree.
  • Reports nobody reads. Ask for a three-line summary at the top: what moved, what it probably means, what to check. Everything else becomes supporting detail.
  • Timeouts on large queries. Analytics runs are the most likely to hit the 20-minute ceiling. Narrow the window, reduce the metric count, or split one routine into two.

On this page

Edit this page on GitHub