A product team installs analytics because it wants to know what users are doing. The installation is real progress. Events begin arriving, funnels become visible and sessions can be replayed. But a subtle substitution often follows: the team starts treating what the system captured as the complete shape of what matters.
That is not a failure of the analytics product. It is a category mistake. Analytics is a sensor. The UX function decides what should be sensed, relates the reading to customer and business context, chooses the right method when behaviour cannot answer the question, and turns the result into an action.
The instrumentation gap comes before the insight gap
Suppose a team wants to understand why new accounts fail to reach first value. A funnel may show a drop between setup and completion. That still leaves several different possibilities: the completion event may be wrong, the setup event may fire too early, the account grain may hide the person who actually owns the task, or the measured behaviour may be correct but unable to explain intent.
These possibilities are not interchangeable. A missing event, a measured zero and an insufficient sample should produce different product states. If a system collapses them into the same number, its apparent precision makes the decision less safe.
Before asking what the metric means, establish whether the metric exists in the form the decision requires.
Behaviour needs context
Behavioural evidence becomes more useful when it can be related to the account, the commercial relationship, the customer’s stated intent and the change that shipped. A twelve-point drop may be a comprehension problem, a service hand-off, a billing constraint or a deliberate choice by a particular customer segment.
No single source should be forced to answer every part of that question. The useful move is to retain the contribution and limitation of each source, then route the remaining uncertainty through the right UX discipline.
- Product analytics can describe observed behaviour.
- Commercial context can show which accounts or revenue are exposed.
- The repository can show what changed and re-arm an old assumption.
- Research can address intent, comprehension and meaning.
- Interaction design can explain avoidable effort in the flow.
- Service design can expose the operational hand-off behind the screen.
The missing step is action
Even a correct analysis can terminate too early. The team receives a finding, discusses it in a meeting and returns to the roadmap. The assumption that began the work, the downside of the recommendation and the intended outcome gradually separate.
A UX operating system should keep that chain intact. It should show what the team believed, which evidence changed the read, what action was approved, who owns implementation and when the result will be reviewed. A null or negative outcome belongs in the record just as much as a win.
PostHog and Sightspool should complement each other
Sightspool is not an argument against PostHog. PostHog is a first-class behavioural source in the product. Rebuilding replay, funnels, dashboards or survey delivery would be wasteful and would weaken both products.
The distinction is responsibility. PostHog helps the team capture and inspect behaviour. Sightspool establishes whether the signal can answer the question, joins it to other approved context, routes the uncertainty through the UX studio, creates an evidence-backed action and watches what happens after it ships.
The sensor matters. So does the function that decides where to point it.