Docs

PostHog Android Rage Tap and Dead Tap Tracking

PostHog Android interaction signals detect rage taps and dead taps without session replay. Learn which properties to track and how to act on them.

Engagement

Most Android teams only learn that a screen is frustrating when ratings drop or support tickets arrive. By then the damage is done. A button that looks tappable but does nothing, or a slow control that users hammer five times in a row, never shows up as a crash, so standard crash and performance dashboards stay green while users quietly leave.

On 25 September 2026, PostHog’s changelog introduced Android interaction signals. Apps can now opt into semantic autocapture of taps on View and Compose elements, plus frustration signals for rage taps and likely dead taps, without switching on session replay. That matters because replay carries bandwidth, storage and privacy costs that many teams are not willing to pay just to find broken controls.

Without this kind of signal, you are guessing. You fix what is loud, not what is hurting conversion.

Data Points to Track

  • Tap target identity: the element’s label, type (View or Compose), screen name and a stable identifier, so you can group taps by control rather than by coordinates
  • Rage tap count: number of rage-tap events per control, per screen and per app version
  • Dead tap count: taps on controls that produced no visible response, with the screen and control they happened on
  • Rage tap rate: rage taps divided by total taps on that control, so busy screens do not dominate the ranking
  • Session context: app version, OS version, device model and network type at the time of the signal
  • Follow-on behaviour: whether the user retried, navigated back, or left the app within 30 seconds of the signal

Setup Steps

  1. Upgrade the PostHog Android SDK to a release that includes interaction signals and check the changelog for the exact configuration flag.
  2. Opt in to interaction autocapture and frustration signals in your SDK configuration, leaving session replay off if you do not need it.
  3. Label important controls. Give Compose and View elements meaningful content descriptions or test tags so events carry readable names.
  4. Review privacy metadata. Confirm that captured labels contain no personal data, and exclude sensitive screens such as payment or health forms.
  5. Build an insight that ranks controls by rage tap rate and dead tap count, filtered by app version.
  6. Set an alert for any control whose rage tap rate jumps after a release.

Actionable Insights

Dead taps point to broken or misleading interfaces: a disabled-looking button that is actually active, a tap target that is too small, or a handler that fails silently. Fix these first, because the user gets no feedback at all.

Rage taps usually indicate latency. If the same control shows rage taps and slow response times in your performance data, add a loading state or optimistic update before you touch the backend.

Compare signals by app version. A spike after a release is a regression you can trace to a specific change. Finally, join frustration signals to your funnel: a control with a high rage tap rate that sits on your checkout or sign-up path deserves priority over one in settings.

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