A PostHog review process that creates growth tasks

Tin Computer's PostHog review process starts with a decision, verifies the event stream, separates public acquisition from product and test activity, reconstructs real journeys, and ends with one of three outputs: ship a focused change, repair the measurement path, or wait because the evidence is too thin.

A dashboard can tell you that something happened. It cannot decide whether a page needs new copy, a handoff is broken, or a channel deserves more work. That decision comes from connecting the count to a source, an ordered journey, and the behavior before and after the apparent drop.

This is the process Tin uses when reviewing acquisition and product behavior for small software products. It is intentionally stricter than browsing charts for interesting movement. Every review begins with a question the team can answer and includes a condition for making no change.

Start with the decision, not the dashboard

The weak starting question is 'What are users doing?' It has no defined audience, success event, or action threshold. A useful question is narrower: 'Do public scan readers from direct traffic continue into workspace start?' or 'Do visitors from this partner path preserve their source through the report handoff?'

Write the decision as a sentence: We will decide whether to change a specific surface for a specific source based on whether a success event repeats in a defined window. Then add the no-change condition. That might be one real trace, a missing source property, a returning dashboard user mixed into acquisition, or a smoke test that proves the flow works but says nothing about demand.

Check whether the events can support the decision

PostHog defines events as captured actions or facts and properties as the metadata attached to them. Properties can be used to filter, break down, and connect behavior, but only if the instrumentation captures the fields the review needs. Before reading a funnel, Tin checks that the key events exist, appear on the expected surface, and still carry the relevant properties on later captured events.

• —Acquisition source or campaign, such as direct, organic, pricing, comparison, referral, or partner.
• —Current URL or landing path, so the public surface can be separated from signed-in use.
• —A stable scan, report, project, or workspace key that connects steps across the handoff.
• —The meaningful downstream action: report shown, plan continued, workspace-start click, signup, workspace start, or return use.
• —A reliable way to exclude automation, local checks, obvious example data, and founder tests.

This check has changed real Tin decisions. In one anonymous partner review, the claim-page source appeared at entry but disappeared from later scan and workspace events. The page had created report activity, yet the channel could not be judged. The correct output was to carry the source through the journey, not rewrite the page from a broken funnel.

Segment by the job the session is doing

Raw totals mix several different jobs. A public visitor can show acquisition intent. A partner participant can show whether a promise travels through the handoff. A signed-in user can show activation or retention. An internal trace can prove that the event fires. Those sessions should not vote on the same product decision.

• —Public acquisition: homepage, pricing, comparison, learn pages, search, referrals, and direct visits.
• —Partner or campaign traffic: claim pages, campaign parameters, and partner identifiers.
• —Product use: dashboard, workspace, task, chat, invite, and returning signed-in activity.
• —Internal or test activity: local checks, automation, example domains, and obvious smoke tests.

A returning product user can be a good retention signal and the wrong reason to change the homepage. A smoke test can prove that attribution now survives the path and still say nothing about whether a channel works. Labeling the job of each session prevents a healthy product-use trace from disguising a weak acquisition sample.

Use funnels, paths, and event sequences for different questions

A funnel is useful when the steps and success event are already defined. PostHog's funnel analysis measures conversion between selected events and surfaces the step where people drop. A report view can therefore be treated as early intent while a later workspace start remains the meaningful activation step.

A path or ordered event sequence answers a different question: what happened before and after that step? Tin follows the landing surface, source, first action, report or product step, stop point, later return, and whether another person from the same source repeated the pattern. PostHog's paths documentation describes this as exploring the routes people take through events and pages.

One recent anonymous review showed a public report path reaching the handoff and plan-continue step, then stopping before a workspace-start click or signup. That was not enough to justify another copy change. The sequence proved the route was readable and identified the next event to watch. The output was to keep the flow unchanged until a real public pattern repeated.

When a full replay-based review is worth the extra work

Event sequences show that people stopped. Session replay can show the visible conditions around the stop. Tin uses replay when the decision depends on whether the person saw the action, hit an error, waited on a loading state, looped between screens, or repeatedly returned to the same control.

A full replay-based review is stricter than opening a recording that looks interesting. First classify the candidate sessions as abandonment, confusion, errors, or successful completion. Then watch the worst few examples before calling the issue a growth loss. Confusion inside a session that still reaches the goal is lower priority than the same confusion followed by abandonment.

Replay is observational. It does not reveal why someone left, and it should not be used to infer private intent. PostHog provides privacy controls for masking inputs and text. Tin also strips names, domains, session links, thread identifiers, and customer-specific details from public examples. The public artifact describes the pattern, not the person.

Use an evidence threshold that matches the change

A universal minimum session count is the wrong rule. One real person hitting a hard error or dead end may be enough to justify a fix. A missing property on one connected journey can be enough to justify instrumentation repair. Copy, onboarding, and funnel changes usually need repeated behavior from the same source or segment because those changes interpret preference rather than remove a confirmed failure.

• —Hard failure: ship the smallest fix and verify the blocked path.
• —Repeated stop at the same step from the same source: ship a focused change.
• —Missing source or join fields: repair measurement before judging the channel.
• —One interesting trace that does not repeat: record the clue and wait.
• —Confusion followed by success: keep it below repeated failed sessions in the queue.
• —A clean smoke test: treat it as instrumentation proof, not demand proof.

End with ship, repair, or wait

Ship when a repeated journey names a fixable obstruction. A strong task names the surface and source, the observed stop, the change, and the event that should move. Tin once clarified a report action so the next workspace step was explicit and measurable. The review did not claim a conversion lift before one existed.

Repair measurement when a journey exists but the evidence cannot connect it. This is growth work when it prevents the next acquisition or activation decision from being wrong. The repair should name the exact property or journey key that must persist and every downstream event that needs it.

Wait when the sample is too thin, test activity dominates, or the pattern does not repeat. A no-change decision should name what would change the call. Waiting is not a vague follow-up. It is an instruction to preserve the current product until a defined leading indicator appears again.

Official PostHog sources used for this method

The ship, repair, or wait framework is Tin Computer's operating method. The product concepts below are documented by PostHog and support the technical parts of the process.

Run the process on one decision

Choose one live question, not the whole dashboard. Write the success event and no-change condition, verify the properties, split the traffic jobs, and reconstruct the smallest useful set of journeys. If the evidence supports a change, cut it to one reviewable task. If it does not, say exactly what needs to repeat or be repaired before the product moves.