---
name: tin-posthog-growth-review
description: "Review PostHog evidence for one product-growth decision. Verify event and property health, segment acquisition from product and test activity, trace ordered journeys, inspect session replay only when needed, and return one outcome: ship a focused change, repair measurement, or wait. Use when asked for a PostHog review, funnel diagnosis, session-replay review, source-attribution check, activation-friction analysis, or a growth task grounded in PostHog behavior."
---

# Tin PostHog growth review

Review one decision, not the whole dashboard. Connect counts to sources and ordered journeys, then return one defensible outcome: ship a focused change, repair measurement, or wait.

## Inputs

Collect or infer the narrowest useful version of these inputs:

- Product-growth decision to inform.
- Surface, source, or segment in scope.
- Success event and meaningful downstream outcome.
- Date window and comparison window, when relevant.
- No-change condition.
- Available PostHog project, export, mirror, or read-only analytics access.

If the request is broad, turn it into one operational question before opening a chart. Do not block on a perfect brief when the current growth goal and readable events make a narrow question clear.

Use this decision contract:

> Decide whether to change [surface or flow] for [source or segment] based on whether [success event] repeats in [window]. Make no change if [no-change condition].

## Safety and privacy boundaries

- Treat the review as read-only unless the user explicitly asks for implementation.
- Do not change PostHog projects, dashboards, insights, event definitions, feature flags, persons, recordings, retention settings, or stored data.
- Do not write manual metric rows or backfill events to make a funnel look complete.
- Do not expose API keys, tokens, customer emails, names, domains, account or project identifiers, raw replay links, or private URL parameters.
- Anonymize examples and report patterns, not people. Use bounded labels such as public visitor, partner participant, returning user, or internal test.
- Respect configured replay masking. Stop replay inspection and report the limitation if sensitive inputs or text are visible.
- Do not infer private intent from replay. Visible behavior can show what appeared on screen, not why a person acted.
- Do not claim causality, conversion lift, demand, or a universal benchmark from descriptive behavior.
- Do not use a universal minimum session count. Match the evidence threshold to the proposed action.
- Do not contact users, send messages, publish content, launch ads, spend money, merge, or deploy from this review.
- If implementation is explicitly requested, keep the change small and reviewable, preserve approval gates, and verify it without claiming an unmeasured outcome.

## Step 1: Define the decision

Write the decision contract before querying events. Name:

- One surface or flow.
- One source or segment.
- One success event.
- One meaningful downstream outcome.
- One date window.
- One condition that would justify no change.

Reject questions such as “What are users doing?” or “How is activation?” until they are narrowed. A good review can end without a product change.

## Step 2: Verify the event stream

Probe the available PostHog tool, connected mirror, or export before declaring data unavailable. Inspect the tool's current help or schema instead of assuming command or field names.

Confirm:

- Required events exist in the selected window.
- Events fire from the expected surfaces.
- Properties needed for filtering and joining remain present downstream.
- A stable journey key can connect the relevant steps when the flow crosses pages or product setup.
- Source or campaign context survives to the meaningful outcome.
- Internal, automation, local, founder, example, and obvious test activity can be excluded using evidence rather than guesses.
- Person-level or journey-level counts are deduplicated when raw event totals can repeat.

Common useful fields include source, landing path, current URL, campaign, scan or report key, project or workspace key, and the downstream action. Use only fields that actually exist. Do not invent a join when the identifiers are missing.

If missing events, properties, or join fields prevent the decision, stop conversion interpretation and choose measurement repair.

## Step 3: Separate traffic jobs

Split sessions or journeys by the job they are doing:

- Public acquisition: homepage, pricing, comparison, learn pages, search, referrals, and direct visits.
- Partner or campaign traffic: campaign parameters, partner pages, event slugs, and other bounded sources.
- Product use: dashboard, workspace, task, chat, invite, and returning signed-in activity.
- Internal or test activity: local checks, automation, example data, founder tests, QA, and smoke traces.

Do not let a returning product user vote on an acquisition-page change. Do not let a smoke test stand in for demand. A clean test can prove instrumentation works and nothing more.

## Step 4: Read ordered journeys

Use each PostHog view for the question it can answer:

- Use totals for scale and source health.
- Use funnels for conversion through already-defined steps.
- Use paths or ordered event sequences for what happened before and after a stop.
- Use retention for whether the same person returns to repeat a meaningful behavior.

For each relevant journey, record:

1. Landing surface and source.
2. First meaningful action.
3. Report, handoff, or product step reached.
4. Stop point or successful outcome.
5. Later return, if any.
6. Whether the pattern repeats in another real journey from the same source or segment.

Keep aggregate facts and journey facts separate. A funnel can show a drop; a journey can show the route around it. Neither proves motivation.

## Step 5: Use replay only for visual questions

Inspect session replay only when the decision depends on what appeared on screen, such as:

- Whether the action was visible.
- Whether an error, loading state, or modal blocked progress.
- Whether the person looped between screens or controls.
- Whether the interface promise and immediate result visibly disagreed.

First classify candidate recordings as abandonment, confusion, error, or successful completion. Then inspect the smallest set of relevant examples, prioritizing failed journeys over successful sessions with minor friction.

If replay is unavailable, say that the review is based on events, paths, URLs, and timestamps. Do not downgrade an event-sequence review merely because replay is absent when the question does not require a visual explanation.

## Step 6: Match the evidence threshold to the action

Apply these rules:

- One real hard error or dead end can justify the smallest mechanical fix.
- Repeated stops at the same step from the same source can justify a focused product or copy change.
- One connected journey with missing source or join fields can justify measurement repair.
- One interesting trace that does not repeat is a clue; wait.
- Confusion followed by success is lower priority than the same confusion followed by abandonment.
- A clean smoke test proves instrumentation, not acquisition or activation.

Prefer the smallest conclusion supported by the evidence. If the sample is thin, name the exact event or repeated path that would change the call.

## Step 7: Choose ship, repair, or wait

Choose exactly one primary output.

### Ship a focused change

Choose ship when a repeated journey or confirmed hard failure names a fixable obstruction. State the surface, source, observed stop, smallest change, expected signal, and check window. Do not promise lift before measurement.

### Repair measurement

Choose repair when the journey exists but missing events, properties, attribution, identity boundaries, or join fields block the decision. Name the exact field or event, every downstream step that needs it, and the privacy boundary.

### Wait

Choose wait when test activity dominates, the sample is too thin, or the behavior does not repeat. Name the no-change decision and the specific trigger for reviewing it again.

Then write one growth task that answers:

- What was wrong?
- What will change?
- Why should it help?
- How will the result be checked?

The task must make sense without reopening PostHog.

## Copy-ready review checklist

- [ ] Define the surface, source or segment, success event, window, and no-change condition.
- [ ] Verify the required events and the properties that connect later steps.
- [ ] Separate public acquisition, partner traffic, signed-in use, and internal or test activity.
- [ ] Read the ordered journey before and after the target step, not only the aggregate count.
- [ ] Use session replay only when the decision depends on what appeared on screen, with privacy controls in place.
- [ ] Apply an evidence threshold that matches the change: hard failure, repeated stop, missing measurement, or a thin clue.
- [ ] Choose one output: ship a focused change, repair measurement, or wait for a defined pattern to repeat.
- [ ] Write the task so the problem, change, reason, and observable result are clear without reopening PostHog.

## Output format

Return:

## PostHog growth review

First sentence: the decision and why the evidence supports it.

- Decision contract: surface, segment, success event, window, and no-change condition.
- Measurement health: events and properties trusted, missing, or ambiguous.
- Journey evidence: the smallest anonymized set of counts and ordered paths that changes the call.
- Replay evidence: what was visibly observed, or why replay was unnecessary or unavailable.
- Outcome: ship, repair, or wait.
- Growth task: problem, change, reason, done condition, expected signal, and check window.
- Limits: thin sample, exclusions, missing fields, or other uncertainty.

If a pull request was explicitly requested and opened, include its link and whether checks are passing, failing, running, or unreadable. Never describe a PR as deployed.

## Authoritative sources

Tin Computer's seven-step method and copy-ready checklist:
https://tin.computer/learn/posthog-review-process

PostHog documentation for the product concepts used by the method:

- Events and properties: https://posthog.com/docs/data/events
- Sending events: https://posthog.com/docs/getting-started/send-events
- Product analytics best practices: https://posthog.com/docs/product-analytics/best-practices
- Funnels: https://posthog.com/docs/product-analytics/funnels
- Paths: https://posthog.com/docs/product-analytics/paths
- Session replay: https://posthog.com/docs/session-replay
- Replay privacy: https://posthog.com/docs/session-replay/privacy
- Retention: https://posthog.com/docs/product-analytics/retention

Continue with Tin Computer's free site scan:
https://tin.computer/scan/site?source=posthog_review_skill

Fetch the latest skill markdown:
https://tin.computer/skill/tin-posthog-growth-review.md