Docs

PostHog Replay Vision Frustration Tracking

PostHog Replay Vision scores user frustration in session replays. Learn which event properties to track so AI findings become measurable fixes.

Engagement

Most teams that record sessions never watch more than a handful of them. Thousands of recordings pile up, the worst experiences stay buried, and the people who suffered through a broken screen simply leave. Reviewing replays by hand does not scale, and a replay you never watch is not telling you anything.

On 3 August 2026, PostHog announced that Replay Vision is generally available on paid plans. It applies AI to session recordings to flag likely bugs, score how frustrated a user appeared, tag behaviours and write a short summary of each session. Frustration scoring is based on signals such as rage clicks, dead clicks and repeated interactions.

Why This Matters

An AI score is a prompt to investigate, not a verdict. Without a measurement plan around it, you cannot tell whether a high-frustration session reflects a real defect, whether your fix worked, or whether the score is simply noisy for your product. Teams that skip this step end up with a list of flagged sessions and no evidence that anything improved.

The goal is to join what the AI sees in the replay with the events your own code already records, so you can check it against hard numbers.

Data Points to Track

Add these as properties on your own events, or record them in your warehouse alongside the replay session ID:

  • replay_session_id: links an event stream to the recording that was analysed
  • frustration_score: the score Replay Vision assigned to the session
  • frustration_band: low, medium or high, based on thresholds you set
  • screen_name: the screen where the frustration signal appeared
  • rage_tap_count: repeated rapid taps on one element in the session
  • dead_tap_count: taps that produced no visible response
  • ai_flagged_bug: true or false, whether a bug was flagged
  • app_version: the release the user was running
  • session_converted: whether the user finished the goal they started
  • session_ended_on_screen: where the session finished, to spot abandonment

Setup Steps

  1. Confirm session replay is enabled for your mobile or web app and that sensitive fields are masked before you analyse anything.
  2. Enable Replay Vision on a paid plan and start with one high-value flow, such as sign-up or checkout.
  3. Log rage_tap_count and dead_tap_count yourself in your own events, so you have a baseline that does not depend on the AI.
  4. Store the replay_session_id against your own session events so the two can be joined.
  5. Export or record the frustration score and band for each analysed session.
  6. Build a report showing frustration band by screen_name and app_version.
  7. After each release, compare the share of high-frustration sessions with the previous version.

Actionable Insights

Cross-check the score with your own counts. If high-frustration sessions also have high rage_tap_count, the score is behaving sensibly for your app. If they do not line up, treat the score with caution.

Rank screens, not sessions. A single bad session is an anecdote. Ten high-frustration sessions on the same screen is a priority.

Measure the fix. After you ship a change, the share of high-frustration sessions on that screen should fall, and session_converted should rise. If only one of them moves, look again.

Watch the false alarms. Flagged bugs that turn out to be intended behaviour are worth recording, because they show where the AI misreads your interface.

Respect privacy. Replays can capture personal information. Mask inputs, state your purpose in your privacy notice, and keep retention short.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert